Azure Kubernetes 服务 (AKS)生产升级策略

使用这些模式安全地升级生产Azure Kubernetes 服务 (AKS)群集。 本指南适用于需要最大限度地减少停机时间和控制升级风险的站点可靠性工程师和平台团队。

AKS 生产升级策略概述

• 实现最少停机时间升级的蓝绿部署。
• 跨多个环境进行分阶段车队升级。
• 通过验证关卡安全采用 Kubernetes 版本。
• 紧急安全修补，以便快速响应常见漏洞和暴露（CVE）。
• 最大程度减少升级中断的应用程序复原模式。
• 迁移切换回滚，并快速将流量切回源环境。

需要最短停机时间时使用这些模式。

选择最符合业务需求的方案：

• 是否需要紧急升级？
• 您有有状态工作负载吗？
• 是否从另一个群集或环境迁移工作负荷？

Kubernetes 先决条件

本文假设你了解 Kubernetes 部署和服务，包括以下概念：

• Pod 干扰预算（PDB）：限制在节点升级等自愿性中断期间可处于不可用状态的所选 Pod 数量。 使用 maxUnavailable: 1Kubernetes 时，最多允许一个选定的 Pod 在清空期间不可用。
• 就绪情况探测：当 Pod 准备好接收流量时发出信号。 在升级期间，Kubernetes 会等待就绪探针通过后，才将 Pod 视为健康。
• 存活探针：自动重启不健康的 Pod。 在群集升级期间，这些探测可确保失败的 Pod 快速恢复。
• 终结器：在 Kubernetes 删除资源之前运行的自定义逻辑。 长时间运行的最终确定器可能会在排空期间阻塞 Pod 终止。

选择策略

基于角色的起始点

使用此表查找与角色匹配的 AKS 生产升级指南。

方案 1：停机时间最短的生产升级

• 挑战：“我需要在工作时间内升级生产集群，并将停机时间控制在 2 分钟以内。”
• 策略：采用蓝绿部署，并结合智能流量切换。 蓝绿部署运行两个相同的生产环境（蓝色和绿色）。 部署到非活动环境，对其进行验证，然后切换流量。 如果出现问题，流量会切换回活动环境。 实际收敛时间取决于所选的流量路由服务、运行状况探针以及客户端缓存或 DNS 缓存。

实现概述（15 分钟）

# List the Kubernetes versions available in the target region, then select a supported version.
az aks get-versions --location chinanorth3 --output table

# 1. Create green cluster (parallel to blue)
az aks create --name myaks-green --resource-group myRG \
  --kubernetes-version <supported-kubernetes-version> --enable-cluster-autoscaler \
  --min-count 3 --max-count 10

# 2. Deploy application to green cluster
kubectl config use-context myaks-green
kubectl apply -f ./production-manifests/

# 3. Validate green cluster
# Run your application-specific health checks here
# Examples: API endpoint tests, database connectivity, dependency checks

# 4. Switch traffic (target: less than two minutes, including traffic convergence)
az network traffic-manager endpoint update \
  --resource-group traffic-rg --profile-name prod-tm \
  --name green-endpoint --type azureEndpoints --weight 100
az network traffic-manager endpoint update \
  --resource-group traffic-rg --profile-name prod-tm \
  --name blue-endpoint --type azureEndpoints --weight 0

# Create resource group for green cluster
az group create --name myRG-green --location chinanorth3

# Create green cluster with same configuration as blue
az aks create \
  --resource-group myRG-green \
  --name myaks-green \
  --kubernetes-version <supported-kubernetes-version> \
  --node-count 3 \
  --enable-cluster-autoscaler \
  --min-count 3 \
  --max-count 10 \
  --enable-addons monitoring \
  --generate-ssh-keys

# Get green cluster credentials
az aks get-credentials --resource-group myRG-green --name myaks-green

# Deploy application stack
# Apply your Kubernetes manifests in order:
kubectl apply -f ./your-manifests/namespace.yaml      # Create namespace
kubectl apply -f ./your-manifests/secrets/           # Deploy secrets
kubectl apply -f ./your-manifests/configmaps/        # Deploy config maps
kubectl apply -f ./your-manifests/deployments/       # Deploy applications
kubectl apply -f ./your-manifests/services/          # Deploy services

# Wait for all pods to be ready
kubectl wait --for=condition=ready pod --all --timeout=300s

# Validate application health
kubectl get pods -A
kubectl logs -l app=my-app --tail=50

# Pre-switch validation
GREEN_ENDPOINT_URL=<green-endpoint-url>
API_URL=<application-url>
curl -f "${GREEN_ENDPOINT_URL}/health"
if [ $? -ne 0 ]; then echo "Green health check failed!"; exit 1; fi

# Execute traffic switch
az network dns record-set cname set-record \
  --resource-group myRG-dns \
  --zone-name mycompany.com \
  --record-set-name api \
  --cname myapp-green.chinanorth3.chinacloudapp.cn

# Immediate validation
sleep 30
curl -f "${API_URL}/health"

# Monitor traffic and errors for 15 minutes
kubectl top nodes
kubectl top pods
kubectl logs -l app=my-app --since=15m | grep ERROR

# Check application metrics
curl "${API_URL}/metrics" | grep http_requests_total

Troubleshooting

• 域名系统（DNS）传播速度缓慢：在升级之前使用低生存时间（TTL）值，并验证 DNS 缓存刷新。
• Pod 卡在终止状态：检查最终确定器、长时间关闭挂钩或带有 maxUnavailable: 0 的 PDB。
• 流量未转移：验证Azure 负载均衡器/Azure 流量管理器配置和运行状况探测。
• 回滚失败：始终让蓝色集群保持就绪状态，直到绿色集群经过充分验证，并且回滚窗口结束。

常见问题 (FAQ)

是否可以使用开源软件工具进行验证？

Yes. 使用 kube-no-trouble 进行 API 检查，并使用 Trivy 进行镜像扫描。

AKS 的独特之处是什么？

借助与 Traffic Manager、Azure Kubernetes Fleet Manager 以及节点映像修补功能的原生集成，可帮助最大限度地减少升级期间的中断。

高级配置

对于具有非两分钟停机时间目标的应用程序，请使用会话相关性来减少流量收敛期间的会话中断：

# Use session affinity during transition
apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 300

成功验证

若要验证进度，请使用以下清单：

• 应用程序在两秒内响应。
• 日志中没有 5xx 错误。
• 数据库连接稳定。
• 保留用户会话。

紧急回滚（如有需要）

# Immediate rollback to blue cluster
az network dns record-set cname set-record \
  --resource-group myRG-dns \
  --zone-name mycompany.com \
  --record-set-name api \
  --cname myapp-blue.chinanorth3.chinacloudapp.cn

预期结果：停机时间保留在已验证的目标和快速流量回滚功能内。 防止数据丢失需要针对特定工作负载的复制机制、写入协调以及经过测试的恢复流程。

场景 2：跨环境分阶段升级

• 挑战：“我需要通过适当的验证入口通过开发、测试和生产安全地测试升级。
• 策略：通过分阶段推出使用 Azure Kubernetes Fleet Manager。

若要了解详细信息，请参阅 Azure Kubernetes Fleet Manager 概述 和 更新业务流程。

先决条件

# Install Fleet extension
az extension add --name fleet
az extension update --name fleet

# Create Fleet resource
az fleet create \
  --resource-group fleet-rg \
  --name production-fleet \
  --location chinanorth3

实现步骤

步骤 1：定义阶段配置

创建 upgrade-stages.json：

{
  "stages": [
    {
      "name": "development",
      "groups": [{ "name": "dev-clusters" }],
      "afterStageWaitInSeconds": 1800
    },
    {
      "name": "testing",
      "groups": [{ "name": "test-clusters" }],
      "afterStageWaitInSeconds": 3600
    },
    {
      "name": "production",
      "groups": [{ "name": "prod-clusters" }],
      "afterStageWaitInSeconds": 0
    }
  ]
}

步骤 2：将集群添加到舰队中

# Add development clusters
az fleet member create \
  --resource-group fleet-rg \
  --fleet-name production-fleet \
  --name dev-east \
  --member-cluster-id "/subscriptions/.../clusters/aks-dev-east" \
  --update-group dev-clusters

# Add test clusters
az fleet member create \
  --resource-group fleet-rg \
  --fleet-name production-fleet \
  --name test-east \
  --member-cluster-id "/subscriptions/.../clusters/aks-test-east" \
  --update-group test-clusters

# Add production clusters
az fleet member create \
  --resource-group fleet-rg \
  --fleet-name production-fleet \
  --name prod-east \
  --member-cluster-id "/subscriptions/.../clusters/aks-prod-east" \
  --update-group prod-clusters

步骤 3：创建并运行暂存更新

选择每个 Fleet 成员在更新运行中支持的目标 Kubernetes 版本。

# Create staged update run
az fleet updaterun create \
  --resource-group fleet-rg \
  --fleet-name production-fleet \
  --name supported-version-upgrade \
  --upgrade-type Full \
  --kubernetes-version <supported-kubernetes-version> \
  --node-image-selection Latest \
  --stages upgrade-stages.json

# Start the staged rollout
az fleet updaterun start \
  --resource-group fleet-rg \
  --fleet-name production-fleet \
  --name supported-version-upgrade

步骤 4：阶段之间的验证检查点

开发阶段后（30 分钟浸泡）：

# Run automated test suite
./scripts/run-e2e-tests.sh dev-cluster
./scripts/performance-baseline.sh dev-cluster

# Check for any regressions
kubectl get events --sort-by='.lastTimestamp' | grep -i warn

测试阶段后（60分钟浸泡）：

# Extended testing with production-like load
./scripts/load-test.sh test-cluster 1000-users 15-minutes
./scripts/chaos-engineering.sh test-cluster

# Manual approval gate
echo "Approve production deployment? (y/n)"
read approval

Troubleshooting

• 阶段因配额失败：预检整个舰队中所有群集的区域配额。
• 验证脚本失败：确保测试脚本具有幂等性，并返回清晰的成功或失败结果。
• 手动审批延迟：将自动化用于非生产。 只需手动进行生产。

常见问题 (FAQ)

是否可以使用开源软件工具进行验证？

Yes. 集成 Sonobuoy 用于一致性测试，集成 kube-bench 用于安全检查。

AKS 的独特之处是什么？

Azure Kubernetes Fleet Manager 提供分阶段推出和验证入口。

方案 3：安全 Kubernetes 版本引入

• 挑战：“我需要采用较新的支持的 Kubernetes 版本，而不会中断现有工作负载或 API。
• 策略：将多阶段验证与 Canary 部署配合使用。

实现步骤

步骤 1：API 弃用分析

# Install kubent after reviewing the installation script
sh -c "$(curl -sSL https://git.io/install-kubent)"

# Scan the cluster selected by your current kubeconfig context
kubent -o json > api-deprecation-report.json

# Review and remediate findings
cat api-deprecation-report.json | jq '.[] | select(.deprecated==true)'

若要了解详细信息，请参阅 Kubernetes API 弃用指南 和 kube-no-trouble 文档。

步骤 2：创建金丝雀环境

# Create canary cluster with target version
az aks create \
  --resource-group canary-rg \
  --name aks-canary-target \
  --kubernetes-version <supported-kubernetes-version> \
  --node-count 2 \
  --tier premium \
  --enable-addons monitoring

# Deploy subset of workloads
kubectl apply -f ./canary-manifests/

步骤 3：渐进式工作负荷迁移

# Phase 1: Stateless services (20% traffic)
kubectl patch service api-service -p '{"spec":{"selector":{"version":"canary"}}}'
./scripts/monitor-error-rate.sh 15-minutes

# Phase 2: Background jobs (50% traffic)
kubectl scale deployment batch-processor --replicas=3
./scripts/validate-job-completion.sh

# Phase 3: Critical services (100% traffic)
kubectl patch deployment critical-api -p '{"spec":{"template":{"metadata":{"labels":{"cluster":"canary"}}}}}'

步骤 4：功能门验证

# Test features and APIs in the target Kubernetes version
apiVersion: v1
kind: ConfigMap
metadata:
  name: feature-validation
data:
  test-script: |
    # Test new security features
    kubectl auth can-i create pods --as=service-account:default:test-sa

    # Validate performance improvements
    kubectl top nodes --use-protocol-buffers=true

    # Check the API versions enabled on the canary cluster
    kubectl api-versions

成功指标

• API 兼容性：100%（零重大更改）
• 性能：关键指标回退不超过 5%
• 功能采纳情况：已在 Canary 中验证的新功能

方案 4：最快的安全修补程序部署

• 挑战：“一项严重的 CVE 漏洞已被公布。” 我需要在四小时内将补丁部署到所有集群。
• 策略：使用自动化节点映像修补程序，尽量减少中断。

若要了解详细信息，请参阅 节点映像升级策略、 自动升级通道和安全 修补最佳做法。

实现步骤

步骤 1：紧急响应准备

第一个命令为 AKS 标准群集配置群集级节点 OS 自动升级通道。 此通道独立于群集 Kubernetes 版本自动升级通道。

# Configure the cluster-level node OS autoupgrade channel
az aks update \
  --resource-group production-rg \
  --name aks-prod \
  --node-os-upgrade-channel SecurityPatch

# Configure maintenance window for emergency patches
az aks maintenanceconfiguration add \
  --resource-group production-rg \
  --cluster-name aks-prod \
  --name aksManagedNodeOSUpgradeSchedule \
  --schedule-type Weekly \
  --day-of-week Monday \
  --interval-weeks 1 \
  --duration 4 \
  --utc-offset +00:00 \
  --start-time 00:00

若要了解详细信息，请参阅 计划内维护配置 和 自动升级通道。

步骤 2：自动安全扫描

# security-scan-cronjob.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: security-scanner
spec:
  schedule: "0 */6 * * *"  # Every 6 hours
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: scanner
            image: aquasec/trivy:latest
            command:
            - trivy
            - k8s
            - --report
            - summary
            - cluster

步骤 3：快速部署补丁

# Trigger immediate node image upgrade for security patches
az aks nodepool upgrade \
  --resource-group production-rg \
  --cluster-name aks-prod \
  --name nodepool1 \
  --node-image-only \
  --max-surge 50% \
  --drain-timeout 5

# Monitor patch deployment
watch az aks nodepool show \
  --resource-group production-rg \
  --cluster-name aks-prod \
  --name nodepool1 \
  --query "upgradeSettings"

步骤 4：合规性验证

# Verify patch installation
kubectl get nodes -o wide
kubectl describe node | grep "Kernel Version"

# Generate compliance report
./scripts/generate-security-report.sh > security-compliance-$(date +%Y%m%d).json

# Notify security team
curl -X POST "$SLACK_WEBHOOK" -d "{\"text\":\"Security patches deployed to production cluster. Compliance report attached.\"}"

成功指标

• 部署时间：从 CVE 公告不到 4 小时
• 覆盖范围：100% 的节点已修补
• 停机时间：每个节点池的停机时间少于 5 分钟

方案 5：用于复原升级的应用程序体系结构

• 挑战：“我希望我的应用程序能够正常处理群集升级，而不会影响用户。
• 策略：使用可复原的应用程序模式并正常降级。

实现步骤

步骤 1：实施健全的健康检查

# robust-health-checks.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: resilient-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: resilient-api
  template:
    metadata:
      labels:
        app: resilient-api
    spec:
      containers:
      - name: api
        image: myapp:latest
        readinessProbe:
          httpGet:
            path: /health/ready
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5
          timeoutSeconds: 3
          successThreshold: 1
          failureThreshold: 3
        livenessProbe:
          httpGet:
            path: /health/live
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
          timeoutSeconds: 5
          failureThreshold: 3
        lifecycle:
          preStop:
            exec:
              command: ["/bin/sh", "-c", "sleep 15"]

此部署运行 3 个 resilient-api 副本，将未就绪的 Pod 从服务流量中移除，重启状态异常的容器，并给予正在终止的 Pod 15 秒的流量排空时间。

步骤 2：配置 Pod 中断预算 (PDB)

# optimal-pdb.yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-pdb
spec:
  selector:
    matchLabels:
      app: resilient-api
  maxUnavailable: 1
  # Ensures at least 2 pods remain available during upgrades
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: database-pdb
spec:
  selector:
    matchLabels:
      app: database
  minAvailable: 2
  # Critical: Always keep majority of database pods running

这些预算最多允许一个 resilient-api Pod 不可用，并要求在自愿中断期间至少有两个数据库 Pod 保持可用。

步骤 3：实现断路器模式

// circuit-breaker.js
const CircuitBreaker = require('opossum');

const options = {
  timeout: 3000,
  errorThresholdPercentage: 50,
  resetTimeout: 30000,
  fallback: () => 'Service temporarily unavailable'
};

const breaker = new CircuitBreaker(callExternalService, options);

// Monitor circuit breaker state during upgrades
breaker.on('open', () => console.log('Circuit breaker opened'));
breaker.on('halfOpen', () => console.log('Circuit breaker half-open'));

当至少 50% 请求失败、使用回退响应并在 30 秒后测试恢复时，断路器将打开。

步骤 4：数据库连接复原

# connection-pool-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: db-config
data:
  database.yml: |
    production:
      adapter: postgresql
      pool: 25
      timeout: 5000
      retry_attempts: 3
      retry_delay: 1000
      connection_validation: true
      validation_query: "SELECT 1"
      test_on_borrow: true

此配置维护一个包含 25 个数据库连接的池，在使用前验证连接，并重试最多三次失败的连接。

成功指标

• 错误率：在升级期间小于 0.01%
• 响应时间：下降不超过 10%
• 恢复时间：在节点更换后不到 30 秒

场景 6：迁移切换回滚

• 挑战：“我将工作负荷从源群集、VM 资产或本地环境迁移到新的 AKS 群集。 如果在切换后出现任何问题，我需要快速将流量切回源端。
• 策略：使用蓝绿双群集（源群集 = 蓝色、新的 AKS 群集 = 绿色），或使用节点池在新 AKS 群集内使用蓝/绿。 使源环境保持运行并可由同一外部前门（DNS、流量管理器或负载均衡器）访问。 通过将流量切换到绿色端点来完成最终切换。 如果出现任何问题，将流量切回蓝色环境。

为什么这有效

• 切换是在入口层或服务层执行的单次流量切换操作。
• 源在生产回退时保持不变。 在你确认可以将其退役之前，不会进行任何破坏性迁移操作。
• 可以预热缓存、验证实际流量下的行为，并在指标超过中止阈值时立即削减。

实现概述

# variables (replace)
RG="myResourceGroup"
CLUSTER="myAksCluster"
GREEN_POOL="greenpool"
NODE_COUNT=3
VM_SIZE="Standard_DS2_v2"

# Step 1: Create a green node pool in the target AKS cluster
az aks nodepool add \
  --resource-group $RG \
  --cluster-name $CLUSTER \
  --name $GREEN_POOL \
  --node-count $NODE_COUNT \
  --node-vm-size $VM_SIZE \
  --labels pool=green

# Step 2: Get credentials
az aks get-credentials --resource-group $RG --name $CLUSTER

# Step 3: Cutover - patch the Service selector to green pods
kubectl patch svc myapp -n production -p '{"spec":{"selector":{"app":"myapp","version":"green"}}}'

# Rollback - patch selector back to blue
kubectl patch svc myapp -n production -p '{"spec":{"selector":{"app":"myapp","version":"blue"}}}'

az aks nodepool add \
  --resource-group $RG \
  --cluster-name $CLUSTER \
  --name $GREEN_POOL \
  --node-count $NODE_COUNT \
  --node-vm-size $VM_SIZE \
  --labels pool=green

az aks get-credentials --resource-group $RG --name $CLUSTER

# Confirm nodes are in the new pool
kubectl get nodes --show-labels | grep $GREEN_POOL

# deployment-green.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-green
  labels:
    app: myapp
    version: green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      version: green
  template:
    metadata:
      labels:
        app: myapp
        version: green
    spec:
      nodeSelector:
        "kubernetes.azure.com/agentpool": "greenpool"
      containers:
      - name: myapp
        image: myregistry.azurecr.cn/myapp:green
        ports:
        - containerPort: 80

kubectl apply -f deployment-green.yaml -n production
kubectl rollout status deploy/myapp-green -n production

# Check pod health
kubectl get pods -l app=myapp,version=green -n production
kubectl logs -l app=myapp,version=green -n production --tail=100

# Example: check cluster CPU (adjust resource ID for your cluster)
az monitor metrics list \
  --resource /subscriptions/<sub>/resourceGroups/$RG/providers/Microsoft.ContainerService/managedClusters/$CLUSTER \
  --metric "CpuUsagePercentage" \
  --interval PT1M

kubectl patch svc myapp -n production -p '{"spec":{"selector":{"app":"myapp","version":"green"}}}'

# Verify endpoints updated
kubectl get endpoints myapp -n production -o wide

kubectl patch svc myapp -n production -p '{"spec":{"selector":{"app":"myapp","version":"blue"}}}'

# Verify
kubectl get endpoints myapp -n production -o wide
kubectl rollout status deploy/myapp-blue -n production

双集群迁移（源为独立的集群或虚拟机）

如果源（蓝色）环境是单独的群集或 VM，请从外部操作前门，并在该处切换终结点，而不是修补新群集内的服务。

• Azure 流量管理器或 Front Door：翻转终结点优先级或权重以在源和目标之间路由。
• DNS 切换：保持 DNS 名称不变，并将 A 记录（TTL 设为较短）改为目标集群 IP。 在规划切换时，请将客户端和 DNS 解析器的 DNS 缓存考虑在内。
• 外部负载均衡器：为每个群集使用后端池，并切换后端池成员身份。

回滚触发器（go/no-go 指标）

定义会导致立即回滚的明确触发条件。 根据服务级别目标（SLO）调整阈值。

在 Azure Monitor 或 Application Insights 中配置自动警报，以通知值班工程师，并可选择触发将流量回切的 Runbook。

Troubleshooting

• DNS 传播较慢：在切换前设置较短的 TTL，并确认 DNS 缓存已刷新。
• 源端上的 Pod 一直处于终止状态：检查终结器或耗时过长的关闭钩子。
• 流量未转移：验证流量管理器运行状况探测和终结点配置。
• 回滚失败：在正式停用源环境之前，请保持其已打补丁且可访问。

成功验证清单

切换前：

• [ ] 源 （蓝色） 保持运行且可访问。
• [ ] 绿色环境具有相同或兼容的服务终结点、机密和配置。
• [ ] 已配置和测试就绪情况和运行情况探测。
• [ ] 已建立针对错误、延迟和资源压力的监控和告警机制。
• [ ] 已编写脚本的回滚操作已准备就绪并经过测试。
• [ ] 相关干系人和值班人员已收到通知并处于待命状态。

预期结果：快速回滚流量，以及经过充分演练、由指标驱动的切换流程，在您选择停用源系统之前始终保持源系统完好无损。 可实现的恢复时间和恢复点取决于流量收敛、数据复制、写入协调和测试的恢复过程。

迁移的后续步骤

• AKS 迁移指南 - 从此处开始进行迁移规划和清单。
• AKS 的蓝绿节点池升级模式 - 节点池蓝/绿和零风险升级。

监视 AKS 生产升级

使用适用于 Prometheus 指标的 Azure Monitor 托管服务、容器见解日志和 Grafana 仪表板监视升级进度和应用程序运行状况。 若要了解详细信息，请参阅 AKS 监视概述、 容器见解和 Prometheus 指标。

要监视的基本指标

# upgrade-monitoring.yaml
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: upgrade-monitoring
spec:
  groups:
  - name: upgrade.rules
    rules:
    - alert: UpgradeInProgress
      expr: kube_node_spec_unschedulable > 0
      for: 1m
      annotations:
        summary: "Node upgrade in progress"

    - alert: HighErrorRate
      expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.01
      for: 2m
      annotations:
        summary: "High error rate during upgrade"

    - alert: PodEvictionFailed
      expr: increase(kube_pod_container_status_restarts_total[5m]) > 5
      for: 1m
      annotations:
        summary: "Multiple pod restarts detected"

AKS 升级仪表板信号示例

以下概念 JSON 组 Prometheus 信号用于 AKS 节点状态和应用程序运行状况。 将这些信号调整为适用于 Grafana 或 Azure 托管 Grafana 中的 Azure Monitor 仪表板；此示例不是可导入的仪表板定义。

{
  "dashboard": {
    "title": "AKS Upgrade Dashboard",
    "panels": [
      {
        "title": "Upgrade Progress",
        "targets":
        [
          "kube_node_info",
          "kube_node_status_condition"
        ]
      },
      {
        "title": "Application Health",
        "targets":
        [
          "up{job='kubernetes-pods'}",
          "http_request_duration_seconds"
        ]
      }
    ]
  }
}

故障排除指南

若要了解详细信息，请参阅 AKS 故障排除指南、 节点和 Pod 故障排除以及 AKS 错误代码 PodDrainFailure。

常见问题和解决方案

紧急回滚规程

# Quick rollback script
#!/bin/bash
echo "Initiating emergency rollback..."

# Route traffic back to the previous cluster endpoint
az network traffic-manager endpoint update \
  --resource-group traffic-rg \
  --profile-name production-tm \
  --name current-endpoint \
  --type azureEndpoints \
  --weight 0

az network traffic-manager endpoint update \
  --resource-group traffic-rg \
  --profile-name production-tm \
  --name previous-endpoint \
  --type azureEndpoints \
  --weight 100

# Verify rollback success
API_URL=<application-url>
curl -f "${API_URL}/health"
echo "Rollback completed in $(date)"

相关资源

特定场景

• 有状态工作负荷：使用 PostgreSQL、Redis 和 MongoDB 升级模式。
• 升级方案中心：选择升级路径。
• 基本 AKS 升级：查找简单的群集版本升级。

支持工具

• 自动升级配置：使用自动升级通道。
• 维护时段：计划升级时段。
• 升级监视：使用实时升级警报。

最佳做法

• 群集可靠性：升级设计。
• 安全准则：使用安全升级做法。
• 支持策略：了解升级支持窗口。

下一个任务

对于现有 AKS 标准群集

• 设置监视：在首次升级之前配置 升级通知 。
• 安全实践：在预发布环境中使用 群集快照测试场景。
• 逐步实现自动化：先在非生产环境中使用自动升级通道。
• 处理有状态数据：如果运行数据库，请查看 有状态工作负荷模式 。