Pod的生命周期
- 容器初始化环境
- 运行容器的pause基础容器
- init c容器(init c可以有多个,串行运行)
- main c启动主容器(启动之初允许执行一个执行命令或一个脚本,在结束的时候允许执行一个命令)
- readless
- liveness
Init C
Init容器与普通容器非常像,处理如下两点:
- Init容器总是运行到成功为止
- 每个Init容器都必须在在一个Init容器启动之前完成
如果Pod的Init容器失败,Kubernetes会不断重启该Pod,知道Init容器成功为止。如果Pod对应的restartPolicy为Nerver,它不会重新启动
例:
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
lables:
app: myapp
spec:
containers:
- name: myapp-container
images: busybox
command: ["sh","-c","echo this app is running! && sleep 3600"]
initContainers:
- name: init-myservice
images: busybox
command: ['sh','-c','until nslookup myservice;do echo waiting for myservice;sleep 2;done;']
//until循环nslookup检测myservice是否存在,存在才启动主容器myapp-container,否则一直重启
//init C可以有多个
容器探针
探针是由kubelet对容器执行的定期诊断。kubelet调用由容器实现的Handler,有下面三种类型的处理程序:
- ExecAction: 在容器内执行指定命令,如果命令退出返回码为0则认为成功
- TCPSocketAction:对指定端口上的容器的IP地址做TCP检查,如果端口打开则被认为成功
- HTTPGetAction: 对指定端口和路径上的容器IP指定HTTP Get请求,如状态码大于等于200且小于400则被认为成功
探针探测方式
- livenessProbe: 容器是否正在运行。如果存活探测失败,则kubelet会杀死容器并根据RestarPolicy策略执行相应操作。如果容器不提供存活探针,默认状态为success
- readnessProbe: 容器是否准备好服务请求,如果失败,端点控制器从与Pod匹配的所有Service的端点中删除该Pod的ip地址,初始延迟之前就绪状态为Failure。如果容器不提供就绪探针,默认状态为success‘
//readnessProbe就绪检测(http方式检测)
apiVersion: v1
kind: Pod
metadata:
name: readness-http-pod
spec:
containers:
- name: readness-http-pod
iamges: myapp:v1
readnessProbe:
httpGet:
port: 80
path: /index.html
initalDelaySeconds: 1
periodSeconds: 3
//livenessProbe存活检测(http方式检测)
apiVersion: v1
kind: Pod
metadata:
name: liveness-http-pod
spec:
containers:
- name: liveness-http-pod
iamges: myapp:v1
livenessProbe:
httpGet:
port: 80
path: /index.html
initalDelaySeconds: 1
periodSeconds: 3
timeoutSeconds: 10
Pod在k8s中的状态
- 挂起(pending): Pod已被kubernetes系统接受,但有一个或多个容器镜像未创建,等待时间包括调度Pod的时间和通过网络下载镜像的时间,可能需要花点时间
- 运行中(Running): 该Pod已经绑定到一个节点,Pod中所有的容器都已经被创建。至少有个一容器正在运行或者处于启动或重启状态
- 成功(Successed): Pod中所有容器都被成功终止,并且不会再重启
- 失败(Failed): Pod中所有容器都已经被终止,并且至少有一个容器是因为失败终止。也就是说容器以非0状态退出或被系统终止
- 未知(Unknown): 因为某些原因无法取得Pod的状态,通常是因为与Pod主机通信失败