K8S架构

阅读目录

• 一、架构图
• 二、pod
• 三、k8s核心功能全景图
•  四、k8s编排逻辑

 

回到顶部

一、架构图

1.Mater
API-Server　　　　   : api接口调用,可以水平扩缩
Scheduler 　　　     : pod资源调度
Controller-manager  : 控制器，节点控制器、端点分片控制器、任务控制器、服务账号控制器

2.Etcd
集群键值对持久化数据存储地

3.Node
kubelet    管理pod的生命周期、网络空间、存储空间
kube-proxy 提供server为集群内服务发现和负载均衡
CNI(container networking interface) : 容器网络接口
CRI(container runtime interface)    : 容器运行时接口
CSI(container storage interface)    : 容器存储接口 
OCI(Open Container Initiative)      : 开放式容器协议

4.过程
kublet通过CRI接口调用container runtime启动一个容器镜像，container runtime通过调用OCI协议与linux os进行系统调用（操作 Linux Namespace 和 Cgroups 等）
k8s把docker当做最底层的容器运行时实现。

回到顶部

二、pod

 

 

Pod 里的所有容器，共享的是同一个 Network Namespace，并且可以声明共享同一个 Volume。
为了Pod 里的多个容器是对等关系，而不是拓扑关系。
在 Kubernetes 项目里，Pod 的实现需要使用一个中间容器，这个容器叫作 Infra 容器
在这个 Pod 中，Infra 容器永远都是第一个被创建的容器，而其他用户定义的容器，则通过 Join Network Namespace 的方式，与 Infra 容器关联在一起。
Infra镜像: k8s.gcr.io/pause 这个镜像是一个用汇编语言编写的、永远处于“暂停”状态的容器，解压后的大小也只有 100~200 KB 左右。
Pod 的生命周期只跟 Infra 容器一致，而与容器 A 和 B 无关。
容器的IP地址不固定，会变化，因此k8s给pod绑定一个service服务（IP等信息固定不变）。

pod和容器的属性区分:

把pod看成虚拟机,  凡是调度、网络、存储，以及安全相关的属性，基本上是 Pod 级别的。这些属性的共同特征是，它们描述的是“机器”这个整体，而不是里面运行的“程序”。比如，配置这个“机器”的网卡（即：Pod 的网络定义），配置这个“机器”的磁盘（即：Pod 的存储定义），配置这个“机器”的防火墙（即：Pod 的安全定义）。更不用说，这台“机器”运行在哪个服务器之上（即：Pod 的调度）。

status --pod生命周期变化

pod.status.phase  5种状态:pending、running、succeed、unkonwn、faild

NodeSelector

apiVersion: v1
kind: Pod
...
spec:
　　nodeSelector:
　　　　disktype: ssd

NodeName

一旦 Pod 的这个字段被赋值，Kubernetes 项目就会被认为这个 Pod 已经经过了调度，调度的结果就是赋值的节点名字。

HostAliases

需要指出的是，在 Kubernetes 项目中，如果要设置 hosts 文件里的内容，一定要通过这种方法。否则，如果直接修改了 hosts 文件的话，在 Pod 被删除重建之后，kubelet 会自动覆盖掉被修改的内容。

apiVersion: v1
kind: Pod
...
spec:
  hostAliases:
  - ip: "10.1.2.3"
    hostnames:
    - "foo.remote"
    - "bar.remote"
...

容器属性:

ImagePullPolicy

ImagePullPolicy 的值默认是 Always，即每次创建 Pod 都重新拉取一次镜像。另外，当容器的镜像是类似于 nginx 或者 nginx:latest 这样的名字时，ImagePullPolicy 也会被认为 Always。而如果它的值被定义为 Never 或者 IfNotPresent，则意味着 Pod 永远不会主动拉取这个镜像，或者只在宿主机上不存在这个镜像时才拉取。

Lifecycle

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
      preStop:
        exec:
          command: ["/usr/sbin/nginx","-s","quit"]

先说 postStart 吧。它指的是，在容器启动后，立刻执行一个指定的操作。需要明确的是，postStart 定义的操作，虽然是在 Docker 容器 ENTRYPOINT 执行之后，但它并不严格保证顺序。也就是说，在 postStart 启动时，ENTRYPOINT 有可能还没有结束。当然，如果 postStart 执行超时或者错误，Kubernetes 会在该 Pod 的 Events 中报出该容器启动失败的错误信息，导致 Pod 也处于失败的状态。而类似地，preStop 发生的时机，则是容器被杀死之前（比如，收到了 SIGKILL 信号）。而需要明确的是，preStop 操作的执行，是同步的。所以，它会阻塞当前的容器杀死流程，直到这个 Hook 定义操作完成之后，才允许容器被杀死，这跟 postStart 不一样。所以，在这个例子中，我们在容器成功启动之后，在 /usr/share/message 里写入了一句“欢迎信息”（即 postStart 定义的操作）。而在这个容器被删除之前，我们则先调用了 nginx 的退出指令（即 preStop 定义的操作），从而实现了容器的“优雅退出”。

-------------------------------------------------------------------------------------------------------------------------------------------------------------

pod对容器的定义字段: containers、init containers 

内容完全相同，只是 Init Containers 的生命周期，会先于所有的 Containers，并且严格按照定义的顺序执行

-------------------------------------------------------------------------------------------------------------------------------------------------------------

凡是跟容器的 Linux Namespace 相关的属性，也一定是 Pod 级别的,举例:共享PID Namespace

定义shareProcessNamespace=true

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  shareProcessNamespace: true
  containers:
  - name: nginx
    image: nginx
  - name: shell
    image: busybox
    stdin: true
    tty: true

 

回到顶部

三、k8s核心功能全景图

控制器模式: deployment、service、job、daemonset等

容器紧密协作           : container到pod

多个相同实例           : pod到deployment(replicas)

固定IP和负载均衡       : service
授权信息              : secret

Web 应用对数据库访问时需要 Credential（数据库的用户名和密码）Kubernetes 项目提供了一种叫作 Secret 的对象，它其实是一个保存在 Etcd 里的键值对数据。这样，你把 Credential 信息以 Secret 的方式存在 Etcd 里，Kubernetes 就会在你指定的 Pod（比如，Web 应用的 Pod）启动时，自动把 Secret 里的数据以 Volume 的方式挂载到容器里。这样，这个 Web 应用就可以访问数据库了。

一次性运行任务         : job（大数据任务）

描述每个宿主机上必须且只能运行一个副本的守护进程服务 : DaemonSet

定时任务              :CronJob

如此种种，正是 Kubernetes 项目定义容器间关系和形态的主要方法。

回到顶部

 四、k8s编排逻辑

首先，通过一个“编排对象”，比如 Pod、Job、CronJob 等，来描述你试图管理的应用；
然后，再为它定义一些“服务对象”，比如 Service、Secret、Horizontal Pod Autoscaler（自动水平扩展器）等。这些对象，会负责具体的平台级功能。
Kubernetes 项目为用户提供的不仅限于一个工具。它真正的价值，乃在于提供了一套基于容器构建分布式系统的基础依赖。