目录
一、概述
二、init容器
1.概述
2.init容器作用
3.InitC容器示例
三、容器探针
1.概述
2.探针类型
3.readinessProbe-就绪检测示例
4.livenessProbe-存活检测示例
5.livenessProbe-tcp--检测端口模板
四、钩子
1.概述
2.yaml模板
3.示例
一、概述
1.当一个pod被创建的时候，会启动第一个容器pause。
作用：挂载可能存在的存储卷，初始化网络栈，后来僵尸进程的杀死。维护。
2.pause容器启动后，就会启动另一个部分， 不是mainC，而是initC（初始化容器，initC>=0）
initC初始化容器的特性：
-
线性启动:
- 阻塞特性，前一个initC-1必须退出，后面的initC-2才会运行。执行退出命令的返回码为0，代表成功退出。如果initC启动过程中失败，出现错误，那么pause会重新开始创建initC-1，initC-2，initC-3等等。只有所有initC全部成功启动退出，才会继续往下运行。
-
独立于应用容器:
- Init 容器可以有自己的独立镜像，这与应用容器使用的镜像可以完全不同。因此，它们具有其特殊的依赖和工具，不会影响应用容器的镜像构成。
-
运行到完成:
- Init 容器必须在终止前运行到完成。它们不是用来启动长期运行的进程的。一旦它们成功执行了启动命令，它们就会终止。
-
重新启动策略:
- 如果 Init 容器失败，Kubernetes 默认的重新启动策略是 'Always'，它会一直重试直到容器成功为止。这与应用容器的启动失败策略是独立的。
-
资源限制:
- 与应用容器一样，可以对 Init 容器设置资源请求和限制。
-
与应用容器共享卷:
- Init 容器可以访问与应用容器相同的数据卷。这意味着它们可以用来准备或修改数据，这些数据后续将由应用容器使用。
-
运行环境隔离:
- Init 容器和应用容器可以有不同的运行环境和根文件系统。它们甚至可以在不同的命名空间下执行，从而提供额外的安全隔离。
二、init容器
1.概述
Pod 能够具有多个容器，应用运行在容器里面，但是它也可能有一个或多个先于应用容器启动的 Init 容器。
Init 容器与普通的容器非常像，除了如下两点：
1. Init 容器总是运行到成功完成为止
2. 每个 Init 容器都必须在下一个 Init 容器启动之前成功完成
如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。然而，如果 Pod 对应的 restartPolicy 为 Never，它不会重新启动。
2.init容器作用
因为 Init 容器具有与应用程序容器分离的单独镜像，所以它们的启动相关代码具有如下优势：
1. 可以包含并运行实用工具，但是出于安全考虑，是不建议在应用程序容器镜像中包含这些实用工具的。
2. 应用程序镜像可以分离出创建和部署的角色，而没有必要联合它们构建一个单独的镜像。
3. Init 容器使用 Linux Namespace，所以相对应用程序容器来说具有不同的文件系统视图。因此，它们能够具有访问 Secret 的权限，而应用程序容器则不能。
4. 它们必须在应用程序容器启动之前运行完成，而应用程序容器是并行运行的，所以 Init 容器能够提供了一种简单的阻塞或延迟应用容器的启动的方法，直到满足了一组先决条件。
3.InitC容器示例
vim initC-pod.yamlapiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: busybox:1.35.0
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
initContainers:
- name: init-myservice
image: busybox:1.35.0
command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
- name: init-mydb
image: busybox:1.35.0
command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
kubectl apply -f initC-pod.yaml
kubectl get pod
kubectl describe pod myapp-pod
kubectl logs myapp-pod -c init-myservice
#因为这里无法解析myservice的dns地址，所以才会报错 
kubectl create svc clusterip myservice --tcp=80:80
kubectl get svc
kubectl get pod
#这里只加载好一个是因为，只解析了myservice的DNS，找不到mydb的DNS，所以无法加载
kubectl create svc clusterip mydb --tcp=80:80
#稍等一会再次查看,就会加载完成
kubectl get pod
三、容器探针
1.概述
探针是由 kubelet 对容器执行的定期诊断。要执行诊断，kubelet 调用由容器实现的 Handler。有三种类型的处理程序：
（1）ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
（2）TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。
（3）HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的
2.探针类型
livenessProbe：指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其 重启策略 的影响。如果容器不提供存活探针，则默认状态为 Success
readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success
存活探测：
探测失败：根据重启策略进行重载
探测成功：静默，等待下一次的存活探测
探测未知：静默，等待下一次探测
就绪探测：如果mainC 不添加就绪探测，默认就绪，如果添加就绪探测，必须就绪通过后才标记就绪
探测失败：静默，等待下一次的探测
探测成功：将当前的未就绪状态，改为就绪
探测未知：静默，等待下一次探测
3.readinessProbe-就绪检测示例
vim readiness-pod.yamlapiVersion: v1
kind: Pod
metadata:
name: readiness-httpget-pod
namespace: default
labels:
app: myapp
env: test
spec:
containers:
- name: readiness-httpget-container
image: nginx:latest
imagePullPolicy: IfNotPresent
readinessProbe:
httpGet:
port: 80
path: /index1.html
initialDelaySeconds: 1 #延迟的间隔是一秒
periodSeconds: 3 #检测的间隔时间是3秒
timeoutSeconds: 3 #超时时间是3秒kubectl create -f readiness-pod.yaml
kubectl get pod
#未就绪状态，因为请求不到index1.html文件
kubectl exec -it readiness-httpget-pod -- /bin/sh#pod中添加index1.html文件
cd /usr/share/nginx/html/
echo "123" > index1.html
exit
#就绪状态，可以正常对外提供访问
kubectl get pod
4.livenessProbe-存活检测示例
vim livenessProbe-pod.yamlapiVersion: v1
kind: Pod
metadata:
name: liveness-exec-pod
namespace: default
spec:
restartPolicy: Never
containers:
- name: liveness-exec-container
image: busybox:1.35.0
imagePullPolicy: IfNotPresent
command: ["/bin/sh","-c","touch /tmp/live ; sleep 60; rm -rf /tmp/live; sleep 3600"]
livenessProbe:
exec:
command: ["test","-e","/tmp/live"]
initialDelaySeconds: 1 #延迟的间隔是一秒
periodSeconds: 3 #检测的间隔时间是3秒
timeoutSeconds: 3 #超时时间是3秒
kubectl apply -f livenessProbe-pod.yaml
kubectl get pod
kubectl get pod
#再次查看，已处于error状态。
#文件被删除，存活探测失败。
5.livenessProbe-tcp--检测端口模板
apiVersion: v1
kind: Pod
metadata:
name: probe-tcp
spec:
containers:
- name: nginx
image: nginx:latest
livenessProbe: #存活探测
initialDelaySeconds: 5 #初始化间隔时间时5秒
timeoutSeconds: 1 #超时时间是1秒
periodSeconds: 3 #检测间隔是3秒
tcpSocket:
port: 80 #检测的端口是80说明：这种方式不太好，检测端口是否存在，不代表服务能正常响应。
四、钩子
1.概述
Pod hook（钩子）是由 Kubernetes 管理的 kubelet 发起的，当容器中的进程启动前或者容器中的进程终止之前运行，这是包含在容器的生命周期之中。可以同时为 Pod 中的所有容器都配置 hook。
Hook 的类型包括两种：
exec：执行一段命令
HTTP：发送 HTTP 请求
启动后钩子可以编译软件，挂载存储。
关闭前钩子可以保存文件，解除存储。
2.yaml模板
apiVersion: v1
kind: Pod
metadata:
name: lifecycle-demo
spec:
containers:
- name: lifecycle-demo-container
image: nginx:latest
lifecycle:
postStart: #启动后
exec:
command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
preStop: #关闭前
exec:
command: ["/bin/sh", "-c", "echo Hello from the preStop handler > /usr/share/message"]3.示例
vim lifecycle-pod.yamlapiVersion: v1
kind: Pod
metadata:
name: lifecycle-demo
spec:
containers:
- name: lifecycle-demo-container
image: nginx:latest
lifecycle:
postStart:
exec:
command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
preStop:
exec:
command: ["/bin/sh", "-c", "echo Hello from the preStop handler > /usr/share/message"]kubectl apply -f lifecycle-pod.yaml
kubectl get pod
kubectl exec -it lifecycle-demo -- /bin/sh#pod中执行
while 2>1;do cat /usr/share/message;done#再开一个终端删除pod，然后观察原终端的返回信息
kubectl delete pod --all
