回到目录
工作负载(workloads)
工作负载(workload)是在kubernetes集群中运行的应用程序。无论你的工作负载是单一服务还是多个一同工作的服务构成,在kubernetes中都可以使用pod来运行它
workloads分为pod与controllers
-
pod通过控制器实现应用的运行,如何伸缩,升级等
-
controllers 在集群中管理pod
-
pod与控制器之间通过label-selector相关联,是唯一的关联方式
官方文档https://kubernetes.io/zh-cn/docs/concepts/workloads/
一 pod介绍
官网文档 podhttps://kubernetes.io/zh-cn/docs/concepts/workloads/pods/
1.1 pod定义
-
Pod(豌豆荚) 是Kubernetes集群管理(创建、部署)与调度的最小计算单元,表示处于运行状态的一组容器。
-
Pod不是进程,而是容器运行的环境。
-
一个Pod可以封装一个容器或多个容器(主容器或sidecar边车容器)
-
一个pod内的多个容器之间共享部分命名空间,例如:Net Namespace,UTS Namespace,IPC Namespace及存储资源
-
用户pod默认会被调度运行在node节点之上(不运行在master节点上,但也有例外情况,污点和容忍)
-
pod内的IP不是固定的,集群外不能直接访问pod
1.2 pod分类
-
静态Pod 也称之为“无控制器管理的自主式pod”,直接由特定节点上的
kubelet
守护进程管理, 不需要API 服务器看到它们,尽管大多数 Pod 都是通过控制面(例如,Deployment) 来管理的,对于静态 Pod 而言,kubelet
直接监控每个 Pod,并在其失效时重启之。 -
控制器管理的pod 控制器可以控制pod的副本数,扩容与裁剪,版本更新与回滚等
1.3 查看pod命令
kubectl get pod # pod或pods,po都可以,不指定namespace,默认是名为default的namespace
kubectl get pod -n kube-system
1.4 pod的yaml资源清单格式
# yaml格式的pod定义文件完整内容:
apiVersion: v1 #必选,api版本号,例如v1
kind: Pod #必选,Pod
metadata: #必选,元数据name: string #必选,Pod名称namespace: string #Pod所属的命名空间,默认在default的namespacelabels: # 自定义标签name: string #自定义标签名字annotations: #自定义注释列表name: string
spec: #必选,Pod中容器的详细定义(期望)containers: #必选,Pod中容器列表- name: string #必选,容器名称image: string #必选,容器的镜像名称imagePullPolicy: [Always | Never | IfNotPresent] #获取镜像的策略 Alawys表示下载镜像 IfnotPresent表示优先使用本地镜像,否则下载镜像,Nerver表示仅使用本地镜像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,默认TCPenv: #容器运行前需设置的环境变量列表- 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 #内存清求,容器启动的初始可用数量livenessProbe: #对Pod内个容器健康检查的设置,当探测无响应几次后将自动重启该容器,检查方法有exec、httpGet和tcpSocket,对一个容器只需设置其中一种方法即可exec: #对Pod容器内检查方式设置为exec方式command: [string] #exec方式需要制定的命令或脚本httpGet: #对Pod内个容器健康检查方法设置为HttpGet,需要制定Path、portpath: stringport: numberhost: stringscheme: stringHttpHeaders:- name: stringvalue: stringtcpSocket: #对Pod内个容器健康检查方式设置为tcpSocket方式port: numberinitialDelaySeconds: 0 #容器启动完成后首次探测的时间,单位为秒timeoutSeconds: 0 #对容器健康检查探测等待响应的超时时间,单位秒,默认1秒periodSeconds: 0 #对容器监控检查的定期探测时间设置,单位秒,默认10秒一次successThreshold: 0failureThreshold: 0securityContext:privileged:falserestartPolicy: [Always | Never | OnFailure] # Pod的重启策略,Always表示一旦不管以何种方式终止运行,kubelet都将重启,OnFailure表示只有Pod以非0退出码退出才重启,Nerver表示不再重启该PodnodeSelector: obeject # 设置NodeSelector表示将该Pod调度到包含这个label的node上,以key:value的格式指定imagePullSecrets: #Pull镜像时使用的secret名称,以key:secretkey格式指定- name: stringhostNetwork: 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: stringpath: stringconfigMap: #类型为configMap的存储卷,挂载预定义的configMap对象到容器内部name: stringitems:- key: stringpath: string
YAML格式查找帮助方法回顾
kubectl explain namespace
[root@k8s-master ~]# kubectl explain namespace
KIND: Namespace
VERSION: v1DESCRIPTION:Namespace provides a scope for Names. Use of multiple namespaces isoptional.FIELDS:apiVersion <string>APIVersion defines the versioned schema of this representation of anobject. Servers should convert recognized schemas to the latest internalvalue, and may reject unrecognized values. More info:https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resourceskind <string>Kind is a string value representing the REST resource this objectrepresents. Servers may infer this from the endpoint the client submitsrequests to. Cannot be updated. In CamelCase. More info:https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kindsmetadata <Object>Standard object's metadata. More info:https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadataspec <Object>Spec defines the behavior of the Namespace. More info:https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-statusstatus <Object>Status describes the current status of a Namespace. More info:https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
kubectl explain pod
root@k8s-master ~]# kubectl explain pod
KIND: Pod
VERSION: v1DESCRIPTION:Pod is a collection of containers that can run on a host. This resource iscreated by clients and scheduled onto hosts.FIELDS:apiVersion <string>APIVersion defines the versioned schema of this representation of anobject. Servers should convert recognized schemas to the latest internalvalue, and may reject unrecognized values. More info:https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resourceskind <string>Kind is a string value representing the REST resource this objectrepresents. Servers may infer this from the endpoint the client submitsrequests to. Cannot be updated. In CamelCase. More info:https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kindsmetadata <Object>Standard object's metadata. More info:https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadataspec <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-statusstatus <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
二 pod创建
2.1 命令创建
2.1.1 创建
# kubectl run pod名 --image=镜像名
kubectl run nginx1 --image=nginx:1.15-alpine
2.1.2 验证
#查看默认命名空间的所有pod
kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx1 1/1 Running 0 41s
2.2 yaml创建pod
2.2.1 准备ymal文件
apiVersion: v1 # api版本
kind: Pod # 资源类型为Pod
metadata: name: pod-stress # 自定义pod的名称
spec:containers: # 定义pod里包含的容器- name: c1 # 自定义pod中的容器名image: polinux/stress # 启动容器的镜像名command: ["stress"] # 自定义启动容器时要执行的命令(类似dockerfile里的CMD)args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"] # 自定义启动容器执行命令的参数# polinux/stress这个镜像用于压力测试,在启动容器时传命令与参数就是相当于分配容器运行时需要的压力
2.2.2 创建
#kubectl apply -f yaml文件
kubectl apply -f pod1.yml
三 pod查看
3.1 查看基本信息
命令语法:
kubectl get pod
kubectl get po
kubectl get pods
[root@k8s-master1 ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
pod-stress 1/1 Running 0 45s
3.2 查看详细信息
命令语法:
default命名空间:kubectl get pods -o wide
指定命名空间:kubectl get pods -o wide -n kube-system
[root@k8s-master1 ~]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-stress 1/1 Running 0 71s 10.244.194.72 k8s-worker1 <none> <none>
3.3 查看指定pod的详细信息
命令语法:kubectl describe pod pod名称
[root@k8s-master1 ~]# kubectl describe pod pod-stress
......
Events:Type Reason Age From Message---- ------ ---- ---- -------Normal Scheduled 102s default-scheduler Successfully assigned default/pod-stress to k8s-worker1Normal Pulling 102s kubelet Pulling image "polinux/stress"Normal Pulled 83s kubelet Successfully pulled image "polinux/stress" in 18.944533343sNormal Created 83s kubelet Created container c1Normal Started 82s kubelet Started container c1
四 pod删除
4.1 单个pod删除
4.1.1 方式一:指定pod名称
命令语法: kubectl delete pod pod名称
[root@k8s-master1 ~]# kubectl delete pod pod-stress
pod "pod-stress" deleted
4.1.2 方式二:通过yaml文件
命令语法:kubectl delete -f pod创建的yaml文件
[root@k8s-master1 ~]# kubectl delete -f pod1.yml
4.2 多个pod删除
4.2.1 后接多个pod名
[root@k8s-master1 ~]# kubectl delete pod pod名1 pod名2 pod名3 ......
4.2.2 通过awk截取要删除的pod名称,然后管道给xargs
现获取pods,取第一列,并且行数大于1(取消列头name)
[root@k8s-master1 ~]# kubectl get pods |awk 'NR>1 {print $1}' |xargs kubectl delete pod
4.2.3 如果要删除的pod都在同一个非default的命名空间,则可直接删除命名空间
[root@k8s-master1 ~]# kubectl delete ns xxxx
五 镜像拉去策略
由imagePullPolicy参数控制
-
Always : 不管本地有没有镜像,都要从仓库中下载镜像
-
Never : 从来不从仓库下载镜像, 只用本地镜像,本地没有就算了
-
IfNotPresent: 如果本地存在就直接使用, 不存在才从仓库下载
默认的策略是:
-
当镜像标签版本是latest,默认策略就是Always
-
如果指定特定版本默认拉取策略就是IfNotPresent。
yaml例子
apiVersion: v1
kind: Pod
metadata:name: pod-stressnamespace: default
spec:containers:- name: c1image: polinux/stresscommand: ["stress"]args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]imagePullPolicy: IfNotPresent # 增加了这一句
六 pod标签
为pod设置label,用于控制器通过label与pod关联
node的标签和pod标签区别
node的label用于pod调度到指定label的node节点
pod的label用于controller关联控制的pod
6.1 通过命令管理pod标签
6.1.1 查看
命令语法: kubectl get pods --show-labels
[root@k8s-master1 ~]# kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
pod-stress 1/1 Running 0 7m25s <none>
6.1.2 加标签
命令语法:kubectl label pod pod名称 标签
[root@k8s-master1 ~]# kubectl label pod pod-stress region=huanai zone=A env=test bussiness=game
pod/pod-stress labeled[root@k8s-master1 ~]# kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
pod-stress 1/1 Running 0 8m54s bussiness=game,env=test,region=huanai,zone=A
6.2.3 删除标签
命令语法:kubectl label pod pod名称 标签名-
[root@k8s-master1 ~]# kubectl label pod pod-stress region- zone- env- bussiness-
pod/pod-stress labeled[root@k8s-master1 ~]# kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
pod-stress 1/1 Running 0 16m <none>
6.2.4 查找
方式一:等值关系查找
命令语法: kubectl get pods -l 标签名=标签值
-l
指定为标签
[root@k8s-master1 ~]# kubectl get pods -l zone=A
NAME READY STATUS RESTARTS AGE
pod-stress 1/1 Running 0 9m22s
方式二:集合关系查找
命令语法: kubectl get pods -l "标签名 in (标签值,标签值)
[root@k8s-master1 ~]# kubectl get pods -l "zone in (A,B,C)"
NAME READY STATUS RESTARTS AGE
pod-stress 1/1 Running 0 9m55s
6.2 通过yaml方式添加标签
在metadata中添加labels
apiVersion: v1
kind: Pod
metadata:name: pod-stressnamespace: defaultlabels:env: devapp: nginx # 直接在原来的yaml里加上多个标签
spec:containers:- name: c1image: polinux/stresscommand: ["stress"]args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]imagePullPolicy: IfNotPresent
七 pod资源限制
spec.containers.resources中进行限制
包含对所占内存,cpu使用情况限制
spec:containers:- name: c1image: polinux/stressimagePullPolicy: IfNotPresentresources:limits:cpu: 0.5 #限制最多使用多少cpumemory: "200Mi" #限制最多使用内存200Mrequests:cpu: 0.1 #指定启动对小使用cpumemory: "100Mi" #指定启动时最小内存100M
注意
如果pod启动容器时由于对资源进行限制,没有达到启动要求,容器启动失败
-
如果启动策略时always,则会一直反复尝试重启
-
如果是OnFailures,只有当容器正常终止才重启
-
如果是Never,则不重启
七 对pod里的容器进行操作
命令 kubectl exec
7.1 直接用命令操作
格式为: kubectl exec pod名 -c 容器名 -- 命令
注意:
-
-c 容器名为可选项,如果是1个pod中1个容器,则不用指定;
-
如果是1个pod中多个容器,不指定默认为第1个。
[root@k8s-master1 ~]# kubectl exec pod-stress4 -c c2 -- touch /111[root@k8s-master1 ~]# kubectl exec pod-stress4 -c c2 -- ls /111
/111
不指定容器名,则默认为pod里的第1个容器
[root@k8s-master1 ~]# kubectl exec pod-stress4 -- touch /222
Defaulting container name to c1.
Use 'kubectl describe pod/pod-stress4 -n default' to see all of the containers in this pod.
7.2 与容器进行交互操作
命令格式kubectl exec -it pod名 -c 容器名 -- /bin/bash
和docker exec几乎一样
[root@k8s-master1 ~]# kubectl exec -it pod-stress4 -c c1 -- /bin/bash
bash-5.0# touch /333
bash-5.0# ls
222 bin etc lib mnt proc run srv tmp var
333 dev home media opt root sbin sys usr
bash-5.0# exit
exit
八 pod调度
8.1 pod调度过程
Step1
通过kubectl命令应用资源清单文件(yaml格式)向api server 发起一个create pod 请求Step2
api server接收到pod创建请求后,生成一个包含创建信息资源清单文件Step3
apiserver 将资源清单文件中信息写入etcd数据库Step4
Scheduler启动后会一直watch API Server,
获取 podSpec.NodeName为空的Pod,即判断pod.spec.Node == null?
若为null,表示这个Pod请求是新的,需要创建,
因此先进行调度计算(共计2步:1、过滤不满足条件的,2、选择优先级高的),
找到合适的node,然后将信息在etcd数据库中更新分配结果:pod.spec.Node = nodeA (设置一个具体的节点)Step5
kubelet 通过watch etcd数据库(即不停地看etcd中的记录),
发现有新的Node出现,如果这条记录中的Node与所在节点编号相同,
即这个Pod由scheduler分配给自己,
则调用node中的Container Runtime,进而创建container,
并将创建后的结果返回到给api server用于更新etcd数据库中数据状态。
8.2 pod调度到指定node节点中
我们为了实现容器主机资源平衡使用, 可以使用约束把pod调度到指定的node节点
spec.nodeName 通过nodeName调度pod到指定node上
spec.nodeSelector进行node标签匹配,调度到匹配上的node上
8.2.1 nodeName
apiVersion: v1
kind: Pod
metadata:name: pod-nodename
spec:nodeName: k8s-worker1 # 通过nodeName调度到k8s-worker1节点containers:- name: nginximage: nginx:1.15-alpine
8.2.2 nodeSelector
apiVersion: v1
kind: Pod
metadata:name: pod-nodeselect
spec:nodeSelector: # nodeSelector节点选择器bussiness: game # 指定调度到标签为bussiness=game的节点containers:- name: nginximage: nginx:1.15-alpine
九 pod的生命周期
有些pod(比如运行httpd服务),正常情况下会一直运行中,但如果手动删除它,此pod会终止
也有些pod(比如执行计算任务),任务计算完后就会自动终止
上面两种场景中,pod从创建到终止的过程就是pod的生命周期。
容器启动
-
pod中的容器在创建前,有初始化容器(init container)来进行初始化环境
-
初化完后,主容器(main container)开始启动
-
主容器启动后,有一个post start的操作(启动后的触发型操作,或者叫启动后钩子)
-
post start后,就开始做健康检查
-
第一个健康检查叫存活状态检查(liveness probe ),用来检查主容器存活状态的
-
第二个健康检查叫准备就绪检查(readiness probe),用来检查主容器是否启动就绪
-
容器终止
-
可以在容器终止前设置pre stop操作(终止前的触发型操作,或者叫终止前钩子)
-
当出现特殊情况不能正常销毁pod时,大概等待30秒会强制终止
-
终止容器后还可能会重启容器(视容器重启策略而定)。
9.1 探针
容器内应用的监测机制,根据不同的探针来判断容器应用当前的状态
9.1.1 探针类型
方式 | 说明 |
---|---|
Liveness Probe(存活状态探测) | 指示容器是否正在运行。如果存活态探测失败,则 kubelet 会杀死容器, 并且容器将根据其重启策略决定未来。如果容器不提供存活探针, 则默认状态为 Success 。 |
readiness Probe(就绪型探测) | 指示容器是否准备好为请求提供服务。如果就绪态探测失败, 端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。 初始延迟之前的就绪态的状态值默认为 Failure 。 如果容器不提供就绪态探针,则默认状态为 Success 。注:检查后不健康,将容器设置为Notready;如果使用service来访问,流量不会转发给此种状态的pod |
startup Probe | 指示容器中的应用是否已经启动。如果提供了启动探针,则所有其他探针都会被 禁用,直到此探针成功为止。如果启动探测失败,kubelet 将杀死容器,而容器依其 重启策略进行重启。 如果容器没有提供启动探测,则默认状态为 Success 。 |
9.1.2 探测方式
方式 | 说明 |
---|---|
Exec | 执行命令 |
HTTPGet | http请求某一个URL路径 |
TCP | tcp连接某一个端口 |
gRPC | 使用 gRPC 执行一个远程过程调用。 目标应该实现 gRPC健康检查。 如果响应的状态是 "SERVING",则认为诊断成功。 gRPC 探针是一个 alpha 特性,只有在你启用了 "GRPCContainerProbe" 特性门控时才能使用。 |
通用参数
initialDelaySeconds: 60 # 初始化时间
timeoutSeconds: 2 # 超时时间
periodSeconds: 5 # 监测间隔时间
successThreshold: 1 # 检查 1 次成功就表示成功
failureThreshold: 2 # 监测失败 2 次就表示失败
9.1.2.1 启动探针
当配置了 startupProbe 后,会先禁用其他探针,直到 startupProbe 成功后,其他探针才会继续。
作用:
由于有时候不能准确预估应用一定是多长时间启动成功,因此配置另外两种方式不方便配置初始化时长来检测
而配置了 statupProbe 后,只有在应用启动成功了,才会执行另外两种探针,可以更加方便的结合使用另外两种探针使用。
startupProbe:httpGet:path: /api/startupport: 80
9.1.2.1 存活探针
Spec.containers.livenessProbe
1 exec示例
apiVersion: v1
kind: Pod
metadata:name: liveness-execnamespace: default
spec:containers:- name: livenessimage: busyboximagePullPolicy: IfNotPresentargs:- /bin/sh- -c- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600livenessProbe: # 存活探针exec: # 命令方式command: # 命令- cat # 查看是否有这个目录- /tmp/healthyinitialDelaySeconds: 5 # pod启动延迟5秒后探测periodSeconds: 5 # 每5秒探测1次
查看pod日志
[root@k8s-master1 ~]# kubectl describe pod liveness-exec
......
Events:Type Reason Age From Message---- ------ ---- ---- -------Normal Scheduled 40s default-scheduler Successfully assigned default/liveness-exec to k8s-worker1Normal Pulled 38s kubelet Container image "busybox" already present on machineNormal Created 37s kubelet Created container livenessNormal Started 37s kubelet Started container livenessWarning Unhealthy 3s kubelet Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory看到40s前被调度以k8s-worker1节点,3s前健康检查出问题
2 httpGet示例
apiVersion: v1
kind: Pod
metadata:name: liveness-httpgetnamespace: default
spec:containers:- name: livenessimage: nginx:1.15-alpineimagePullPolicy: IfNotPresentports: # 指定容器端口,这一段不写也行,端口由镜像决定 - name: http # 自定义名称,不需要与下面的port: http对应containerPort: 80 # 类似dockerfile里的expose 80livenessProbe:httpGet: # 使用httpGet方式port: http # http协议,也可以直接写80端口path: /index.html # 探测家目录下的index.htmlinitialDelaySeconds: 3 # 延迟3秒开始探测periodSeconds: 5 # 每隔5s钟探测一次
3 tcp示例
apiVersion: v1
kind: Pod
metadata:name: liveness-tcpnamespace: default
spec:containers:- name: livenessimage: nginx:1.15-alpineimagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80livenessProbe:tcpSocket: # 使用tcp连接方式port: 80 # 连接80端口进行探测initialDelaySeconds: 3periodSeconds: 5
9.1.2.2 准备好探针
apiVersion: v1
kind: Pod
metadata:name: readiness-httpgetnamespace: default
spec:containers:- name: readinessimage: nginx:1.15-alpineimagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80readinessProbe: # 这里由liveness换成了readinesshttpGet:port: httppath: /index.htmlinitialDelaySeconds: 3periodSeconds: 5
9.2 生命周期
post-start:容器创建完成后执行的动作,不能保证该操作一定在容器的 command 之前执行,一般不使用
pre-stop:在容器停止前执行的动作
9.2.1 post-start
apiVersion: v1
kind: Pod
metadata:name: poststartnamespace: default
spec:containers:- name: poststartimage: nginx:1.15-alpineimagePullPolicy: IfNotPresentlifecycle: # 生命周期事件postStart: #容器创建完成后执行动作exec: # 可以是 exec / httpGet / tcpSocketcommand: ["mkdir","-p","/usr/share/nginx/html/haha"]
9.2.2 pre-stop
apiVersion: v1
kind: Pod
metadata:name: prestopnamespace: default
spec:containers:- name: prestopimage: nginx:1.15-alpineimagePullPolicy: IfNotPresentlifecycle: # 生命周期事件preStop: # preStopexec: # 可以是 exec / httpGet / tcpSocketcommand: ["/bin/sh","-c","sleep 60000000"] # 容器终止前sleep 60000000秒httpGet: # 发送一个 http 请求path: /port: 80
由于 k8s 默认给 pod 的停止宽限时间为 30s
如果我们停止操作会超过 30s 时,不要光设置 sleep 50,还要将 terminationGracePeriodSeconds: 30 也更新成更长的时间
否则 k8s 最多只会在这个时间的基础上再宽限几秒,不会真正等待 50s
9.3 pod退出流程
-
endpoint中删除该pod的ip
-
pod状态变成terminating状态
-
执行pre-stop的指令
9.4 pod的pre-stop应用
-
注册中心下线
-
数据清理
-
数据销毁
十 pod故障排除
状态 | 描述 |
---|---|
Pending(悬决) | Pod 已被 Kubernetes 系统接受,但有一个或者多个容器尚未创建亦未运行。此阶段包括等待 Pod 被调度的时间和通过网络下载镜像的时间。 |
Running(运行中) | pod已经绑定到一个节点,并且已经创建了所有容器。至少有一个容器正在运行中,或正在启动或重新启动。 |
completed(完成) | Pod中的所有容器都已成功终止,不会重新启动。 |
Failed(失败) | Pod的所有容器均已终止,且至少有一个容器已在故障中终止。也就是说,容器要么以非零状态退出,要么被系统终止。 |
Unknown(未知) | 由于某种原因apiserver无法获得Pod的状态,通常是由于Master与Pod所在主机kubelet通信时出错。 |
CrashLoopBackOff | 多见于CMD语句错误或者找不到container入口语句导致了快速退出,可以用kubectl logs 查看日志进行排错 |
查看pod具体日志
-
kubectl describe pod pod名 # 查看pod描述信息
-
kubectl logs pod [-c CONTAINER] # 查看pod的详细日志
-
kubectl exec POD [-c CONTAINER] --COMMAND [args...] # 进入pod查看