Shell脚本如何配置容器Pod反亲和

wen 实用脚本 2026-07-16 3

Kubernetes实战：Shell脚本自动化配置容器Pod反亲和策略

目录导读

为什么需要Pod反亲和？
Pod反亲和的核心机制
Shell脚本配置全流程
生产级脚本模板详解
常见问题与性能优化
问答环节

为什么需要Pod反亲和？

在Kubernetes集群中，默认调度器会将Pod均匀分布到不同节点，但在高可用场景下，我们可能需要明确阻止某些Pod部署在同一节点。

Shell脚本如何配置容器Pod反亲和

数据库主从实例：避免master和slave因节点故障同时宕机
缓存集群：防止热点数据集中在一个物理节点
有状态服务：保障跨AZ（可用区）的故障隔离

Shell脚本自动配置Pod反亲和，能避免手动修改YAML的繁琐，尤其适合CI/CD流水线或大规模集群运维。

Pod反亲和的核心机制

Pod反亲和通过podAntiAffinity规则实现,分为两种模式：

requiredDuringSchedulingIgnoredDuringExecution：硬约束，调度时必须满足
preferredDuringSchedulingIgnoredDuringExecution：软约束，调度器尽量满足

关键参数：

topologyKey: "kubernetes.io/hostname"  # 节点维度
topologyKey: "topology.kubernetes.io/zone"  # 可用区维度

匹配规则：

labelSelector：匹配Pod的标签
namespaces：指定命名空间（默认当前ns）
matchExpressions：支持In/NotIn等运算符

Shell脚本配置全流程

步骤1：环境预检与变量定义

#!/bin/bash
set -euo pipefail
NAMESPACE="${1:-default}"
DEPLOY_NAME="${2:-my-app}"
ANTI_AFFINITY_TYPE="${3:-hard}"  # hard|soft
TOPOLOGY_KEY="${4:-kubernetes.io/hostname}"

步骤2：生成反亲和配置JSON

generate_anti_affinity() {
    local label_key="app"
    local label_value="$DEPLOY_NAME"
    # 构建匹配表达式
    local match_expression="[{\"key\":\"$label_key\",\"operator\":\"In\",\"values\":[\"$label_value\"]}]"
    # 根据类型生成不同策略
    if [[ "$ANTI_AFFINITY_TYPE" == "hard" ]]; then
        cat <<EOF
{
  "requiredDuringSchedulingIgnoredDuringExecution": [{
    "topologyKey": "$TOPOLOGY_KEY",
    "labelSelector": {
      "matchExpressions": $match_expression
    }
  }]
}
EOF
    else
        cat <<EOF
{
  "preferredDuringSchedulingIgnoredDuringExecution": [{
    "weight": 100,
    "podAffinityTerm": {
      "topologyKey": "$TOPOLOGY_KEY",
      "labelSelector": {
        "matchExpressions": $match_expression
      }
    }
  }]
}
EOF
    fi
}

步骤3：通过kubectl patch注入

patch_deploy() {
    local anti_affinity_json=$(generate_anti_affinity)
    # 使用patch更新Deployment的spec.affinity
    kubectl patch deployment "$DEPLOY_NAME" \
        -n "$NAMESPACE" \
        --type='merge' \
        --patch "{\"spec\":{\"template\":{\"spec\":{\"affinity\":$anti_affinity_json}}}}"
    echo "[SUCCESS] $ANTI_AFFINITY_TYPE anti-affinity applied to $DEPLOY_NAME"
}

生产级脚本模板详解

增强版脚本（含回滚与验证）

#!/bin/bash
# 功能：为Deployment/StatefulSet配置Pod反亲和
# 用法：./set_pod_anti_affinity.sh <资源类型> <资源名称> [hard|soft] [拓扑键]
set -e
RESOURCE_TYPE="${1:?Missing resource type (deployment|statefulset)}"
RESOURCE_NAME="${2:?Missing resource name}"
AFFINITY_TYPE="${3:-hard}"
TOPOLOGY="${4:-kubernetes.io/hostname}"
NS="${5:-default}"
# 备份当前配置用于回滚
BACKUP_FILE="/tmp/$(date +%s)_${RESOURCE_TYPE}_${RESOURCE_NAME}.yaml"
kubectl get "$RESOURCE_TYPE" "$RESOURCE_NAME" -n "$NS" -o yaml > "$BACKUP_FILE"
# 生成反亲和配置
ANTI_JSON=$(cat <<EOF
{
  "spec": {
    "template": {
      "spec": {
        "affinity": {
          "podAntiAffinity": {
EOF
)
if [[ "$AFFINITY_TYPE" == "hard" ]]; then
    ANTI_JSON+=$(cat <<EOF
            "requiredDuringSchedulingIgnoredDuringExecution": [{
                "topologyKey": "$TOPOLOGY",
                "labelSelector": {
                    "matchExpressions": [{
                        "key": "app",
                        "operator": "In",
                        "values": ["$RESOURCE_NAME"]
                    }]
                }
            }]
EOF
)
else
    ANTI_JSON+=$(cat <<EOF
            "preferredDuringSchedulingIgnoredDuringExecution": [{
                "weight": 100,
                "podAffinityTerm": {
                    "topologyKey": "$TOPOLOGY",
                    "labelSelector": {
                        "matchExpressions": [{
                            "key": "app",
                            "operator": "In",
                            "values": ["$RESOURCE_NAME"]
                        }]
                    }
                }
            }]
EOF
)
fi
ANTI_JSON+=$(cat <<EOF
        }
      }
    }
  }
}
EOF
)
# 应用配置
echo "$ANTI_JSON" | kubectl patch "$RESOURCE_TYPE" "$RESOURCE_NAME" -n "$NS" --type='merge' -f -
# 等待1秒后验证Pod调度
sleep 2
kubectl get pods -n "$NS" -l app="$RESOURCE_NAME" -o wide
# 验证反亲和是否生效（检查同一节点是否有两个Pod）
NODE_NAMES=$(kubectl get pods -n "$NS" -l app="$RESOURCE_NAME" -o jsonpath='{.items[*].spec.nodeName}' | tr ' ' '\n' | sort -u)
POD_COUNT=$(kubectl get pods -n "$NS" -l app="$RESOURCE_NAME" --no-headers | wc -l)
UNIQUE_NODES=$(echo "$NODE_NAMES" | wc -l)
if [[ "$POD_COUNT" -eq "$UNIQUE_NODES" ]]; then
    echo "[PASS] Pods are distributed across different nodes"
else
    echo "[WARN] Some pods share the same node (${POD_COUNT} pods on ${UNIQUE_NODES} nodes)"
    echo "Backup saved at: $BACKUP_FILE"
fi

脚本关键点说明

安全校验：set -euo pipefail捕获任何错误
备份机制：修改前保存原始YAML，可执行kubectl replace -f $BACKUP_FILE回滚
动态化拓扑：支持hostname、zone甚至自定义标签
验证反馈：自动检查同节点Pod数量，输出是否符合预期

常见问题与性能优化

Q1: 为什么我的反亲和规则不生效？
A: 检查三要素：

Pod必须有匹配的标签（例中app: <名称>）
拓扑键（topologyKey）必须在节点上有对应标签
如果是soft模式，集群中存在可调度节点时仍可能违反规则

Q2: 如何配置多个标签匹配？
A: 在matchExpressions数组中添加多个条件：

"matchExpressions": [
  {"key": "app", "operator": "In", "values": ["my-app"]},
  {"key": "tier", "operator": "NotIn", "values": ["cache"]}
]

Q3: 配置后Pod处于Pending状态怎么办？
A: 通常是因为节点数量少于Pod副本数，解决方案：

增加节点
将硬约束改为软约束
移除重复的标签选择器

Q4: 大规模集群（1000+ Pod）性能如何？
A: 调度器处理反亲和会消耗更多CPU，建议：

仅对关键服务使用required模式
使用weight值控制软约束优先级
避免在matchExpressions中使用NotIn过度复杂条件

问答环节

Q：您提到Shell脚本可以自动化配置，在实际CI/CD中如何集成？
A：推荐在构建流水线中添加以下阶段：

# GitLab CI示例
deploy-job:
  script:
    - kubectl apply -f deployment.yaml
    - ./set_pod_anti_affinity.sh deployment my-app hard kubernetes.io/hostname

关键点：先部署基础资源，再用脚本调整调度策略，最后用kubectl rollout status确认Pod健康。

Q：如果我想为不同环境（开发/生产）配置不同的反亲和策略，脚本如何扩展？
A：使用环境变量控制：

# 在脚本中增加
if [[ "$ENV" == "production" ]]; then
    AFFINITY_TYPE="hard"
    TOPOLOGY="topology.kubernetes.io/zone"
else
    AFFINITY_TYPE="soft"
    TOPOLOGY="kubernetes.io/hostname"
fi

生产环境强制跨可用区（zone）调度,开发环境仅建议跨节点。

Q：反亲和与Pod间通信延迟如何权衡？
A：需要具体场景分析：

延迟敏感型（如Redis）：使用软约束（weight=50），优先保持节点亲和
高可用型（如数据库主从）：使用硬约束跨区域（zone），牺牲部分延迟
可通过Prometheus监控调度结果，动态调整weight值

通过以上Shell脚本方案，您能高效地在Kubernetes中配置Pod反亲和策略，兼顾自动化与灵活性，建议先在测试环境验证脚本，再逐步推广到生产集群，反亲和是微服务高可用的重要保障，但过度使用也可能导致资源碎片化,需要根据业务特性合理选择约束类型与拓扑维度。