(五)Kubernetes Pod状态和生命周期管理
Pod中封装着应用的容器（有的情况下是好几个容器），存储、独立的网络IP，管理容器如何运行的策略选项。Pod代表着部署的一个单位：kubernetes中应用的一个实例，可能由一个或者多个容器组合在一起共享资源。
Docker是kubernetes中最常用的容器运行时，但是Pod也支持其他容器运行时。在
Kubernetes集群中Pod有如下两种方式：
一个Pod中运行一个容器。“每个
Pod中一个容器”的模式是最常见的用法；在这种使用方式中，你可以把Pod想象成单个容器的封装，Kubernetes管理的是Pod而不是直接管理容器。在一个Pod中同时运行多个容器。一个
Pod也可以同时封装几个需要紧密耦合互相协作的容器，它们之间共享资源。这些在同一个Pod中的容器可以互相协作成为一个service单位——一个容器共享文件，另一个“sidecar”容器来更新这些文件。Pod将这些容器的存储资源作为一个实体来管理。
Pod中共享的环境包括Linux的namespace、cgroup和其他可能的隔绝环境，这一点跟Docker容器一致。在Pod的环境中，每个容器可能还有更小的子隔离环境。
Pod中的容器共享IP地址和端口号，它们之间可以通过localhost互相发现。它们之间可以通过进程间通信，例如SystemV信号或者POSIX共享内存。不同Pod之间的容器具有不同的IP地址，不能直接通过IPC通信。
Pod中的容器也有访问共享volume的权限，这些volume会被定义成pod的一部分并挂载到应用容器的文件系统中。就像每个应用容器，
pod被认为是临时（非持久的）实体。在Pod的生命周期中讨论过，pod被创建后，被分配一个唯一的ID（UID），调度到节点上，并一致维持期望的状态直到被终结（根据重启策略）或者被删除。如果node死掉了，分配到了这个node上的pod，在经过一个超时时间后会被重新调度到其他node节点上。一个给定的pod（如UID定义的）不会被“重新调度”到新的节点上，而是被一个同样的pod取代，如果期望的话甚至可以是相同的名字，但是会有一个新的UID。
注意在一个
Pod中同时运行多个容器是一种比较高级的用法。只有当你的容器需要紧密配合协作的时候才考虑用这种模式。例如，你有一个容器作为web服务器运行，需要用到共享的volume，有另一个“sidecar”容器来从远端获取资源更新这些文件，如下图所示：
网络：每个
pod都会被分配一个唯一的IP地址。Pod中的所有容器共享网络空间，包括IP地址和端口。Pod内部的容器可以使用localhost互相通信。Pod中的容器与外界通信时，必须分配共享网络资源（例如使用宿主机的端口映射）。存储：可以为一个
Pod指定多个共享的Volume。Pod中的所有容器都可以访问共享的volume。Volume也可以用来持久化Pod中的存储资源，以防容器重启后文件丢失。
注意：重启
Pod中的容器跟重启Pod不是一回事。Pod只提供容器的运行环境并保持容器的运行状态，重启容器不会造成Pod重启。
Pod不会自愈。如果Pod运行的Node故障，或者是调度器本身故障，这个Pod就会被删除。同样的，如果Pod所在Node缺少资源或者Pod处于维护状态，Pod也会被驱逐。Kubernetes使用更高级的称为Controller的抽象层，来管理Pod实例。虽然可以直接使用Pod，但是在Kubernetes中通常是使用Controller来管理Pod的。
Controller可以创建和管理多个Pod，提供副本管理、滚动升级和集群级别的自愈能力。例如，如果一个Node故障，Controller就能自动将该节点上的Pod调度到其他健康的Node上。
无论是手动创建还是通过
Deployment等控制器创建，Pod对象总是应该处于其生命进程中以下几个相位（phase）之一。
挂起（
Pending）：API Server创建了pod资源对象已存入etcd中，但它尚未被调度完成，或者仍处于从仓库下载镜像的过程中。运行中（
Running）：Pod已经被调度至某节点，并且所有容器都已经被kubelet创建完成。成功（
Succeeded）：Pod中的所有容器都已经成功终止并且不会被重启失败（
Failed）：Pod中的所有容器都已终止了，并且至少有一个容器是因为失败终止。即容器以非0状态退出或者被系统禁止。未知（
Unknown）：Api Server无法正常获取到Pod对象的状态信息，通常是由于无法与所在工作节点的kubelet通信所致。
API Server尝试着将Pod对象的相关信息存入etcd中，待写入操作执行完成，API Server即会返回确认信息至客户端。
API Server开始反映etcd中的状态变化。所有的
kubernetes组件均使用“watch”机制来跟踪检查API Server上的相关的变动。
kube-scheduler（调度器）通过其“watcher”觉察到API Server创建了新的Pod对象但尚未绑定至任何工作节点。
kube-scheduler为Pod对象挑选一个工作节点并将结果信息更新至API Server。调度结果信息由
API Server更新至etcd存储系统，而且API Server也开始反映此Pod对象的调度结果。
Pod被调度到的目标工作节点上的kubelet尝试在当前节点上调用Docker启动容器，并将容器的结果状态返回送至API Server。
API Server将Pod状态信息存入etcd系统中。在
etcd确认写入操作成功完成后，API Server将确认信息发送至相关的kubelet，事件将通过它被接受。
1）初始化容器必须运行完成直至结束，若某初始化容器运行失败，那么
kubernetes需要重启它直到成功完成。（注意：如果pod的spec.restartPolicy字段值为“Never”，那么运行失败的初始化容器不会被重启。）2）每个初始化容器都必须按定义的顺序串行运行。
容器探测（
container probe）是Pod对象生命周期中的一项重要的日常任务，它是kubelet对容器周期性执行的健康状态诊断，诊断操作由容器的处理器（handler）进行定义。Kubernetes支持三种处理器用于Pod探测：
ExecAction：在容器内执行指定命令，并根据其返回的状态码进行诊断的操作称为Exec探测，状态码为0表示成功，否则即为不健康状态。
TCPSocketAction：通过与容器的某TCP端口尝试建立连接进行诊断，端口能够成功打开即为正常，否则为不健康状态。
HTTPGetAction：通过向容器IP地址的某指定端口的指定path发起HTTP GET请求进行诊断，响应码为2xx或3xx时即为成功，否则为失败。任何一种探测方式都可能存在三种结果：
“Success”（成功）、“Failure”（失败）、“Unknown”（未知），只有success表示成功通过检测。
容器探测分为两种类型：
存活性探测（livenessProbe）：用于判定容器是否处于“运行”（
Running）状态；一旦此类检测未通过，kubelet将杀死容器并根据重启策略（restartPolicy）决定是否将其重启；未定义存活检测的容器的默认状态为“Success”。就绪性探测（readinessProbe）：用于判断容器是否准备就绪并可对外提供服务；未通过检测的容器意味着其尚未准备就绪，端点控制器（如
Service对象）会将其IP从所有匹配到此Pod对象的Service对象的端点列表中移除；检测通过之后，会再将其IP添加至端点列表中。
如果希望容器在探测失败时被杀死并重新启动，那么请指定一个存活探针，并指定
restartPolicy为Always或OnFailure。如果要仅在探测成功时才开始向
Pod发送流量，请指定就绪探针。在这种情况下，就绪探针可能与存活探针相同，但是spec中的就绪探针的存在意味着Pod将在没有接收到任何流量的情况下启动，并且只有在探针探测成功才开始接收流量。如果希望容器能够自行维护，可以指定一个就绪探针，该探针检查与存活探针不同的端点。
注意：如果只想在
Pod被删除时能够排除请求，则不一定需要使用就绪探针；在删除Pod时，Pod会自动将自身置于未完成状态，无论就绪探针是否存在。当等待Pod中的容器停止时，Pod仍处于未完成状态。
Always：但凡
Pod对象终止就将其重启，默认值OnFailure：仅在
Pod对象出现错误时方才将其重启Never：从不重启
[root@k8s-master ~]# vim manfests/liveness-exec.yaml apiVersion: v1 kind: Pod metadata: name: liveness-exec-pod namespace: default labels: test: liveness-exec spec: containers: - name: liveness-exec-container image: busybox:latest imagePullPolicy: IfNotPresent command: ["/bin/sh","-c","touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 3600"] livenessProbe: exec: command: ["test","-e","/tmp/healthy"] initialDelaySeconds: 1 periodSeconds: 3 [root@k8s-master ~]# kubectl create -f manfests/liveness-exec.yaml #创建pod pod/liveness-exec-pod created [root@k8s-master ~]# kubectl get pods #查看pod NAME READY STATUS RESTARTS AGE liveness-exec-pod 1/1 Running 0 6s #等待一段时间后再次查看其状态 [root@k8s-master ~]# kubectl get pods NAME READY STATUS RESTARTS AGE liveness-exec-pod 1/1 Running 2 2m46s
host <string>：请求的主机地址，默认为Pod IP，也可以在httpHeaders中使用“Host:”来定义。 httpHeaders <[]Object>：自定义的请求报文首部。 port <string>：请求的端口，必选字段。 path <string>：请求的HTTP资源路径，即URL path。 scheme <string>：建立连接使用的协议，仅可为HTTP或HTTPS，默认为HTTP。
[root@k8s-master ~]# vim manfests/liveness-httpget.yaml apiVersion: v1 kind: Pod metadata: name: liveness-http namespace: default labels: test: liveness spec: containers: - name: liveness-http-demo image: nginx:1.12 imagePullPolicy: IfNotPresent ports: - name: http containerPort: 80 lifecycle: postStart: exec: command: ["/bin/sh", "-c", "echo Healthz > /usr/share/nginx/html/healthz"] livenessProbe: httpGet: path: /healthz port: http scheme: HTTP [root@k8s-master ~]# kubectl create -f manfests/liveness-httpget.yaml #创建pod pod/liveness-http created [root@k8s-master ~]# kubectl get pods #查看pod NAME READY STATUS RESTARTS AGE liveness-http 1/1 Running 0 7s [root@k8s-master ~]# kubectl describe pods/liveness-http #查看liveness-http详细信息 ...... Containers: liveness-http-demo: ...... Port: 80/TCP Host Port: 0/TCP State: Running Started: Mon, 09 Sep 2019 15:43:29 +0800 Ready: True Restart Count: 0 ......
[root@k8s-master ~]# kubectl exec pods/liveness-http -it -- /bin/sh #进入到上面创建的pod中 # rm -rf /usr/share/nginx/html/healthz #删除healthz测试页面 # [root@k8s-master ~]# kubectl get pods NAME READY STATUS RESTARTS AGE liveness-http 1/1 Running 1 10m [root@k8s-master ~]# kubectl describe pods/liveness-http ...... Containers: liveness-http-demo: ...... Port: 80/TCP Host Port: 0/TCP State: Running Started: Mon, 09 Sep 2019 15:53:04 +0800 Last State: Terminated Reason: Completed Exit Code: 0 Started: Mon, 09 Sep 2019 15:43:29 +0800 Finished: Mon, 09 Sep 2019 15:53:03 +0800 Ready: True Restart Count: 1 ......
host <string>：请求连接的目标IP地址，默认为Pod IP port <string>：请求连接的目标端口，必选字段
[root@k8s-master ~]# vim manfests/liveness-tcp.yaml apiVersion: v1 kind: Pod metadata: name: liveness-tcp-pod namespace: default labels: test: liveness-tcp spec: containers: - name: liveness-tcp-demo image: nginx:1.12 imagePullPolicy: IfNotPresent ports: - name: http containerPort: 80 livenessProbe: tcpSocket: port: http
[root@k8s-master ~]# kubectl explain pods.spec.containers.livenessProbe KIND: Pod VERSION: v1 RESOURCE: livenessProbe <Object> exec command 的方式探测，例如 ps 一个进程是否存在 failureThreshold 探测几次失败 才算失败， 默认是连续三次 initialDelaySeconds 初始化延迟探测，即容器启动多久之后再开始探测，默认为0秒 periodSeconds 每隔多久探测一次，默认是10秒 successThreshold 处于失败状态时，探测操作至少连续多少次的成功才算通过检测，默认为1秒 timeoutSeconds 存活性探测的超时时长，默认为1秒 httpGet http请求探测 tcpSocket 端口探测
与存活性探测机制类似，就绪性探测是用来判断容器就绪与否的周期性（默认周期为10秒钟）操作，它用于探测容器是否已经初始化完成并可服务于客户端请求，探测操作返回
”success“状态时，即为传递容器已经”就绪“的信号。就绪性探测也支持
Exec、HTTPGet和TCPSocket三种探测方式，且各自的定义机制也都相同。但与存活性探测触发的操作不同的是，探测失败时，就绪探测不会杀死或重启容器以保证其健康性，而是通知其尚未就绪，并触发依赖于其就绪状态的操作（例如，从Service对象中移除此Pod对象）以确保不会有客户端请求接入此Pod对象。
设置HTTP探针示例
#终端1： [root@k8s-master ~]# vim manfests/readiness-httpget.yaml #编辑readiness-httpget测试pod的yaml文件 apiVersion: v1 kind: Pod metadata: name: readiness-http namespace: default labels: test: readiness-http spec: containers: - name: readiness-http-demo image: nginx:1.12 imagePullPolicy: IfNotPresent ports: - name: http containerPort: 80 readinessProbe: httpGet: path: /index.html port: http scheme: HTTP [root@k8s-master ~]# kubectl create -f manfests/readiness-httpget.yaml #创建pod pod/readiness-http created [root@k8s-master ~]# kubectl get pods 查看pod状态 NAME READY STATUS RESTARTS AGE liveness-tcp-pod 1/1 Running 1 7d18h readiness-http 1/1 Running 0 7s #新打开一个终端2进入到容器里面 [root@k8s-master ~]# kubectl exec pods/readiness-http -it -- /bin/sh #进入上面创建的pod # rm -f /usr/share/nginx/html/index.html #删除nginx的主页面文件 # ls /usr/share/nginx/html 50x.html # #回到终端1上面查看pod状态 [root@k8s-master ~]# kubectl get pods #查看pod状态 NAME READY STATUS RESTARTS AGE liveness-tcp-pod 1/1 Running 1 7d18h readiness-http 0/1 Running 0 2m44s
浙公网安备 33010602011771号