目录
一、资源限制
1.Pod和容器的资源请求和限制
2.CPU 资源单位
案例一
案例二
二、健康检查，又称为探针（Probe）
1.探针的三种规则
2.Probe支持三种检查方法
3.探测获得的三种结果
案例一：exec
案例二：httpget
案例三：tcpSocket
案例四：就绪检测readinessProbe1
案例五：就绪检测readinessProbe2
案例六：启动、退出
一、资源限制
当定义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/
1.Pod和容器的资源请求和限制
spec .containers[].resources.requests.cpu //定义创建容器时预分配的CPU资源
spec.containers[].resources.requests.memory //定义创建容器时预分配的内存资源
spec.containers[].resources.imits.cpu //定义cpu 的资源上限
spec.containers[].resources.1imits.memory //定义内存的资源上限
2.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 亳秒。
案例一
OOMKilled：资源不足被杀死
apiVersion: v1
kind: Pod
metadata:name: ky-web-db
spec:containers:- name: webimage: nginxenv:- name: WEB_ROOT_PASSWORDvalue: "password"resources:requests:memory: "64Mi"cpu: "250m"limits:memory: "128Mi"cpu: "500m"- name: dbimage: mysqlenv:- name: MYSQL_ROOT_PASSWORDvalue: "abc123"resources:requests:memory: "64Mi"cpu: "0.25"limits:memory: "128Mi"cpu: "500m"
案例二
给足资源
二、健康检查，又称为探针（Probe）
探针是由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状态的。
2.Probe支持三种检查方法
●exec ：在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功。
●tcpSocket ：对指定端口上的容器的IP地址进行TCP检查（三次握手）。如果端口打开，则诊断被认为是成功的。
●==httpGet ==：对指定的端口和路径上的容器的IP地址执行HTTPGet请求。如果响应的状态码大于等于200且小于400，则诊断被认为是成功的
3.探测获得的三种结果
每次探测都将获得以下三种结果之一
●成功：容器通过了诊断。
●失败：容器未通过诊断。
●未知：诊断失败，因此不会采取任何行动
官网示例：
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
案例一：exec
apiVersion: v1
kind: Pod
metadata:labels:test: livenessname: liveness-exec
spec:containers:- name: livenessimage: busyboximagePullPolicy: IfNotPresentargs: - /bin/sh- -c- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 60livenessProbe:exec:command:- cat- /tmp/healthyfailureThreshold: 1 initialDelaySeconds: 5periodSeconds: 5
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 60
创建一个名为
/tmp/healthy的文件，暂停执行脚本，等待 30 秒钟，删除后，再次暂停执行脚本，等待额外的 60 秒钟
案例二：httpget
apiVersion: v1
kind: Pod
metadata:name: liveness-httpgetnamespace: default
spec:containers:- name: liveness-httpget-containerimage: soscscs/myapp:v1 #soscscs：nginx1.12imagePullPolicy: IfNotPresent #拉取策略ports:- name: httpcontainerPort: 80livenessProbe: #探针httpGet:port: httppath: /index.htmlinitialDelaySeconds: 1 #延迟1秒开始探测periodSeconds: 3 #每3秒探测一次timeoutSeconds: 10 #超时时间10秒
删除index.html页面，报错404，探针失败
案例三：tcpSocket
apiVersion: v1
kind: Pod
metadata:name: xzq-tcp-live
spec:containers:- name: nginximage: soscscs/myapp:v1livenessProbe:initialDelaySeconds: 5 #第一次探测延迟5秒，第6秒开始timeoutSeconds: 1tcpSocket:port: 8080periodSeconds: 10 #每10秒探测一次failureThreshold: 2 #允许2次失败
案例四：就绪检测readinessProbe1
apiVersion: v1
kind: Pod
metadata:name: readiness-httpgetnamespace: default
spec:containers:- name: readiness-httpget-containerimage: soscscs/myapp:v1imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80readinessProbe:httpGet:port: 80path: /index1.htmlinitialDelaySeconds: 1periodSeconds: 3livenessProbe:httpGet:port: httppath: /index.htmlinitialDelaySeconds: 1periodSeconds: 3timeoutSeconds: 10
案例五：就绪检测readinessProbe2
apiVersion: v1
kind: Pod
metadata:name: myapp1labels:app: myapp
spec:containers:- name: myappimage: soscscs/myapp:v1ports:- name: httpcontainerPort: 80readinessProbe:httpGet:port: 80path: /index.htmlinitialDelaySeconds: 5periodSeconds: 5timeoutSeconds: 10
---
apiVersion: v1
kind: Pod
metadata:name: myapp2labels:app: myapp
spec:containers:- name: myappimage: soscscs/myapp:v1ports:- name: httpcontainerPort: 80readinessProbe:httpGet:port: 80path: /index.htmlinitialDelaySeconds: 5periodSeconds: 5timeoutSeconds: 10
---
apiVersion: v1
kind: Pod
metadata:name: myapp3labels:app: myapp
spec:containers:- name: myappimage: soscscs/myapp:v1ports:- name: httpcontainerPort: 80readinessProbe:httpGet:port: 80path: /index.htmlinitialDelaySeconds: 5periodSeconds: 5timeoutSeconds: 10
---
apiVersion: v1
kind: Service
metadata:name: myapp
spec:selector:app: myapptype: ClusterIPports:- name: httpport: 80targetPort: 80
删除页面，看效果
//readiness探测失败，Pod 无法进入READY状态，且端点控制器将从 endpoints 中剔除删除该 Pod 的 IP 地址
案例六：启动、退出
apiVersion: v1
kind: Pod
metadata:name: lifecycle-demo
spec:containers:- name: lifecycle-demo-containerimage: soscscs/myapp:v1lifecycle: #此为关键字段postStart:exec:command: ["/bin/sh", "-c", "echo Hello from the postStart handler >> /var/log/nginx/message"] preStop:exec:command: ["/bin/sh", "-c", "echo Hello from the poststop handler >> /var/log/nginx/message"]volumeMounts:- name: message-logmountPath: /var/log/nginx/readOnly: falseinitContainers:- name: init-myserviceimage: soscscs/myapp:v1command: ["/bin/sh", "-c", "echo 'Hello initContainers' >> /var/log/nginx/message"]volumeMounts:- name: message-logmountPath: /var/log/nginx/readOnly: falsevolumes:- name: message-loghostPath:path: /data/volumes/nginx/log/type: DirectoryOrCreate
