前言

大家好，我是秋意零。

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

👿 简介

在这里插入图片描述

系列文章目录

文章目录

前言
系列文章目录
一、Pod 生命周期
- Pod 状态
二、如何区分 Pod 的 API 对象属性级别
三、重要字段用法
总结

正文开始：

快速上船，马上开始掌舵了（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 节点标签。

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