目录
一、资源限制
1. CPU 资源单位
2.内存 资源单位
3.示例
二、重启策略
三、健康检查（探针)
1.探针的三种规则：
1.1就绪探测
2.Probe支持三种检查方法：
2.1exec检查方式
2.2httpGet方式
2.3tcpSocket方式
3. 启动、退出动作
3.1编写启动和退出动作的yaml文件
3.2验证启动、退出动作
一、资源限制
当定义 Pod 时可以选择性地为每个容器设定所需要的资源数量。 最常见的可设定资源是 CPU 和内存大小，以及其他类型的资源。
- 当为 Pod 中的容器指定了 request 资源时，代表容器运行所需的最小资源量，调度器就使用该信息来决定将 Pod 调度到哪个节点上。当还为容器指定了 limit 资源时，kubelet 就会确保运行的容器不会使用超出所设的 limit 资源量。kubelet 还会为容器预留所设的 request 资源量， 供该容器使用。
- 如果 Pod 运行所在的节点具有足够的可用资源，容器可以使用超出所设置的 request 资源量。不过，容器不可以使用超出所设置的 limit 资源量。
- 如果给容器设置了内存的 limit 值，但未设置内存的 request 值，Kubernetes 会自动为其设置与内存 limit 相匹配的 request 值。 类似的，如果给容器设置了 CPU 的 limit 值但未设置 CPU 的 request 值，则 Kubernetes 自动为其设置 CPU 的 request 值 并使之与 CPU 的 limit 值匹配。
官网示例：
https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/
//Pod 和 容器 的资源请求和限制：
spec.containers[].resources.requests.cpu #定义创建容器时预分配的CPU资源
spec.containers[].resources.requests.memory #定义创建容器时预分配的内存资源
spec.containers[].resources.limits.cpu #定义 cpu 的资源上限
spec.containers[].resources.limits.memory #定义内存的资源上限1. CPU 资源单位
CPU 资源的 request 和 limit 以 cpu 为单位。Kubernetes 中的一个 cpu 相当于1个 vCPU（1个超线程）。
Kubernetes 也支持带小数 CPU 的请求。spec.containers[].resources.requests.cpu 为 0.5 的容器能够获得一个 cpu 的一半 CPU 资源（类似于Cgroup对CPU资源的时间分片）。表达式 0.1 等价于表达式 100m（毫核），表示每 1000 毫秒内容器可以使用的 CPU 时间总量为 0.1*1000 毫秒。
Kubernetes 不允许设置精度小于 1m 的 CPU 资源。
2.内存 资源单位
内存的 request 和 limit 以字节为单位。可以以整数表示，或者以10为底数的指数的单位（E、P、T、G、M、K）来表示， 或者以2为底数的指数的单位（Ei、Pi、Ti、Gi、Mi、Ki）来表示。
如：
- 1KB=10^3=1000，1MB=10^6=1000000=1000KB，1GB=10^9=1000000000=1000MB
- 1KiB=2^10=1024，1MiB=2^20=1048576=1024KiB
3.示例
apiVersion: v1
kind: Pod
metadata:
name: frontend
spec:
containers:
- name: web
image: nginx
imagePullPolicy: IfNotPresent
env:
- name: WEB_ROOT_PASSWORD
value: "password"
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
- name: db
image: mysql
imagePullPolicy: IfNotPresent #设置镜像拉取策略
env:
- name: MYSQL_ROOT_PASSWORD #设置密码
value: "abc123"
resources:
requests: #requests：预留的最少资源
memory: "512Mi"
cpu: "0.5"
limits: #limits：资源所需的上限值
memory: "1Gi" #mysql镜像至少要1G，少于1G会导致OOM问题（内存不足）
cpu: "1"
此例子中的 Pod 有两个容器。
nginx容器的 request 值为 0.25 cpu 和 64MiB 内存，每个容器的 limit 值为 0.5 cpu 和 128MiB 内存。
mysql容器的 request 值为 0.5 cpu 和 512MiB 内存，每个容器的 limit 值为 1 cpu 和 1Gi 内存。
那么可以认为该 Pod 的总的资源 request 为 0.75 cpu 和 576 MiB 内存，总的资源 limit 为 1.5 cpu 和 1152MiB 内存。
kubectl describe nodes node01
二、重启策略
当 Pod 中的容器退出时通过节点上的 kubelet 重启容器。适用于 Pod 中的所有容器。
- Always：当容器终止退出后，总是重启容器，默认策略
- OnFailure：当容器异常退出（退出状态码非0）时，重启容器；正常退出则不重启容器
- Never：当容器终止退出，从不重启容器。
注意：
- K8S 中不支持重启 Pod 资源，只有删除重建。
- 在用 yaml 方式创建 Deployment 和 StatefulSet 类型时，restartPolicy 只能是 Always，kubectl run 创建 Pod 可以选择 Always,OnFailure,Never 三种策略
#示例
vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:
name: foo
spec:
containers:
- name: busybox
image: busybox
args:
- /bin/sh
- -c
- sleep 30; exit 3
kubectl apply -f pod3.yaml
#查看Pod状态，等容器启动后30秒后执行exit退出进程进入error状态，就会重启次数加1
kubectl get pods
NAME READY STATUS RESTARTS AGE
foo 1/1 Running 1 50s三、健康检查（探针)
探针是由kubelet对容器执行的定期诊断。
1.探针的三种规则：
- livenessProbe ：判断容器是否正在运行。如果探测失败，则kubelet会杀死容器，并且容器将根据 restartPolicy 来设置 Pod 状态。 如果容器不提供存活探针，则默认状态为Success。
- readinessProbe ：判断容器是否准备好接受请求。如果探测失败，端点控制器将从与 Pod 匹配的所有 service endpoints 中剔除删除该Pod的IP地址。 初始延迟之前的就绪状态默认为Failure。如果容器不提供就绪探针，则默认状态为Success。
- startupProbe（这个1.17版本增加的）：判断容器内的应用程序是否已启动，主要针对于不能确定具体启动时间的应用。如果配置了 startupProbe 探测，则在 startupProbe 状态为 Success 之前，其他所有探针都处于无效状态，直到它成功后其他探针才起作用。 如果 startupProbe 失败，kubelet 将杀死容器，容器将根据 restartPolicy 来重启。如果容器没有配置 startupProbe， 则默认状态为 Success。
注：以上规则可以同时定义。在readinessProbe检测成功之前，Pod的running状态是不会变成ready状态的。
1.1就绪探测
vim readiness-httpget.yaml
apiVersion: v1
kind: Pod
metadata:
name: readiness-httpget
namespace: default
spec:
containers:
- name: readiness-httpget-container
image: soscscs/myapp:v1
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
readinessProbe:
httpGet:
port: 80
path: /index1.html #就绪探针探测index1.html文件
initialDelaySeconds: 1
periodSeconds: 3
livenessProbe:
httpGet:
port: http
path: /index.html
initialDelaySeconds: 1
periodSeconds: 3
timeoutSeconds: 10
kubectl create -f readiness-httpget.yaml
#readiness探测失败，无法进入READY状态
kubectl get pods
NAME READY STATUS RESTARTS AGE
readiness-httpget 0/1 Running 0 18s
#进入容器中创建index1.com文件
kubectl exec -it readiness-httpget sh
# cd /usr/share/nginx/html/
# ls
50x.html index.html
# echo 123 > index1.html
# exit
kubectl get pods
NAME READY STATUS RESTARTS AGE
readiness-httpget 1/1 Running 0 2m31s
kubectl exec -it readiness-httpget -- rm -rf /usr/share/nginx/html/index.html
kubectl get pods -w
NAME READY STATUS RESTARTS AGE
readiness-httpget 1/1 Running 0 4m10s
readiness-httpget 0/1 Running 1 4m15s2.Probe支持三种检查方法：
- exec ：在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功。
- tcpSocket ：对指定端口上的容器的IP地址进行TCP检查（三次握手）。如果端口打开，则诊断被认为是成功的。
- httpGet ：对指定的端口和uri路径上的容器的IP地址执行HTTPGet请求。如果响应的状态码大于等于200且小于400，则诊断被认为是成功的
每次探测都将获得以下三种结果之一：
- 成功（Success）：表示容器通过了检测。
- 失败（Failure）：表示容器未通过检测。
- 未知（Unknown）：表示检测没有正常进行。
2.1exec检查方式
apiVersion: v1
kind: Pod
metadata:
labels:
run: pod-exec
name: pod-exec
spec:
containers:
- image: nginx
name: pod-demo3
command:
- sh
- -c
- "touch /nginx.txt; sleep 10; rm -f /nginx.txt; sleep 3600"
livenessProbe: #存活探针
exec: #探测方式，exec：在容器中执行命令探测
command: #容器中探测使用的命令
- "test -e /nginx.txt"
initialDelaySeconds: 2 #延迟探测时间
periodSeconds: 5 #每隔5秒再次探测
failureThreshold: 3 #探测失败后，重新探测次数
restartPolicy: Always #重启策略
kubectl descibe pod pod-exec
#initialDelaySeconds：指定 kubelet 在执行第一次探测前应该等待5秒，即第一次探测是在容器启动后的第6秒才开始执行。默认是 0 秒，最小值是 0。
#periodSeconds：指定了 kubelet 应该每 5 秒执行一次存活探测。默认是 10 秒。最小值是 1。
#failureThreshold: 当探测失败时，Kubernetes 将在放弃之前重试的次数。 存活探测情况下的放弃就意味着重新启动容器。就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。
#timeoutSeconds：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。（在 Kubernetes 1.20 版本之前，exec 探针会忽略 timeoutSeconds 探针会无限期地 持续运行，甚至可能超过所配置的限期，直到返回结果为止。） 
2.2httpGet方式
apiVersion: v1
kind: Pod
metadata:
labels:
run: pod-httpget
name: pod-httpget
spec:
containers:
- image: nginx
name: pod-demo4
ports: #指定容器的端口及端口名称
- name: http
containerPort: 80
livenessProbe:
httpGet:
port: http #探测http名称的端口
path: /index.html #请求的文件路径
initialDelaySeconds: 2
periodSeconds: 5
failureThreshold: 3
initialDelaySeconds: 3 #在执行第一次探测前应该等待3秒
timeoutSeconds: 10 #超过10秒未收到信息，则表示探测失败
restartPolicy: Always
#免交互删除容器中的文件
kubectl exec -it pod-httpget -- rm -f /usr/share/nginx/html/index.html
kubectl get pods -owide -w
kubectl describe pod pod-httpget
2.3tcpSocket方式
apiVersion: v1
kind: Pod
metadata:
labels:
run: pod-tcp
name: pod-tcp
spec:
containers:
- image: nginx
name: pod-demo4
ports:
- name: http
containerPort: 8080
livenessProbe:
tcpSocket:
port: http
initialDelaySeconds: 2
periodSeconds: 5
failureThreshold: 3
restartPolicy: Always
3. 启动、退出动作
- postStart：设置 Pod 容器启动时额外的命令操作
- preStop：设置 Pod 容器运行中被kubelet杀掉退出时所执行的命令操作（不包含容器自行退出的情况）
3.1编写启动和退出动作的yaml文件
vim post.yaml
apiVersion: v1
kind: Pod
metadata:
name: lifecycle-demo
spec:
containers:
- name: lifecycle-demo-container
image: soscscs/myapp:v1
lifecycle: #此为关键字段
postStart: #设置容器启动额外操作的命令
exec:
command: ["/bin/sh", "-c", "echo Hello from the postStart handler >> /var/log/nginx/message"]
preStop: #设置容器被kubectl删除退出时执行的操作命令
exec:
command: ["/bin/sh", "-c", "echo Hello from the poststop handler >> /var/log/nginx/message"]
volumeMounts:
- name: message-log
mountPath: /var/log/nginx/
readOnly: false
initContainers:
- name: init-myservice
image: soscscs/myapp:v1
command: ["/bin/sh", "-c", "echo 'Hello initContainers' >> /var/log/nginx/message"]
volumeMounts:
- name: message-log
mountPath: /var/log/nginx/
readOnly: false
volumes:
- name: message-log
hostPath:
path: /data/volumes/nginx/log/
type: DirectoryOrCreate3.2验证启动、退出动作
kubectl create -f post.yaml
kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
lifecycle-demo 1/1 Running 0 2m8s 10.244.2.28 node02 <none> <none>
kubectl exec -it lifecycle-demo -- cat /var/log/nginx/message
Hello initContainers
Hello from the postStart handler
//在 node02 节点上查看
[root@node02 ~]# cd /data/volumes/nginx/log/
[root@node02 log]# ls
access.log error.log message
[root@node02 log]# cat message
Hello initContainers
Hello from the postStart handler
#由上可知，init Container先执行，然后当一个主容器启动后，Kubernetes 将立即发送 postStart 事件。
//删除 pod 后，再在 node02 节点上查看
kubectl delete pod lifecycle-demo
[root@node02 log]# cat message
Hello initContainers
Hello from the postStart handler
Hello from the poststop handler
#由上可知，当在容器被终结之前， Kubernetes 将发送一个 preStop 事件。
