K8S-pod进阶
一.资源限制
- 当定义 Pod 时可以选择性地为每个容器设定所需要的资源数量。
- 最常见的可设定资源是 CPU 和内存大小,以及其他类型的资源。
- 当为 Pod 中的容器指定了 request 资源时,调度器就使用该信息来决定将 Pod 调度到哪个节点上。
- 当还为容器指定了 limit 资源时,kubelet 就会确保运行的容器不会使用超出所设的 limit 资源量。
- kubelet 还会为容器预留所设的 request 资源量, 供该容器使用。
小结:pod根据指定的request,通过预选和优选策略选择合适节点来进行pod的调度
- 如果 Pod 运行所在的节点具有足够的可用资源,容器可以使用超出所设置的 request 资源量。
- 不过,容器不可以使用超出所设置的 limit 资源量。
小结:request是预分配的资源,limit是上限资源;当节点的资源足够可以超出request设置的资源,但不能超过limit上限资源
- 如果给容器设置了内存的 limit 值,但未设置内存的 request 值,
- Kubernetes 会自动为其设置与内存 limit 相匹配的 request 值。
- 类似的,如果给容器设置了 CPU 的 limit 值但未设置 CPU 的 request 值,
- 则 Kubernetes 自动为其设置 CPU 的 request 值 并使之与 CPU 的 limit 值匹配。
小结:限制资源时只设置了request的值,没有设置limit值,那limit值将于设置的request值相匹配
1.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 资源。
②内存
- 内存的 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
PS:在买硬盘的时候,操作系统报的数量要比产品标出或商家号称的小一些,主要原因是标出的是以 MB、GB为单位的,1GB 就是1,000,000,000Byte,而操作系统是以2进制为处理单位的,因此检查硬盘容量时是以MiB、GiB为单位,1GiB=2^30=1,073,741,824,相比较而言,1GiB要比1GB多出1,073,741,824-1,000,000,000=73,741,824Byte,所以检测实际结果要比标出的少一些。
1.2资源限制示例
二.健康检查【探针 Probe】
- 探针是由kubelet对容器执行的定期诊断。
2.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.2探针的三种检查方式
①exec
- 在容器内执行指定命令。
- 如果命令退出时返回码为0则认为诊断成功。
②tcpSocket
- 对指定端口上的容器的IP地址进行TCP检查(三次握手)。
- 如果端口打开,则诊断被认为是成功的。
③httpGet
- 对指定的端口和路径上的容器的IP地址执行HTTPGet请求。
- 如果响应的状态码大于等于200且小于400,则诊断被认为是成功的。
2.3探测获得的结果【三种】
①成功
- 容器通过了诊断。
②失败
- 容器未通过诊断。
③未知
- 诊断失败,因此不会采取任何行动
2.4检查方法示例
①exec方式
apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness-exec spec: containers: - name: liveness images: k8s.gcr.io/busybox args: - /bin/sh - -c - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 60 livenessProbe: exec: command: - cat - /tmp/healthy failureThreshold: 1 initialDelaySeconds: 5 periodSeconds: 5
②tcpSocket方式
apiVersion: v1 kind: Pod metadata: lables: test: liveness name: liveness-http spec: containers: - name: liveness image: k8s.gcr.io/liveness arg: - /server livenessProbe: httpGet: path: /healthz port: 8080 httpHeaders: - name: Custom-Header value: Awesome initialDelaySeconds: 3 periodSeconds: 3
③httpGet方式
apiVersion: v1 kind: Pod metadata: name: goproxy labels: app: goproxy spec: containers: - name: goproxy images: k8s.gcr.io/goproxy:0.1 ports: - containerPort: 8080 readinessProbe: tcpSocket: port: 8080 initialDelaySeconds: 5 periodSeconds: 10 livenessProbe: tcpSocket: port: 8080 initalDelaySeconds: 15 periodSeconds: 20
2.5启动和退出动作
①启动
spec.containers.lifecycle.postStart
:配置exec.command字段设置Linux命令,实现当应用容器启动时,会执行的额外操作
②退出
spec.containers.lifecycle.preStop
:配置exec.command字段设置 Linux命令,实现当应用容器退出时,会执行的最后一个操作
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: exec: command: ["/bin/sh", "-c", "echo hello from the preStop 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: DirectoryOrCreate
三.总结
pod容器镜像拉取策略【imagepullpolicy】三种容器
① ifNotpresent:优先使用本地已存在的镜像,如本地没有则从仓库拉取镜像
② Always:总是从仓库拉取镜像,无论本地是否一存在镜像
③ Never:总是补充仓库拉取镜像,仅使用本地镜像
镜像重启策略
① always:当容器终止退出后,总是重启容器,默认策略
② ONFailure:当容器异常退出时【退出状态码非0】时,重启容器:正常退出不重启容器
③ Never:当容器终止退出,从不重启容器
pod容器探针三种
① 存活探针:判断容器是否运行正常,如果探测失败则杀掉容器【不是pod】,容器会根据重启策略是否重启
② 就绪探针:判断pod是否能进入ready状态,做好接受请求的准备;探测失败会进入notready状态并从service资源的endpoint中剔除,service将不会把请求转发给这个pod
③ 启动探针:判断容器内的应用是否启动成功,在探测成功状态为success之前,其他探针都会处于失效状态
三种探测方式
① exec:通过command设置执行在容器内执行的命令来进行探测,如果返回码为0,则认为探测成功
② httpget:通过http get 请求访问指定的容器端口和url路径,如果假设返回状态码为大于等于200且小于400,则认为探测成功
③ tcpsocket:通过指定的端口发送tcp连接,如果端口无误且三次握手过程(tcp连接成功),测认为探测成功