4. kubernetes 资源清单 - pod进阶
请依据kubernetes版本及官方文档 kubernetes api，这里整理的资料仅供参考。
一、 简介
资源清单有5个顶级字段组成:apiVersion、kind、metadata、spec、status.
apiVersion: group/apiversion # 如果没有给定 group 名称，那么默认为 core，可以使用
kubectl apiversions # 获取当前 k8s 版本上所有的 apiVersion 版本信息( 每个版本可能不同 )
kind: #资源类别
metadata： #资源元数据
name
namespace
lables
annotations # 主要目的是方便用户阅读查找
spec: # 期望的状态（disired state）
status：# 当前状态，本字段由 Kubernetes 自身维护，用户不能去定义
1. 查看api version版本信息及api支持
kubectl api-versions
admissionregistration.k8s.io/v1
apiextensions.k8s.io/v1
apiregistration.k8s.io/v1
apps/v1
authentication.k8s.io/v1
authorization.k8s.io/v1
autoscaling/v1
autoscaling/v2
autoscaling/v2beta1
autoscaling/v2beta2
batch/v1
batch/v1beta1
certificates.k8s.io/v1
coordination.k8s.io/v1
crd.projectcalico.org/v1
discovery.k8s.io/v1
discovery.k8s.io/v1beta1
events.k8s.io/v1
events.k8s.io/v1beta1
flowcontrol.apiserver.k8s.io/v1beta1
flowcontrol.apiserver.k8s.io/v1beta2
networking.k8s.io/v1
node.k8s.io/v1
node.k8s.io/v1beta1
policy/v1
policy/v1beta1
rbac.authorization.k8s.io/v1
scheduling.k8s.io/v1
storage.k8s.io/v1
storage.k8s.io/v1beta1
v1
2. 获取字段设置帮助文档
# 比如我们要查看pod 相关的资源配置方式
kubectl explain pod
KIND: Pod
VERSION: v1
DESCRIPTION:
Pod is a collection of containers that can run on a host. This resource is
created by clients and scheduled onto hosts.
FIELDS:
apiVersion <string>
APIVersion defines the versioned schema of this representation of an
object. Servers should convert recognized schemas to the latest internal
value, and may reject unrecognized values. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
kind <string>
Kind is a string value representing the REST resource this object
represents. Servers may infer this from the endpoint the client submits
requests to. Cannot be updated. In CamelCase. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
metadata <Object>
Standard object's metadata. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec <Object>
Specification of the desired behavior of the pod. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
status <Object>
Most recently observed status of the pod. This data may not be up to date.
Populated by the system. Read-only. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
3. 字段配置格式类型
apiVersion <string> #表示字符串类型
metadata <Object> #表示需要嵌套多层字段
labels <map[string]string> #表示由k:v组成的映射
finalizers <[]string> #表示字串列表
ownerReferences <[]Object> #表示对象列表
hostPID <boolean> #布尔类型
priority <integer> #整型
name <string> -required- #如果类型后面接 -required-，表示为必填字段
4. pod资源文件详解
下面是一份详细的pod 各项配置规则及案例，仅供参考，具体以官方文档为主。
语法规则
apiVersion: v1 #必选，版本号，例如v1
kind: Pod #必选，资源类型，例如 Pod
metadata: #必选，元数据
name: string #必选，Pod名称
namespace: string #Pod所属的命名空间,默认为"default"
labels: #自定义标签列表
- name: string
spec: #必选，Pod中容器的详细定义
containers: #必选，Pod中容器列表
- name: string #必选，容器名称
image: string #必选，容器的镜像名称
imagePullPolicy: [ Always|Never|IfNotPresent ] #获取镜像的策略
command: [string] #容器的启动命令列表，如不指定，使用打包时使用的启动命令
args: [string] #容器的启动命令参数列表
workingDir: string #容器的工作目录
volumeMounts: #挂载到容器内部的存储卷配置
- name: string #引用pod定义的共享存储卷的名称，需用volumes[]部分定义的的卷名
mountPath: string #存储卷在容器内mount的绝对路径，应少于512字符
readOnly: boolean #是否为只读模式
ports: #需要暴露的端口库号列表
- name: string #端口的名称
containerPort: int #容器需要监听的端口号
hostPort: int #容器所在主机需要监听的端口号，默认与Container相同
protocol: string #端口协议，支持TCP和UDP，默认TCP
env: #容器运行前需设置的环境变量列表
- name: string #环境变量名称
value: string #环境变量的值
resources: #资源限制和请求的设置
limits: #资源限制的设置
cpu: string #Cpu的限制，单位为core数，将用于docker run --cpu-shares参数
memory: string #内存限制，单位可以为Mib/Gib，将用于docker run --memory参数
requests: #资源请求的设置
cpu: string #Cpu请求，容器启动的初始可用数量
memory: string #内存请求,容器启动的初始可用数量
lifecycle: #生命周期钩子
postStart: #容器启动后立即执行此钩子,如果执行失败,会根据重启策略进行重启
preStop: #容器终止前执行此钩子,无论结果如何,容器都会终止
livenessProbe: #对Pod内各容器健康检查的设置，当探测无响应几次后将自动重启该容器
exec: #对Pod容器内检查方式设置为exec方式
command: [string] #exec方式需要制定的命令或脚本
httpGet: #对Pod内个容器健康检查方法设置为HttpGet，需要制定Path、port
path: string
port: number
host: string
scheme: string
HttpHeaders:
- name: string
value: string
tcpSocket: #对Pod内个容器健康检查方式设置为tcpSocket方式
port: number
initialDelaySeconds: 0 #容器启动完成后首次探测的时间，单位为秒
timeoutSeconds: 0 #对容器健康检查探测等待响应的超时时间，单位秒，默认1秒
periodSeconds: 0 #对容器监控检查的定期探测时间设置，单位秒，默认10秒一次
successThreshold: 0
failureThreshold: 0
securityContext:
privileged: false
restartPolicy: [Always | Never | OnFailure] #Pod的重启策略
nodeName: <string> #设置NodeName表示将该Pod调度到指定到名称的node节点上
nodeSelector: obeject #设置NodeSelector表示将该Pod调度到包含这个label的node上
imagePullSecrets: #Pull镜像时使用的secret名称，以key：secretkey格式指定
- name: string
hostNetwork: false #是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络
volumes: #在该pod上定义共享存储卷列表
- name: string #共享存储卷名称 （volumes类型有很多种）
emptyDir: {} #类型为emtyDir的存储卷，与Pod同生命周期的一个临时目录。为空值
hostPath: string #类型为hostPath的存储卷，表示挂载Pod所在宿主机的目录
path: string #Pod所在宿主机的目录，将被用于同期中mount的目录
secret: #类型为secret的存储卷，挂载集群与定义的secret对象到容器内部
scretname: string
items:
- key: string
path: string
configMap: #类型为configMap的存储卷，挂载预定义的configMap对象到容器内部
name: string
items:
- key: string
path: string
案例示意
# test-pod
apiVersion: v1 #指定api版本，此值必须在kubectl apiversion中
kind: Pod #指定创建资源的角色/类型
metadata: #资源的元数据/属性
name: test-pod #资源的名字，在同一个namespace中必须唯一
labels: #设定资源的标签
k8s-app: apache
version: v1
kubernetes.io/cluster-service: "true"
annotations: #自定义注解列表
- name: String #自定义注解名字
spec: #specification of the resource content 指定该资源的内容
restartPolicy: Always #表明该容器一直运行，默认k8s的策略，在此容器退出后，会立即创建一个相同的容器
nodeSelector: #节点选择，先给主机打标签kubectl label nodes kube-node1 zone=node1
zone: node1
containers:
- name: test-pod #容器的名字
image: 10.192.21.18:5000/test/chat:latest #容器使用的镜像地址
imagePullPolicy: Never #三个选择Always、Never、IfNotPresent，每次启动时检查和更新（从registery）images的策略，
# Always，每次都检查
# Never，每次都不检查（不管本地是否有）
# IfNotPresent，如果本地有就不检查，如果没有就拉取
command: ['sh'] #启动容器的运行命令，将覆盖容器中的Entrypoint,对应Dockefile中的ENTRYPOINT
args: ["$(str)"] #启动容器的命令参数，对应Dockerfile中CMD参数
workingDir: /root/
env: #指定容器中的环境变量
- name: str #变量的名字
value: "/etc/run.sh" #变量的值
resources: #资源管理
requests: #容器运行时，最低资源需求，也就是说最少需要多少资源容器才能正常运行
cpu: 0.1 #CPU资源（核数），两种方式，浮点数或者是整数+m，0.1=100m，最少值为0.001核（1m）
memory: 32Mi #内存使用量
limits: #资源限制
cpu: 0.5
memory: 1000Mi
ports:
- containerPort: 80 #容器开发对外的端口
name: httpd #名称
protocol: TCP
livenessProbe: #pod内容器健康检查的设置
httpGet: #通过httpget检查健康，返回200-399之间，则认为容器正常
path: / #URI地址
port: 80
#host: 127.0.0.1 #主机地址
scheme: HTTP
initialDelaySeconds: 180 #表明第一次检测在容器启动后多长时间后开始
timeoutSeconds: 5 #检测的超时时间
periodSeconds: 15 #检查间隔时间
#也可以用这种方法
#exec: 执行命令的方法进行监测，如果其退出码不为0，则认为容器正常
# command:
# - cat
# - /tmp/health
#也可以用这种方法
#tcpSocket: //通过tcpSocket检查健康
# port: number
lifecycle: #生命周期管理
postStart: #容器运行之前运行的任务
exec:
command:
- 'sh'
- 'yum upgrade -y'
preStop: #容器关闭之前运行的任务
exec:
command: ['service httpd stop']
volumeMounts: #挂载持久存储卷
- name: volume #挂载设备的名字，与volumes[*].name 需要对应
mountPath: /data #挂载到容器的某个路径下
readOnly: True
volumes: #定义一组挂载设备
- name: volume #定义一个挂载设备的名字
#meptyDir: {}
hostPath:
path: /opt #挂载设备类型为hostPath，路径为宿主机下的/opt,这里设备类型支持很多种
二、pod 生命周期
我们对pod 的生命周期做个简单了解即可。
image.png
1. initC
我们把 init container 简称 initC
1.1 特点
- initC总数运行到成功完成为止。
- 每个initC容器都必须在下一个initC启动之前成功完成。也就是说，如果init C1 运行失败，那么不会运行init C2。
- 如果initC容器运行失败，kubernetes集群会不断的重启该pod，知道inicC容器成功为止。
- 如果设置pod的 restartPolicy 属性为nerver，他就不会重新启动
1.2 资源清单示例
apiVersion: v1
kind: Pod
metadata:
name: initcpod-test
labels:
app: initcpod-test
spec:
containers:
- name: initcpod-test #相位
image: busybox:1.32.0 # container依赖镜像，busybox 可以为理解是一个轻量的linux系统，可以执行shell命令
imagePullPolicy: IfNotPresent # image pull 方式： 如果本地有用本地，否则从远端拉取
command: ['sh','-c','echo The app is running! && sleep 3600'] # 要执行的shell命令
initContainers:
- name: init-myservice
image: busybox:1.32.0
imagePullPolicy: IfNotPresent
command: ['sh','-c','until nslookup myservice; do echo waitting for myservice; sleep 2; done;']
- name: init-mydb
imagePullPolicy: IfNotPresent
image: busybox:1.32.0
command: ['sh','-c','until nslookup mydb; do echo waitting for mydb; sleep 2; done;']
restartPolicy: Always # pod失败重启策略
2. readinessProbe
2.1 特点
readinessProbe -- 准备就绪，用于判断pod容器是否准备就绪 ====== 对应我们查看pod 时 的 READ
image.png
1/1 initC 的数量对应 分母， initC 执行成功数量 对应 分子。
只有当Pod中的容器都处于就绪状态，也就是pod的condition里的Ready为true时，kubelet才会认定该Pod 处于就绪状态。而pod是否处于就绪状态的作用是控制哪些Pod应该作为service的后端。如果Pod处于非就绪状态，那么它们将会被从service的endpoint中移除。
2.2 资源清单示例
apiVersion: v1
kind: Pod
metadata:
name: readinessprobe-pod
labels:
app: readinessprobe-pod
spec:
containers:
- name: readinessprobe-pod
image: nginx:1.17.10-alpine
imagePullPolicy: IfNotPresent
readinessProbe: # 准备就绪检测策略
httpGet: # 使用httpGet的方式进行判断，访问80端口的index.html页面是否访问成功(访问成功代表准备就绪)
port: 80
path: /index1.html
initialDelaySeconds: 1 # 启动容器后的多长时间进行探测。
periodSeconds: 3 # 间隔多长时间执行一次探测， 默认是 10 秒。最小值是 1
timeoutSeconds: 5 # 探测超时等待多少秒进行下一次探测， 默认值是 1 秒。最小值是 1。
successThreshold: 1 # 从失败转为成功的重试次数，探测器失败后，被视为成功的最小连续成功数，默认值是1，存活探测的这个值必须是1，最小值是 1。
failureThreshold: 3 # 从成功转为失败的重试次数，当Pod启动了而且探测到失败，Kubernetes的重试次数，存活探测状况下的放弃就意味着重新启动容器，就绪探测状况下的放弃Pod会被打上`未就绪`的标签，默认值是3，最小值是1。
restartPolicy: Always
initialDelaySeconds是pod被调度后启动容器开始计算，如果应用启动的时间是49s，这里initialDelaySeconds是50s，后面每隔3s进行一次探测，根据failureThreshold的值是会进行3次探测，如果第一、二次探测为失败，第三次探测成功，根据successThreshold的值为1，说明只需要一次成功，就被标记为成功，还是会继续探测，但是 failureThreshold的值可以抽象认为是置0。如果第一、二、三次都为失败，根据 failureThreshold的值为3，容器会开始重启，重启完继续探测。
3. livenessProbe
3.1 特点
livenessProbe-- 存活检测，用于判断pod容器是否存活状态
确定何时重启容器。
liveness探测的结果会存储在livenessManager中。kubelet在syncPod时，发现该容器的liveness探针检测失败时，会将其加入待启动的容器列表中，在之后的操作中会重新创建该容器（kubelet将根据Pod配置清单中定义的重启策略restartPolicy来对Pod进行重启）。
3.2 资源清单示例
apiVersion: v1
kind: Pod
metadata:
name: livenesspod-test
labels:
app: livenesspod-test
spec:
containers:
- name: livenesspod-test
image: nginx:1.17.10-alpine
imagePullPolicy: IfNotPresent
livenessProbe:
httpGet:
port: 80
path: /index.html
initialDelaySeconds: 3
timeoutSeconds: 10
restartPolicy: Always
4. 钩子函数
4.1 特点
钩子函数为我们提供了两个节点：postStart、preStop 即： 开始后，结束前。
4.2 资源清单示例
apiVersion: v1
kind: Pod
metadata:
name: lifecle-test
labels:
app: lifecle-test
spec:
containers:
- name: lifecle-test
image: busybox:1.32.0
imagePullPolicy: IfNotPresent
command: ['sh','-c','sleep 5000']
lifecycle: # 钩子函数
postStart: # 触发节点，容器创建前之后运行
exec: # 执行 cmd 命令 xxxx
command: ['mkdir','-p','/lagou/k8s/index.html']
restartPolicy: Always
5. 完整的资源清单文件示例案例
这里用的是 Pod健康检查介绍 提供的示例，具体请参照博客原文
cat nginx-health.yaml
#create namespace
apiVersion: v1
kind: Namespace
metadata:
name: nginx-health-ns
labels:
resource: nginx-ns
spec:
---
#create deploy and pod
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-health-deploy
namespace: nginx-health-ns
labels:
resource: nginx-deploy
spec:
replicas: 3
revisionHistoryLimit: 10
selector:
matchLabels:
app: nginx-health
template:
metadata:
namespace: nginx-health-ns
labels:
app: nginx-health
spec:
restartPolicy: Always
containers:
- name: nginx-health-containers
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
command:
- /bin/sh
- -c
- /usr/sbin/nginx; sleep 60; rm -rf /run/nginx.pid
readinessProbe:
initialDelaySeconds: 5
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 3
failureThreshold: 1
httpGet:
path: /index.html
port: 80
scheme: HTTP
livenessProbe:
initialDelaySeconds: 15
periodSeconds: 3
successThreshold: 1
timeoutSeconds: 1
failureThreshold: 2
tcpSocket:
port: 80
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
---
#create service
apiVersion: v1
kind: Service
metadata:
name: nginx-health-svc
namespace: nginx-health-ns
labels:
resource: nginx-svc
spec:
clusterIP: 10.106.189.88
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: nginx-health
sessionAffinity: ClientIP
type: ClusterIP
三、pod 生命周期总结
pod对象自从创建开始至终止退出的时间范围称为生命周期，在这段时间中，pod会处于多种不同的状态，并执行一些操作；其中，创建主容器为必须的操作，其他可选的操作还包括运行初始化容器（init container）、容器启动后钩子（start hook）、容器的存活性探测（liveness probe）、就绪性探测（readiness probe）以及容器终止前钩子（pre stop hook）等，这些操作是否执行则取决于pod的定义 。
1. pod 相位--STATUS
使用 kubectl get pods 命令,STATUS被称之为相位(phase)。
无论是手动创建还是通过控制器创建pod，pod对象总是应该处于其生命进程中以下几个相位之一：
- pending：apiserver创建了pod资源对象并存入etcd中，但它尚未被调度完成或者仍处于下载镜像的过程中
- running：pod已经被调度至某节点，并且所有容器都已经被kubelet创建完成
- succeeded：pod中的所有容器都已经成功终止并且不会被重启
- failed：所有容器都已经终止，但至少有一个容器终止失败，即容器返回了非0值的退出状态或已经被系统终止。
- unknown：apiserver无法正常获取到pod对象的状态信息，通常是由于其无法于所在工作节点的kubelet通信所致。
pod的相位是在其生命周期中的宏观概念，而非对容器或pod对象的综合汇总，而且相位的数量和含义被严格界定。
2. pod 创建过程
pod是k8s的基础单元，以下为一个pod资源对象的典型创建过程：
- 用户通过kubectl或其他api客户端提交pod spec给api server
- api server尝试着将pod对象的相关信息存入etcd中，待写入操作执行完成，api server即会返回确认信息至客户端。
- api server开始反映etcd中的状态变化
- 所有的k8s组件均使用watch机制来跟踪检查api server上的相关变动
- kube-scheduler通过其watch觉察到api server创建了新的pod对象但尚未绑定至任何工作节点
- kube-scheduler为pod对象挑选一个工作节点并将结果信息更新至api server
- 调度结果信息由api server更新至etcd，而且api server也开始反映此pod对象的调度结果
- pod被调度到目标工作节点上的kubelet尝试在当前节点上调用docker启动容器，并将容器的结果状态回送至api server
- api server将pod状态信息存入etcd中
- 在etcd确认写入操作成功完成后，api server将确认信息发送至相关的kubelet。
3. pod 生命周期中的重要行为
除了创建应用容器之外，用户还可以为pod对象定义其生命周期中的多种行为，如初始化容器、存活性探测及就绪性探测等。
初始化容器即应用程序的主容器启动之前要运行的容器，常用于为主容器执行一些预置操作，它们具有两种典型特征：
- 初始化容器必须运行完成直至结束，若某初始化容器运行失败，那么k8s需要重启它直到成功完成
- 每个初始化容器都必须按定义的顺序串行运行
有不少场景都需要在应用容器启动之前进行部分初始化操作，例如，等待其他相关联组件服务可用、基于环境变量或配置模板为应用程序生成配置文件、从配置中心获取配置等。初始化容器的典型应用需求具体包含如下几种：
- 用于运行特定的工具程序，出于安全等反面的原因，这些程序不适于包含在主容器镜像中
- 提供主容器镜像中不具备的工具程序或自定义代码
- 为容器镜像的构建和部署人员提供了分离、独立工作的途径，使得它们不必协同起来制作单个镜像文件
- 初始化容器和主容器处于不同的文件系统视图中，因此可以分别安全地使用敏感数据，例如secrets资源
- 初始化容器要先于应用容器串行启动并运行完成，因此可用于延后应用容器的启动直至其依赖的条件得到满足
pod资源的spec.initContainers字段以列表的形式定义可用的初始容器，其嵌套可用字段类似于spec.containers。
4. 生命周期钩子函数(hook)
容器生命周期钩子使它能够感知其自身生命周期管理中的事件，并在相应的时刻到来时运行由用户指定的处理程序代码。k8s为容器提供了两种生命周期钩子：
- postStart：于容器创建完成之后立即运行的钩子处理器（handler），不过k8s无法确保它一定会于容器中的entrypoint之前运行
- preStop：于容器终止操作之前立即运行的钩子处理器，它以同步的方式调用，因此在其完成之前会阻塞删除容器的操作调用。
钩子处理器的实现方法由Exec和HTTP两种，前一种在钩子事件触发时直接在当前容器中运行由用户定义的命令，后一种则是在当前容器中向某url发起http请求。postStart和preStop处理器定义在spec.lifecycle嵌套字段中
5. 容器探测
容器探测是pod对象生命周期中的一项重要的日常任务，它是kubelet对容器周期性执行的健康状态诊断，诊断操作由容器的处理器进行定义。k8s支持三种容器探针用于pod探测：
- ExecAction：在容器中执行一个命令，并根据其返回的状态码进行诊断的操作称为Exec探测，状态码为0表示成功，否则即为不健康状态
- TCPSocketAction：通过与容器的某TCP端口尝试建立连接进行诊断，端口能够成功打开即为正常，否则为不健康状态。
- HTTPGetAction：通过向容器IP地址的某指定端口的指定path发起HTTP GET请求进行诊断，响应码大于等于200且小于400时即为成功。
任何一种探测方式都可能存在三种结果：
- success(成功)：容器通过了诊断
- failure(失败)：容器未通过了诊断
- unknown(未知)：诊断失败，因此不会采取任何行动
kubelet可在活动容器上执行两种类型的检测：
- (livenessProbe)存活性检测：用于判定容器是否处于运行状态，一旦此类检测未通过，kubelet将杀死容器并根据restartPolicy决定是否将其重启；未定义存活性检测的容器的默认状态为success
- (readinessProbe)就绪性检测：用于判断容器是否准备就绪并可对外提供服务；未通过检测的容器意味着尚未准备就绪，端点控制器会将其IP从所有匹配到此pod对象的service对象的端点列表中移除；检测通过之后，会再次将其IP添加至端点列表中。
6. 容器的重启策略
容器程序发生奔溃或容器申请超出限制的资源等原因都可能会导致pod对象的终止，此时是否应该重建该pod对象则取决于其重启策略（restartPolicy）属性的定义：
- Always：但凡pod对象终止就将其重启，此为默认设定
- OnFailure：紧在pod对象出现错误时方才将其重启
- Never：从不重启。
restartPolicy适用于pod对象中的所有容器，而且它仅用于控制在同一节点上重新启动pod对象的相关容器。首次需要重启的容器，将在其需要时立即进行重启，随后再次需要重启的操作将由kubelet延迟一段时间后进行，且反复的重启操作的延迟时长以此为例10s、20s、40s、80s、160s和300s，300s是最大延迟时长。事实上，一旦绑定到一个节点，pod对象将永远不会重新绑定到另一个节点，它要么被重启，要么终止，直到节点发生故障或被删除
7. pod 的终止过程
当用户提交删除请求之后，系统就会进行强制删除操作的宽限期倒计时，并将TERM信息发送给pod对象的每个容器中的主进程。宽限期倒计时结束后，这些进程将收到强制终止的KILL信号，pod对象随即也将由api server删除，如果在等待进程终止的过程中，kubelet或容器管理器发生了重启，那么终止操作会重新获得一个满额的删除宽限期并重新执行删除操作。
一个典型的pod对象终止流程具体如下：
- 用户发送删除pod对象的命令
- api服务器中的pod对象会随着时间的推移而更新，在宽限期内（默认30s），pod被视为dead
- 将pod标记为terminating状态
- 与第三步同时运行，kubelet在监控到pod对象转为terminating状态的同时启动pod关闭过程
- 与第三步同时运行，端点控制器监控到pod对象的关闭行为时将其从所有匹配到此端点的service资源的端点列表中移除
- 如果当前pod对象定义了preStop钩子处理器，则在其标记为terminating后即会以同步的方式启动执行；若宽限期结束后，preStop仍未执行结束，则第二步会被重新执行并额外获取一个时长为2s的小宽限期
- pod对象中的容器进程收到TERM信号
- 宽限期结束后，若存在任何一个仍在运行的进程，那么pod对象即会收到SIGKILL信号
- kubelet请求api server将此pod资源的宽限期设置为0从而完成删除操作，它变得对用户不再可见。
默认情况下，所有删除操作的宽限期都是30s，不过，kubectl delete命令可以使用“--grace-period=”选项自定义其时长，若使用0值则表示直接强制删除指定的资源，不过此时需要同时使用命令“--forece”选项。
网友评论