目录
生命周期图示
init 容器
初始化容器,在 main c 运行之前运行,init 在运行结束后会自行删除。
特点
总是运行到成功完成为止
每个 init 容器在运行完成后才能运行下一个 init 容器
(如果 pod 的 init 运行失败,kubernetes 会不断的重启该 pod 直到成功为止。如果该 pod 对应的 restartPolicy 为 never,则不会重启。)
作用
Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。
Init 容器可以安全地运行这些工具,避免这些工具导致应用镜像的安全性降低。
应用镜像的创建者和部署者可以各自独立工作,而没有必要联合构建一个单独的应用镜像。
Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此,Init容器可具有访问 Secrets 的权限,而应用容器不能够访问。
由于 Init 容器必须在应用容器启动之前运行完成,因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动,直到满足了一组先决条件。一旦前置条件满足,Pod内的所有的应用容器会并行启动。
资源清单
vim init-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: init-pod
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: busyboxplus
command: ['/bin/sh','-c','echo the app is running && sleep 3600']
initContainers:
- name: myservice
image: busyboxplus
command: ['/bin/sh','-c','until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
- name: mydb
image: busyboxplus
command: ['/bin/sh','-c','until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
kubectl apply -f init-pod.yaml
kubectl get pod
kubectl logs init-pod myservice
kubectl apply -f myservice.yaml
kubectl apply -f mydb.yaml
kubectl get svc
kubectl get pod
探针
探针是由 kubelet 对容器进行定期的诊断,kubelet 调用容器实现的 Handler。
类型
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。
readiness就绪探针
apiVersion: v1
kind: Pod
metadata:
name: readness
namespace: default
spec:
containers:
- name: readness-docker
image: myapp:v1
imagePullPolicy: IfNotPresent
readinessProbe:
httpGet:
port: 80
path: index1.html
initialDelaySeconds: 1
periodSeconds: 3
使用 httpGet 来检测pod中是否有 index1.html 文件,如果有则为就绪状态,没有则不就绪。
使用 kubectl exec readness -it -- /bin/sh 在容器内部创建 index1.html 再次查看则就绪。
liveness存活探针
1. exec 的检测方式
apiVersion: v1
kind: Pod
metadata:
name: liveness
namespace: default
spec:
containers:
- name: liveness-docker
image: busyboxplus
imagePullPolicy: IfNotPresent
command: ["/bin/sh","-c","touch /wty;sleep 60;rm -rf /wty; sleep 3600"]
livenessProbe:
exec:
command: ["test","-e","/wty"]
initialDelaySeconds: 1
periodSeconds: 3
运行容器时创建 /wty 并在 60s 后删除,在 60s 后在检测到 /wty 不存在,容器开始重启。开始不断重复上述内容。
2.httGet 的检测方式
apiVersion: v1
kind: Pod
metadata:
name: liveness-httpget
namespace: default
spec:
containers:
- name: live-docker
image: myapp:v1
imagePullPolicy: IfNotPresent
livenessProbe:
httpGet:
port: 80
path: index.html
initialDelaySeconds: 1
periodSeconds: 3
timeoutSeconds: 10
容器运行时,检测 index.html 文件是否存在,存在则正常运行,不存在则重启。
使用 curl 访问正常,进入容器中删除 index.html 在使用 curl 发现无法访问。过10秒之后开始重启,则又可以正常访问。
3.tcp 的检测方式
apiVersion: v1
kind: Pod
metadata:
name: liveness-tcp
namespace: default
spec:
containers:
- name: live-docker
image: myapp:v1
imagePullPolicy: IfNotPresent
livenessProbe:
timeoutSeconds: 10
initialDelaySeconds: 1
periodSeconds: 3
tcpSocket:
port: 8080
和上述的 httpGet 相同,不过该检测的是端口8080。
启动退出动作
apiVersion: v1
kind: Pod
metadata:
name: start-stop
namespace: default
spec:
containers:
- name: pod-docker
image: busyboxplus
lifecycle:
postStart:
exec:
command: ["/bin/sh","-c","echo hello postStart > /wty"]
preStop:
exec:
command: ["/bin/sh","-c","echo hello postStart > /wty"]
容器开始时执行 echo hello postStart 结束时也执行 echo hello postStart
通过 kubectl exec start-stop -it -- /bin/sh 来进行查看
K8S状态可能存在的值
1. 挂起(Pending):Pod 已经被 kubernetes 所接受,但有一个或者多个容器镜像尚未被创建,等待时间包括调度 Pod 的时间和通过网络下载镜像的时间
2.运行中(Running):该 Pod 已经被绑到一个 node 上,Pod 中所有的容器已经被创建,至少有一个容器正在运行,或者正处于启动或重启的状态
3.成功(Succeeded):Pod 所有的容器都被成功终止,并且不会重启
4.失败(Failed):Pod中的所有容器以及被终止了,并且至少有一个容器是因为失败而终止的。也就是说,容器是以非 0 状态退出或被终止
5.未知(Unknown):因为某些原因无法取得 Pod 的状态,通常是因为与 Pod 所在主机通信失败