K8s Pod状态与容器探针

1、pod的调度流程及常见状态

1.1、pod的调度流程


Pod创建过程如上图所示，首先用户向apiserver发送创建pod的请求，apiserver收到用于创建pod请求后，对应会对该用户身份信息进行验证，该用户是否是合法的用户，是否具有创建pod的权限，如果能够通过apiserver的验证，则进行下一步，对用户提交的资源进行准入控制，所谓准入控制是指对用户提交的资源做格式，语法的验证，是否满足apiserver中定义的对应资源的api格式和语法；如果上述身份验证和准入控制能够顺利通过，接下来，apiserver才会把对应创建pod的信息存入etcd中，否者就直接拒绝用户创建pod；etcd将对应数据存放好以后，会返回给apiserver一个事件，即创建pod的相关信息已经存入etcd中了；apiserver收到etcd的资源信息存入完成事件后，会返回给用户一个pod创建完成的消息；随后，scheduler通过监视到apiserver上的资源变动事件，会对pod进行调度，调度规则就是先预选（预选就是把不符合pod运行的节点先踢出去，然后在剩下的节点中进行优选），然后再优选（优选就是在满足预选留下的节点中进行打分，得分高者负责运行pod）；scheduler最后通过预选+优选的方式把pod调度到后端某个node节点上运行的结果返回给apiserver，由apiserver将最终调度信息存入etcd中，等待etcd将对应调度信息更新完毕后，再返回给apiserver一个pod状态信息更新完毕，apiserver再将对应状态返回给scheduler；随后负责运行pod的node节点上的kubelet通过监视apiserver的资源变动事件，会发现一个和自己相关的事件，此时对应节点上的kubelet会调用本地容器引擎，将对应pod在本地运行起来；当本地容器引擎将pod正常运行起来后，对应容器引擎会返回给本地kubelet一个pod运行完成的事件，随后再由kubelet将对应事件返回给apiserver，随后apiserver再将pod状态信息存入etcd中,etcd将更新pod状态信息完成的事件通过apiserver将对应事件返回给kubelet；如果此时用户查询pod状态，就能够正常通过apiserver在etcd中检索出来的pod状态；以上就是pod创建的一个大概过程；
1.2、pod的常见状态

• Unschedulable：#Pod不能被调度，kube-scheduler没有匹配到合适的node节点
  
• PodScheduled：#pod正处于调度中，在kube-scheduler刚开始调度的时候，还没有将pod分配到指定的node，在筛选出合适的节点后就会更新etcd数据，将pod分配到指定的node。
  
• Pending: #正在创建Pod但是Pod中的容器还没有全部被创建完成=[处于此状态的Pod应该检查Pod依赖的存储是否有权限挂载等。
  
• Failed：#Pod中有容器启动失败而导致pod工作异常。
  
• Unknown：#由于某种原因无法获得pod的当前状态，通常是由于与pod所在的node节点通信错误。
  
• Initialized：#所有pod中的初始化容器已经完成了。
  
• ImagePullBackOff：#Pod所在的node节点下载镜像失败。
  
• Running：#Pod内部的容器已经被创建并且启动。
  
• Ready：#表示pod中的容器已经可以提供访问服务。
  
• Error: #pod 启动过程中发生错误。
  
• NodeLost: #Pod 所在节点失联。
  
• Waiting: #Pod 等待启动。
  
• Terminating: #Pod 正在被销毁。
  
• CrashLoopBackOff：#pod崩溃，但是kubelet正在将它重启。
  
• InvalidImageName：#node节点无法解析镜像名称导致的镜像无法下载。
  
• ImageInspectError：#无法校验镜像，镜像不完整导致。
  
• ErrImageNeverPull：#策略禁止拉取镜像，镜像中心权限是私有等。
  
• RegistryUnavailable：#镜像服务器不可用，网络原因或harbor宕机。
  
• ErrImagePull：#镜像拉取出错，超时或下载被强制终止。
  
• CreateContainerConfigError：#不能创建kubelet使用的容器配置。
  
• CreateContainerError：#创建容器失败。
  
• RunContainerError：#pod运行失败，容器中没有初始化PID为1的守护进程等。
  
• ContainersNotInitialized：#pod没有初始化完毕。
  
• ContainersNotReady：#pod没有准备完毕。
  
• ContainerCreating：#pod正在创建中。
  
• PodInitializing：#pod正在初始化中。
  
• DockerDaemonNotReady：#node节点decker服务没有启动。
  
• NetworkPluginNotReady：#网络插件没有启动。
  

2、pause容器及init容器

2.1、pause容器简介

Pause 容器，又叫 Infra 容器，是pod的基础容器，镜像体积只有几百KB左右，配置在kubelet中，主要的功能是一个pod中多个容器的网络通信。
Infra 容器被创建后会初始化 Network Namespace，之后其它容器就可以加入到 Infra 容器中共享Infra 容器的网络了，因此如果一个 Pod 中的两个容器 A 和 B，那么关系如下 ：

• A容器和B容器能够直接使用 localhost 通信；
  
• A容器和B容器可以可以看到网卡、IP与端口监听信息。
  
• Pod 只有一个 IP 地址，也就是该 Pod 的 Network Namespace 对应的IP 地址(由Infra 容器初始化并创建)。
  
• k8s环境中的每个Pod有一个独立的IP地址(前提是地址足够用)，并且此IP被当前 Pod 中所有容器在内部共享使用。
  
• pod删除后Infra 容器随机被删除,其IP被回收。
  

2.2、Pause容器共享的Namespace

• NET Namespace：Pod中的多个容器共享同一个网络命名空间，即使用相同的IP和端口信息。
  
• IPC Namespace：Pod中的多个容器可以使用System V IPC或POSIX消息队列进行通信。
  
• .UTS Namespace：pod中的多个容器共享一个主机名。MNT Namespace、PID Namespace、User Namespace未共享。
  

2.3、Pause容器Namespace验证

1、 运行pod，进入容器查看iflink编号

2、到pod所在宿主机验证网卡

2.4、pause容器配置示例

2.4.1、准备nginx配置文件，并配置动静分离

1. error_log stderr;
2. events { worker_connections 1024; }
3. http {
4.   access_log /dev/stdout;
5.   server {
6.     listen 80 default_server;
7.     server_name www.mysite.com;
8.     location / {
9.       index index.html index.php;
10.       root /usr/share/nginx/html;
11.     }
12.     location ~ \.php$ {
13.     root /usr/share/nginx/html;
14.     fastcgi_pass 127.0.0.1:9000;
15.     fastcgi_index index.php;
16.     fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
17.     include fastcgi_params;
18.     }
19.   }
20. }

复制代码

2.4.2、部署pause容器

2.4.2.1、下载pause镜像

1. nerdctl pull registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.8

复制代码

2.4.2.2、运行pause镜像为容器

1. nerdctl run -d -p 80:80 --name pause-container-test registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.8

复制代码

2.4.3、准备测试web页面

1. root@deploy:~# mkdir html
2. root@deploy:~# cd html
3. root@deploy:~/html# echo "<h1>pause container web test</h1>" >index.html
4. root@deploy:~/html# cat >> index.php << EOF
5. > <?php
6. >      phpinfo();
7. > ?>
8. > EOF
9. root@deploy:~/html# ll
10. total 16
11. drwxr-xr-x 2 root root 4096 May 26 00:03 ./
12. drwxr-xr-x 9 root root 4096 May 26 00:02 ../
13. -rw-r--r-- 1 root root   34 May 26 00:02 index.html
14. -rw-r--r-- 1 root root   25 May 26 00:03 index.php
15. root@deploy:~/html# cat index.html
16. <h1>pause container web test</h1>
17. root@deploy:~/html# cat index.php
18. <?php
19.      phpinfo();
20. ?>
21. root@deploy:~/html#

复制代码

2.4.4、部署nginx 容器，并使用pause容器网络

1. nerdctl run -d --name nginx-container-test \
2.             -v `pwd`/nginx.conf:/etc/nginx/nginx.conf \
3.             -v `pwd`/html:/usr/share/nginx/html \
4.             --net=container:pause-container-test \
5.             nginx:1.20.2

复制代码

2.4.5、部署php容器，并使用pause容器网络

1. nerdctl run -d --name php-container-test \
2.             -v `pwd`/html:/usr/share/nginx/html \
3.             --net=container:pause-container-test \
4.             php:5.6.40-fpm

复制代码

2.4.6、pause容器验证

访问宿主机的80端口的index.php，看看是否能够访问到php页面？

2.5、init容器简介

2.5.1、init容器的作用

• 可以为业务容器提前准备好业务容器的运行环境，比如将业务容器需要的配置文件提前生成并放在指定位置、检查数据权限或完整性、软件版本等基础运行环境。
  
• 可以在运行业务容器之前准备好需要的业务数据，比如从OSS下载、或者从其它位置copy。
  
• 检查依赖的服务是否能够访问。
  

2.5.2、init容器的特点

• 一个pod可以有多个业务容器还能在有多个init容器，但是每个init容器和业务容器的运行环境都是隔离的。
  
• init容器会比业务容器先启动。
  
• init容器运行成功之后才会继续运行业务容器。
  
• 如果一个pod有多个init容器，则需要从上到下逐个运行并且全部成功，最后才会运行业务容器。
  
• init容器不支持探针检测(因为初始化完成后就退出再也不运行了)。
  

2.5.3、init容器示例

1. kind: Deployment
2. #apiVersion: extensions/v1beta1
3. apiVersion: apps/v1
4. metadata:
5.   labels:
6.     app: myserver-myapp
7.   name: myserver-myapp-deployment-name
8.   namespace: myserver
9. spec:
10.   replicas: 1
11.   selector:
12.     matchLabels:
13.       app: myserver-myapp-frontend
14.   template:
15.     metadata:
16.       labels:
17.         app: myserver-myapp-frontend
18.     spec:
19.       containers:
20.         - name: myserver-myapp-container
21.           image: nginx:1.20.0
22.           #imagePullPolicy: Always
23.           volumeMounts:
24.           - mountPath: "/usr/share/nginx/html/myserver"
25.             name: myserver-data
26.           - name: tz-config
27.             mountPath: /etc/localtime
28.       initContainers:
29.         - name: init-web-data
30.           image: centos:7.9.2009
31.           command: ['/bin/bash','-c',"for i in `seq 1 10`;do echo '<h1>'$i web page at $(date +%Y%m%d%H%M%S) '<h1>' >> /data/nginx/html/myserver/index.html;sleep 1;done"]
32.           volumeMounts:
33.           - mountPath: "/data/nginx/html/myserver"
34.             name: myserver-data
35.           - name: tz-config
36.             mountPath: /etc/localtime
37.         - name: change-data-owner
38.           image: busybox:1.28
39.           command: ['/bin/sh','-c',"/bin/chmod 644 /data/nginx/html/myserver/* -R"]
40.           volumeMounts:
41.           - mountPath: "/data/nginx/html/myserver"
42.             name: myserver-data
43.           - name: tz-config
44.             mountPath: /etc/localtime
45.       volumes:
46.       - name: myserver-data
47.         hostPath:
48.           path: /tmp/data/html
49.       - name: tz-config
50.         hostPath:
51.           path: /etc/localtime
53. ---
54. kind: Service
55. apiVersion: v1
56. metadata:
57.   labels:
58.     app: myserver-myapp-service
59.   name: myserver-myapp-service-name
60.   namespace: myserver
61. spec:
62.   type: NodePort
63.   ports:
64.   - name: http
65.     port: 80
66.     targetPort: 80
67.     nodePort: 30080
68.   selector:
69.     app: myserver-myapp-frontend

复制代码

上述配置清单，主要利用两个初始化容器对nginx主容器生成数据和修改数据文件权限的操作；在spec.template.spec字段下用initcontainers来定义初始化容器相关内容；
应用配置清单

访问nginx服务，看看对应数据是否生成？

2.6、Health Check

health check是指对容器做健康状态检测；该检测主要确保容器里的某些服务是否处于健康状态；该检测是一个周期性的动作，即每隔几秒或指定时间周期内进行检测；
2.6.1、docker health check实现方式

2.6.1.1、在docker-compose实现健康状态检测

1. version: '3.6'
2. services:
3.   nginx-service:
4.     image: nginx:1.20.2
5.     container_name: nginx-web1
6.     expose:
7.       - 80
8.       - 443
9.     ports:
10.       - "80:80"
11.       - "443:443"
12.     restart: always
13.     healthcheck: #添加服务健康状态检查
14.       test: ["CMD", "curl", "-f", "http://localhost"]
15.       interval: 5s #健康状态检查的间隔时间，默认为30s
16.       timeout: 5s #单次检查的失败超时时间，默认为30s
17.       retries: 3 #连续失败次数默认3次，当连续失败retries次数后将容器置为unhealthy状态
18.       start_period: 60s #60s后每间隔interval的时间检查一次，连续retries次后才将容器置为unhealthy状态, 但是start_period时间内检查成功就认为是检查成功并装容器置于healthy状态

复制代码

应用配置清单

1. docker-compose -f docker-compose-demo.yaml up -d

复制代码

验证容器健康状态

2.6.1.2、在dockerfile实现健康状态检测

1. FROM nginx:1.20.2
3. HEALTHCHECK --interval=5s --timeout=2s --retries=3 \
4. CMD curl --silent --fail localhost:80 || exit 1

复制代码

生成镜像

1. docker build -t mynginx:1.20.2 -f ./dockerfile .

复制代码

运行容器

1. docker run -it -d -p 80:80 mynginx:1.20.2

复制代码

验证健康状态检测

1. root@k8s-deploy:/compose# docker ps
2. CONTAINER ID   IMAGE            COMMAND                  CREATED         STATUS                            PORTS                               NAMES
3. c3af9bdd5a41   mynginx:1.20.2   "/docker-entrypoint.…"   4 seconds ago   Up 2 seconds (health: starting)   0.0.0.0:80->80/tcp, :::80->80/tcp   keen_brown
4. root@k8s-deploy:/compose# docker ps
5. CONTAINER ID   IMAGE            COMMAND                  CREATED         STATUS                   PORTS                               NAMES
6. c3af9bdd5a41   mynginx:1.20.2   "/docker-entrypoint.…"   9 seconds ago   Up 8 seconds (healthy)   0.0.0.0:80->80/tcp, :::80->80/tcp   keen_brown
7. root@k8s-deploy:/compose#

复制代码

在检测通过之前容器处于starting状态,检测通过(检测返回状态码为 0)之后为healthy状态,检测失败(检测返回状态码为 1)之后为unhealthy状态;

3、kubernetes pod生命周期

pod的生命周期( pod lifecycle)，从pod start时候可以配置postStart检测，运行过程中可以配置livenessProbe和readinessProbe,最后在 stop前可以配置preStop操作。

3.1、探针简介

探针是由 kubelet 对容器执行的定期诊断，以保证Pod的状态始终处于运行状态，要执行诊断，kubelet 调用由容器实现的Handler(处理程序)，也成为Hook(钩子)，有三种类型的处理程序：

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

每次探测都将获得以下三种结果之一：

• 成功：容器通过了诊断。
  
• 失败：容器未通过诊断。
  
• 未知：诊断失败，因此不会采取任何行动。
  

Pod 重启策略:Pod 一旦配置探针，在检测失败时候，会基于restartPolicy 对 Pod进行下一步操作：

• restartPolicy (容器重启策略)：
  
  
  
  • Always：当容器异常时，k8s自动重启该容器，ReplicationController/Replicaset/Deployment，默认为Always。
    
  • OnFailure：当容器失败时(容器停止运行且退出码不为0)，k8s自动重启该容器。
    
  • Never：不论容器运行状态如何都不会重启该容器,Job或CronJob
    
  
  
• imagePullPolicy (镜像拉取策略)：
  
  
  
  • IfNotPresent：node节点没有此镜像就去指定的镜像仓库拉取，node有就使用node本地镜像。
    
  • Always：每次重建pod都会重新拉取镜像。
    
  • Never：从不到镜像中心拉取镜像，只使用本地镜像。
    
  
  

3.2、探针类型

• startupProbe: #启动探针,kubernetes v1.16引入
  判断容器内的应用程序是否已启动完成，如果配置了启动探测，则会先禁用所有其它的探测，直到startupProbe检测成功为止，如果startupProbe探测失败，则kubelet将杀死容器，容器将按照重启策略进行下一步操作，如果容器没有提供启动探测，则默认状态为成功
  
• livenessProbe: #存活探针
  检测容器容器是否正在运行，如果存活探测失败，则kubelet会杀死容器，并且容器将受到其重启策略的影响，如果容器不提供存活探针，则默认状态为 Success，livenessProbe用于控制是否重启pod。
  
• readinessProbe: #就绪探针
  如果就绪探测失败，端点控制器将从与Pod匹配的所有Service的端点中删除该Pod的IP地址，初始延迟之前的就绪状态默认为Failure(失败)，如果容器不提供就绪探针，则默认状态为 Success，readinessProbe用于控制pod是否添加至service。
  

3.3、探针配置参数

探针有很多配置字段，可以使用这些字段精确的控制存活和就绪检测的行为,官方文档https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

• initialDelaySeconds: 120 #初始化延迟时间，告诉kubelet在执行第一次探测前应该等待多少秒，默认是0秒，最小值是0。
  
• periodSeconds: 60 #探测周期间隔时间，指定了kubelet应该每多少秒秒执行一次存活探测，默认是 10 秒。最小值是 1。
  
• timeoutSeconds: 5 #单次探测超时时间，探测的超时后等待多少秒，默认值是1秒，最小值是1。
  
• successThreshold: 1 #从失败转为成功的重试次数，探测器在失败后，被视为成功的最小连续成功数，默认值是1，存活探测的这个值必须是1，最小值是 1。
  
• failureThreshold：3 #从成功转为失败的重试次数，当Pod启动了并且探测到失败，Kubernetes的重试次数，存活探测情况下的放弃就意味着重新启动容器，就绪探测情况下的放弃Pod 会被打上未就绪的标签，默认值是3，最小值是1。
  

3.3.1、探针http配置参数

HTTP 探测器可以在 httpGet 上配置额外的字段

• host: #连接使用的主机名，默认是Pod的 IP，也可以在HTTP头中设置 “Host” 来代替。
  
• scheme: http #用于设置连接主机的方式（HTTP 还是 HTTPS），默认是 HTTP。
  
• path: /monitor/index.html #访问 HTTP 服务的路径。
  
• httpHeaders: #请求中自定义的 HTTP 头,HTTP 头字段允许重复。
  
• port: 80 #访问容器的端口号或者端口名，如果数字必须在 1 ～ 65535 之间。
  

3.4、探针示例

3.4.1、使用httpGet实现pod存活性探测

1. apiVersion: apps/v1
2. kind: Deployment
3. metadata:
4.   name: myserver-myapp-frontend-deployment
5.   namespace: myserver
6. spec:
7.   replicas: 1
8.   selector:
9.     matchLabels: #rs or deployment
10.       app: myserver-myapp-frontend-label
11.     #matchExpressions:
12.     #  - {key: app, operator: In, values: [myserver-myapp-frontend,ng-rs-81]}
13.   template:
14.     metadata:
15.       labels:
16.         app: myserver-myapp-frontend-label
17.     spec:
18.       containers:
19.       - name: myserver-myapp-frontend-label
20.         image: nginx:1.20.2
21.         ports:
22.         - containerPort: 80
23.         readinessProbe:
24.         livenessProbe:
25.           httpGet:
26.             #path: /monitor/monitor.html
27.             path: /index.html
28.             port: 80
29.           initialDelaySeconds: 5
30.           periodSeconds: 3
31.           timeoutSeconds: 1
32.           successThreshold: 1
33.           failureThreshold: 3
34. ---
35. apiVersion: v1
36. kind: Service
37. metadata:
38.   name: myserver-myapp-frontend-service
39.   namespace: myserver
40. spec:
41.   ports:
42.   - name: http
43.     port: 81
44.     targetPort: 80
45.     nodePort: 40012
46.     protocol: TCP
47.   type: NodePort
48.   selector:
49.     app: myserver-myapp-frontend-label

复制代码

上述配置清单，主要描述了使用httpget探针对nginxpod进行存活性探测，探测方法就是对容器的80端口，路径为/index.html进行每隔3秒访问一次，探测超时等待1秒，如果连续3次访问失败，则该pod存活性探测失败；只要有一次访问成功，则该pod存活性探测成功；

3.4.2、使用tcpSocket实现pod存活性探测

1. apiVersion: apps/v1
2. kind: Deployment
3. metadata:
4.   name: myserver-myapp-frontend-deployment
5.   namespace: myserver
6. spec:
7.   replicas: 1
8.   selector:
9.     matchLabels: #rs or deployment
10.       app: myserver-myapp-frontend-label
11.     #matchExpressions:
12.     #  - {key: app, operator: In, values: [myserver-myapp-frontend,ng-rs-81]}
13.   template:
14.     metadata:
15.       labels:
16.         app: myserver-myapp-frontend-label
17.     spec:
18.       containers:
19.       - name: myserver-myapp-frontend-label
20.         image: nginx:1.20.2
21.         ports:
22.         - containerPort: 80
23.         livenessProbe:
24.         #readinessProbe:
25.           tcpSocket:
26.             port: 80
27.             #port: 8080
28.           initialDelaySeconds: 5
29.           periodSeconds: 3
30.           timeoutSeconds: 5
31.           successThreshold: 1
32.           failureThreshold: 3
33. ---
34. apiVersion: v1
35. kind: Service
36. metadata:
37.   name: myserver-myapp-frontend-service
38.   namespace: myserver
39. spec:
40.   ports:
41.   - name: http
42.     port: 81
43.     targetPort: 80
44.     nodePort: 40012
45.     protocol: TCP
46.   type: NodePort
47.   selector:
48.     app: myserver-myapp-frontend-label

复制代码

3.4.3、使用exec执行命令的方式实现pod存活性探测

1. apiVersion: apps/v1
2. kind: Deployment
3. metadata:
4.   name: myserver-myapp-redis-deployment
5.   namespace: myserver
6. spec:
7.   replicas: 1
8.   selector:
9.     matchLabels: #rs or deployment
10.       app: myserver-myapp-redis-label
11.     #matchExpressions:
12.     #  - {key: app, operator: In, values: [myserver-myapp-redis,ng-rs-81]}
13.   template:
14.     metadata:
15.       labels:
16.         app: myserver-myapp-redis-label
17.     spec:
18.       containers:
19.       - name: myserver-myapp-redis-container
20.         image: redis
21.         ports:
22.         - containerPort: 6379
23.         livenessProbe:
24.         #readinessProbe:
25.           exec:
26.             command:
27.             #- /apps/redis/bin/redis-cli
28.             - /usr/local/bin/redis-cli
29.             - quit
30.           initialDelaySeconds: 5
31.           periodSeconds: 3
32.           timeoutSeconds: 5
33.           successThreshold: 1
34.           failureThreshold: 3
35.       
36. ---
37. apiVersion: v1
38. kind: Service
39. metadata:
40.   name: myserver-myapp-redis-service
41.   namespace: myserver
42. spec:
43.   ports:
44.   - name: http
45.     port: 6379
46.     targetPort: 6379
47.     nodePort: 40016
48.     protocol: TCP
49.   type: NodePort
50.   selector:
51.     app: myserver-myapp-redis-label

复制代码

3.4.4、启动探针示例

1. apiVersion: apps/v1
2. kind: Deployment
3. metadata:
4.   name: myserver-myapp-frontend-deployment
5.   namespace: myserver
6. spec:
7.   replicas: 1
8.   selector:
9.     matchLabels: #rs or deployment
10.       app: myserver-myapp-frontend-label
11.     #matchExpressions:
12.     #  - {key: app, operator: In, values: [myserver-myapp-frontend,ng-rs-81]}
13.   template:
14.     metadata:
15.       labels:
16.         app: myserver-myapp-frontend-label
17.     spec:
18.       containers:
19.       - name: myserver-myapp-frontend-label
20.         image: nginx:1.20.2
21.         ports:
22.         - containerPort: 80
23.         startupProbe:
24.           httpGet:
25.             path: /index.html
26.             port: 80
27.           initialDelaySeconds: 5 #首次检测延迟5s
28.           failureThreshold: 3  #从成功转为失败的次数
29.           periodSeconds: 3 #探测间隔周期
30. ---
31. apiVersion: v1
32. kind: Service
33. metadata:
34.   name: myserver-myapp-frontend-service
35.   namespace: myserver
36. spec:
37.   ports:
38.   - name: http
39.     port: 81
40.     targetPort: 80
41.     nodePort: 40012
42.     protocol: TCP
43.   type: NodePort
44.   selector:
45.     app: myserver-myapp-frontend-label

复制代码

3.4.5、启动探针，存活探针，就绪探针示例

1. apiVersion: apps/v1
2. kind: Deployment
3. metadata:
4.   name: myserver-myapp-frontend-deployment
5.   namespace: myserver
6. spec:
7.   replicas: 3
8.   selector:
9.     matchLabels: #rs or deployment
10.       app: myserver-myapp-frontend-label
11.     #matchExpressions:
12.     #  - {key: app, operator: In, values: [myserver-myapp-frontend,ng-rs-81]}
13.   template:
14.     metadata:
15.       labels:
16.         app: myserver-myapp-frontend-label
17.     spec:
18.       terminationGracePeriodSeconds: 60
19.       containers:
20.       - name: myserver-myapp-frontend-label
21.         image: nginx:1.20.2
22.         ports:
23.         - containerPort: 80
24.         startupProbe:
25.           httpGet:
26.             path: /index.html
27.             port: 80
28.           initialDelaySeconds: 5 #首次检测延迟5s
29.           failureThreshold: 3  #从成功转为失败的次数
30.           periodSeconds: 3 #探测间隔周期
31.         readinessProbe:
32.           httpGet:
33.             #path: /monitor/monitor.html
34.             path: /index.html
35.             port: 80
36.           initialDelaySeconds: 5
37.           periodSeconds: 3
38.           timeoutSeconds: 5
39.           successThreshold: 1
40.           failureThreshold: 3
41.         livenessProbe:
42.           httpGet:
43.             #path: /monitor/monitor.html
44.             path: /index.html
45.             port: 80
46.           initialDelaySeconds: 5
47.           periodSeconds: 3
48.           timeoutSeconds: 5
49.           successThreshold: 1
50.           failureThreshold: 3
51. ---
52. apiVersion: v1
53. kind: Service
54. metadata:
55.   name: myserver-myapp-frontend-service
56.   namespace: myserver
57. spec:
58.   ports:
59.   - name: http
60.     port: 81
61.     targetPort: 80
62.     nodePort: 40012
63.     protocol: TCP
64.   type: NodePort
65.   selector:
66.     app: myserver-myapp-frontend-label

复制代码

3.5、postStart and preStop handlers简介


官方文档https://kubernetes.io/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/
postStart 和 preStop handlers 处理函数

• postStart：Pod启动后立即执行指定的擦操作:
  
  
  
  • Pod被创建后立即执行,即不等待pod中的服务启动。
    
  • 如果postStart执行失败pod不会继续创建。
    
  
  
• preStop：
  
  
  
  • pod被停止之前执行的动作。
    
  • 如果preStop一直执行不完成，则最后宽限2秒后强制删除。
    
  
  

3.5.1、postStart and preStop handlers示例

1. apiVersion: apps/v1
2. kind: Deployment
3. metadata:
4.   name: myserver-myapp1-lifecycle
5.   labels:
6.     app: myserver-myapp1-lifecycle
7.   namespace: myserver
8. spec:
9.   replicas: 1
10.   selector:
11.     matchLabels:
12.       app: myserver-myapp1-lifecycle-label
13.   template:
14.     metadata:
15.       labels:
16.         app: myserver-myapp1-lifecycle-label
17.     spec:
18.       terminationGracePeriodSeconds: 60
19.       containers:
20.       - name: myserver-myapp1-lifecycle-label
21.         image: tomcat:7.0.94-alpine
22.         lifecycle:
23.           postStart:
24.             exec:
25.              #command: 把自己注册到注册在中心
26.               command: ["/bin/sh", "-c", "echo 'Hello from the postStart handler' >> /usr/local/tomcat/webapps/ROOT/index.html"]
28.             #httpGet:
29.             #  #path: /monitor/monitor.html
30.             #  host: www.magedu.com
31.             #  port: 80
32.             #  scheme: HTTP
33.             #  path: index.html
34.           preStop:
35.             exec:
36.              #command: 把自己从注册中心移除
37.               command:
38.                 - /bin/bash
39.                 - -c
40.                 - 'sleep 10000000'
41.               #command: ["/usr/local/tomcat/bin/catalina.sh","stop"]
42.               #command: ['/bin/sh','-c','/path/preStop.sh']
43.         ports:
44.           - name: http
45.             containerPort: 8080
47. ---
48. apiVersion: v1
49. kind: Service
50. metadata:
51.   name: myserver-myapp1-lifecycle-service
52.   namespace: myserver
53. spec:
54.   ports:
55.   - name: http
56.     port: 80
57.     targetPort: 8080
58.     nodePort: 30012
59.     protocol: TCP
60.   type: NodePort
61.   selector:
62.     app: myserver-myapp1-lifecycle-label

复制代码

3.6、Pod的终止流程

• 向API-Server提交删除请求、API-Server完成鉴权和准入并将事件写入etcd
  
• Pod被设置为”Terminating”状态、从service的Endpoints列表中删除并不再接受客户端请求。
  
• pod执行PreStop
  
• kubelet向pod中的容器发送SIGTERM信号(正常终止信号)终止pod里面的主进程，这个信号让容器知道自己很快将会被关闭terminationGracePeriodSeconds: 60 #可选终止等待期(pod删除宽限期)，如果有设置删除宽限时间，则等待宽限时间到期，否则最多等待30s，Kubernetes等待指定的时间称为优雅终止宽限期,默认情况下是30秒,值得注意的是等待期与preStop Hook和SIGTERM信号并行执行，即Kubernetes可能不会等待preStop Hook完成(最长30秒之后主进程还没有结束就就强制终止pod)。
  
• SIGKILL信号被发送到Pod，并删除Pod
  

        出处：https://www.cnblogs.com/qiuhom-1874/        本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利.
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！