Kubernetes：Pod剖析

一. 简介

Pod，是 Kubernetes 项目中最小的 API 对象。一个Pod里面可以运行多个用户容器，容器之间可以存在一定的拓扑结构。

但是，Pod 只是一个逻辑概念，提供的是一种编排思想，而不是具体的技术方案。准确来说，Kubernetes 真正处理的，还是宿主机操作系统上 Linux 容器的 Namespace 和 Cgroups，而并不存在一个所谓的 Pod 的边界或者隔离环境。

关于本文的案例代码，都在此链接中：GitHub项目地址

二. 共享网络

2.1 原理

Pod，其实是一组共享了某些资源的容器。具体的说：Pod 里的所有容器，共享的是同一个 Network Namespace，并且可以声明共享同一个 Volume。

2.2 Infra容器

在 Kubernetes 项目里，Pod 的实现需要使用一个中间容器，这个容器叫作 Infra 容器。在这个 Pod 中，Infra 容器永远都是第一个被创建的容器，而其他用户定义的容器，则通过Join Network Namespace 的方式，与 Infra 容器关联在一起。

infra architecture

例如上图，这个 Pod 里有两个容器Container-1 和Container-2，还有一个 Infra 容器。在 Kubernetes 项目里，Infra 容器一定要占用极少的资源，所以它使用的是一个非常特殊的镜像，叫作：k8s.gcr.io/pause。
这个镜像是一个用汇编语言编写的、永远处于“暂停”状态的容器，解压后的大小也只有100~200 KB 左右。

如下就能看到一对一的关系：

Infra List

2.3 流程

对于 Pod 里的Container-1 和Container-2 来说：

• 容器可以直接使用 localhost 进行通信。
• 容器看到的网络设备跟 Infra 容器看到的完全一样。
• 一个 Pod 只有一个 IP 地址，也就是这个 Pod 的 Network Namespace 对应的 IP 地址。
• 其他的所有网络资源，都是一个 Pod 一份，并且被该 Pod 中的所有容器共享。
• Pod 的生命周期只跟 Infra 容器一致，而与容器 A 和 B 无关。

三. 共享存储

3.1 原理

在Pod中共享文件或目录很简单，实际上是通过将Volume转移到Pod级别来完成的。容器中的所有容器共享所有Volume。

3.2 案例

如下案例，描述共享存储的案例：

apiVersion: v1
kind: Pod
metadata:
  name: demo-containers
spec:
  restartPolicy: Never
  volumes:
  - name: shared-data
    hostPath:      
      path: /data
  containers:
  - name: nginx-container
    image: nginx
    volumeMounts:
    - name: shared-data
      mountPath: /usr/share/nginx/html
  - name: debian-container
    image: debian
    volumeMounts:
    - name: shared-data
      mountPath: /pod-data
    command: ["/bin/sh"]
    args: ["-c", "echo Hello World > /pod-data/index.html"]

在这个例子中，debian-container 和 nginx-container 都声明挂载了 shared-data 这个 Volume。而 shared-data 是 hostPath 类型。所以，它对应在宿主机上的目录就是：/data。
而这个目录，其实就被同时绑定挂载进了上述两个容器当中，所以 nginx-container 可以从它的/usr/share/nginx/html 目录中读取到 debian-container 生成的 index.html 文件。

三. 拓展

3.1 超亲密关系

Pod 是一种“超亲密关系”容器的设计思想。当用户需要思考多个容器之间是否需要部署进同一个Pod时，这是一个首要问题。

简单的场景如下：

Pod 场景

关于“超亲密关系”，可以分为以下几类：

• 文件在进程之间交换。一个进程写入日志，而另一个进程读取日志。
• 两个进程都需要通过localhost或本地套接字相互通信。
• 容器和微服务都需要频繁的RPC调用。这可以提高性能。
• 两个容器或应用程序需要共享一些Linux名称空间。例如，将一个容器添加到另一个容器的网络名称空间中，以查看网络设备和该容器的网络信息。

3.2 Pod级别

在Pod YAML中，可以做出如下的分类：

1. 凡是调度、网络、存储，以及安全相关的属性，基本上是 Pod 级别的。
2. 凡是跟容器的 Linux Namespace 相关的属性，也一定是 Pod 级别的。Pod 的设计，就是要让它里面的容器尽可能多地共享 Linux Namespace，仅保留必要的隔离和限制能力。
3. 凡是 Pod 中的容器要共享宿主机的 Namespace，也一定是 Pod 级别的定义。

3.3 Pod参数

案例Pod YAML如下：

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
spec:
  nodeSelector:
    gpu: nvida
  containers:
    - name: demo-pod-container
      image: nginx
      imagePullPolicy: Always
      lifecycle:
        postStart:
          exec:
            command:
              ["/bin/sh", "-c", "echo Hello PostStart > /usr/share/message"]
        preStop:
          exec:
            command: ["/usr/sbin/nginx", "-s", "quit"]

1. 关于Pod参数的具体含义：

• NodeSelector
  帮助供用户将 Pod 与 Node 进行绑定的字段，意味着这个 Pod 永远只能运行在携带了“gpu: nvida”标签（Label）的节点上；否则，它将调度失败。
• NodeName（隐式）：
  一旦 Pod 的这个字段被赋值，Kubernetes 项目就会被认为这个 Pod 已经经过了调度，调度的结果就是赋值的节点名字。所以，这个字段一般由调度器负责设置。
• HostAliases
  定义了 Pod 的 hosts 文件（比如 /etc/hosts）里的内容。
• Init Containers（optional）
  Init Containers的生命周期，会先于所有的 Containers，并且严格按照定义的顺序执行。

2. 关于Container参数的具体含义

• ImagePullPolicy
  这定义了镜像拉取的策略，类型选择有个有三种Always, Never, IfNotPresent。
  ImagePullPolicy 的值默认是 Always，即每次创建 Pod 都重新拉取一次镜像。另外，当容器的镜像是类似于 nginx 或者 nginx:latest 这样的名字时，ImagePullPolicy 也会被认为 Always。
  Never 或者 IfNotPresent，则意味着 Pod 永远不会主动拉取这个镜像，或者只在宿主机上不存在这个镜像时才拉取。

• Lifecycle
  Lifecycle定义的是 Container Lifecycle Hooks。作用是在容器状态发生变化时触发一系列“钩子”，例如：postStart 和 preStop

  • postStart
    在容器启动后，立刻执行一个指定的操作。需要明确的是，postStart 定义的操作，虽然是在 Docker 容器 ENTRYPOINT 执行之后，但它并不严格保证顺序。也就是说，在 postStart 启动时，ENTRYPOINT 有可能还没有结束。
  • preStop
    事件在容器被杀死之前（比如，收到了 SIGKILL 信号）。而需要明确的是，preStop 操作的执行，是同步的。所以，它会阻塞当前的容器杀死流程，直到这个 Hook 定义操作完成之后，才允许容器被杀死，这跟 postStart 不一样。

3.3 Pod状态

Pod 生命周期的变化，主要体现在 Pod API 对象的 Status 部分，pod.status.phase就是 Pod 的当前状态.
它有如下几种可能的情况：

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

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

• PodScheduled
• Ready
• Initialized
• Unschedulable

正常情况下，我们都是这样的running状态：

running status

四. 总结

Pod，实际上是在扮演传统基础设施里“虚拟机”的角色。而容器，则是这个虚拟机里运行的用户程序。而且，Pod的设计完全脱离Docker这样的容器，对于Kubernetes这样的操作系统来说，达到普适性的目标非常有帮助。
Pod是一个最基本也是颗粒度最小的调度单位，学会这个是迈出Kubernetes的第一步。

顺便说一句，VS Code的对Kubernetes的YAMl编写提示还是非常友好的，对新手很合适。

VS code

最后，欢迎关注我的博客：https://blog.wyatt.plus

Reference

https://alibaba-cloud.medium.com/getting-started-with-kubernetes-pods-and-container-design-modes-c76ade940ea0
https://time.geekbang.org/column/article/40366?utm_campaign=guanwang&utm_source=baidu-ad&utm_medium=ppzq-pc&utm_content=title&utm_term=baidu-ad-ppzq-title