kubenetes-pod高可用

一、概述

实现pod层面的高可用，需要避免容器进程被终止避免Pod被驱逐：

1. 设置合理的resources.memory limits 防止容器进程被 OOMKill，防止Pod被驱逐；
2. 设置合理的emptydir.sizeLimit 并且确保数据写入不超过emptyDir的限制，防止Pod被驱逐。

二、Pod的QoS 分类

1. Guaranteed
   -Pod的每个容器都设置了资源CPU和内存需求，Limits 和 requests的值完全一致
2. Burstable
   -至少一个容器制定了CPU或内存request ，并且requests和limits不一致
3. 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的，需要注意。