Kubernetes(k8s)四、Pod生命周期（初始化容器的应用，探针liveness、readliness应用，）

Pod生命周期

学习目标：初始化容器的应用及两个探针的应用
探针是由 kubelet 对容器执行的定期诊断:
Kubelet 可以选择是否执行在容器上运行的三种探针执行和做出反应：
liveness实例
readiness实例
初始化容器+ svc

学习目标：初始化容器的应用及两个探针的应用

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

Init 容器与普通的容器非常像，除了如下两点：
它们总是运行到完成。
Init 容器不支持 Readiness（就绪探针），因为它们必须在 Pod 就绪之前运行完成，每个 Init 容器必须运行成功，下一个才能够运行。

如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。然而，如果 Pod 对应的 restartPolicy 值为 Never，它不会重新启动。

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

探针是由 kubelet 对容器执行的定期诊断:

ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。
HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的。

每次探测都将获得以下三种结果之一：
成功：容器通过了诊断。
失败：容器未通过诊断。
未知：诊断失败，因此不会采取任何行动。

Kubelet 可以选择是否执行在容器上运行的三种探针执行和做出反应：

livenessProbe指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为 Success。

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

startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探测(startup probe)，则禁用所有其他探测，直到它成功为止。如果启动探测失败，kubelet 将杀死容器，容器服从其重启策略进行重启。如果容器没有提供启动探测，则默认状态为成功Success。

重启策略
PodSpec 中有一个 restartPolicy 字段，可能的值为 Always、OnFailure 和 Never。默认为 Always。

Pod 的生命
一般Pod 不会消失，直到人为销毁他们，这可能是一个人或控制器。

建议创建适当的控制器来创建 Pod，而不是直接自己创建 Pod。因为单独的 Pod 在机器故障的情况下没有办法自动复原，而控制器却可以。

三种可用的控制器：
使用 Job 运行预期会终止的 Pod，例如批量计算。Job 仅适用于重启策略为 OnFailure 或 Never 的 Pod。
对预期不会终止的 Pod 使用 ReplicationController、ReplicaSet 和 Deployment ，例如 Web 服务器。 ReplicationController 仅适用于具有 restartPolicy 为 Always 的 Pod。
提供特定于机器的系统服务，使用 DaemonSet 为每台机器运行一个 Pod 。

官方文档
https://kubernetes.io/zh/docs/concepts/workloads/pods/pod-lifecycle/

https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

liveness实例

指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为 Success。

[root@server2 ~]# cat pod3.yml
apiVersion: v1
kind: Pod
metadata:labels:test: livenessname: liveness-exec
spec:containers:- name: livenessimage: busyboxplusargs:- /bin/sh- -c- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600livenessProbe:exec:command:- cat- /tmp/healthyinitialDelaySeconds: 5periodSeconds: 5

会重启

readiness实例

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

[root@server2 ~]# cat pod3.yml
apiVersion: v1
kind: Pod
metadata:labels:test: livenessname: liveness-exec
spec:containers:- name: livenessimage: myapp:v1livenessProbe:tcpSocket:port: 80initialDelaySeconds: 2   #启动需要2秒periodSeconds: 3  #间隔3秒readinessProbe:httpGet:path: /test.htmlport: 80initialDelaySeconds: 3   #启动需要3秒periodSeconds: 3  #间隔3秒

kubectl delete -f pod3.yml

kubectl create -f pod3.yml

[root@server2 ~]# cat pod3.yml
apiVersion: v1
kind: Pod
metadata:labels:test: livenessname: liveness-exec
spec:containers:- name: livenessimage: myapp:v1livenessProbe:tcpSocket:port: 8080    ###端口错误initialDelaySeconds: 2   #启动需要2秒periodSeconds: 3  #间隔3秒readinessProbe:httpGet:path: /hostname.htmlport: 80initialDelaySeconds: 3   #启动需要3秒periodSeconds: 3  #间隔3秒

https://kubernetes.io/zh/docs/concepts/workloads/pods/init-containers/
检测服务

创建初始化
初始化容器一直在初始化，

初始化容器+ svc

创建思路
创建service后会提供dns解析
service.yml就是创建一个svc
没有endpoint
访问不到，但可以解析。进入Demo，nslookup myserice通过域名会更加简单，
myapp一个应用容器，plus，初始化容器，一直nslook解析，解析过才能退出，才能运行myapp，

所以不能先创建svc,先创建初始化,正在初始化，init contaoners，没有得到相应的解析，看日志，一直停在初始化,
此时创建svc，可以解析到
初始化容器优先于普通容器myapp，而且必须运行成功后才能完成，解析到域名，退出，结束，此时才能运行应用容器myapp

[root@server2 ~]# cat service.yml
apiVersion: v1
kind: Service
metadata:name: myservice
spec:ports:- protocol: TCPport: 80targetPort: 80


[root@server2 ~]# cat init.yml
apiVersion: v1
kind: Pod
metadata:name: myapp-podlabels:app: myapp
spec:containers:- name: myapp-containerimage: myapp:v1initContainers:- name: init-myserviceimage: busyboxpluscommand: ['sh', '-c', "until nslookup myservice.default.svc.cluster.local; do echo waiting for myservice; sleep 2; done"]

[root@server2 ~]# kubectl create -f init.yml
pod/myapp-pod created
[root@server2 ~]# kubectl  get pod
NAME                     READY   STATUS             RESTARTS   AGE
demo                     1/1     Running            6          17h
liveness-exec            0/1     CrashLoopBackOff   87         3h43m
myapp-pod                0/1     Init:0/1           0          5s
nginx-597468cf8f-p9m6z   2/2     Running            3          13h
[root@server2 ~]# kubectl  create -f service.yml
service/myservice created
[root@server2 ~]# kubectl  get svc
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP   9d
myservice    ClusterIP   10.100.197.241   <none>        80/TCP    10s
[root@server2 ~]# kubectl get pod
NAME                     READY   STATUS             RESTARTS   AGE
demo                     1/1     Running            6          17h
liveness-exec            0/1     CrashLoopBackOff   87         3h45m
myapp-pod                1/1     Running            0          2m19s
nginx-597468cf8f-p9m6z   2/2     Running            3          13h

查看日志：

kubectl logs myapp-pod -c init-myservice # 查看第一个 Init 容器