Kubernetes-node资源预留

Node 为什么需要资源预留?

Kubernetes 的节点可以按照 Capacity 调度。默认情况下 pod 能够使用节点全部可用容量。这是个问题,因为节点自己通常运行了不少驱动 OS 和 Kubernetes 的系统守护进程(system daemons)。除非为这些系统守护进程留出资源,否则它们将与 pod 争夺资源并导致节点资源短缺问题。

按照是否为 Pod,可以把计算节点的进程分为两类:

  • Pod 类进程:容器内部的进程,这些容器由 K8S 创建
  • 非 Pod 类进程:系统进程,如内核,systemd 等;K8S 管理进程,如 Docker, Kubelet, Kube-proxy 等

如果没有资源预留,K8S 认为宿主机上所有的资源(RAM, CPU)都是可以分配给 Pod 类进程。因为非 Pod 类进程也需要占用一定的资源,当 Pod 创建很多时,就有可能出现资源不足的情况。宿主机中 kubelet、kube-proxy等进程被kill掉,最后导致整个 Node 节点不可用。

我们知道,当 Pod 里面内存不足时,会触发 Cgroup 把 Pod 里面的进程杀死;当系统内存不足时,就有可能触发系统 OOM,这时候根据 oom score 来确定优先杀死哪个进程,而 oom_score_adj 又是影响 oom score 的重要参数,其值越低,表示 oom 的优先级越低。在计算节点中,进程的 oom_score_adj 如下:
在这里插入图片描述

所以,很大概率上,OOM 的优先级如下:

BestEffort Pod > 其它进程 > Guarantee Pod > kubelet,docker,kube-proxy等 > sshd 等

那么问题来了,如果节点没有 BestEffort 类型的 pod,那么其它进程就有可能被 OOM,包括系统进程等,后果可想而知。所以,预留一定的资源给系统和 K8S 管理服务,非常有必要。

预留多少资源

K8S 1.5 支持 CPU 和 RAM 两种资源的预留,更高版本支持 Disk 资源的预留。

以下参考设置是个人建议

  • CPU:作为可压缩资源,超配的后果是运行变慢,影响较小,为了充分发挥节点性能,CPU 不预留
  • RAM:8GB < RAM <= 16GB 预留 3GB; RAM > 16G 预留 4GB; (以上机器只跑k8s服务,没有额外应用服务)
  • Disk:磁盘可预留 5% 至 10% 左右

如何预留

kubelet 公开了一个名为 Node Allocatable 的特性,有助于为系统守护进程预留计算资源。Kubernetes 推荐集群管理员按照每个节点上的工作负载密度配置 Node Allocatable

Node Allocatable(节点可分配资源):

      Node Capacity
---------------------------
|     kube-reserved       |
|-------------------------|
|     system-reserved     |
|-------------------------|
|    eviction-threshold   |
|-------------------------|
|                         |
|      allocatable        |
|   (available for pods)  |
|                         |
|                         |
---------------------------

Kubernetes 节点上的 Allocatable 被定义为 pod 可用计算资源量。调度器不会超额申请 Allocatable。目前支持 CPU, memorystorage 这几个参数。

Node Allocatable 暴露为 API 中 v1.Node 对象的一部分,也是 CLI 中 kubectl describe node 的一部分。

kubelet 中,可以为两类系统守护进程预留资源。

  • 启用 QoS 和 Pod 级别的 cgroups

    为了恰当的在节点范围实施 node allocatable,您必须通过 --cgroups-per-qos 标志启用新的 cgroup 层次结构。这个标志是默认启用的。启用后,kubelet 将在其管理的 cgroup 层次结构中创建所有终端用户的 pod。

  • 配置 cgroup 驱动

    kubelet 支持在主机上使用 cgroup 驱动操作 cgroup 层次结构。驱动通过 --cgroup-driver 标志配置。

    支持的参数值如下:

    • cgroupfs 是默认的驱动,在主机上直接操作 cgroup 文件系统以对 cgroup 沙箱进行管理。
    • systemd 是可选的驱动,使用 init 系统支持的资源的瞬时切片管理 cgroup 沙箱。

    取决于相关容器运行时(container runtime)的配置,操作员可能需要选择一个特定的 cgroup 驱动来保证系统正常运行。例如如果操作员使用 docker 运行时提供的 cgroup 驱动时,必须配置 kubelet 使用 systemd cgroup 驱动。

K8S 把计算节点资源分为 4 个部分:

  • Kube Reserved:预留给 K8S 管理进程的资源,如 Kubelet,Docker Daemon 等
  • System Reserved:预留给系统资源,如 kernel,sshd,udev 等
  • Eviction Thresholds:驱逐(Eviction)的阈值,只支持 memory 和 storage。
  • Allocatable(available for pods):pods 可以使用的资源

官方文档示例:

这是一个用于说明节点分配计算方式的示例:

  • 节点拥有 32Gi 内存16 核 CPU100Gi 存储
  • --kube-reserved 设置为 cpu=1,memory=2Gi,ephemeral-storage=1Gi
  • --system-reserved 设置为 cpu=500m,memory=1Gi,ephemeral-storage=1Gi
  • --eviction-hard 设置为 memory.available<500Mi,nodefs.available<10%

在这个场景下,Allocatable 将会是 14.5 CPUs28.5Gi 内存以及 88Gi 本地存储。 调度器保证这个节点上的所有 pod 请求的内存总量不超过 28.5Gi,存储不超过 88Gi。 当 pod 的内存使用总量超过 28.5Gi 或者磁盘使用总量超过 88Gi 时,Kubelet 将会驱逐它们。如果节点上的所有进程都尽可能多的使用 CPU,则 pod 加起来不能使用超过 14.5 CPUs 的资源。

当没有执行 kube-reservedsystem-reserved 且系统守护进程使用量超过其预留时,如果节点内存用量高于 31.5Gi存储大于 90Gi,kubelet 将会驱逐 pod。

小结:为了简化管理,建议不对 kube-reserved/system-reserved 做区分,直接使用 --system-reserved做系统预留。在 kubelet 配置文件中设置如下参数:

--system-reserved=memory=3Gi,storage=5Gi \
--eviction-hard=memory.available<1Gi,nodefs.available<10Gi,imagefs.available<15Gi \
--eviction-soft=memory.available<1.5Gi,nodefs.available<15Gi,imagefs.available<20Gi \
--eviction-soft-grace-period=memory.available=2m,nodefs.available=2m,imagefs.available=2m \
--eviction-max-pod-grace-period=30 \
--eviction-minimum-reclaim=memory.available=200Mi,nodefs.available=5Gi,imagefs.available=5Gi \

使用 kubectl describe nodes node-name 查询设置效果。

例如下面效果:

Capacity:
 cpu:                12
 ephemeral-storage:  2683368944Ki
 hugepages-1Gi:      0
 hugepages-2Mi:      0
 memory:             65701752Ki
 pods:               110
Allocatable:
 cpu:                12
 ephemeral-storage:  2262397424Ki
 hugepages-1Gi:      0
 hugepages-2Mi:      0
 memory:             55215992Ki
 pods:               110

其它

Kubelet 还支持使用 cgroup 从物理上限制预留资源,这需要给 K8S 管理进程和系统进程分别设置 cgroup,复杂度相对较高,并且不好维护,个人不推荐这种方法。

🔥运维干货分享

<think>首先,用户的问题是关于Kubernetes控制平面节点角色配置和资源。用户提到了“control-plane node role configuration and resources”,所以我需要根据系统级指令来回答。 系统级指令: - 行内数学表达式必须使用$...$格式。 - 独立公式必须使用$$...$$格式并单独成段。 - LaTeX语法正确。 - 使用中文回答。 - 生成相关问题。 - 回答中引用的段落末尾自然地添加引用标识。 - 回答结构清晰,帮助用户逐步解决问题。 - 保证回答真实可靠。 用户提供的引用是关于Kubernetes集群搭建的,具体包括: - 引用[1]: 移除控制平面节点的污点(taints)。 - 引用[2]: 节点状态显示为Ready。 - 引用[3]: kubeadm使用配置文件保存参数。 - 引用[4]: 环境清理和重置节点。 - 引用[5]: 使用pacemaker搭建高可用。 用户意图似乎是查找与Kubernetes控制平面节点相关的资源或配置,包括角色配置、污点管理、高可用性等。 我的回答需要: 1. **结构清晰**:逐步解释控制平面节点的角色配置和资源。 2. **使用中文**。 3. **正确使用LaTeX**:如果有数学表达式,但在这个上下文中可能没有复杂的数学,所以可能不需要。 4. **生成相关问题**:在回答结束后添加相关问题部分。 5. **添加引用标识**:在引用内容时,在末尾添加如[^1]的标识。 关键点从引用中提取: - 控制平面节点有污点(taints),如`node-role.kubernetes.io/control-plane:NoSchedule`,这阻止了Pod调度。 - 可以通过`kubectl taint`命令移除污点。 - kubeadm用于初始化集群和加入节点。 - 高可用性可以通过工具如pacemaker实现。 回答结构: 1. **介绍控制平面节点角色**:解释什么是控制平面节点及其作用。 2. **配置角色**:如何配置节点为控制平面角色。 3. **污点管理**:如何管理污点以允许Pod调度。 4. **资源考虑**:讨论控制平面节点所需的资源(CPU、内存等)。 5. **高可用性**:简要提及如何实现高可用。 6. **引用标识**:在适当的地方添加引用。 最后,生成相关问题。 确保回答真实可靠:基于Kubernetes官方文档和常见实践。</think>### Kubernetes 控制平面节点角色配置与资源管理 在 Kubernetes 集群中,控制平面节点(Control Plane Node)负责管理集群的核心组件,如 API Server、Scheduler、Controller Manager 等。这些节点通常被标记为 `control-plane` 角色,并可能带有污点(Taints)以防止普通工作负载调度到其上,确保集群稳定性。下面我将逐步解释控制平面节点的角色配置、资源管理及相关操作,确保回答基于 Kubernetes 官方文档和实际最佳实践。 #### 1. **控制平面节点角色配置** - **角色定义**:在 Kubernetes 中,节点角色通过标签(Labels)和污点(Taints)来定义。控制平面节点通常带有 `node-role.kubernetes.io/control-plane:NoSchedule` 污点,这表示默认情况下 Pod 不会调度到这些节点上,除非 Pod 有对应的容忍(Tolerations)。 - 例如,从引用中可以看到,节点 `master1` 和 `master2` 初始状态带有污点: ```bash $ kubectl describe node master1 | grep Taints Taints: node-role.kubernetes.io/control-plane:NoSchedule ``` 这可以防止非系统 Pod 调度到控制平面节点上[^1]。 - **配置方法**:使用 `kubeadm` 工具初始化集群时,会自动为控制平面节点添加污点。如果需要修改污点(例如允许某些 Pod 调度),可以使用 `kubectl taint` 命令: - 移除污点: ```bash $ kubectl taint node master1 node-role.kubernetes.io/control-plane- node/master1 untainted ``` 这会使节点变为可调度状态[^1]。 - 添加污点: ```bash $ kubectl taint node master1 node-role.kubernetes.io/control-plane:NoSchedule ``` - **配置文件支持**:`kubeadm` 允许通过配置文件初始化集群,参数以 ConfigMap 形式保存在集群中,便于后续查询和升级[^3]。例如,配置文件可以指定节点角色和初始污点。 #### 2. **资源管理** - **硬件资源需求**:控制平面节点需要足够的 CPU、内存和存储资源来运行核心组件。典型资源要求包括: - **CPU**:至少 2 核(建议 4 核以上),以处理 API Server 的高并发请求。 - **内存**:至少 2GB(建议 4GB 以上),用于运行 etcd 和其他组件。 - **存储**:SSD 磁盘用于 etcd 数据存储,确保低延迟和高可用性。 - 资源不足可能导致集群不稳定或组件崩溃,如 API Server 超时[^2]。 - **资源监控与优化**: - 使用 `kubectl top nodes` 监控节点资源使用: ```bash $ kubectl top nodes NAME CPU(cores) MEMORY(bytes) master1 150m 1.2Gi ``` - 如果资源不足,可以: - 垂直扩展:增加节点资源(CPU/内存)。 - 水平扩展:添加更多控制平面节点以实现高可用(HA)。 - 从引用中看,节点状态为 `Ready` 表示资源充足且组件正常运行[^2]。 #### 3. **高可用性配置** - 控制平面节点的高可用(HA)是生产环境的关键。常见方法包括: - **使用负载均衡器**:如 HAProxy,将流量分发到多个控制平面节点。引用中展示了通过 Pacemaker 实现 HAProxy 的高可用: ```bash $ yum install haproxy -y $ scp haproxy.cfg server8:/etc/haproxy/ ``` 这确保了 API Server 的冗余和故障转移[^5]。 - **多节点部署**:使用 `kubeadm` 初始化多个控制平面节点: ```bash $ kubeadm init --control-plane-endpoint "LOAD_BALANCER_IP:PORT" ``` 然后加入其他节点。 - 如果节点故障,可以通过环境清理和重置恢复: ```bash $ kubectl delete nodes server2 $ kubeadm reset $ reboot ``` 这有助于维护集群健康[^4]。 #### 4. **最佳实践与注意事项** - **安全隔离**:保留控制平面节点的污点,除非必要(如部署监控 Pod),避免普通工作负载影响核心组件。 - **资源预留**:使用 Kubernetes 资源配额(Resource Quotas)为系统组件预留资源,防止资源争抢。 - **备份与恢复**:定期备份 etcd 数据,以防控制平面故障。 - 从实际部署看,控制平面节点配置不当可能导致调度问题或集群不稳定,因此建议在测试环境验证[^1][^2]。 通过以上步骤,您可以有效配置和管理 Kubernetes 控制平面节点的角色与资源。如果遇到具体问题(如污点移除后节点仍不可调度),请检查组件日志(如 `kube-scheduler`)。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

企鹅侠客

您的打赏是我创作旅程中的关键燃

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值