02-Pod-2

Pod，而不是容器，才是 Kubernetes 项目中的最小编排单位。将这个设计落实到 API 对象上，容器（Container）就成了 Pod 属性里的一个普通的字段。

那么问题来了：

  • 到底哪些属性属于 Pod 对象，
  • 而又有哪些属性属于 Container 呢？

Pod 扮演的是传统部署环境里“虚拟机”的角色。这样的设计，是为了使用户从传统环境（虚拟机环境）向 Kubernetes（容器环境）的迁移，更加平滑。

如果把 Pod 看成传统环境里的“机器”、把容器看作是运行在这个“机器”里的“用户程序”，那么很多关于 Pod 对象的设计就非常容易理解了。

比如，凡是调度、网络、存储，以及安全相关的属性，基本上是 Pod 级别的。

这些属性的共同特征是，它们描述的是“机器”这个整体，而不是里面运行的“程序”。比如:

  1. 配置这个“机器”的网卡（即：Pod 的网络定义），
  2. 配置这个“机器”的磁盘（即：Pod 的存储定义），
  3. 配置这个“机器”的防火墙（即：Pod 的安全定义），
  4. 这台“机器”运行在哪个服务器之上（即：Pod 的调度）。

0.1. Pod 中几个重要字段

0.1.1. NodeSelector

是一个供用户将 Pod 与 Node 进行绑定的字段，用法如下所示：

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

这样的一个配置，意味着这个 Pod 永远只能运行在携带了“disktype:ssd”标签（Label）的节点上；否则，它将调度失败。

0.1.2. NodeName

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

所以，这个字段一般由调度器负责设置，但用户也可以设置它来“骗过”调度器，当然这个做法一般是在测试或者调试的时候才会用到。

0.1.3. HostAliases

定义了 Pod 的 hosts 文件（比如 /etc/hosts）里的内容，用法如下：

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

在这个 Pod 的 YAML 文件中，设置了一组 IP 和 hostname 的数据。这样，这个 Pod 启动 后，/etc/hosts 文件的内容将如下所示：

cat /etc/hosts
# Kubernetes-managed hosts file.
127.0.0.1 localhost
...
10.244.135.10 hostaliases-pod
10.1.2.3 foo.remote
10.1.2.3 bar.remote

其中，最下面两行记录，就是通过 HostAliases 字段为 Pod 设置的。

需要指出的是：

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

除了上述跟“机器”相关的配置外，凡是跟容器的 Linux Namespace 相关的属性，也一定是 Pod级别的。

Pod的设计，就是要让它里面的容器尽可能多地共享 Linux Namespace，仅保留必要的隔离和限制能力。这样，Pod模拟出的效果，就跟虚拟机里程序间的关系非常类似了。

举个例子，在下面这个 Pod 的 YAML 文件中，定义 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

这就意味着这个 Pod 里的容器要共享 PID Namespace。

而在这个 YAML 文件中，还定义了两个容器：一个是 nginx 容器，一个是开启了 tty 和 stdin 的shell 容器。在 Pod 的 YAML 文件里声明开启它们俩，其实等同于设置了 docker run 里的 -it（-i 即 stdin，-t 即 tty）参数。

可以直接认为 tty 就是Linux给用户提供的一个常驻小程序，用于接收用户的标准输入，返回操作系统的标准输出。当然，为了能够在 tty 中输入信息，你还需要同时开启 stdin（标准输入流）。

这个 Pod 被创建后，就可以使用shell容器的tty跟这个容器进行交互了。

0.1.3.1. 例子

kubectl create -f nginx.yaml      //上一节创建的yaml文件

kubectl attach -it nginx -c shell     //使用kubectl attach 命令，连接到shell容器的tty上

kubectl attach -it nginx -c shell
# ps ax
PID   USER     TIME  COMMAND
    1 root      0:00 /pause
    8 root      0:00 nginx: master process nginx -g daemon off;
   14 101       0:00 nginx: worker process
   15 root      0:00 sh
   21 root      0:00 ps ax

在这个容器里，我们不仅可以看到它本身的 ps ax 指令，还可以看到 nginx 容器的进程，以及 Infra容器的 /pause 进程。这就意味着，整个 Pod 里的每个容器的进程，对于所有容器来说都是可见的：它们共享了同一个 PID Namespace。

类似地，凡是 Pod 中的容器要共享宿主机的 Namespace，也一定是Pod级别的定义，比如:

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

在这个 Pod 中，定义了共享宿主机的 Network、IPC 和 PID Namespace。这就意味着，这个Pod 里的所有容器:

  1. 会直接使用宿主机的网络、
  2. 直接与宿主机进行IPC通信、
  3. 看到宿主机里正在运行的所有进程。

当然，除了这些属性，Pod 里最重要的字段当属“Containers”了。

"container"与“Init Containers”。其实，这两个字段都属于Pod对容器的定义，内容也完全相同，只是 Init Containers 的生命周期，会先于所有的Containers，并且严格按照定义的顺序执行。

Kubernetes 项目中对 Container 的定义，和 Docker 相比并没有什么太大区别。

容器技术概念中：

  • Image（镜像）
  • Command（启动命令）
  • workingDir（容器的工作目录）
  • Ports（容器要开放的端口）
  • 以及 volume Mounts（容器要挂载的 Volume）

都是构成 Kubernetes 项目中 Container 的主要字段。

不过在这里，还有这么几个属性值得额外关注。

  1. 首先，是 ImagePullPolicy 字段。它定义了镜像拉取的策略。而它之所以是一个 Container 级别的属性，是因为容器镜像本来就是 Container 定义中的一部分。 ImagePullPolicy 的值默认是Always，即每次创建Pod都重新拉取一次镜像。另外，当容器的镜像是类似于 nginx 或者 nginx:latest 这样的名字时，ImagePullPolicy 也会被认为 Always。而如果它的值被定义为 Never 或者 IfNotPresent，则意味着 Pod 永远不会主动拉取这个镜像，或者只在宿主机上不存在这个镜像时才拉取。

  2. 其次，是 Lifecycle 字段。它定义的是 Container Lifecycle Hooks。顾名思义，Container Lifecycle Hooks 的作用，是在容器状态发生变化时触发一系列“钩子”。

我们来看这样一个例子：

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"]

这是一个来自 Kubernetes 官方文档的 Pod 的 YAML 文件。它其实非常简单，只是定义了一个 nginx 镜像的容器。不过，在这个 YAML 文件的容器（Containers）部分，你会看到这个容器分别设置了一个 postStart 和 preStop 参数。

  • postStart ，它指的是，在容器启动后，立刻执行一个指定的操作。需要明确的是， postStart 定义的操作，虽然是在 Docker 容器 ENTRYPOINT 执行之后，但它并不严格保证顺序。

也就是说，在 postStart 启动时，ENTRYPOINT 有可能还没有结束。 当然，如果 postStart 执行超时或者错误，Kubernetes 会在该 Pod 的 Events 中报出该容器启动失败的错误信息，导致 Pod 也处于失败的状态。

  • preStop 发生的时机，则是容器被杀死之前（比如，收到了 SIGKILL 信号）。preStop操作的执行，是同步的。所以，它会阻塞当前的容器杀死流程，直到这个 Hook定义操作完成之后，才允许容器被杀死，这跟 postStart 不一样。

所以，在这个例子中，我们在容器成功启动之后，在 /usr/share/message 里写入了一句“欢迎信息”（即postStart定义的操作）。而在这个容器被删除之前，我们则先调用了 nginx 的退出指令（即 preStop 定义的操作），从而实现了容器的“优雅退出”。

0.2. Pod 生命周期

Pod 对象在 Kubernetes 中的生命周期。Pod 生命周期的变化，主要体现在 Pod API 对象的Status 部分，这是它除了 Metadata 和 Spec 之外的第三个重要字段。其中，pod.status.phase，就是 Pod的当前状态，它有如下几种可能的情况：

  1. Pending。这个状态意味着，Pod 的 YAML 文件已经提交给了 Kubernetes，API 对象已经被创建并保存在 Etcd 当中。但是，这个 Pod 里有些容器因为某种原因而不能被顺利创建。比如，调度不成功。
  2. Running。这个状态下，Pod已经调度成功，跟一个具体的节点绑定。它包含的容器都已经创建成功，并且至少有一个正在运行中。
  3. Succeeded。这个状态意味着，Pod 里的所有容器都正常运行完毕，并且已经退出了。这种情况在运行一次性任务时最为常见。
  4. Failed。这个状态下,Pod 里至少有一个容器以不正常的状态（非 0 的返回码）退出。这个状态的出现，意味着得想办法 Debug 这个容器的应用，比如查看 Pod 的 Events 和日志。
  5. Unknown。这是一个异常状态，意味着 Pod 的状态不能持续地被 kubelet 汇报给 kubeapiserver，这很有可能是主从节点（Master和 Kubelet）间的通信出现了问题。

Pod 对象的 Status 字段，还可以再细分出一组 Conditions。这些细分状态的值包括：

  • PodScheduled
  • Ready
  • Initialized
  • Unschedulable

它们主要用于描述造成当前Status 的具体原因是什么。

比如，Pod 当前的 Status 是 Pending，对应的 Condition 是Unschedulable，这就意味着它的调度出现了问题。

而其中，Ready 这个细分状态非常值得我们关注：它意味着 Pod 不仅已经正常启动（Running 状态），而且已经可以对外提供服务了。Running和Ready是有区别的。

Pod 的这些状态信息，是我们判断应用运行情况的重要标准，尤其是 Pod 进入了非“Running”状态后，一定要能迅速做出反应，根据它所代表的异常情况开始跟踪和定位，而不是去手忙脚乱地查阅文档。

对于 Pod 状态是 Ready，实际上不能提供服务的情况能想到几个例子：

  1. 程序本身有 bug，本来应该返回 200，但因为代码问题，返回的是500；
  2. 程序因为内存问题，已经僵死，但进程还在，但无响应；
  3. Dockerfile 写的不规范，应用程序不是主进程，那么主进程出了什么问题都无法发现；
  4. 程序出现死循环。
上次修改: 14 April 2020