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配置文件,并配置动静分离
error_log stderr;events { worker_connections 1024; }http { access_log /dev/stdout; server { listen 80 default_server; server_name www.mysite.com; location / { index index.html index.php; root /usr/share/nginx/html; } location ~ \.php$ { root /usr/share/nginx/html; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } }}
2.4.2、部署pause容器2.4.2.1、下载pause镜像
nerdctl pull registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.8
2.4.2.2、运行pause镜像为容器
nerdctl run -d -p 80:80 --name pause-container-test registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.8
2.4.3、准备测试web页面
root@deploy:~# mkdir htmlroot@deploy:~# cd htmlroot@deploy:~/html# echo "pause container web test
" >index.htmlroot@deploy:~/html# cat >> index.php < phpinfo();> ?>> EOFroot@deploy:~/html# lltotal 16drwxr-xr-x 2 root root 4096 May 26 00:03 ./drwxr-xr-x 9 root root 4096 May 26 00:02 ../-rw-r--r-- 1 root root 34 May 26 00:02 index.html-rw-r--r-- 1 root root 25 May 26 00:03 index.phproot@deploy:~/html# cat index.html pause container web test
root@deploy:~/html# cat index.php root@deploy:~/html#
2.4.4、部署nginx 容器,并使用pause容器网络
nerdctl run -d --name nginx-container-test \ -v `pwd`/nginx.conf:/etc/nginx/nginx.conf \ -v `pwd`/html:/usr/share/nginx/html \ --net=container:pause-container-test \ nginx:1.20.2
2.4.5、部署php容器,并使用pause容器网络
nerdctl run -d --name php-container-test \ -v `pwd`/html:/usr/share/nginx/html \ --net=container:pause-container-test \ 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容器示例
kind: Deployment#apiVersion: extensions/v1beta1apiVersion: apps/v1metadata: labels: app: myserver-myapp name: myserver-myapp-deployment-name namespace: myserverspec: replicas: 1 selector: matchLabels: app: myserver-myapp-frontend template: metadata: labels: app: myserver-myapp-frontend spec: containers: - name: myserver-myapp-container image: nginx:1.20.0 #imagePullPolicy: Always volumeMounts: - mountPath: "/usr/share/nginx/html/myserver" name: myserver-data - name: tz-config mountPath: /etc/localtime initContainers: - name: init-web-data image: centos:7.9.2009 command: ['/bin/bash','-c',"for i in `seq 1 10`;do echo ''$i web page at $(date +%Y%m%d%H%M%S) '' >> /data/nginx/html/myserver/index.html;sleep 1;done"] volumeMounts: - mountPath: "/data/nginx/html/myserver" name: myserver-data - name: tz-config mountPath: /etc/localtime - name: change-data-owner image: busybox:1.28 command: ['/bin/sh','-c',"/bin/chmod 644 /data/nginx/html/myserver/* -R"] volumeMounts: - mountPath: "/data/nginx/html/myserver" name: myserver-data - name: tz-config mountPath: /etc/localtime volumes: - name: myserver-data hostPath: path: /tmp/data/html - name: tz-config hostPath: path: /etc/localtime ---kind: ServiceapiVersion: v1metadata: labels: app: myserver-myapp-service name: myserver-myapp-service-name namespace: myserverspec: type: NodePort ports: - name: http port: 80 targetPort: 80 nodePort: 30080 selector: 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实现健康状态检测
version: '3.6'services: nginx-service: image: nginx:1.20.2 container_name: nginx-web1 expose: - 80 - 443 ports: - "80:80" - "443:443" restart: always healthcheck: #添加服务健康状态检查 test: ["CMD", "curl", "-f", "http://localhost"] interval: 5s #健康状态检查的间隔时间,默认为30s timeout: 5s #单次检查的失败超时时间,默认为30s retries: 3 #连续失败次数默认3次,当连续失败retries次数后将容器置为unhealthy状态 start_period: 60s #60s后每间隔interval的时间检查一次,连续retries次后才将容器置为unhealthy状态, 但是start_period时间内检查成功就认为是检查成功并装容器置于healthy状态
应用配置清单
docker-compose -f docker-compose-demo.yaml up -d
验证容器健康状态
2.6.1.2、在dockerfile实现健康状态检测
FROM nginx:1.20.2HEALTHCHECK --interval=5s --timeout=2s --retries=3 \CMD curl --silent --fail localhost:80 || exit 1
生成镜像
docker build -t mynginx:1.20.2 -f ./dockerfile .
运行容器
docker run -it -d -p 80:80 mynginx:1.20.2
验证健康状态检测
root@k8s-deploy:/compose# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMESc3af9bdd5a41 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_brownroot@k8s-deploy:/compose# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMESc3af9bdd5a41 mynginx:1.20.2 "/docker-entrypoint.…" 9 seconds ago Up 8 seconds (healthy) 0.0.0.0:80->80/tcp, :::80->80/tcp keen_brownroot@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存活性探测
apiVersion: apps/v1kind: Deploymentmetadata: name: myserver-myapp-frontend-deployment namespace: myserverspec: replicas: 1 selector: matchLabels: #rs or deployment app: myserver-myapp-frontend-label #matchExpressions: # - {key: app, operator: In, values: [myserver-myapp-frontend,ng-rs-81]} template: metadata: labels: app: myserver-myapp-frontend-label spec: containers: - name: myserver-myapp-frontend-label image: nginx:1.20.2 ports: - containerPort: 80 readinessProbe: livenessProbe: httpGet: #path: /monitor/monitor.html path: /index.html port: 80 initialDelaySeconds: 5 periodSeconds: 3 timeoutSeconds: 1 successThreshold: 1 failureThreshold: 3---apiVersion: v1kind: Servicemetadata: name: myserver-myapp-frontend-service namespace: myserverspec: ports: - name: http port: 81 targetPort: 80 nodePort: 40012 protocol: TCP type: NodePort selector: app: myserver-myapp-frontend-label
上述配置清单,主要描述了使用httpget探针对nginxpod进行存活性探测,探测方法就是对容器的80端口,路径为/index.html进行每隔3秒访问一次,探测超时等待1秒,如果连续3次访问失败,则该pod存活性探测失败;只要有一次访问成功,则该pod存活性探测成功;
3.4.2、使用tcpSocket
实现pod存活性探测
apiVersion: apps/v1kind: Deploymentmetadata: name: myserver-myapp-frontend-deployment namespace: myserverspec: replicas: 1 selector: matchLabels: #rs or deployment app: myserver-myapp-frontend-label #matchExpressions: # - {key: app, operator: In, values: [myserver-myapp-frontend,ng-rs-81]} template: metadata: labels: app: myserver-myapp-frontend-label spec: containers: - name: myserver-myapp-frontend-label image: nginx:1.20.2 ports: - containerPort: 80 livenessProbe: #readinessProbe: tcpSocket: port: 80 #port: 8080 initialDelaySeconds: 5 periodSeconds: 3 timeoutSeconds: 5 successThreshold: 1 failureThreshold: 3---apiVersion: v1kind: Servicemetadata: name: myserver-myapp-frontend-service namespace: myserverspec: ports: - name: http port: 81 targetPort: 80 nodePort: 40012 protocol: TCP type: NodePort selector: app: myserver-myapp-frontend-label
3.4.3、使用exec
执行命令的方式实现pod存活性探测
apiVersion: apps/v1kind: Deploymentmetadata: name: myserver-myapp-redis-deployment namespace: myserverspec: replicas: 1 selector: matchLabels: #rs or deployment app: myserver-myapp-redis-label #matchExpressions: # - {key: app, operator: In, values: [myserver-myapp-redis,ng-rs-81]} template: metadata: labels: app: myserver-myapp-redis-label spec: containers: - name: myserver-myapp-redis-container image: redis ports: - containerPort: 6379 livenessProbe: #readinessProbe: exec: command: #- /apps/redis/bin/redis-cli - /usr/local/bin/redis-cli - quit initialDelaySeconds: 5 periodSeconds: 3 timeoutSeconds: 5 successThreshold: 1 failureThreshold: 3 ---apiVersion: v1kind: Servicemetadata: name: myserver-myapp-redis-service namespace: myserverspec: ports: - name: http port: 6379 targetPort: 6379 nodePort: 40016 protocol: TCP type: NodePort selector: app: myserver-myapp-redis-label
3.4.4、启动探针示例
apiVersion: apps/v1kind: Deploymentmetadata: name: myserver-myapp-frontend-deployment namespace: myserverspec: replicas: 1 selector: matchLabels: #rs or deployment app: myserver-myapp-frontend-label #matchExpressions: # - {key: app, operator: In, values: [myserver-myapp-frontend,ng-rs-81]} template: metadata: labels: app: myserver-myapp-frontend-label spec: containers: - name: myserver-myapp-frontend-label image: nginx:1.20.2 ports: - containerPort: 80 startupProbe: httpGet: path: /index.html port: 80 initialDelaySeconds: 5 #首次检测延迟5s failureThreshold: 3 #从成功转为失败的次数 periodSeconds: 3 #探测间隔周期---apiVersion: v1kind: Servicemetadata: name: myserver-myapp-frontend-service namespace: myserverspec: ports: - name: http port: 81 targetPort: 80 nodePort: 40012 protocol: TCP type: NodePort selector: app: myserver-myapp-frontend-label
3.4.5、启动探针,存活探针,就绪探针示例
apiVersion: apps/v1kind: Deploymentmetadata: name: myserver-myapp-frontend-deployment namespace: myserverspec: replicas: 3 selector: matchLabels: #rs or deployment app: myserver-myapp-frontend-label #matchExpressions: # - {key: app, operator: In, values: [myserver-myapp-frontend,ng-rs-81]} template: metadata: labels: app: myserver-myapp-frontend-label spec: terminationGracePeriodSeconds: 60 containers: - name: myserver-myapp-frontend-label image: nginx:1.20.2 ports: - containerPort: 80 startupProbe: httpGet: path: /index.html port: 80 initialDelaySeconds: 5 #首次检测延迟5s failureThreshold: 3 #从成功转为失败的次数 periodSeconds: 3 #探测间隔周期 readinessProbe: httpGet: #path: /monitor/monitor.html path: /index.html port: 80 initialDelaySeconds: 5 periodSeconds: 3 timeoutSeconds: 5 successThreshold: 1 failureThreshold: 3 livenessProbe: httpGet: #path: /monitor/monitor.html path: /index.html port: 80 initialDelaySeconds: 5 periodSeconds: 3 timeoutSeconds: 5 successThreshold: 1 failureThreshold: 3---apiVersion: v1kind: Servicemetadata: name: myserver-myapp-frontend-service namespace: myserverspec: ports: - name: http port: 81 targetPort: 80 nodePort: 40012 protocol: TCP type: NodePort selector: 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示例
apiVersion: apps/v1kind: Deploymentmetadata: name: myserver-myapp1-lifecycle labels: app: myserver-myapp1-lifecycle namespace: myserverspec: replicas: 1 selector: matchLabels: app: myserver-myapp1-lifecycle-label template: metadata: labels: app: myserver-myapp1-lifecycle-label spec: terminationGracePeriodSeconds: 60 containers: - name: myserver-myapp1-lifecycle-label image: tomcat:7.0.94-alpine lifecycle: postStart: exec: #command: 把自己注册到注册在中心 command: ["/bin/sh", "-c", "echo 'Hello from the postStart handler' >> /usr/local/tomcat/webapps/ROOT/index.html"] #httpGet: # #path: /monitor/monitor.html # host: www.magedu.com # port: 80 # scheme: HTTP # path: index.html preStop: exec: #command: 把自己从注册中心移除 command: - /bin/bash - -c - 'sleep 10000000' #command: ["/usr/local/tomcat/bin/catalina.sh","stop"] #command: ['/bin/sh','-c','/path/preStop.sh'] ports: - name: http containerPort: 8080---apiVersion: v1kind: Servicemetadata: name: myserver-myapp1-lifecycle-service namespace: myserverspec: ports: - name: http port: 80 targetPort: 8080 nodePort: 30012 protocol: TCP type: NodePort selector: 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
作者:Linux-1874 出处:https://www.cnblogs.com/qiuhom-1874/ 本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利.