《云原生-Kubernetes篇》深入剖析Kubernetes中pod的原理

🍍每日推荐

🍖文章开始之前我想首先介绍一下牛客，以便没有使用过的小伙伴能够快速入手，牛客网是国内最大的算法、面试、招聘网站，涵盖了多种大厂面试真题以及题解，里面大佬云集，各种题目的解决方案层出不穷，绝对能让你大开眼界，而且牛客是你在人生中不同的阶段都能对你有所帮助的编程软件（完全免费），如果感兴趣可以访问注册一下

访问链接：牛客-国内最大的刷题网站

本文是《云原生-k8s-深入剖析k8s》学习笔记的第二篇，主要解析pod的意义及其使用方法。
pod，是k8s中最小的API对象，是原子调度单位。是超亲密关系容器之间组织和部署的单位。类比地说，pod就是虚拟机，其中的容器就是这个虚拟机里面运行的用户进程。

pod中的所有容器共享network、volume、IP地址，在pod启动的时候，需要先启动一个Infra中间容器，而其它容器都是通过join的方式加入到Infra容器的资源中的。Infra容器是一个用汇编语言编写的，永远处于暂停状态的容器，其唯一的作用就是hold住资源，和pod同生命周期。

initcontainers是一种容器类型，相较于containers类型，前者总是先于后者启动，initcontainers如果有多个，则会按照定义的顺序先后启动，只有当所有的initcontainers都启动成功且退出了，containers用户容器才会启动。

sidecar，是一种容器设计模式，指的是我们可以在一个pod中，启动一个辅助容器来完成一些独立于主容器之外的工作。比如initcontainers容器、Infra容器，都属于sidecar。

在进行上云工作的时候，我们可以把虚拟机类同为一个pod，把里面的进程类同为容器镜像，把有顺序关系的容器，定义为initcontainers。如此才是合理的、松耦合的容器编排诀窍，也是传统应用架构演变到微服务架构最自然的过渡方式。

pod有如下几个重要的属性需要掌握。

• nodeSelector，是一个供用户将pod和node进行绑定的字段。apiVersion: v1kind: Pod...spec:# 该pod只能被调度到含有"disktye: ssd"标签的节点上，否则就调度失败nodeSelector:disktye: ssd
• hostAliases，定义了pod中的hosts文件。apiVersion: v1kind: Pod...spec:# /etc/hosts文件的内容将增加如下内容：# 10.1.2.3 foo.remote# bar.remote foo.remote# 这是k8s中唯一设置pod中hosts文件内容的方式hostAliases:-ip:"10.1.2.3"hostnames:-"foo.remote"-"bar.remote"
• shareProcessNamespace，表示pod中的各个容器共享pid namespace。apiVersion: v1kind: Pod...spec:# pod中的nginx容器和shell容器共享进程空间，可以相互看到pod中所有的进程信息shareProcessNamespace:truecontainers:-name: nginx image: nginx -name: shell image: busybox stdin:truetty:true
• hostNetwork、hostIPC、hostPID，表示pod中的各个容器共享宿主机的网络、IPC和进程空间资源。apiVersion: v1kind: Pod...spec:# pod中的nginx容器和shell容器共享宿主机的网络hostNetwork:true# pod中的nginx容器和shell容器可以直接和宿主机进行IPC通信hostIPC:true# pod中的nginx容器和shell容器共享宿主机的进程空间，可以看到宿主机里面运行的所有进程信息hostPID:truecontainers:-name: nginx image: nginx -name: shell image: busybox stdin:truetty:true
• volumes，表示容器需要挂载的数据卷。常用的类型有：- emptyDir，临时空目录，会在宿主机中特定位置建立匿名目录供pod中的多个容器挂载，从而实现数据共享；- hostPath，指定宿主机中的具名挂载路径；
• containers、initContainers，表示容器的类型。其中initContainers是初始化容器，总是先于用户容器containers运行，并且会按照定义的顺序同步执行。apiVersion: v1kind: Pod...spec:# 初始化容器，仅执行cp命令，执行完成就结束，目的是将war拷贝到tomcat的默认目录下initContainers:-image: liuy/sample:v2 name: war command:["cp","/sample.war","/app"]# 挂载到当前容器的/app目录volumeMounts:-mountPath: /app name: app-volume # 用户容器，等待初始化容器执行完毕后才启动，运行默认目录下的war对外提供服务containers:-image: liuy/tomcat:7.0name: tomcat command:["sh","-c","/root/apache-tomcat-7.0.42-v2/bin/start.sh"]# 挂载到当前容器的/root/apache-tomcat-7.0.42-v2/webapps目录volumeMounts:-mountPath: /root/apache-tomcat-7.0.42-v2/webapps name: app-volume ports:-containerPort:8080hostPort:8001# 该pod挂载的数据卷，类型是宿主机中的匿名存储路径volumes:-name: app-volume emptyDir:{}在containers属性下面，又有如下几个需要重点关注的属性：- image，使用的镜像；- command，启动命令；- workingDir，工作目录；- ports，暴露的容器端口及绑定的宿主机端口；- volumeMounts，挂载数据卷的信息；- imagePullPolicy，镜像拉取策略，通常由always、ifNotPresent、never三个级别；- lifeCycle，生命周期钩子，在容器状态发生改变的时候可以设置触发一些钩子事件； - postStart，容器启动后立即执行指定操作，虽然在ENTRYPOINT之后执行，但不能保证ENTRYPOINT已经执行完毕；- preStop，容器被终结之前执行指定操作，容器的终结会因为这个命令被打断，只有当其执行完毕，容器终结才会继续执行；

pod有如下几个状态需要掌握：

• pending，pod创建请求已经提交，但是pod中的某些容器因为某种原因不能被顺利创建；
• running，pod已经成功调度到某个节点，并且其中的容器都已经创建成功，且至少有一个正在运行中；
• succeeded，pod里面的所有容器都正常运行完毕，并且已经退出了，在运行一次性任务时比较常见；
• failed，pod里面至少有一个容器以非正常的状态退出；
• unknown，pod的状态不能被持续地汇报给kube-apiserver，可能是主从节点通信出现了问题；

有几种特殊的volume，它们并不是为了存放容器中的数据，也不是为了进行容器之间或者和宿主机之间进行数据共享，而是为了给容器提供预先定义好的数据。这种数据卷被称为”投射数据卷“，projected volume。

• secret，存放需要加密的数据；
• configmap，存放不需要加密的，但是应用需要的配置信息；
• downward api，让pod里面的容器直接获取到这个api对象的信息；
• service account，让pod里面可以调用k8s的API来控制集群；

pod可以为其中的容器配置探针（probe），用以监控容器的健康检查，而不是以容器镜像是否运行来作为健康检查的依据，因为会存在很多情况，容器是正常运行的，但是无法对外提供服务了，因此探针的健康检查方式更加准确。k8s一旦检测到容器探针发生异常，就会根据设置好的pod恢复机制进行操作，恢复机制restartPolicy有如下几种：

• always，任何时候容器不在运行状态，就进行重新创建；
• onFailure，只在容器异常时才进行重新创建；
• never，从来不重启容器；

默认情况下pod的恢复机制是always，但并不是所有场景下都是合适的，比如initContainers初始化容器执行任务之后就结束了，就不应该设置为always。

如下文档提供了全量的yaml属性，特别是关于PodSpec的属性可以在3050行看到：api/types.go at master · kubernetes/api · GitHub

访问链接：牛客-国内最大的刷题网站

🍋🍋🍋🍋
共勉：

我一直喜欢下午的阳光 它让我相信这个世界任何事情都会有转机 相信命运的宽厚和美好