目录
pod 分类
自主式pod
static Pod
文件方式创建
pod的生命周期
初始化容器 (init container)
pod的五种状态
pod的重启策略(restartPolicy):
Pod健康检测与服务可用性(探针)
ExecAction
TcpSoekcetAction
HTTPGetAction
容器启动前后(postStart与prestop)
pod分为两类:自主式pod与static pod
自主式pod由k8s管理器进行管理,而static pod由kubelet进行创建与管理
自主式pod总是在前台运行,同时接受k8s管理与调度,当集群当中的pod因为某种原因停止,k8s会根据其副本的数量,重新的生成对应的pod
自主式Pod示例:
#创建一个nginx web 服务
apiVersion: v1
kind: Pod
metadata:
name: nginxWeb
namespace: default
labels:
name: nginxWeb
spec:
containers:
- name: nginxWeb
image: nginx
imagePullPolicy: IfNotPresent
ports:
- containerport: 80
#查看运行结果
[root@master mainfest]# kubectl get pod
NAME READY STATUS RESTARTS AGE
nginxweb 1/1 Running 0 65s
static Pod由kubele进行创建管理,一般存在于特定的node上,不通过apiServer管理,并且与Pod管理器(RC,deployment...)无关联,而起kubelet无法实现其健康状态的检查,只能人工手动进行。
static Pod的创建的两种方式:文件方式与http方式
kubelet会定期的扫描读取指定的static Pod的yml文件,kubelet启动时可以使用--config=PATH参数进行配置,指定文件的目录。然后kubelet会根据文件信息生成Pod。
apiVersion: v1
kind: Pod
metadata:
name: test
namespace: default
---
spec:
containers:
- name: test
image: busybox
imagePullPolicy:always
HTTP方式的创建
与文件方式相同,只是配置的kubelet启动参数不同,HTTP的参数的为:--mainfest-url=PATH.
生命周期结构:
在普通容器启动之前会启动一个或者多个的初始化容器,用于完成的容器启动的初始化条件, init c 与其他容器的本质相同,必须的完成之后,才会启动下一个init c 容器。init c 的重启策略是根据容器的重启策略相同,当restartPolicy=Never时,init c 将不会重启,反之,当restartPolicy=Always时,当初始化失败之后,会进行重启直到成功为止。
Pending | Pod已经创建但是的pod当中的容器的没有创建,正在下载容器启动所需要的镜像 |
Running | Pod当中的容器已经创建,至少有一个容器处于已经运行,正在启动或正在重启状态 |
Succeeded | Pod当中的所有容器均成功执行后退出,并且不会重启 |
Fialed | Pod当所有容器均退出,至少有一个容器退出失败 |
Unkown | 无法获取到Pod的状态信息,有可能是网络问题 |
Always | 当容器失败时,会由kubelet重启容器 |
onFailure | 当容器终止运行且终止码不为0时,重启容器 |
Never | 当容器失败后不重启容器 |
pod的重启策略与其控制器息息相关,rc与deployment设置为Always,保证pod失败之后能够立即重启。而job与Cronjob设置为onfailed或者Never,保证任务执行完成之后就结束。
kubernetes对pod进行健康的检测主要是通过两类探针:livnessProbe(存活性探针)与readinessProbe(服务可用性探针)
livenessProbe:存活性探针,用于判断容器是否处于运行,正在启动,或正在重启状态(Running),当探测到容器不健康时,kubelet会根据重启策略,重启容器。当容器当中不存在存活性探针时,那么返回给kubelet的永远是容器处于健康状态(Succeeded)
readinessProbe:服务可用性探针,判断服务是否可用(),对应被service管理的Pod,当Pod处于不健康(not ready),kubernetes会从EndPoint列表当中移除此not ready的服务,保证service不会在进Pod选择时选择到不可用的服务,当有提供正常服务的Pod加入时,会自动加入EndPoint列表当中。
探针的三种的实现方式:
在容器当中的执行一条命令,如果命令执行的返回值为0,表示容器处于健康的状态,查看具体使用方式可以使用kubectl查看
kubectl explain pod.spec.containers.livenessProbe.exec
示例:
apiVersion: v1
kind: Pod
metadata:
name: liveness
labels:
test: liveness
spec:
containers:
- name: liveness
image: busybox
imagePullPolicy: IfNotPresent
args: ["/bin/bash","-c","echo ok> /tmp/heathy","sleep 10","rm -f /tmp/heathy","sleep 6000"]
livenessProbe:
exec:
command: ["cat","/tmp/heathy"]
#initialDelaySeconds:启动容器之后首次进程健康检测的等待时间。
initialDelaySeconds: 15
#timeoutSeconds:发送健康检查的等待响应超时时间,超时,kubelet会认为容器不可用,会对容器根据重启策略重启容器。
timeoutSeconds: 1
通过向容器端口发送tcp报文的方式根据容器响应状态判断容器的是否存活或者容器的服务是否可用。
apiVersion: v1
kind: Pod
metadata:
name: liveness-TCP
labels:
test: liveness-TCP
spec:
containers:
- name: liveness-TCP
image: nginx
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
livenessProbe:
tcpSocket:
port: 80
initialDelaySeconds: 15
timeoutSeconds: 1
通过HTTP协议的的GET方法向容器发送http请求判断容器的状态。
apiVersion: v1
kind: Pod
metadata:
name: liveness-httpGet
labels:
test: liveness-httpGet
spec:
containers:
- name: liveness-httpGet
image: nginx
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
livenessProbe:
httpGet:
path:/_status/heathz
port: 80
initialDelaySeconds: 15
timeoutSeconds: 1
poststart: 容器启动之后立即执行的命令,一般用户资源的配置,环境变量配置。
prestop:容器的在停止之前执行的命令,一般用于通知其他服务。容器停止前的资源保存。
具体实现方式与livenessProbe和readinessProbe相同,可通过kubectl explain查看
kubectl explain pod.spec.containers.[poststart|prestop]