一、概述
实现pod层面的高可用,需要避免容器进程被终止避免Pod被驱逐:
- 设置合理的resources.memory limits 防止容器进程被 OOMKill,防止Pod被驱逐;
- 设置合理的emptydir.sizeLimit 并且确保数据写入不超过emptyDir的限制,防止Pod被驱逐。
二、Pod的QoS 分类
- Guaranteed
-Pod的每个容器都设置了资源CPU和内存需求,Limits 和 requests的值完全一致 - Burstable
-至少一个容器制定了CPU或内存request ,并且requests和limits不一致 - BestEffort
-Pod中的所有容器都未指定CPU或内存资源需求requests.
三种QoS层级关系:
Guaranteed 类型的资源需求,能最大程度保证pod的资源需求,但是可能会造成集群节点的资源利用率不高。而Burstable和BestEffort可以达到资源超卖的效果,因为有些应用的流量有峰谷的差异,比如web应用,只要错峰开来,就能提高资源的利用率,部署更多的pod。
一般而言,Guaranteed用来保护重要的pod,而Burstable适用于大部分场景。
当计算节点检测到内存压力的时候,kubenetes会按照BestEffort–>Burstable–>Guaranteed的顺序依次去驱逐pod。
三、基于Taint的驱逐(Evictions)
当Node出现问题的时候,kubenetes会给Node打上taints,比如Node ping不通的时候打上unreachable,Node上的组件有问题的时候打上not-ready。NoSchedule的动作是会驱逐Node上的pod。
当一个pod创建出来的时候,kubenetes会自动为pod增加Toleration。
有时因为网络原因,导致节点的临时不可达,我们可以适当的增大tolerationSeconds避免pod被驱逐,特别是依赖本地存储的有状态应用
四、健康检查探针
探针属性:
合理使用startupProbe,有些应用可能启动时间会比较长,而livenessProbe探测频率比较高,startupProbe可以避免过于频繁的监测从而影响应用的启动。
五、Post-start和Pre-stop Hook
postStart结束之前,容器不会被标记为running状态。PreStop完成后,Kubelet会发kill-SIGTERM给容器进程,这时就要看应用是否支持处理SIGTERM信号量了,由/bin/bash起的进程是会忽略SIGTERM的,需要注意。