kubernetes-pod高可用

本文探讨了如何在Kubernetes中实现Pod层面的高可用性,包括设置合理的资源限制以防止OOMKill和Pod驱逐,介绍Pod的QoS分类及其对资源利用的影响,以及基于Taint的驱逐策略、健康检查探针和Post-start/Pre-stopHook的使用技巧。
摘要由CSDN通过智能技术生成

一、概述

实现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的,需要注意。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值