Azure Kubernetes 服务 (AKS) 的部署和群集可靠性最佳做法

本文提供了在 Azure Kubernetes 服务 (AKS) 工作负载的部署和群集级别实现的群集可靠性的最佳做法。 本文适用于负责在 AKS 中部署和管理应用程序的群集操作员和开发人员。

本文中的最佳做法分为以下类别：

部署级别最佳做法

以下部署级别最佳做法有助于确保 AKS 工作负载的高可用性和可靠性。 这些最佳做法是可在 POD 和部署的 YAML 文件中实现的本地配置。

Pod 中断预算 (PDB)

最佳实践指南

使用 Pod 中断预算 (PDB) 确保在自愿性中断（例如，升级操作或意外删除 Pod）期间，最小的 Pod 数保持可用。

Pod 中断预算 (PDB)允许定义部署或副本集在自愿性中断（例如，升级操作或意外删除 Pod）期间的响应方式。 使用 PDB，可以定义最小或最大的不可用资源计数。 PDB 仅影响自愿性中断的逐出 API 。

例如，假设需要执行群集升级并已定义 PDB。 在执行群集升级之前，Kubernetes 计划程序可确保 PDB 中定义的最小 Pod 数可用。 如果升级会导致可用 Pod 数低于 PDB 中定义的最小值，计划程序会在允许升级继续之前在其他节点上计划额外的 Pod。 如果未设置 PDB，则计划程序对升级期间可能不可用的 Pod 数没有任何约束，这可能会导致资源缺少和潜在的群集中断。

在以下示例 PDB 定义文件中，minAvailable字段设置在自愿性中断期间必须保持可用的最小 Pod 数。 该值可以是绝对数（例如，3）或所需 pod 数的百分比（例如，10%）。

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
   name: mypdb
spec:
   minAvailable: 3 # Minimum number of pods that must remain available during voluntary disruptions
   selector:
    matchLabels:
      app: myapp

有关详细信息，请参阅使用 PDB 规划可用性和为应用程序指定中断预算。

Pod CPU 和内存限制

最佳实践指南

为所有 Pod 设置 Pod CPU 和内存限制，以确保 Pod 不会消耗节点上的所有资源，并在服务威胁（例如，DDoS 攻击）期间提供保护。

Pod CPU 和内存限制定义 Pod 可使用的最大 CPU 和内存量。 当 Pod 超出其定义的限制时，它会标记为要删除。 有关详细信息，请参阅Kubernetes 中的 CPU 资源单元和Kubernetes 中的内存资源单元。

设置 CPU 和内存限制有助于维护节点运行状况，并最大程度地减少对节点上其他 Pod 的影响。 请避免设置的 pod 限制超过节点可以支持的限制。 每个 AKS 节点将为核心 Kubernetes 组件保留一定的 CPU 和内存量。 如果设置的 Pod 限制高于节点可以支持的限制，则应用程序可能会尝试消耗过多的资源，并对节点上的其他 Pod 产生负面影响。 群集管理员需要针对需设置资源请求和限制的命名空间设置资源配额。 有关详细信息，请参阅在 AKS 中强制实施资源配额。

在以下示例 Pod 定义文件中，resources部分设置 Pod 的 CPU 和内存限制：

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: mcr.azk8s.cn/oss/nginx/nginx:1.15.5-alpine
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 250m
        memory: 256Mi

kubectl describe node <node-name>

# Example output
Capacity:
 cpu:                8
 ephemeral-storage:  129886128Ki
 hugepages-1Gi:      0
 hugepages-2Mi:      0
 memory:             32863116Ki
 pods:               110
Allocatable:
 cpu:                7820m
 ephemeral-storage:  119703055367
 hugepages-1Gi:      0
 hugepages-2Mi:      0
 memory:             28362636Ki
 pods:               110

有关详细信息，请参阅将 CPU 资源分配到容器和 Pod和将内存资源分配给容器和 Pod。

预停止挂钩

最佳实践指南

如果适用，请使用预停止挂钩确保容器正常终止。

在容器因 API 请求或管理事件（例如抢占、资源争用或运行情况/启动探测失败）终止之前，立即调用PreStop挂钩。 如果容器已处于已终止或已完成状态，则对PreStop挂钩的调用会失败，并且挂钩必须在发送停止容器的 TERM 信号之前完成。 Pod 的终止宽限期倒计时在执行PreStop挂钩之前开始，因此容器最终会在终止宽限期内终止。

以下示例 Pod 定义文件演示了如何使用PreStop挂钩确保容器正常终止：

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
      preStop:
        exec:
          command: ["/bin/sh","-c","nginx -s quit; while killall -0 nginx; do sleep 1; done"]

有关详细信息，请参阅容器生命周期挂钩和Pod 终止。

maxUnavailable

最佳实践指南

使用部署中的maxUnavailable字段定义在滚动更新期间不可用的最大 Pod 数，从而确保在升级期间保持最少的 Pod 数。

maxUnavailable字段指定更新过程中可能不可用的最大 Pod 数。 该值可以是绝对数（例如，3）或所需 pod 数的百分比（例如，10%）。 maxUnavailable与滚动更新期间使用的 Delete API 相关。

以下示例部署清单使用maxAvailable字段设置更新过程中可能不可用的最大 Pod 数：

apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 3
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.14.2
       ports:
       - containerPort: 80
 strategy:
   type: RollingUpdate
   rollingUpdate:
     maxUnavailable: 1 # Maximum number of pods that can be unavailable during the upgrade

有关详细信息，请参阅最大不可用。

Pod 拓扑分布约束

最佳实践指南

使用 Pod 拓扑分布约束来确保 Pod 分布在不同的节点或区域，以提高可用性和可靠性。

可以使用 Pod 拓扑分布约束来控制 Pod 如何根据节点的拓扑在群集之间分布，并将 Pod 分散到不同的节点或区域，以提高可用性和可靠性。

以下示例 Pod 定义文件演示如何使用 topologySpreadConstraints 字段将 Pod 分散到不同节点：

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  # Configure a topology spread constraint
  topologySpreadConstraints:
    - maxSkew: <integer>
      minDomains: <integer> # optional
      topologyKey: <string>
      whenUnsatisfiable: <string>
      labelSelector: <object>
      matchLabelKeys: <list> # optional
      nodeAffinityPolicy: [Honor|Ignore] # optional
      nodeTaintsPolicy: [Honor|Ignore] # optional

有关详细信息，请参阅 Pod 拓扑分布约束。

就绪情况、运行情况和启动探测

最佳实践指南

在适用于提高高负载和较低容器重启的复原能力时，请配置就绪情况、运行情况和启动探测。

就绪情况探测

在 Kubernetes 中，kubelet 使用就绪情况探测了解容器什么时候准备好开始接受流量。 所有容器准备就绪时，pod 被视为就绪。 当 pod 未准备好时，会从服务负载均衡器中删除。 有关详细信息，请参阅Kubernetes 中的就绪情况探测。

以下示例 Pod 定义文件显示了就绪情况探测配置：

readinessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5

有关详细信息，请参阅配置就绪情况探测。

运行情况探测

在 Kubernetes 中，kubelet 使用运行情况探测了解什么时候重启容器。 如果容器的运行情况探测失败，会重启容器。 有关详细信息，请参阅Kubernetes 中的运行情况探测。

以下示例 Pod 定义文件显示了运行情况探测配置：

livenessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy

另一种运行情况探测使用 HTTP GET 请求。 以下示例 Pod 定义文件显示了 HTTP GET 请求运行情况探测配置：

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

有关详细信息，请参阅配置运行情况探测和定义运行情况 HTTP 请求。

启动探测

在 Kubernetes 中，kubelet 使用启动探测了解容器应用程序什么时候已启动。 配置启动探测时，在启动探测成功之前，就绪情况和运行情况探测不会启动，确保就绪情况和运行情况探测不会干扰应用程序启动。 有关详细信息，请参阅Kubernetes 中的启动探测。

以下示例 Pod 定义文件显示了启动探测配置：

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

多副本应用程序

最佳实践指南

至少部署应用程序的两个副本，以确保节点关闭场景中的高可用性和复原能力。

在 Kubernetes 中，可以使用部署中的replicas字段指定要运行的 Pod 数。 运行应用程序的多个实例有助于确保节点关闭场景中的高可用性和复原能力。 如果已启用可用性区域，可以使用replicas字段指定要跨多个可用性区域运行的 Pod 数。

以下示例 Pod 定义文件演示了如何使用replicas字段指定要运行的 Pod 数：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

有关详细信息，请参阅AKS 的建议主动-主动高可用性解决方案概述和部署规范中的副本。

群集和节点池级别最佳做法

以下群集和节点池级别最佳做法有助于确保 AKS 群集的高可用性和可靠性。 可以在创建或更新 AKS 群集时实现这些最佳做法。

可用性区域

最佳实践指南

创建 AKS 群集时使用多个可用性区域，以确保区域关闭场景中的高可用性。 请记住，创建群集后无法更改可用性区域配置。

可用性区域是区域内数据中心的分隔组。 这些区域足够近，可以彼此建立低延迟连接，但相距足够远，以减少多个区域受到本地中断或天气影响的可能性。 使用可用性区域有助于数据在区域关闭场景中保持同步和可访问。 有关详细信息，请参阅在多个区域中运行。

群集自动缩放

最佳实践指南

使用群集自动缩放确保群集可以处理增加的负载并在低负载期间降低成本。

若要跟上 AKS 中的应用程序需求，可能需要调整运行工作负荷的节点数。 群集自动缩放程序组件可监视群集中由于资源约束而无法进行计划的 Pod。 当群集自动缩放程序检测到问题时，它会纵向扩展节点池中的节点数来满足应用程序需求。 它还会定期检查节点是否缺少正在运行的 Pod，并根据需要纵向缩减节点数。 有关详细信息，请参阅AKS 中的群集自动缩放。

创建 AKS 群集以启用群集自动缩放程序时，可以使用--enable-cluster-autoscaler参数，如以下示例所示：

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 2 \
    --vm-set-type VirtualMachineScaleSets \
    --load-balancer-sku standard \
    --enable-cluster-autoscaler  \
    --min-count 1 \
    --max-count 3 \
    --generate-ssh-keys

还可以更改群集范围内的自动缩放程序配置文件中的默认值，从而在现有节点池上启用群集自动缩放程序，并配置群集自动缩放程序的更精细的详细信息。

有关详细信息，请参阅在 AKS 中使用群集自动缩放程序。

标准负载均衡器

最佳实践指南

使用标准负载均衡器提供更高的可靠性和资源，跨多个数据中心支持多个可用性区域、HTTP 探测和功能。

在 Azure 中，标准负载均衡器 SKU 旨在在需要高性能和低延迟时为网络层流量进行负载均衡。 标准负载均衡器在区域内和跨区域路由流量，并路由到可用性区域以实现高复原能力。 建议使用标准 SKU，并在创建 AKS 群集时使用默认 SKU。

以下示例演示了使用标准负载均衡器的LoadBalancer服务清单：

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-ipv4 # Service annotation for an IPv4 address
  name: azure-load-balancer
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-load-balancer

有关详细信息，请参阅在 AKS 中使用标准负载均衡器。

系统节点池

使用专用系统节点池

最佳实践指南

使用系统节点池确保其他任何用户应用程序不会在同一节点上运行，这可能会导致资源短缺并影响系统 Pod。

使用专用系统节点池确保没有其他用户应用程序在同一节点上运行，这可能会因争用条件导致资源短缺和潜在的群集中断。 要使用专用系统节点池，可以在系统节点池上使用CriticalAddonsOnly污点。 有关详细信息，请参阅在 AKS 中使用系统节点池。

系统节点池的自动缩放

最佳实践指南

配置系统节点池的自动缩放程序，以设置节点池的最小和最大缩放限制。

在节点池上使用自动缩放程序为节点池配置最小和最大缩放限制。 系统节点池应始终能够缩放以满足系统 Pod 的需求。 如果系统节点池无法缩放，群集会耗尽资源，以帮助管理计划、缩放和负载均衡，这可能会导致无响应群集。

有关详细信息，请参阅在节点池上使用群集自动缩放程序。

每个系统节点池至少有三个节点

最佳实践指南

确保系统节点池至少有三个节点，以确保针对冻结/升级场景提供复原能力，这可能会导致节点重启或关闭。

系统节点池用于运行系统 Pod，例如 kube-proxy、coredns 和 Azure CNI 插件。 建议确保系统节点池至少有三个节点，以确保针对冻结/升级场景提供复原能力，这可能会导致节点重启或关闭。 有关详细信息，请参阅在 AKS 中管理系统节点池。

加速网络

最佳实践指南

使用加速网络在 VM 上提供更低的延迟、减少抖动并降低 CPU 利用率。

加速网络在受支持的 VM 类型上启用单根 I/O 虚拟化 (SR-IOV)，从而大大提高了网络性能。

下图说明了在有和无加速网络的情况下，两个 VM 如何通信：

有关详细信息，请参阅加速网络概述。

映像版本

最佳实践指南

图像不应使用latest标记。

容器映像标记

对容器映像使用latest标记可能会导致不可预知的行为，并难以跟踪群集中正在运行的映像版本。 在生成和运行时，通过在容器中集成和运行扫描及修正工具可最大程度降低风险。 有关详细信息，请参阅AKS 中容器映像管理的最佳做法。

节点映像升级

AKS 为节点 OS 映像升级提供了多个自动升级通道。 可以使用这些通道控制升级的时间。 建议加入这些自动升级通道，以确保节点正在运行最新的安全修补程序和更新。 有关详细信息，请参阅在 AKS 中自动升级节点 OS 映像。

生产工作负载的标准层

最佳实践指南

将标准层用于产品工作负载，提高群集可靠性、增加资源，支持群集中最多 5,000 个节点，以及默认启用的运行时间 SLA。 如果需要 LTS，请考虑使用高级层。

Azure Kubernetes 服务 (AKS) 的标准层为生产工作负载提供经济支持的 99.9% 的运行时间服务级别协议(SLA)。 标准层还提供更高的群集可靠性和资源，支持群集中最多 5,000 个节点，以及默认启用的运行时间 SLA。 有关详细信息，请参阅AKS 群集管理的定价层。

用于动态 IP 分配的 Azure CNI

最佳实践指南

为 Azure CNI 配置动态 IP 分配，以提高 IP 利用率，并防止 AKS 群集的 IP 耗尽。

Azure CNI 中的动态 IP 分配功能从与托管 AKS 群集的子网分开的子网分配 Pod IP，并提供以下优势：

• 更高的 IP 利用率：IP 从 Pod 子网动态分配给群集 Pod。 与传统的 CNI 解决方案（为每个节点静态分配 IP）相比，此功能可以优化群集中的 IP 利用率。
• 可缩放性和灵活性：可以单独缩放节点和 Pod 子网。 单个 Pod 子网可以在群集的多个节点池之间或在同一 VNet 中部署的多个 AKS 群集之间共享。 你还可以为节点池配置单独的 Pod 子网。
• 高性能：由于为 Pod 分配了虚拟网络 IP，因此它们可以直接连接到 VNet 中的其他群集 Pod 和资源。 此解决方案支持非常大的群集，且丝毫不会降低性能。
• 用于 Pod 的单独 VNet 策略：由于 Pod 具有单独的子网，因此你可以单独为它们配置不同于节点策略的 VNet 策略。 这样可以实现许多有用的方案，例如只允许 Pod 而不允许节点连接 Internet，使用 Azure NAT 网关修复节点池中 Pod 的源 IP 以及使用 NSG 筛选节点池之间的流量。
• Kubernetes 网络策略：Azure 网络策略和 Calico 都适用于此解决方案。

有关详细信息，请参阅为 IP 的动态分配和增强的子网支持配置 Azure CNI 网络。

v5 SKU VM

最佳实践指南

使用 v5 VM SKU 提高更新期间和之后的性能，减少整体影响，并为应用程序建立更可靠的连接。

对于 AKS 中的节点池，请使用具有临时 OS 磁盘的 v5 SKU VM，为 kube 系统 Pod 提供足够的计算资源。 有关详细信息，请参阅 在 AKS 中实现性能和缩放大型工作负载的最佳做法。

不要使用 B 系列 VM

最佳实践指南

不要对 AKS 群集使用 B 系列 VM，因为它们性能低，并且不适用于 AKS。

B 系列 VM 的性能低，不适用于 AKS。 相反，建议使用v5 SKU VM。

高级磁盘

最佳实践指南

使用高级磁盘在一个虚拟机 (VM) 中实现 99.9% 的可用性。

Azure 高级磁盘提供一致的亚毫秒级子磁盘延迟和高 IOPS 以及整体性能。 高级磁盘旨在为 VM 提供低延迟、高性能和一致的磁盘性能。

以下示例 YAML 清单显示了高级磁盘的存储类定义：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: premium2-disk-sc
parameters:
   cachingMode: None
   skuName: PremiumV2_LRS
   DiskIOPSReadWrite: "4000"
   DiskMBpsReadWrite: "1000"
provisioner: disk.csi.azure.com
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true

有关详细信息，请参阅在 AKS 上使用 Azure 高级 SSD v2 磁盘。

容器见解

最佳实践指南

启用 Container Insights 以监视和诊断容器化应用程序的性能。

Container Insights是 Azure Monitor 的一项功能，它从 AKS 收集和分析容器日志。 可以使用视图集合和预生成的工作簿分析收集的数据。

可以使用各种方法在 AKS 群集上启用容器见解监视。 以下示例演示了如何使用 Azure CLI 在现有群集上启用容器见解监视：

az aks enable-addons -a monitoring --name myAKSCluster --resource-group myResourceGroup

有关详细信息，请参阅为 Kubernetes 群集启用监视。

Azure Policy

最佳实践指南

使用 Azure Policy 为 AKS 群集应用并强制实施安全性和合规性要求。

可以使用 Azure Policy 在 AKS 群集上应用和强制实施内置的安全策略。 Azure Policy 有助于强制执行组织标准并进行大规模的合规性评估。 安装适用于 AKS 的 Azure Policy 加载项后，可将各个策略定义或策略定义组（称为计划）应用于群集。

有关详细信息，请参阅使用 Azure Policy 保护 AKS 群集。

后续步骤

本文重点介绍 Azure Kubernetes 服务 (AKS) 群集的部署和群集可靠性的最佳做法。 更多最佳做法，请参阅以下文章：

• AKS 中的高可用性和灾难恢复概述
• 大规模运行 AKS 群集
• AKS 群集的基线体系结构