Basic Concept

Pod是Kubernetes中的最小编排单位，凡是调度、网络、存储，以及安全相关的属性，基本上是Pod级别的。

Important Field

NodeSelector

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

  1. apiVersion: v1
  2. kind: Pod
  3. ...
  4. spec:
  5.   nodeSelector:
  6.     disktype: ssd

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

NodeName

一旦Pod的这个字段被赋值，Kubernetes项目就会被认为这个Pod已经经过了调度，调度的结果就是赋值的节点名字。所以，这个字段一般由调度器负责设置，但用户也可以设置它来“骗过”调度器，当然这个做法一般是在测试或者调试的时候才会用到。

HotAliases

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

apiVersion: v1
kind: Pod
metadata:
  name: host-pod
spec:
  containers:
  - name: test-pod-nginx
    image: nginx
  hostAliases:
  - ip: "10.1.2.3"
    hostnames:
    - "czk.com"
    - "czk.top"

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

$ kubectl exec -it host-pod -- /bin/sh
$ cat /etc/hosts
# Kubernetes-managed hosts file.
127.0.0.1    localhost
::1    localhost ip6-localhost ip6-loopback
fe00::0    ip6-localnet
fe00::0    ip6-mcastprefix
fe00::1    ip6-allnodes
fe00::2    ip6-allrouters
10.1.0.29    test-pod-host

# Entries added by HostAliases.
10.1.2.3    czk.com    czk.top

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

shareProcessNamespace

除了上述跟机器相关的配置外，凡是跟容器的Namespace相关的属性，也一定是Pod级别的。这个原因也很容易理解：Pod的设计，就是要让它里面的容器尽可能多地共享Linux Namespace，仅保留必要的隔离和限制能力。这样，Pod模拟出的效果，就跟虚拟机里程序间的关系非常类似了。

举个例子，在下面这个Pod的YAML文件中，定义shareProcessNamespace=true：

apiVersion: v1
kind: Pod
metadata:
  name: test-nginx-pod-1
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跟这个容器进行交互了。

$ kubectl create -f test-nginx-pod-1.yaml
$ kubectl attach -it test-nginx-pod-1 -c shell
/ # ps ax
PID   USER     TIME  COMMAND
    1 65535     0:00 /pause
    8 root      0:00 nginx: master process nginx -g daemon off;
   39 101       0:00 nginx: worker process
   40 101       0:00 nginx: worker process
   41 101       0:00 nginx: worker process
   42 101       0:00 nginx: worker process
   43 101       0:00 nginx: worker process
   44 101       0:00 nginx: worker process
   45 root      0:00 sh
   53 root      0:00 ps ax

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

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

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

在这个Pod中，定义了共享宿主机的Network、IPC和PID Namespace。这意味着，这个Pod里的所有容器，会直接使用宿主机的网络、直接与宿主机进行IPC通信、看到宿主机里正在运行的所有进程。

containers

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

ImagePullPolicy

它定义了镜像拉取的策略，是一个Container级别的属性，是因为容器镜像本来就是Container定义中的一部分。

有三个值：

  • Always：默认值，每次创建Pod都重新拉取一次镜像。
  • Never：Pod永远不会主动拉取这个镜像，或者只在宿主机上不存在这个镜像时才拉取。
  • IfNotPresent：宿主机上不存在这个镜像时才拉取。

Lifecycle

它定义的是Container Lifecycle Hooks，是在容器状态发生变化时出发一系列“钩子”。

如下是一个Kubernetes官方文档的Pod的YAML文件：

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"]
      preStop:
        exec:
          command: ["/usr/bin/nginx", "-s", "quit"]

在这个YAML文件中，容器分别设置了一个postStart和preStop参数。

postStart指的是，在容器启动后，立刻执行一个指定的操作。需要明确的是，postStart定义的操作，虽然是Docker容器ENTRYPOINT执行之后，但它并不严格保证顺序。也就是说，在postStart启动后，ENTRYPOINT有可能还没有结束。

当然，如果postStart执行超时或者错误，Kubernetes会在该Pod的Events中报出该容器启动失败的错误消息，导致Pod也处于失败的状态。

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

在上面的例子中，我们在容器启动成功之后，展示了欢迎信息。而在这个容器被删除之前，我们则先调用了nginx的退出指令，从而实现了容器的优雅退出。

:::info 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汇报给kube-apiserver，这很有可能是主从节点（Master和Kubelet）间的通信出现了问题。


    更进一步地，Pod对象的Status字段，还可以更细分出一组Conditions。这些细分状态的值包括：PodScheduled、Ready、Initialized，以及Unschedulable。它们主要用于描述造成当前Status的具体原因是什么。 :::

Advanced Usage

在Kubernetes中，有几种特殊的Volume，它们存在的意义不是为了存放容器里面的数据，也不是用来进行容器和宿主机之间的数据交换，而是为容器提供预先定义好的数据。

类型 说明
Secret 存储敏感信息
ConfigMap 存储配置信息
Downward API 共享POD信息
ServiceAccountToken 存储授权信息

另外，Kubernetes可以通过Probe对Pod进行健康检查，同时指定Pod恢复机制。

Secret

Secret的作用，是把Pod想要访问的加密数据，存放到Etcd中。
然后，就可以通过在Pod容器里挂在Volume的方式，访问到这些Secret里保存的信息了。

可以通过文件创建secret，例如：

$ kubectl create secret generic pass --from-file=./password.txt

也可以通过YAML构造一个secret对象：

# 生成base64编码的密钥
$ echo @Khighness | base64       
QEtoaWdobmVzcwo=
$ echo KAG1823 | base64
S0FHMTgyMwo=

# 编写secret的YAML
$ cat ./secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  user: QEtoaWdobmVzcwo=
  pass: S0FHMTgyMwo=

# 生成secret对象
$ kubectl create -f secret.yaml

编写Pod的YAML：

$ cat ./k-pod.yaml
apiVersion: v1
kind: Pod
metadata: 
  name: k-pod
spec:
  containers:
  - name: my-container
    image: busybox
    imagePullPolicy: IfNotPresent
    stdin: true
    tty: true
    volumeMounts:
    - name: my-pod-vol
      mountPath: "/my-pod-vol"
      readOnly: true
  volumes:
  - name: my-pod-vol
    projected:
      sources:
      - secret:
          name: mysecret

生成Pod对象并找到secret：

$ kubectl create -f ./k-pod.yaml

$ kubectl attach -it k-pod -c my-container
If you don't see a command prompt, try pressing enter.
/ # cat /my-pod-vol/user 
@Khighness
/ # cat /my-pod-vol/pass
KAG1823

ConfigMap

ConfigMap保存不需要加密的、应用所需的配置信息。
ConfigMap的用法几乎与Secret完全相同，可以通过.properties文件创建，也可以直接通过YAML创建。

可以通过.properties文件来创建ConfigMap：

# properties文件内容
$ cat kafka.properties 
metadata.broker.list=kafka01:9092,kafka02:9092,kafka03:9092
compression.codec=none
serializer.class=kafka.serializer.DefaultEncoder

# 创建ConfigMap
$ kubectl create configmap kafka-config --from-file=kafka.properties

# 查看ConfigMap保存的信息
$ kubectl get configmaps kafka-config -o json
{
    "apiVersion": "v1",
    "data": {
        "kafka.properties": "metadata.broker.list=kafka01:9092,kafka02:9092,kafka03:9092\ncompression.codec=none\nserializer.class=kafka.serializer.DefaultEncoder\n\n"
    },
    "kind": "ConfigMap",
    "metadata": {
        "creationTimestamp": "2022-03-04T08:30:52Z",
        "name": "kafka-config",
        "namespace": "default",
        "resourceVersion": "119280",
        "uid": "ec4c7fe8-105a-4999-98d6-297cfe286268"
    }
}

Downward API

Downward API的作用是让Pod里的容器能够直接获取到这个Pod API对象本身的信息。

比如，在下面的YAML中：

apiVersion: v1
kind: Pod
metadata:
  name: downwardapi
  labels:
    zone: us-est-coast
    cluster: test-cluster1
    rack: rack-22
spec:
  containers:
    - name: client-container
      image: k8s.gcr.io/busybox
      command: ["sh", "-c"]
      args:
      - while true; do
          if [[ -e /etc/podinfo/labels ]]; then
            echo -en '\n\n'; cat /etc/podinfo/labels; fi;
          sleep 5;
        done;
      volumeMounts:
        - name: podinfo
          mountPath: /etc/podinfo
          readOnly: false
  volumes:
    - name: podinfo
      projected:
        sources:
        - downwardAPI:
            items:
              - path: "labels"
                fieldRef:
                  fieldPath: metadata.labels

定义一个容器声明了一个projected类型的Volume。Volume的数据来源是Downward API，Downward API Volume，则声明了要暴露的Pod的metadata.labels信息给容器。

通过这样的声明方式，当前Pod的Labels字段的值，就会被Kubernetes自动挂在成为容器里的/etc/podinfo/labels文件。

创建这个Pod并查看日志：

$ kubectl create -f downwardapi.yaml
$ kubectl logs downwardapi
cluster="test-cluster1"
rack="rack-22"
zone="us-est-coast"

目前，Downward API支持的字段：

1. 使用fieldRef可以声明使用:
spec.nodeName - 宿主机名字
status.hostIP - 宿主机IP
metadata.name - Pod的名字
metadata.namespace - Pod的Namespace
status.podIP - Pod的IP
spec.serviceAccountName - Pod的Service Account的名字
metadata.uid - Pod的UID
metadata.labels['<KEY>'] - 指定<KEY>的Label值
metadata.annotations['<KEY>'] - 指定<KEY>的Annotation值
metadata.labels - Pod的所有Label
metadata.annotations - Pod的所有Annotation

2. 使用resourceFieldRef可以声明使用:
容器的CPU limit
容器的CPU request
容器的memory limit
容器的memory request

仅供参考，使用时可以查阅官方文档。

不过，需要注意的是，Downward API能够获取到的信息，一定是Pod里的容器进程启动之前就能够确定下来的信息。而如果想要获取Pod容器运行后才会出现的信息，比如，容器进程的PID，那就肯定不能使用Downward API了，而应该考虑在Pod里定义一个sidecar容器。

ServiceAccountToken

Service Account对象的作用，就是Kubernetes系统内置的一种服务账户，它是对Kubernetes进行权限分配的对象。

像这样的Service Account的授权信息和文件，实际上保存在它所绑定的一个特殊的Secret对象里的，即ServiceAccountToken。任何运行在Kubernetes集群上的应用，都必须使用这个ServiceAccountToken里保存的首选信息，也就是Token，才可以合法访问API Server。

Probe

在Kubernetes中，可以为Pod里的容器定义一个健康检查“探针”（Probe）。这样，kubelet就会根据这个Probe的返回值决定这个容器的状态，而不是直接以容器镜像是否运行（来自Docker返回的信息）作为依据。这种机制，是生产环境中保证应用健康存活的重要手段。

比如下面Kubernetes官方文档的一个例子，定义了健康检查规则（livenessProbe）：cat /tmp/healthy，如果这个文件存在，那么该命令返回结果为0，Pod就会认为容器是健康的。这个健康检查在容器启动5S后开始执行（initialDelaySeconds），每5S执行一次（periodSeconds）。

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-demo
spec:
  containers:
  - name: liveness-container
    image: busybox
    args: 
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

下面进行实践：

# 创建这个Pod
$ kubectl create -f liveness-demo.yaml 
pod/liveness-demo created
# 查看Pod的状态
$ kubectl get pod
NAME            READY   STATUS    RESTARTS   AGE
downwardapi     1/1     Running   0          40m
liveness-demo   1/1     Running   0          8s
nginx           1/1     Running   0          20m
# 等待一段时间后，查看Pod的Events
$ kubectl describe pod liveness-demo
Events:
  Type     Reason     Age                 From               Message
  ----     ------     ----                ----               -------
  Warning  Unhealthy  2s (x4 over 76s)    kubelet            Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
# 再从查看Pod状态
$ kubectl get pod
liveness-demo   1/1     Running   2 (27s ago)   2m57s

可以看到最后Pod虽然在Events中报告了一个异常，最后Pod的状态虽然是Running，但是Restart字段已经从0变为2，意味着这个容器已经被Kubernetes重启2次了，在重启的过程了，Pod保持Running状态不变。

需要注意的是：Kubernetes并没有Docker的Stop语义，所以虽然是Restart（重启），但实际却是重新创建了容器。

restartPolicy

Kubernetes在容器不健康的情况下重新创建新的容器，这就是Kubernetes的Pod恢复机制，即restartPolicy。

Pod的恢复过程，永远都是发生在当前节点上，而不会跑到别的节点上去。事实上，一旦一个Pod与一个节点（Node）绑定，除非这个绑定发生了变化（pod.spec.node字段被修改），否则它永远都不会离开这个节点。这也就意味着，如果这个宿主机宕机了，这个Pod也不会主动迁移到其他节点上去。

而如果想让Pod出现在其他的可用节点上，就必须使用Deployment这样的控制器来管理Pod，那么只需要一个Pod副本。这就是一个单Pod和Deployment和一个Pod最主要的区别。

restartPolicy的恢复策略：

策略 描述
Always 默认值，任何情况下，容器不在Running状态，就自动重启容器。
OnFailure 容器在Failed状态才重启容器。
Never 从来不重启容器。

基本的设计原理：

  1. 只要Pod的restartPolicy指定的策略允许重启异常的容器（比如：Always），那么这个Pod就会保持Running状态，并进行容器重启。否则，Pod就会进入Failed状态。
  2. 对于包含多个容器的Pod，只有它里面所有的容器都进入异常状态后，Pod才会进入Failed状态。在此之前，Pod都是Running状态。此时，Pod的READY字段会显示正常容器的个数。

如果一个Pod里只有一个容器，这个容器异常退出了，那么只有当restartPolicy=Never时，这个Pod才会进入Failed状态。而其他情况下，由于Kubernetes会自动重启，所以Pod的状态保持Running不变。

如果一个Pod里有多个容器，仅有一个容器异常余处，它会始终保持Running状态，哪怕restartPolicy=Never。只有当所有容器也异常退出之后，这个Pod才会进入Failed状态。