目录
一、资源限制
二、探针（健康检查）
2.1 含义
2.2 探针的三种规则
2.3 probe支持三种检查方法
2.4 探针的示例
1、存活探针：livenessProbe
（1）exec方式
（2）httpGet方式
（3）tcpsocket方式
2、就绪探针：readinessProbe
(1) 就绪探针1
(2) 就绪探针2
3、startupProbe
一、资源限制
容器中的程序要运行，肯定是要占用一定资源的，比如cpu和内存等，如果不对某个容器的资源做限制，那么它就可能吃掉大量资源，导致其它容器无法运行。 针对这种情况，kubernetes提供了对内存和cpu的资源进行配额的机制，这种机制主要通过resources选项实现，他有两个子选项：
limits： 用于限制运行时容器的最大占用资源，当容器占用资源超过limits时会被终止，并进行重启
requests ： 用于设置容器需要的最小资源，如果环境资源不够，容器将无法启动 内存资源单位
内存的request 和limit 以字节为单位，可以整数表示，或者以10为底数的指数的单位（E、P、T、G、M、K）来表示，或者以2 为底数的指数来表示（Ei、Pi、Ti、Gi、Mi、Ki）来表示。 cpu的单位如果为0.5，表示该容器能获取的一个Cpu的一半，（类似于Cgroup对cpu的资源的时间分片），表达式0.1等价于表达式100m（毫核），表示每1000毫秒内容器可以使用cpu时间总量为100号秒。
k8s中会根据预选和优选的策略，就是预选和优选cpu和内存大小，会把不符合的首先剔除，然后再选能保证最小基本运行的。
编辑一个yaml配置文件
vim pod2.yaml
[root@master01 ziyuan]# kubectl apply -f pod1.yaml
pod/frontend created#查看刚刚创建的pod，frontend所在的节点服务器，在node01
[root@master01 ziyuan]# kubectl get pods -owide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
frontend 2/2 Running 0 29m 10.244.1.73 node01 <none> <none>#查看节点01的详细信息，包含cpu，内存资源等信息，验证资源限制是否成功
[root@master01 ziyuan]# kubectl describe nodes node01
二、探针（健康检查）
2.1 含义
探针是由kubelet对容器执行的定期诊断
2.2 探针的三种规则
（1）livenessProbe
判断容器是否正在运行。如果探测失败，则kubelet会杀死容器，并且容器将根据 restartPolicy 来设置 Pod 状态。 如果容器不提供存活探针，则默认状态为Success。
（2）readinessProbe
判断容器是否准备好接受请求。如果探测失败，端点控制器将从与 Pod 匹配的所有 service 址endpoints 中剔除删除该Pod的IP地。 初始延迟之前的就绪状态默认为Failure。如果容器不提供就绪探针，则默认状态为Success。
（3）startupProbe
（这个1.17版本增加的）：判断容器内的应用程序是否已启动，主要针对于不能确定具体启动时间的应用。如果配置了 startupProbe 探测，在则在 startupProbe 状态为 Success 之前，其他所有探针都处于无效状态，直到它成功后其他探针才起作用。 如果 startupProbe 失败，kubelet 将杀死容器，容器将根据 restartPolicy 来重启。如果容器没有配置 startupProbe， 则默认状态为 Success。
#注：以上规则可以同时定义。在readinessProbe检测成功之前，Pod的running状态是不会变成ready状态的。
2.3 probe支持三种检查方法
（1）exec
在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功。
（2）tcpSocket
对指定端口上的容器的IP地址进行TCP检查（三次握手）。如果端口打开，则诊断被认为是成功的。
（3）httpGet
对指定的端口和路径上的容器的IP地址执行HTTPGet请求。如果响应的状态码大于等于200且小于400，则诊断被认为是成功的。
每次探测都获得以下三种结果之一：
成功：容器通过了诊断。
失败：容器未通过诊断。
未知：诊断失败，因此不会采取任何行动。
2.4 探针的示例
1、存活探针：livenessProbe
判断容器是否正在运行。如果探测失败，则kubelet会杀死容器，并且容器将根据 restartPolicy 来设置 Pod 状态。 如果容器不提供存活探针，则默认状态为Success。
（1）exec方式
编辑exec.yaml配置文件
vim exec.yaml
（2）httpGet方式
编辑httpget.yaml配置文件
vim httpget.yaml
[root@master01 ziyuan]# kubectl create -f httpget.yaml
pod/liveness-httpget created查看刚刚创建的pod
[root@master01 ziyuan]# kubectl get pods
NAME READY STATUS RESTARTS AGE
frontend 2/2 Running 0 77m
ky30 0/1 Error 0 21h
liveness-exec 1/1 Running 7 12m
liveness-httpget 1/1 Running 0 38s
myapp-pod 1/1 Running 8 24h
pod-demo2 0/1 CrashLoopBackOff 87 22h#进入liveness-httpgetpod中，并删除index.html文件进行测试
[root@master01 ziyuan]# kubectl exec -it liveness-httpget -- rm -rf /usr/share/nginx/html/index.html#再次查看刚刚创建的pod，发现因为刚刚删除过index.html文件了，导致pod中的容器重启
[root@master01 ziyuan]# kubectl get pods
NAME READY STATUS RESTARTS AGE
frontend 2/2 Running 0 77m
ky30 0/1 Error 0 21h
liveness-exec 1/1 Running 7 12m
liveness-httpget 1/1 Running 1 42s
myapp-pod 1/1 Running 8 24h
pod-demo2 0/1 CrashLoopBackOff 87 22h#查看刚刚创建的pod中容器的ip地址
[root@master01 ziyuan]# kubectl describe pod liveness-httpget
（3）tcpsocket方式
编辑tcpsocket.yaml配置文件
[root@master01 ziyuan]# vim tcpsocket.yaml
[root@master01 ziyuan]# kubectl create -f tcpsocket.yaml
pod/probe-tcp created
#这段输出表明在名为 "probe-tcp" 的 Pod 中，有一个正在监听 80 端口的 TCP 连接，该连接与 Nginx 服务器的主进程相关。这是一个常见的网络配置，用于接受来自客户端的 HTTP 请求。但是刚刚配置文件中指定的探测的端口是8080，所以探测失败，会重新再次探测。因为failureThreshold的值设置为2，所以当连续两次探测失败后，就会重启容器。
[root@master01 ziyuan]# kubectl exec -it probe-tcp -- netstat -natp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1/nginx: master pro
2、就绪探针：readinessProbe
判断容器是否准备好接受请求。如果探测失败，端点控制器将从与 Pod 匹配的所有 service 址endpoints 中剔除删除该Pod的IP地。 初始延迟之前的就绪状态默认为Failure。如果容器不提供就绪探针，则默认状态为Success。
(1) 就绪探针1
vim readness-httpget.yaml
[root@master01 jiuxu]# kubectl create -f readness-httpget.yaml
pod/readliness-httpget created
[root@master01 jiuxu]# kubectl describe pod readliness-httpget
(2) 就绪探针2
vim demo01-readness-myapp.yamlapiVersion: v1
kind: Pod
metadata:name: myapp1namespace: defaultlabels:app: myapp
spec:containers:- name: readiness-http-containerimage: soscscs/myapp:v1imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80readinessProbe:httpGet:port: 80path: /index.htmlinitialDelaySeconds: 1periodSeconds: 3timeoutSeconds: 10---
apiVersion: v1
kind: Pod
metadata:name: myapp2namespace: defaultlabels:app: myapp
spec:containers:- name: readiness-http-containerimage: soscscs/myapp:v1imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80readinessProbe:httpGet:port: 80path: /index.htmlinitialDelaySeconds: 1periodSeconds: 3timeoutSeconds: 10---
apiVersion: v1
kind: Pod
metadata:name: myapp3namespace: defaultlabels:app: myapp
spec:containers:- name: readiness-http-containerimage: soscscs/myapp:v1imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80readinessProbe:httpGet:port: 80path: /index.htmlinitialDelaySeconds: 1periodSeconds: 3timeoutSeconds: 10
---
apiVersion: v1
kind: Service
metadata:name: myapp-svc
spec:ports:- port: 80protocol: TCPtargetPort: 80selector:app: myapp[root@master01 jiuxu]# kubectl apply -f demo01-readness-myapp.yaml
pod/myapp1 created
pod/myapp2 created
pod/myapp3 created
service/myapp-svc created
#删除其中之一pod容器的html页面，使其就绪探针readiness探测失败
[root@master01 jiuxu]# kubectl exec -it myapp2 -- rm -rf /usr/share/nginx/html/index.html
3、startupProbe
spec.container.lifecycle.postStart 配合 exec.command 字段 当容器启动时，会执行的额外操作。
spec.container.lifecycle.postStop 配合 exec.command 字段 当容器退出时，会执行的操作。
（这个1.17版本增加的）：判断容器内的应用程序是否已启动，主要针对于不能确定具体启动时间的应用。如果配置了 startupProbe 探测，在则在 startupProbe 状态为 Success 之前，其他所有探针都处于无效状态，直到它成功后其他探针才起作用。 如果 startupProbe 失败，kubelet 将杀死容器，容器将根据 restartPolicy 来重启。如果容器没有配置 startupProbe， 则默认状态为 Success。
[root@master01 jiuxu]# vim demo2-start-up.yaml
[root@master01 jiuxu]# kubectl create -f demo2-start-up.yaml
pod/lifecycle-demo created
#删除pod
[root@master01 jiuxu]# kubectl delete pod lifecycle-demo
pod "lifecycle-demo" deleted
三、pod生命周期的状态
- 挂起（Pending）：apiserver已经创建了pod资源对象，但它尚未被调度完成或者仍处于下载镜像的过程中。
- 运行中（Running）：pod已经被调度至某节点，并且所有容器都已经被kubelet创建完成。
- 成功（Succeeded）：pod中的所有容器都已经成功终止并且不会被重启。
- 失败（Failed）：所有容器都已经终止，但至少有一个容器终止失败，即容器返回了非0值的退出状态。
- 未知（Unknown）：apiserver无法正常获取到pod对象的状态信息，通常由网络通信失败所导致。
