Kubernetes Pod

pod是什么？

在kubernetes的世界中，k8s并不直接管理容器，而是使用多个容器共存的理念，这组容器就叫做pod。

pod是k8s中可以创建和管理的最小单元，是资源对象模型中由用户创建或部署的最小资源对象模型，其他的资源对象都是用来支撑pod对象功能的，比如，pod控制器就是用来管理pod对象的，service或者ingress资源对象是用来暴露pod引用对象的，persistentvolume资源是用来为pod提供存储等等，

简而言之，k8s不会直接管理容器，而是pod，pod才是k8s中可以创建和管理的最小单元，也是基本单元。

pod的原理是什么

在微服务的概念里，一般的，一个容器会被设计为运行一个进程，除非进程本身产生子进程，

这样，由于不能将多个进程聚集在同一个单独的容器中，所以需要一种更高级的结构将容器绑定在一起，并将它们作为一个单元进行管理，这就是k8s中pod的背后原理。

pod有什么特点？

1、每个pod就像一个独立的逻辑机器，k8s会为每个pod分配一个集群内部唯一的IP地址，所以每个pod都拥有自己的IP地址、主机名、进程等；
2、一个pod可以包含1个或多个容器，1个容器一般被设计成只运行1个进程，1个pod只可能运行在单个节点上，即不可能1个pod跨节点运行，pod的生命周期是短暂，也就是说pod可能随时被消亡（如节点异常，pod异常等情况）；
2、每一个pod都有一个特殊的被称为"根容器"的pause容器，也称info容器，pause容器对应的镜像属于k8s平台的一部分，除了pause容器，每个pod还包含一个或多个跑业务相关组件的应用容器；
3、一个pod中的容器共享network命名空间；
4、一个pod里的多个容器共享pod IP，这就意味着1个pod里面的多个容器的进程所占用的端口不能相同，否则在这个pod里面就会产生端口冲突；既然每个pod都有自己的IP和端口空间，那么对不同的两个pod来说就不可能存在端口冲突；
5、应该将应用程序组织到多个pod中，而每个pod只包含紧密相关的组件或进程；
6、pod是k8s中扩容、缩容的基本单位，也就是说k8s中扩容缩容是针对pod而言而非容器。

pod的重启策略有哪些？

pod重启容器策略是指针对pod内所有容器的重启策略，不是重启pod，其可以通过restartPolicy字段配置pod重启容器的策略，如下：

• Always: 当容器终止退出后，总是重启容器，默认策略就是Always。

• OnFailure: 当容器异常退出，退出状态码非0时，才重启容器。

• Never: 当容器终止退出，不管退出状态码是什么，从不重启容器。

pod的镜像拉取策略有哪几种

pod镜像拉取策略可以通过imagePullPolicy字段配置镜像拉取策略，

主要有3中镜像拉取策略，如下：

• IfNotPresent: 默认值，镜像在node节点宿主机上不存在时才拉取。
• Always: 总是重新拉取，即每次创建pod都会重新从镜像仓库拉取一次镜像。
• Never: 永远不会主动拉取镜像，仅使用本地镜像，需要你手动拉取镜像到node节点，如果node节点不存在镜像则pod启动失败。

kubenetes针对pod资源对象的健康监测机制

提供了三类probe（探针）来执行对pod的健康监测：

• startupProbe启动探针:

启动检查机制，应用一些启动缓慢的业务，避免业务长时间启动而被上面两类探针kill掉，

这个问题也可以换另一种方式解决，就是定义上面两类探针机制时，初始化时间定义的长一些即可;

• livenessProbe存活探针:

可以根据用户自定义规则来判定pod是否健康，用于判断容器是否处于Running状态，

如果不是，kubelet就会杀掉该容器，并根据重启策略做相应的处理。如果容器不包含该探针，那么kubelet就会默认返回值都是success;

• ReadinessProbe就绪探针:

同样是可以根据用户自定义规则来判断pod是否健康，容器服务是否可用（Ready），如果探测失败，控制器会将此pod从对应service的endpoint列表中移除，从此不再将任何请求调度到此Pod上，直到下次探测成功;

 

备注：每种探测方法能支持以下几个相同的检查参数，用于设置控制检查时间：

• initialDelaySeconds：初始第一次探测间隔，用于应用启动的时间，防止应用还没启动而健康检查失败；

• periodSeconds：检查间隔，多久执行probe检查，默认为10s；

• timeoutSeconds：检查超时时长，探测应用timeout后为失败；

• successThreshold：成功探测阈值，表示探测多少次为健康正常，默认探测1次。

就绪探针（ReadinessProbe探针）与存活探针（livenessProbe探针）区别是什么

两者作用不一样，

存活探针是将检查失败的容器杀死，创建新的启动容器来保持pod正常工作；

就绪探针是，当就绪探针检查失败，并不重启容器，而是将pod移出endpoint，就绪探针确保了service中的pod都是可用的，确保客户端只与正常的pod交互并且客户端永远不会知道系统存在问题。

存活探针的属性参数有哪几个？

存活探针的附加属性参数有以下几个：

• initialDelaySeconds：表示在容器启动后延时多久秒才开始探测；

• periodSeconds：表示执行探测的频率，即间隔多少秒探测一次，默认间隔周期是10秒，最小1秒；

• timeoutSeconds：表示探测超时时间，默认1秒，最小1秒，表示容器必须在超时时间范围内做出响应，否则视为本次探测失败；

• successThreshold：表示最少连续探测成功多少次才被认定为成功，默认是1，对于liveness必须是1，最小值是1；

• failureThreshold：表示连续探测失败多少次才被认定为失败，默认是3，连续3次失败，k8s 将根据pod重启策略对容器做出决定；

注意：定义存活探针时，一定要设置initialDelaySeconds属性，该属性为初始延时，如果不设置，默认容器启动时探针就开始探测了，这样可能会存在
应用程序还未启动就绪，就会导致探针检测失败，k8s就会根据pod重启策略杀掉容器然后再重新创建容器的莫名其妙的问题。
在生产环境中，一定要定义一个存活探针。

pod的就绪探针有哪几种

我们知道，当一个pod启动后，就会立即加入service的endpoint ip列表中，并开始接收到客户端的链接请求，

假若此时pod中的容器的业务进程还没有初始化完毕，那么这些客户端链接请求就会失败，为了解决这个问题，kubernetes提供了就绪探针来解决这个问题的。

在pod中的容器定义一个就绪探针，就绪探针周期性检查容器，

如果就绪探针检查失败了，说明该pod还未准备就绪，不能接受客户端链接，则该pod将从endpoint列表中移除，

pod被剔除了, service就不会把请求分发给该pod，

然后就绪探针继续检查，如果随后容器就绪，则再重新把pod加回endpoint列表。

三种探针工作原理

• httpGet：通过容器的IP、端口、路径发送http 请求，返回200-400范围内的状态码表示成功。

• exec：在容器内执行shell命令，根据命令退出状态码是否为0进行判断，0表示健康，非0表示不健康。

• TCPSocket：与容器的IP、端口建立TCP Socket链接，能建立则说明探测成功，不能建立则说明探测失败pod的就绪探针的属性参数有哪些

pod的就绪探针的属性参数有哪些

就绪探针的附加属性参数有以下几个：

• initialDelaySeconds：延时秒数，即容器启动多少秒后才开始探测，不写默认容器启动就探测；

• periodSeconds ：执行探测的频率（秒），默认为10秒，最低值为1；

• timeoutSeconds ：超时时间，表示探测时在超时时间内必须得到响应，负责视为本次探测失败，默认为1秒，最小值为1；

• failureThreshold ：连续探测失败的次数，视为本次探测失败，默认为3次，最小值为1次；

• successThreshold ：连续探测成功的次数，视为本次探测成功，默认为1次，最小值为1次；

pod的重启策略是什么

通过命令“kubectl explain pod.spec”查看pod的重启策略;

• Always：但凡pod对象终止就重启，此为默认策略;

• OnFailure：仅在pod对象出现错误时才重启;

简单讲一下 pod创建过程

情况一、使用kubectl run命令创建的pod：

注意： kubectl run 在旧版本中创建的是deployment， 但在新的版本中创建的是pod则其创建过程不涉及deployment

如果是单独的创建一个pod，则其创建过程是这样的：
1、首先，用户通过kubect提交需要创建的pod信息给apiserver；
2、apiserver验证客户端的用户权限信息，验证通过，开始处理创建请求生成pod对象信息，并将信息存入etcd，然后返回确认信息给客户端；
3、apiserver开始反馈etcd中pod对象的变化，其他组件使用watch机制跟踪apiserver上的变动；
4、scheduler发现有新的pod对象要创建，开始调用内部算法机制为pod分配最佳的主机并绑定，并将结果信息更新至apiserver；
5、node节点上的kubelet通过watch机制跟踪apiserver发现有pod调度到本节点，尝试调用docker启动容器，并将结果反馈apiserver；
6、apiserver将收到的pod状态信息存入etcd中。
至此，整个pod创建完毕。

情况二、使用deployment来创建pod：

1、首先，用户使用kubectl create命令或者kubectl apply命令提交了要创建一个deployment资源请求；
2、api-server收到创建资源的请求后，会对客户端操作进行身份认证，在客户端的~/.kube文件夹下，已经设置好了相关的用户认证信息，这样api-server会知道我是哪个用户，并对此用户进行鉴权，当api-server确定客户端的请求合法后，就会接受本次操作，并把相关的信息保存到etcd中，然后返回确认信息给客户端。
3、apiserver开始反馈etcd中过程创建的对象的变化，其他组件使用watch机制跟踪apiserver上的变动。
4、controller-manager组件会监听api-server的信息，controller-manager是有多个类型的，比如Deployment Controller, 它的作用就是负责监听Deployment，此时Deployment Controller发现有新的deployment要创建，那么它就会去创建一个ReplicaSet，一个ReplicaSet的产生，又被另一个叫做ReplicaSet Controller监听到了，紧接着它就会去分析ReplicaSet的语义，它了解到是要依照ReplicaSet的template去创建Pod, 它一看这个Pod并不存在，那么就新建此Pod，当Pod刚被创建时，它的nodeName属性值为空，代表着此Pod未被调度。
5、调度器Scheduler组件开始介入工作，Scheduler也是通过watch机制跟踪apiserver上的变动，发现有未调度的Pod，则根据内部算法、节点资源情况，pod定义的亲和性反亲和性等等，调度器会综合的选出一批候选节点，在候选节点中选择一个最优的节点，然后将pod绑定该该节点，将信息反馈给api-server。
6、kubelet组件布署于Node之上，它也是通过watch机制跟踪apiserver上的变动，监听到有一个Pod应该要被调度到自身所在Node上来，kubelet首先判断本地是否在此Pod，如果不存在，则会进入创建Pod流程，创建Pod有分为几种情况，第一种是容器不需要挂载外部存储，则相当于直接docker run把容器启动，但不会直接挂载docker网络，而是通过CNI调用网络插件配置容器网络，如果需要挂载外部存储，则还要调用CSI来挂载存储。kubelet创建完pod，将信息反馈给api-server，api-servier将pod信息写入etcd。
7、Pod建立成功后，ReplicaSet Controller会对其持续进行关注，如果Pod因意外或被我们手动退出，ReplicaSet Controller会知道，并创建新的Pod，以保持replicas数量期望值。

k8s 创建一个pod的详细流程，涉及的组件怎么通信的

1）客户端提交创建请求，可以通过 api-server 提供的 restful 接口，或者是通过 kubectl 命令行工具，支持的数据类型包括 JSON 和 YAML；

2）api-server 处理用户请求，将 pod 信息存储至 etcd 中；

3）kube-scheduler 通过 api-server 提供的接口监控到未绑定的 pod，尝试为 pod 分配 node 节点，主要分为两个阶段，预选阶段和优选阶段，其中预选阶段是遍历所有的 node 节点，根据策略筛选出候选节点，而优选阶段是在第一步的基础上，为每一个候选节点进行打分，分数最高者胜出；

4）选择分数最高的节点，进行 pod binding 操作，并将结果存储至 etcd 中；

5）随后目标节点的 kubelet 进程通过 api-server 提供的接口监测到 kube-scheduler 产生的 pod 绑定事件，然后从 etcd 获取 pod 清单，下载镜像并启动容器；

pod生命周期中的状态有哪几种

pod生命周期有的5种状态（也称5种相位），如下：

• Pending（挂起）：API server已经创建pod，但是该pod还有一个或多个容器的镜像没有创建，包括正在下载镜像的过程；

• Running（运行中）：Pod内所有的容器已经创建，且至少有一个容器处于运行状态；

• Succeed（成功）：Pod内所有容器均已退出，且不会再重启；

• Failed（失败）：Pod内所有容器均已退出，且至少有一个容器为退出失败状态

• Unknown（未知）：某于某种原因apiserver无法获取该pod的状态，可能由于网络通行问题导致；

pod一致处于pending状态一般有哪些情况，怎么排查

一个pod一开始创建的时候，它本身就是会处于pending状态，这时可能是正在拉取镜像，正在创建容器的过程。

如果等了一会发现pod一直处于pending状态，

那么我们可以使用kubectl describe命令查看一下pod的Events详细信息。一般可能会有这么几种情况导致pod一直处于pending状态：
1、调度器调度失败。

Scheduer调度器无法为pod分配一个合适的node节点。

而这又会有很多种情况，比如，node节点处在cpu、内存压力，导致无节点可调度；pod定义了资源请求，没有node节点满足资源请求；node节点上有污点而pod没有定义容忍；pod中定义了亲和性或反亲和性而没有节点满足这些亲和性或反亲和性；以上是调度器调度失败的几种情况。
2、pvc、pv无法动态创建。

如果因为pvc或pv无法动态创建，那么pod也会一直处于pending状态，比如要使用StatefulSet 创建redis集群，因为粗心大意，定义的storageClassName名称写错了，那么会造成无法创建pvc，这种情况pod也会一直处于pending状态，或者，即使pvc是正常创建了，但是由于某些异常原因导致动态供应存储无法正常创建pv，那么这种情况pod也会一直处于pending状态。

DaemonSet资源对象的特性

DaemonSet这种资源对象会在每个k8s集群中的节点上运行，并且每个节点只能运行一个pod，这是它和deployment资源对象的最大也是唯一的区别。

所以，在其yaml文件中，不支持定义replicas，

除此之外，与Deployment、RS等资源对象的写法相同,

DaemonSet一般使用的场景有

• 在去做每个节点的日志收集工作；
• 监控每个节点的的运行状态;

删除一个Pod会发生什么事情

Kube-apiserver会接受到用户的删除指令，默认有30秒时间等待优雅退出，超过30秒会被标记为死亡状态，

此时Pod的状态Terminating，kubelet看到pod标记为Terminating就开始了关闭Pod的工作;

关闭流程如下：

1）pod从service的endpoint列表中被移除；

2)如果该pod定义了一个停止前的钩子，其会在pod内部被调用，停止钩子一般定义了如何优雅的结束进程；

3)进程被发送TERM信号（kill -14）;

4)当超过优雅退出的时间后，Pod中的所有进程都会被发送SIGKILL信号（kill -9）;

pod的共享资源

1）PID 命名空间：Pod 中的不同应用程序可以看到其他应用程序的进程 ID；

2）网络命名空间：Pod 中的多个容器能够访问同一个IP和端口范围；

3）IPC 命名空间：Pod 中的多个容器能够使用 SystemV IPC 或 POSIX 消息队列进行通信；

4）UTS 命名空间：Pod 中的多个容器共享一个主机名；

5）Volumes（共享存储卷）：Pod 中的各个容器可以访问在 Pod 级别定义的 Volumes；

pod的初始化容器是干什么的

init container，初始化容器用于在启动应用容器之前完成应用容器所需要的前置条件，

初始化容器本质上和应用容器是一样的，但是初始化容器是仅允许一次就结束的任务，初始化容器具有两大特征：

1、初始化容器必须运行完成直至结束，若某初始化容器运行失败，那么kubernetes需要重启它直到成功完成；
2、初始化容器必须按照定义的顺序执行，当且仅当前一个初始化容器成功之后，后面的一个初始化容器才能运行；

pod的资源请求、限制如何定义

pod的资源请求、资源限制可以直接在pod中定义

主要包括两块内容，

• limits，限制pod能使用的最大cpu和内存，
• requests，pod启动时申请的cpu和内存。

resources: #资源配额
limits: #限制最大资源，上限
cpu: 2 #CPU限制，单位是code数
memory: 2G #内存最大限制
requests: #请求资源（最小，下限）
cpu: 1 #CPU请求，单位是code数
memory: 500G #内存最小请求

pod的定义中有个command和args参数，这两个参数不会和docker镜像的ENTRYPOINT冲突吗

不会。

在pod中定义的command参数用于指定容器的启动命令列表，如果不指定，则默认使用Dockerfile打包时的启动命令，args参数用于容器的启动命令需要的参数列表；

特别说明：kubernetes中的command、args其实是实现覆盖dockerfile中的ENTRYPOINT的功能的。

1、如果command和args均没有写，那么使用Dockerfile的配置；

2、如果command写了但args没写，那么Dockerfile默认的配置会被忽略，执行指定的command；

3、如果command没写但args写了，那么Dockerfile中的ENTRYPOINT的会被执行，使用当前args的参数；

4、如果command和args都写了，那么Dockerfile会被忽略，执行输入的command和args。

pause容器作用是什么

每个pod里运行着一个特殊的被称之为pause的容器，也称根容器，而其他容器则称为业务容器；

创建pause容器主要是为了为业务容器提供 Linux命名空间，共享基础：包括 pid、icp、net 等，以及启动 init 进程，并收割僵尸进程；

这些业务容器共享pause容器的网络命名空间和volume挂载卷，

当pod被创建时，pod首先会创建pause容器，从而把其他业务容器加入pause容器，从而让所有业务容器都在同一个命名空间中，这样可以就可以实现网络共享。

pod还可以共享存储，在pod级别引入数据卷volume，业务容器都可以挂载这个数据卷从而实现持久化存储。