前言
大家好，我是秋意零。
本专栏上一篇中，我们介绍了 Pod 的核心思想以及 Pod 的工作原理。今天我们还是探讨 Pod ，聊一聊 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 的一些常用字段的用法。
