【云原生|探索 Kubernetes 系列 8】探究 Pod 的 API 对象属性级别与重要字段用法

前言

大家好，我是秋意零。

本专栏上一篇中，我们介绍了 Pod 的核心思想以及 Pod 的工作原理。今天我们还是探讨 Pod ，聊一聊 Pod 的基本概念。

简介

• 个人主页： 秋意零
• 个人介绍：在校期间参与众多云计算相关比赛，如： “省赛”、“国赛”，并斩获多项奖项荣誉证书
• 目前状况：24 届毕业生，拿到一家私有云（IAAS）公司 offer，暑假开始实习
• 账号：各个平台， 秋意零 账号创作者、 云社区 创建者
• 欢迎大家：欢迎大家一起学习云计算，走向年薪 30 万

系列文章目录

---

【云原生|探索 Kubernetes 系列 1】容器的本质是进程
【云原生|探索 Kubernetes 系列 2】容器 Linux Cgroups 限制
【云原生|探索 Kubernetes 系列 3】深入理解容器进程的文件系统
【云原生|探索 Kubernetes 系列 4】现代云原生时代的引擎
【云原生|探索 Kubernetes 系列 5】简化 Kubernetes 的部署，深入解析其工作流程
【云原生|探索 Kubernetes 系列 6】从 0 到 1，轻松搭建完整的 Kubernetes 集群
【云原生|探索 Kubernetes 系列 7】探究 Pod 有什么用，为什么需要它

---

正文开始：

• 快速上船，马上开始掌舵了（Kubernetes），距离开船还有 3s，2s，1s…

一、Pod 生命周期

首先，我们来介绍一下 Pod 的生命周期，如图：

• Infra ：首先容器环境初始化由 Infra 容器负责（共享网络和卷）；
• Init C：接着到达 initContainer 容器，Init C 容器的执行顺序严格根据自己定义的顺序保持一致，并且在 Main C 主容器（也就是 Containers）之前执行；Init C 只有执行成功才会执行下一个 Init C，都执行成功才会到 Main C 主容器。
• Start ：在 Main C 主容器之前，还有一个 START 操作，是在 Main C 主容器启动时执行的，类似 Docker 的 ENTRYPROINT。
• Rediness：就绪检测，可以是检测 Pod 里的服务启动没，不仅仅是 Pod Running 了，因为即使是 Pod Running 了，里面服务没有启动也是没有意义的。比如：检测 Web 服务是否能正常访问了，如果正常，那么 Pod 状态才 Running。
• Liveness：存活检测。还是以 Web 服务为例，如果我们容器在运行过程中，这个 Web 服务挂了，导致 Web 服务无法访问，那么这个时候我们也不能把这个 Pod 视为正常运行的 Pod，而 Liveness 存活检测，就是为了预防这种情况发生。如：我们可以设置每隔多久就检测一次 Web 服务是否正常，如果不正常就会导致 Pod 重新启动（No Running 状态）。
• Stop：Stop 发生的时机，则是容器被杀死之前（比如，收到了 kill 信号），而需要明确的是，Stop 操作的执行，是与 kill 信号同步的。所以，它会阻塞当前的容器杀死流程，直到这个 Stop 定义操作完成之后，才允许容器被杀死。

Pod 状态

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

• Pending：挂起等待状态。Pod 的 YAML 文件已经提交给了 Kubernetes，API 对象已经被创建并保存在 Etcd 当中。但是因为某些原因，调度不成功，不能被顺利创建。
• Running：正在运行状态。Pod 已经与节点绑定，并调度成功。Pod 中容器创建成功，并至少有一个容器正在运行中。
• Succeeded：运行成功状态。Pod 里面的容器都正常运行完毕，并且已经正常退出了。
• Failed：失败状态。Pod 里至少有一个容器以不正常的状态（非 0 的返回码）退出。这个一般需要查看 Pod 的 Events 和日志解决。
• Unknown：未知状态（异常状态）。 Pod 的状态不能持续地被 kubelet 汇报给 kube-apiserver，这很有可能是主从节点（Master 和 Kubelet）间的通信出现了问题。

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

二、如何区分 Pod 的 API 对象属性级别

Pod 中包含了容器。那么，我们怎么在写 YAML 文件时，怎么区分 Pod 这个 API 对象中，那些是 Pod 属性里的字段，那些是 containers（容器）属性里的字段呢？

其实，我们可以形象的把虚拟机里面的属性，如：内存、磁盘、网络 等资源，对应到 Pod 中，这样 Pod 就是扮演的 “虚拟机” 的角色。但是，不要把我们本专栏文章中的第 4 篇，提到的 Kubernetes 比作 “操作系统” 的概率混淆。

• Kubernetes 比作 “操作系统”，这个概念是 “宿主机” 的概念，而 Pod 是宿主机虚拟出来的 “虚拟机” 的概念。
• 就好比，我们自己 Windosws 电脑中，安装了 VMware 虚拟化软件，在这个虚拟软件中又安装了一个 CentOS 系统一样。

所以，你把 Pod 看作是 “虚拟机”，把容器还是看做虚拟机里面的 “程序进程”，这样 Pod 的 API 对象里面的属性字段，那些是 Pod 属性里的，那些是 containers（容器）属性里的，就能一清二楚了。

结论：凡是和网络、存储、CPU、内存、调度这种虚拟机操作系统 “机器” 相关的，那么一般都是 Pod 级别的属性。

• 比如：配置 Pod 网络（虚拟机网卡）、配置 Pod 存储（虚拟机磁盘）、配置 Pod 在 Kuberentes 集群中那个 Node 计算节点运行（调度）。

三、重要字段用法

Kubernetes 中有个很重要概率 “标签”：

• “标签” 是由 Key=Value 键值对组成，它是为了标识某个对象（即：Node、Pod、Service、Job 等）。如果我们为某两个对象打了同样的 “标签”，那么它们之前是可以通过“标签” 来与之关联和选择某个对象的依据。
• 比如：一个 Pod 和 Service 对象，都打了 web: app （YAML 文件中的格式）标签，那么它们之间就关联起来了，这样我们访问 Service 的 虚拟 IP 时，就相当于在访问这个 Pod。

节点选择 NodeSelector

NodeSelector 是 Pod 去找对应 Node 计算节点与之绑定的字段，用法如下：

• 1.首先，我们查看 Node 节点标签。

这里也可以自己为 Node 节点打标签，命令：kubectl label。

kubectl get node --show-labels=true

在 Pod 中，spec.nodeSelector 字段下写上 kubernetes.io/hostname: worker01 ，那么这个 Pod 在运行之前进入调度队列时，就一定会在 worker01 节点运行，如果这个标签或者节点不存在，那么 Pod 就一直处于挂起状态并调度失败，否则则调度成功。

cat > web-qyl.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: web
  name: web
spec:
  nodeSelector:
    kubernetes.io/hostname: worker01  
  containers:
  - image: nginx
    name: nginx
    imagePullPolicy: IfNotPresent
EOF

• 2.运行 Pod，并查看 Pod 详细信息（-o wide 是详细输出）。

kubectl apply -f web-qyl.yaml
kubectl get pod -o wide

节点选择（手动）NodeName

NodeName 字段，手动将对象调度到 NodeName 所指定的节点名称上。

这个指其实是 kube-scheduler 组件负责设置赋值的。调度和创建过程：

• 这时有个 Pod 需要创建，首先 kube-scheduler 会监听 kube-apiserver 的消息，发现 Pod 的创建请求，这时 kube-scheduler 会检查 NodeName 字段是否为空，为空就代表没有被调度；
• 这时根据 Pod 的调度策略，还是更具 kube-schedule r默认的调度策略来调度到对应的 Node 节点上，选中一个 Node 节点后，kube-scheduler 会为 NodeName 字段赋值对应节点名称；
• 然后把 Pod 定义资源存回 kube-apiserver，kube-apiserver 会通知 kubelet 创建运行 Pod，然后再通过 kube-apiserver 把 Pod 状态信息给 Etcd 存储起来。

这样就完成了整个调度和创建过程。

总结：所以，我们这里直接使用 NodeName 字段为其赋了值，那么 kube-scheduler 判断 NodeName 这个值是否为空时，发现有值，那么这个调度过程就是完成了的。

主机名 IP 映射 HostAliases

HostAliases 是定义了 Pod 的 /etc/hosts 文件中的内容，用法如下：

cat > hostaliases-qyl.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: hostaliases-qyl
  name: hostliases-qyl
spec:
  hostAliases:
  - ip: "192.168.200.1"
    hostnames:
    - "vm1.com"
    - "vm2.com"
  - ip: "192.168.200.2"
    hostnames:
    - "vm.com"
  containers:
  - image: busybox
    name: busybox
    imagePullPolicy: IfNotPresent
    command: [ "/bin/sh", "-c", "sleep 3600" ]
EOF

上诉中，我们在 spec.hostAliases 字段下，写了两组 ip 和 hostnames 的配置。我运行 Pod 后，查看 /etc/hosts 文件内容：

• 可以看到，我框出的内容，就是 spec.hostAliases.ip.hostnames 设置的内容；
• 在 Kubernetes 中，要配置 hosts 文件，一定要通过这种方式。因为如果，你进入 Pod 中的容器修改，那么 Pod 被删除或者重建后，这个 hosts 文件内容也会变成最初默认内容，非常麻烦。

kubectl apply -f hostaliases-qyl.yaml
kubectl get -f hostaliases-qyl.yaml -owide
kubectl exec -it pod/hostliases-qyl -- cat /etc/hosts

这里 spec.hostAliases 字段，也体现了跟 “虚拟机机器” 相关的配置外，也会发现，凡是跟容器的 Linux Namespace 相关的属性，也一定是 Pod 级别的。

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

这里，我们开启 shareProcessNamespace=true，意味着 Pod 里的容器要共享 PID Namespace ，举个例子：

cat > nginx-shell.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: shell-qyl
  name: shell-qyl
spec:
  shareProcessNamespace: true
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  - image: busybox
    name: busybox
    imagePullPolicy: IfNotPresent
    command: [ "/bin/sh", "-c", "sleep 3600" ]
EOF

kubectl apply -f nginx-shell.yaml

执行 ps 命令，查看进程：

• 这里，可以看到有我们容器中的 nginx 容器的 nginx -g daemon off;进程，和 busybox 容器 sleep 3600 进程，以及 Infra 容器的 /pause 进程；
• 这意味着 Pod 中每个容器进程，对于所有容器都是可见的；
  

总结：凡是跟容器的 Linux Namespace 相关的属性，也一定是 Pod 级别的。

容器列表 Containers

containers 可以算是 Pod 中最重要的字段了，本专栏。上一篇文章中（第 7 篇），我们提到了一个 containers 字段中的属性 initContainers ，这两个字段都是对 Pod 中容器的定义，定义的内容也完全相同，不同的是它们的启动顺序不同。initContainers 定义的容器，会在 containers 定义的容器之前运行，并严格按照定义的顺序执行。

containers 字段定义的内容就是为了创建容器的相关属性，比如：image（镜像）、ports（端口）、command（启动命令）、volumeMounts（挂载卷）、imagePullPolicy（镜像拉取策略）、name（容器名称）。

镜像拉取策略 ImagePullPolicy

imagePullPolicy 的取值有：

• 默认值是 Always（总是）：每次创建 Pod 都重新拉取一次镜像，不管你本地是否已经存在了该镜像；
• Never 或者 IfNotPresent：只在宿主机上不存在这个镜像时才拉取。

生命周期挂钩 Lifecycle

Lifecycle，它定义的是 Container Lifecycle Hooks（生命周期挂钩）。顾名思义，Container Lifecycle Hooks 的作用，是在容器状态发生变化时（如：启动、停止之前）触发一系列 “钩子” 。

我们来看个例子：

• postStart：在容器启动后，立刻执行一个指定的操作。如果 postStart 执行超时或者错误，Kubernetes 会在该 Pod 的 Events 中报出该容器启动失败的错误信息，导致 Pod 也处于失败的状态。
• preStop：容器被杀死之前（kill 命令）执行的操作，而需要明确的是，kill 命令 与 preStop 操作的执行，是同步的。所以，它会阻塞当前的容器杀死（kill）流程，直到这个 Hook 定义操作完成之后，才允许容器被杀死。

我们在容器成功启动之后，在 /usr/share/message 里写入了一句 “Hello World”。而在这个容器被删除之前，我们则先调用了 nginx 的退出指令，从而实现了容器的 “优雅退出”。

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

总结

今天介绍了，Pod 的基本概念。

重点说明了，Pod 的 API 对象属性字段，那些是属于 Pod 级别，那些是属于容器级别的。所以你应该了解了，能够区分大部分 Pod 的 API 对象属性字段的级别是什么。

之后介绍了，Pod 的一些常用字段的用法。