深入浅出 Kubernetes：初识 Pod（上）
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/solaraceboy/article/details/97923925
文章目录
- 深入浅出 Kubernetes：初识 Pod（上）
- 一 概念
- 二 Pod 中几个重要字段的含义和用法
- 三 相关资源
深入浅出 Kubernetes：初识 Pod（上）
一 概念
Pod 的中文意为： 豆荚，从字面意思不难理解，它就像一个豆荚，里面包含许多豆子，这些豆子就可以类比为 container 。实际上，Pod 是一个逻辑概念，Kubernetes 真正处理的，还是宿主机操作系统上 Linux 容器的 Namespace 和 Cgroups，而并不存在一个所谓的 Pod 的边界或者隔离环境。 Pod 是一组共享了某些资源的容器，Pod里的所有容器，共享的是同一个 Network Namespace，并且可以声明共享同一个 Volume 。在 Kubernetes 项目里，Pod 的实现需要使用一个中间容器，这个容器叫做Infra容器（ Infra容器k8s.gcr.io/pause占用极少的资源，它的镜像时用汇编语言编写的，永远处于“暂停”状态的容器 ）。 在Pod中，Infra 容器永远都是第一个被创建的容器，而其他用户定义的容器，则通过 join Network Namespace的方式，与Infra容器关联在一起，对于同一个Pod里面的所有用户容器，它们的进出流量都是通过Infra容器完成的。同一个 Pod 里面的所有用户容器来说，它们的进出流量，也可以认为都是通过 Infra 容器完成的。凡是调度、网络、存储，以及安全相关的属性，基本上是 Pod 级别的。
二 Pod 中几个重要字段的含义和用法
NodeSelector：是一个供用户将 Pod 与 Node 进行绑定的字段，用法如下所示：
apiVersion: v1
kind: Pod
metadata:
name: gysl-nodeselect
spec:
nodeSelector:
kubernetes.io/hostname: 172.31.2.12
containers:
- name: gysl-nginx
image: nginx这就意味着这个 Pod 只能在携带 kubernetes.io/hostname 标签的 Node 上运行了，否则，调度失败。
NodeName：一旦 Pod 的这个字段被赋值，Kubernetes 项目就会被认为这个 Pod 已经经过了调度，调度的结果就是赋值的节点名字。所以，这个字段一般由调度器负责设置，但用户也可以设置它来“骗过”调度器，当然这个做法一般是在测试或者调试的时候才会用到。
apiVersion: v1
kind: Pod
metadata:
name: gysl-nodename
spec:
nodeName: 172.31.2.12
containers:
- name: gysl-nginx
image: nginxHostAliases：定义了 Pod 的 hosts 文件（比如 /etc/hosts）里的内容。
apiVersion: v1
kind: Pod
metadata:
name: gysl-hostaliases
spec:
hostAliases:
- ip: "10.0.0.20"
hostnames:
- "test.gysl"
- "app.gysl"
containers:
- name: gysl-nginx
image: nginx最下面两行记录，就是我通过 HostAliases 字段为 Pod 设置的。需要指出的是，在 Kubernetes 项目中，如果要设置 hosts 文件里的内容，一定要通过这种方法。否则，如果直接修改了 hosts 文件的话，在 Pod 被删除重建之后，kubelet 会自动覆盖掉被修改的内容。
凡是跟容器的 Linux Namespace 相关的属性，也一定是 Pod 级别的。这个原因也很容易理解：Pod 的设计，就是要让它里面的容器尽可能多地共享 Linux Namespace，仅保留必要的隔离和限制能力。
继续看以下例子：
apiVersion: v1
kind: Pod
metadata:
name: gysl-shareprocessnamespace
spec:
shareProcessNamespace: true
containers:
- name: nginx
image: nginx
- name: busybox
image: busybox
tty: true
stdin: true使用以下命令进入指定的 container ：
kubectl attach -it gysl-shareprocessnamespace -c busybox进入之后查看一下进程共享情况：
/ # ps aux
PID USER TIME COMMAND
1 root 0:00 /pause
6 root 0:00 nginx: master process nginx -g daemon off;
11 101 0:00 nginx: worker process
12 root 0:00 sh
32 root 0:00 ps aux在这个容器里，我们不仅可以看到它本身的 ps aux 指令，还可以看到 nginx 容器的进程，以及 Infra 容器的 /pause 进程。这就意味着，整个 Pod 里的每个容器的进程，对于所有容器来说都是可见的：它们共享了同一个 PID Namespace。凡是 Pod 中的容器要共享宿主机的 Namespace，也一定是 Pod 级别的定义。
再看一个例子：
apiVersion: v1
kind: Pod
metadata:
name: gysl-share-namespace
spec:
hostPID: true
hostIPC: true
hostNetwork: true
nodeName: 172.31.2.11
shareProcessNamespace: true
containers:
- name: nginx-gysl
image: nginx
imagePullPolicy: IfNotPresent
- name: busybox-gysl
image: busybox
stdin: true
tty: true
imagePullPolicy: Always
lifecycle:
postStart:
exec:
command: ['/bin/sh','-c','echo "This is a test of gysl. ">/gysl.txt']
preStop:
exec:
command: ['/bin/sh','-c','echo "This is a demo of gysl."']上面的例子中，定义了共享宿主机的 Network、IPC 和 PID Namespace。这就意味着，这个 Pod 里的所有容器，会直接使用宿主机的网络、直接与宿主机进行 IPC 通信、看到宿主机里正在运行的所有进程。
除此之外，ImagePullPolicy 和 Lifecycle 也是值得我们关注的两个字段。
ImagePullPolicy 字段定义了镜像拉取的策略。而它之所以是一个 Container 级别的属性，是因为容器镜像本来就是 Container 定义中的一部分。ImagePullPolicy 的值默认是 Always，即每次创建 Pod 都重新拉取一次镜像。如果它的值被定义为 Never 或者 IfNotPresent，则意味着 Pod 永远不会主动拉取这个镜像，或者只在宿主机上不存在这个镜像时才拉取。
Lifecycle 字段。它定义的是 Container Lifecycle Hooks。顾名思义，Container Lifecycle Hooks 的作用，是在容器状态发生变化时触发一系列“钩子”。在这个字段中，我们看到了 postStart 和 preStop 两个参数。postStart 参数在容器启动后，立刻执行一个指定的操作。需要明确的是，postStart 定义的操作，虽然是在 Docker 容器 ENTRYPOINT 执行之后，但它并不严格保证顺序。也就是说，在 postStart 启动时，ENTRYPOINT 有可能还没有结束。如果 postStart 执行超时或者错误，Kubernetes 会在该 Pod 的 Events 中报出该容器启动失败的错误信息，导致 Pod 也处于失败的状态。preStop 发生的时机，则是容器被杀死之前（比如，收到了 SIGKILL 信号）。而需要明确的是，preStop 操作的执行，是同步的。所以，它会阻塞当前的容器杀死流程，直到这个 Hook 定义操作完成之后，才允许容器被杀死，这跟 postStart 不一样。
三 相关资源
文中涉及到的资源可以从本人 GitHub 上获取，链接如下：