linux企业级运维-----＞kubernetes（4）Pod生命周期

一、Pod的相位

Pod的status字段是PodStatus对象，它拥有一个名为phase的字段即Pod的相位。
pod的相位是对Pod的生命周期中所属位置的一种简单宏观的概述。相位不是pod状态或容器状态的汇总，也不是为了当作综合状态机来使用的。

pod的相位值是严格界定的。除了这些已经定义的相位值外，不会有其他任何值的出现。

相位值	说明
Pending	pod已经被kubernetes系统接受，但尚有一个或多个容器镜像未能创建。比如，调度前消耗的运算时间，以及通过网络下载镜像所消耗的时间这些准备时间都会导致容器镜像未创建。
Running	pod已经绑定到node中，所有的容器均已经创建。至少有一个容器还在运行，或者正在启动或重新启动
Succeeded	pod中的所有容器都已经成功终止并且不会重新启动
Failed	pod中的所有容器都已经终止，并且至少有一个容器表现出失败的终止状态。也就是说，容器要么非零退出，要么被系统终止
Unknown	由于某种原因无法获得pod的状态，者通常是pod所在的宿主机通信出错而导致的

在pod的整个生命周期里，会经历两个大的阶段：（1）初始化容器运行阶段（2）正是容器运行阶段

二、init初始化容器运行阶段

1、init容器

Pod 可以包含多个容器,应用运行在这些容器里面,同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。

init容器与普通容器的区别：

（1）它们总是运行到完成。
（2）Init 容器不支持 Readiness,因为它们必须在 Pod 就绪之前运行完成。
每个 Init 容器必须运行成功,下一个才能够运行。

Init 容器能做什么?

• Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化
代码。
• Init 容器可以安全地运行这些工具,避免这些工具导致应用镜像的安全性
降低。
• 应用镜像的创建者和部署者可以各自独立工作,而没有必要联合构建一个
单独的应用镜像。
• Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此,Init容器
可具有访问 Secrets 的权限,而应用容器不能够访问。
• 由于 Init 容器必须在应用容器启动之前运行完成,因此 Init 容器提供了一
种机制来阻塞或延迟应用容器的启动,直到满足了一组先决条件。一旦前
置条件满足,Pod内的所有的应用容器会并行启动。

一些命令

命令	含义
kubectl describe -f myapp.yaml	查看容器详细信息
kubectl logs myapp-pod -c init-myservice	查看pod内指定容器的日志
kubectl create -f services.yaml	创建服务

2、init初始化容器

pause镜像为pod提供了基础的初始化环境

#在server1中查找并拉取busyboxplus镜像并上传到私有仓库
docker login reg.westos.org
docker search busyboxplus
docker pull radial/busyboxplus
docker tag docker.io/radial/busyboxplus:latest reg.westos.org/library/busyboxplus:latest
docker push  reg.westos.org/library/busyboxplus:latest

#在server2中
cd pod
vim init.yaml
-------------------------------------
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
  - name: init-mydb
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]

-----------------------------------------------------
kubectl apply -f init.yaml
kubectl get pod#读取资源清单创建的pod可以看到两个初始化容器都未能成功运行

每个init初始化容器必须成功运行并退出后，主容器才能成功运行，因此pod一直未就绪
在这一刻，Init 容器将会等待至发现名称为 myapp 和 myservice 的 Service。

vim service.yaml
------------------------------
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
---
apiVersion: v1
kind: Service
metadata:
  name: mydb
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9377
---------------------------------
kubectl create -f service.yaml#创建 mydb 和 myservice 服务的命令
kubectl get pod#可以看到pod进入running状态

三、探针

在正是容器刚刚创建成功之后，就会触发postart事件。而在整个容器持续运行的过程中，可以设置存活探针(liveness probe)和就绪探针(readiness probe)来持续检查容器的健康状况。

存活探针：测定容器是否正在运行。如果存活探针返回failure，kubelet会终止容器，然后容器会遵顼其重启策略。如果没有给容器提供存活探针，默认状态是Success。

就绪探针：测定容器是否已经准备好为请求提供服务。如果就绪探针返回failure，endpoint控制器会从所有service的endpoint中移除此pod的ip地址。在出时等待探测时间（也就是容器启动后并在第一册探测之前的时间间隔）内，默认的就绪状态就是failure。如果没有给容器提供就绪探针，默认状态就是success.

探针返回的结果

状态	说明
Success	容器通过诊断
Failure	容器没有通过诊断
Unkonwn	诊断失败，不会采取任何措施

当同时设置存活探针、就绪探针，先判断容器是否存活，再看是否就绪

1、存活探针

#编辑资源清单文件，设置在生成pod时使用存活探针探测容器的8080端口是否开放
#从而指示容器是否正在运行
vim liveness.yaml
-------------------------
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: readness
  name: readiness-http
spec:
  containers:
    - name: readiness
      image: nginx
      imagePullPolicy: IfNotPresent
      livenessProbe:
        tcpSocket:
          port: 8080 #探测容器的8080端口是否开放
        initialDelaySeconds: 1
        periodSeconds: 3
        timeoutSeconds: 1
--------------------------------
kubectl apply -f liveness.yaml
kubectl get pod -w#查看Pod信息可以在状态中看到新建的容器无法成功运行

我们在文件中指定使用nginx镜像创建容器，nginx容器默认开放的是80端口，8080端口不处于侦听状态，存活探针探测到后认为容器未在运行，k8s会杀死容器，并且容器将受到其重启策略的影响

vim liveness.yaml
-----------------------
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: readness
  name: readiness-http
spec:
  containers:
    - name: readiness
      image: nginx
      imagePullPolicy: IfNotPresent
      livenessProbe:
        tcpSocket:
          port: 80 #探测容器的80端口是否开放
        initialDelaySeconds: 1
        periodSeconds: 3
        timeoutSeconds: 1
-----------------------------------
kubectl delete -f liveness.yaml 
kubectl apply -f liveness.yaml
kubectl get pod#查看pod信息可以看到pod成功运行
kubectl describe pod readiness-http#查看pod的详细描述信息可以看到80端口开放

2、就绪探针

#编辑清单文件，设置在生成pod时使用就绪探针检测容器默认发布路径下是否有指定test.html文件
#从而指示容器是否准备好服务请求
vim readiness.yaml
------------------------------
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: readness
  name: readiness-http
spec:
  containers:
    - name: readiness
      image: nginx
      imagePullPolicy: IfNotPresent
      readinessProbe:
        httpGet:
          path: /test.html #指定test.html文件
          port: 80
        initialDelaySeconds: 1
        periodSeconds: 3
        timeoutSeconds: 1
--------------------------
kubectl apply -f readiness.yaml
kubectl get pod
kubectl exec -it readiness-http -- bash
---------------------------
root@readiness-http:/# cd /usr/share/nginx/html/
root@readiness-http:/usr/share/nginx/html# ls
50x.html  index.html
root@readiness-http:/usr/share/nginx/html# echo testpage > test.html
root@readiness-http:/usr/share/nginx/html# cat test.html 
testpage
root@readiness-http:/usr/share/nginx/html# exit
exit
-------------------------------------
kubectl get pod
kubectl get pod -o wide

#删除test.html
kubectl exec -it readiness-http -- rm -f /usr/share/nginx/html/test.html
curl 10.244.1.21/test.html#无法访问发布页面
kubectl get pod#再次查看pod状态，回归未就绪状态
kubectl describe pod readiness-http#查看pod的详细描述信息可以看到pod处于unhealthy状态