Kubernetes基础_02_Pod全解析

Posted 2022-12-30 毛奇志

系列文章目录

文章目录

• 系列文章目录
• 前言
• 一、Pod的生命周期Lifecycle
• 二、Pod的重启策略RestartPolicy
• 三、静态Pod
• 四、Pod的健康检查
• 五、Pod的资源占用
• 总结

---

前言

Pod是Kubernetes最小单位，当然一个Pod可以有多个Container，但是container是docker的元素，不是Kubernetes的元素，所以Pod就是Kubernetes的最小单位。

Pod 组成 ReplicaSet(就是RS)，ReplicaSet组成 Deployment StatefulSet DaemonSet Job/CronJob，浙西都是Controller，由静态Pod ControllerManager 来管理，然后Service资源通过 selecter - label 标签选择器与各种 Controller 绑定，通过 targetPort - port 完成端口映射，Service 分为普通Service和无头Service两类，所有的这些都在 namespace 命令空间里面。

一、Pod的生命周期Lifecycle

官网：https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/

• 挂起（Pending）：Pod 已被 Kubernetes 系统接受，但有一个或者多个容器镜像尚未创建。等待时间包括调度 Pod 的时间和通过网络下载镜像的时间，这可能需要花点时间。

• 运行中（Running）：该 Pod 已经绑定到了一个节点上，Pod 中所有的容器都已被创建。至少有一个容器正在运行，或者正处于启动或重启状态。

• 成功（Succeeded）：Pod 中的所有容器都被成功终止，并且不会再重启。

• 失败（Failed）：Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止。

• 未知（Unknown）：因为某些原因无法取得 Pod 的状态，通常是因为与 Pod 所在主机通信失败。

注意：对于最小逻辑单元pod来说（ kubectl get pod） 正常状态是 running；
对于最小物理单元node来说（ kubectl get node），正常状态是 ready 。

二、Pod的重启策略RestartPolicy

官网：https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy

A PodSpec has a restartPolicy field with possible values Always, OnFailure, and Never. The default value is Always. (默认是always) restartPolicy applies to all Containers in the Pod. restartPolicy only refers to restarts of the Containers by the kubelet on the same node. Exited Containers that are restarted by the kubelet are restarted with an exponential back-off delay (10s, 20s, 40s …) capped at five minutes, and is reset after ten minutes of successful execution. As discussed in the Pods document, once bound to a node, a Pod will never be rebound to another node.

小结：Pod中重启策略包括三种，如下：

• Always：容器失效时重启（默认方式）
• OnFailure：容器终止运行且退出码不为0时重启，即失败重启
• Never:永远不重启

三、静态Pod

Pod分为两类，一类是普通Pod，通过yaml创建，一类是静态Pod（Static Pod）。

静态Pod
(1) 静态Pod是由kubelet进行管理的；
(2) 存在于特定的Node上，比如master节点Node；
(3) 无法与ReplicationController,Ddeployment或者DaemonSet进行关联，也无法进行健康检查。

普通Pod
(1) 通过API Server进行管理；
(2) 随机分配到某个node执行，除非使用 selectNode 属性指定运行在哪个node上；
(3) 可以与ReplicationController,Ddeployment或者DaemonSet进行关联，也无法进行健康检查。

静态Pod可以通过 kubectl get pods -o wide -n kube-system 来查看，这些都是 kubeadm-init 初始化安装的， 在 /etc/kubernetes/manifests 目录下， 里面有很多 yaml ，如下：

问题：开发中，程序员如何一眼判断哪些是静态Pod，哪些是普通Pod？
回答：静态Pod存在于特定的Node上，比如master节点Node。使用 kubectl get pod -o wide ，查看 IP 这一列，这一列都是内网ip，但是有不同，静态Pod都是使用的是具体的node的内网ip，普通Pod使用的都是 calico 生成的虚拟IP。

四、Pod的健康检查

pod的健康检查：deployment里面的一个可选属性，即是否开启健康检查。

官网：https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes

Pod的健康检查是通过探针来完成的，针对运行中的容器，kubelet 可以选择是否执行以下三种探针（存活态探针、就绪态探针、启动探针 ），以及如何针对探测结果作出反应：

livenessProbe
指示容器是否正在运行。如果存活态探测失败，则 kubelet 会杀死容器， 并且容器将根据其重启策略(三种：Always、OnFailure、Never)决定未来。如果容器不提供存活探针， 则默认状态为 Success。

readinessProbe
指示容器是否准备好为请求提供服务。如果就绪态探测失败， 端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。 初始延迟之前的就绪态的状态值默认为 Failure。 如果容器不提供就绪态探针，则默认状态为 Success。

startupProbe
指示容器中的应用是否已经启动。如果提供了启动探针，则所有其他探针都会被 禁用，直到此探针成功为止。如果启动探测失败，kubelet 将杀死容器，而容器依其 重启策略进行重启。 如果容器没有提供启动探测，则默认状态为 Success。

五、Pod的资源占用

Pod资源两要素: cpu + 内存
Pod共享两要素:网络+磁盘持久化

因为K8S的最小操作单元是Pod，所以这里主要讨论的是Pod的资源

官网：https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/

在K8S的集群中，Node节点的资源信息会上报给APIServer

requests 和 limits 可以通过这两个属性设置cpu和内存

vi resource.yaml
kubectl apply -f resource.yaml
kubctl get pod -o wide
kubectl describe node pod所在node节点

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
 containers:
  - name: db
    image: mysql
    env:
      - name: MYSQL_ROOT_PASSWORD
        value: "password"
    resources:
      requests:
        memory: "6Mi"     # 表示6M需要内存
        cpu: "25m"        # 表示需要0.025核的CPU
      limits:
        memory: "12Mi"    
        cpu: "50m"

limits 是上限，request是最小需要(即下限)

总结