K8S系列深入解析Pod对象
Posted 颜淡慕潇
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了K8S系列深入解析Pod对象相关的知识，希望对你有一定的参考价值。
目录
序言
任何一件事情，只要坚持六个月以上，你都可以看到质的飞跃。
在上一篇文章中：【K8S系列】Pod详解
详细介绍了 Pod 这个 Kubernetes 项目中最重要的概念。
而在今天这篇文章中，我会和你分享 Pod 对象的更多细节。希望这篇文章，能帮助你对K8s-pod有个进一步的了解
文章标记颜色说明：
- 黄色：重要标题
- 红色：用来标记结论
- 绿色：用来标记一级论点
- 蓝色：用来标记二级论点
1.问题引入
1.1 问题描述
通过上一篇的学习，我们知道Pod，不是容器，而是 Kubernetes 项目中的最小编排单位。
将这个设计落实到 API 对象上，容器（Container）就成了 Pod 属性里的一个普通的字段。
那么，我们思考一个问题：
到底哪些属性属于 Pod 对象，而又有哪些属性属于 Container 呢？
2 问题解答
需要明确一个概念，也是上一篇文章提到的：Pod 扮演的是传统部署环境里“虚拟机”的角色。
这样的设计，是为了使用户从传统环境（虚拟机环境）向 Kubernetes（容器环境）的迁移，更加平滑。
所以，我们可以把 Pod 看成传统环境里的“机器”、把容器看作是运行在这个“机器”里的“用户程序”，那么很多关于 Pod 对象的设计是不是就容易理解了？
比如，凡是调度、网络、存储，以及安全相关的属性，基本上是 Pod 级别的。
这些属性的共同特征是，它们描述的是“机器”这个整体，而不是里面运行的“程序”。
比如：
- Pod 的网络定义：即-配置这个“机器”的网卡
- Pod 的存储定义：即-配置这个“机器”的磁盘
- Pod 的安全定义：即-配置这个“机器”的防火墙
- Pod 的资源调度：即-这台“机器”运行在哪个服务器之上
下面先介绍 Pod 中几个重要字段的含义和用法
2.1 pod 属性
2.1.1 NodeSelector
NodeSelector：是一个供用户将 Pod 与 Node 进行绑定的字段，
用法如下所示：
apiVersion: v1 kind: Pod …… spec: nodeSelector: disktype: ssd这个配置，意味着这个 Pod 永远只能运行在携带了“disktype: ssd”标签（Label）的节点上；否则，它将调度失败。
2.1.2 HostAliases
HostAliases：定义了 Pod 的 hosts 文件（比如 /etc/hosts）里的内容，用法如下：
apiVersion: v1 kind: Pod ... spec: hostAliases: - ip: "10.1.2.4" hostnames: - "test1.remote" - "test2.remote" ...在这个 Pod 的 YAML 文件中，设置了一组 IP 和 hostname 的数据。这样，这个 Pod 启动后，/etc/hosts 文件的内容将如下所示：
cat /etc/hosts # Kubernetes-managed hosts file. 127.0.0.1 localhost ... 10.244.135.10 hostaliases-pod 10.1.2.4 test1.remote 10.1.2.4 test2.remote其中，最下面两行记录，是通过 HostAliases 字段为 Pod 设置的。
需要指出的是，在 Kubernetes 项目中，如果要设置 hosts 文件里的内容，一定要通过这种方法。
否则，如果直接修改了 hosts 文件的话，在 Pod 被删除重建之后，kubelet 会自动覆盖掉被修改的内容。
2.1.3 shareProcessNamespace
凡是跟容器的 Linux Namespace 相关的属性，也一定是 Pod 级别的。
因为，Pod 的设计，是要让它里面的容器尽可能多地共享 Linux Namespace，仅保留必要的隔离和限制能力。
这样，Pod 模拟出的效果，就跟虚拟机里程序间的关系非常类似了。
举个例子，在下面这个 Pod 的 YAML 文件中，定义了 shareProcessNamespace=true：
apiVersion: v1 kind: Pod metadata: name: nginx spec: shareProcessNamespace: true containers: - name: nginx image: nginx - name: shell image: busybox stdin: true tty: true这就意味着这个 Pod 里的容器要共享 PID Namespace。
在这个 YAML 文件中，定义了两个容器：
- 一个是 nginx 容器，
- 一个是开启了 tty 和 stdin 的 shell 容器。
什么是tty 和 stdin，可以直接认为 tty 就是 Linux 给用户提供的一个常驻小程序，用于接收用户的标准输入，返回操作系统的标准输出。
当然，为了能够在 tty 中输入信息，还需要同时开启 stdin（标准输入流）。
这个 Pod 被创建后，就可以使用 shell 容器的 tty 跟这个容器进行交互了。我们一起实践一下：
1. 创建pod:
kubectl create -f nginx.yaml2. 进入pod:使用 kubectl attach 命令，连接到 shell 容器的 tty 上
kubectl attach -it nginx -c shell3. 查看进程：shell 容器里执行 ps 指令，查看所有正在运行的进程：
/ # ps ax PID USER TIME COMMAND 1 root 0:00 /pause 8 root 0:00 nginx: master process nginx -g daemon off; 14 101 0:00 nginx: worker process 15 root 0:00 sh 21 root 0:00 ps ax可以看到，在这个容器里，不仅看到它本身的 ps ax 指令，还可以看到 nginx 容器的进程，以及 Infra 容器的 /pause 进程。
这就意味着，整个 Pod 里的每个容器的进程，对于所有容器来说都是可见的：它们共享了同一个 PID Namespace。
2.1.4 NodeName
NodeName：当Pod 的这个字段被赋值，Kubernetes 项目就会被认为这个 Pod 已经经过了调度，调度的结果就是赋值的节点名字。
所以，这个字段一般由调度器负责设置，但用户也可以设置它来“骗过”调度器，当然这个做法一般是在测试或者调试的时候才会用到。
2.1.5 其他pod属性
凡是 Pod 中的容器要共享宿主机的 Namespace，也一定是 Pod 级别的定义，
比如：
- Network
- IPC
- PID
- Namespace
apiVersion: v1 kind: Pod metadata: name: nginx spec: hostNetwork: true hostIPC: true hostPID: true containers: - name: nginx image: nginx - name: shell image: busybox stdin: true tty: true在这个 Pod 中，定义了共享宿主机的 Network、IPC 和 PID Namespace。
这就意味着，这个 Pod 里的所有容器，会直接使用宿主机的网络、直接与宿主机进行 IPC 通信、看到宿主机里正在运行的所有进程。
2.2 容器属性
Kubernetes 项目中对 Container 的定义，和 Docker 相比并没有什么太大区别。
- Image（镜像）
- Command（启动命令）
- workingDir（容器的工作目录）
- Ports（容器要开发的端口）
- volumeMounts（容器要挂载的 Volume）
这些都是构成 Kubernetes 项目中 Container 的主要字段。不过除了这些，还有这么几个属性值得我们额外关注。
2.2.1 ImagePullPolicy
ImagePullPolicy 字段。它定义了镜像拉取的策略。注意事项：
- Always：即每次创建 Pod 都重新拉取一次镜像
- Never / IfNotPresent：则意味着 Pod 永远不会主动拉取这个镜像，或者只在宿主机上不存在这个镜像时才拉取。
- ImagePullPolicy 的值默认是Always 。
- 当容器的镜像是类似于 nginx 或者 nginx:latest 这样的名字时，ImagePullPolicy 也会被认为 Always。
2.2.2 Lifecycle
Lifecycle 字段。它定义的是 Container Lifecycle Hooks。
顾名思义，Container Lifecycle Hooks 的作用，是在容器状态发生变化时触发一系列“钩子”。我们来看这样一个例子：
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 > /usr/share/message"] preStop: exec: command: ["/usr/sbin/nginx","-s","quit"]
postStart ：指在容器启动后，立刻执行一个指定的操作。
另外，postStart 定义的操作，虽然是在 Docker 容器 ENTRYPOINT 执行之后，但它并不严格保证顺序。也就是说，在 postStart 启动时，ENTRYPOINT 有可能还没有结束。
当然，如果 postStart 执行超时或者错误，Kubernetes 会在该 Pod 的 Events 中报出该容器启动失败的错误信息，导致 Pod 也处于失败的状态。
preStop: 发生的时机，则是容器被杀死之前（比如，收到了 SIGKILL 信号）。
而需要明确的是，preStop 操作的执行，是同步的。
所以，它会阻塞当前的容器杀死流程，直到这个 Hook 定义操作完成之后，才允许容器被杀死，这跟 postStart 不一样。
所以，在上面例子中，它在容器成功启动之后，在 /usr/share/message 里写入了一句“Hello from the postStart handler”（即 postStart 定义的操作）。
而在这个容器被删除之前，则先调用了 nginx 的退出指令（即 preStop 定义的操作），从而实现了容器的“优雅退出”。
3 总结
在这篇文章中，详细讲解了 Pod API 对象，介绍了 Pod 的核心使用方法，并分析了 Pod 和 Container 在字段上的异同。
希望这些讲解能够帮你更好地理解和记忆 Pod YAML 中的核心字段，以及这些字段的准确含义。
最后，Pod API 对象是整个 Kubernetes 体系中最核心的一个概念，后面讲解各种控制器时都会反复提到。
4. 投票
深入玩转K8S之利用Label控制Pod位置
首先介绍下什么是Label？
Label是Kubernetes系列中一个核心概念。是一组绑定到K8s资源对象上的key/value对。同一个对象的labels属性的key必须唯一。label可以附加到各种资源对象上，如Node,Pod,Service,RC等。
通过给指定的资源对象捆绑一个或多个不用的label来实现多维度的资源分组管理功能，以便于灵活，方便地进行资源分配，调度，配置，部署等管理工作。
默认配置下，Scheduler 会将 Pod 调度到所有可用的 Node。不过有些实际情况我们希望将 Pod 部署到指定的 Node，比如将有大量磁盘 I/O 的 Pod 部署到配置了 SSD 的 Node；或者 Pod 需要 GPU，需要运行在配置了 GPU 的节点上。
下面我们来实际的操作下，比如执行如下命令标注 k8s-node1 是配置了 SSD的节点。
kubectl label node k8snode1 disktype=ssd
然后通过 kubectl get node --show-labels 查看节点的 label。
可以看到disktype=ssd 已经成功添加到 k8snode1，除了 disktype，Node 还有几个 Kubernetes 自己维护的 label。有了 disktype 这个自定义 label，接下来就可以指定将 Pod 部署到 k8snod1。比如我编辑nginx.yml，增加nodeSelector标签，指定将此Pod部署到具有ssd属性的Node上去。
最后通过kubectl get pod -o wide。
如果要删除 label disktype，就执行如下命令删除即可：
kubectl label node k8s-node1 disktype-
但是要注意已经部署的 Pod 并不会重新部署，依然在 k8snode1 上运行。可能会有人说了，那怎么让Pod变回原样呢也就是分配到多个node上，那就需要一个笨方法了（至少在目前我学习的方法里面只会这样操作），就是在刚才编辑的那个nginx.yml文件里面删除nodeSelector标签，然后在利用kubectl apply重新部署，Kubernetes 会删除之前的 Pod 并调度和运行新的 Pod。
好了本次的Label标签的实践讨论到此结束，本文参考了Kubernetes 官网和每天5分钟玩转K8S。
以上是关于K8S系列深入解析Pod对象的主要内容，如果未能解决你的问题，请参考以下文章