节点可用内存调度配置求助：避免低内存调度及Pod误驱逐

方案一：节点自动封锁/解封（不驱逐现有Pod） #

之前配置evictionHard会触发Pod驱逐，是因为这是kubelet的资源回收策略，核心目标是释放节点资源。要实现仅阻止新Pod调度、保留现有Pod的需求，应该用kubectl cordon/uncordon操作结合监控实现自动化：

• 1. 监控节点内存状态
     用Prometheus采集节点指标node_memory_MemAvailable_bytes，配置告警规则：

  groups:
  - name: node-memory-alerts
    rules:
    - alert: NodeMemoryBelow8Gi
      expr: node_memory_MemAvailable_bytes < 8589934592
      for: 1m
      labels:
        severity: warning
      annotations:
        summary: "Node {{ $labels.node }} available memory below 8Gi"
    - alert: NodeMemoryRecoveredTo8Gi
      expr: node_memory_MemAvailable_bytes >= 8589934592
      for: 1m
      labels:
        severity: info
      annotations:
        summary: "Node {{ $labels.node }} available memory recovered to 8Gi"
  

• 2. 编写Webhook脚本处理告警
     脚本逻辑：收到NodeMemoryBelow8Gi告警时执行kubectl cordon <node-name>封锁节点；收到恢复告警时执行kubectl uncordon <node-name>解封。示例脚本片段：

  #!/bin/bash
  read -r payload
  node_name=$(echo "$payload" | jq -r '.alerts[0].labels.node')
  alert_status=$(echo "$payload" | jq -r '.alerts[0].status')
  
  if [ "$alert_status" == "firing" ]; then
    kubectl cordon "$node_name"
  elif [ "$alert_status" == "resolved" ]; then
    kubectl uncordon "$node_name"
  fi
  

• 3. 配置Alertmanager路由到Webhook
     在Alertmanager配置中添加webhook接收端，将上述脚本部署为服务，让Alertmanager能触发执行。

方案二：Pod调度约束（仅调度到内存充足节点） #

如果不需要修改节点全局调度状态，只想让Pod主动避开内存不足的节点，可以用节点亲和性+动态标签控制器：

• 1. 给节点动态打标签
     编写定时脚本或控制器，定期检查节点可用内存：
  • 当节点可用内存≥8Gi时，添加标签memory-available: "8Gi+"
  • 当节点可用内存<8Gi时，移除该标签
    示例脚本：

  #!/bin/bash
  for node in $(kubectl get nodes -o name); do
    available_mem=$(kubectl describe "$node" | grep -A1 "Allocatable" | grep memory | awk '{print $2}')
    # 转换为数值判断（假设单位为Gi）
    if [[ "$available_mem" =~ ([0-9]+)Gi ]]; then
      mem_num=${BASH_REMATCH[1]}
      if [ "$mem_num" -ge 8 ]; then
        kubectl label "$node" memory-available="8Gi+" --overwrite
      else
        kubectl label "$node" memory-available-
      fi
    fi
  done
  

  可以用CronJob定期执行这个脚本。

• 2. 配置Pod的节点亲和性
     在Pod的spec中添加强制亲和性规则，要求节点必须带有memory-available: "8Gi+"标签：

  apiVersion: v1
  kind: Pod
  metadata:
    name: demo-pod
  spec:
    affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: memory-available
              operator: In
              values:
              - "8Gi+"
    containers:
    - name: demo-container
      image: nginx:alpine
  

  这里requiredDuringSchedulingIgnoredDuringExecution的含义是：调度时必须满足规则，运行时节点标签变化不影响Pod运行，完全符合不驱逐现有Pod的需求。

方案对比 #

• 方案一适合全局控制节点的调度状态，所有新Pod都不会调度到内存不足的节点
• 方案二适合针对特定Pod设置调度规则，灵活度更高

内容的提问来源于stack exchange，提问作者kl kl