你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
Azure Kubernetes 服务 (AKS) 中的可用性区域
当数据中心发生故障时,可用性区域可以帮助你保护应用程序和数据。 这些区域是 Azure 地区中独特的物理位置。 每个区域包含一个或多个配备了独立电源、冷却设备和网络的数据中心。
通过将 AKS 与可用性区域配合使用,能够以物理方式在单个区域内的不同可用性区域之间分配资源,从而提高可靠性。 在多个区域中部署节点不会产生额外的费用。
本文介绍了如何配置 AKS 资源以使用可用性区域。
AKS 资源
此图显示了在创建 AKS 群集时创建的 Azure 资源:
AKS 控制面板
Microsoft 将 AKS 控制平面、Kubernetes API 服务器以及 scheduler
和 etcd
等服务作为托管服务进行托管。 Microsoft 将控制平面复制到多个区域中。
群集的其他资源部署在 Azure 订阅中的托管资源组中。 默认情况下,此资源组以“MC_”(表示托管群集)为前缀,并包含以下资源:
节点池
节点池在 Azure 订阅中作为虚拟机规模集创建。
创建 AKS 群集时,需要一个系统节点池并且会自动创建它。 它托管着关键系统 Pod,例如 CoreDNS
和 metrics-server
。 你可以向 AKS 群集中添加更多用户节点池来托管你的应用程序。
可以通过三种方式来部署节点池:
- 跨区域
- 区域对齐
- 区域
对于系统节点池,使用的区域数是在创建群集时配置的。
跨区域
跨区域规模集将使用 --zones
参数指定所选区域,从而将节点分散到所有选定区域。
# Create an AKS Cluster, and create a zone spanning System Nodepool in all three AZs, one node in each AZ
az aks create --resource-group example-rg --name example-cluster --node-count 3 --zones 1, 2, 3
# Add one new zone spanning User Nodepool, two nodes in each
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-a --node-count 6 --zones 1, 2, 3
AKS 自动平衡区域之间的节点数。
如果发生区域性中断,则受影响区域中的节点可能会受到影响,而其他可用性区域中的节点不受影响。
区域对齐
每个节点都对齐(固定)到一个特定区域。 为具有三个可用性区域的地区创建三个节点池:
# # Add three new zone aligned User Nodepools, two nodes in each
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-x --node-count 2 --zones 1
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-y --node-count 2 --zones 2
az aks nodepool add --resource-group example-rg --cluster-name example-cluster --name userpool-z --node-count 2 --zones 3
要求节点之间的延迟较低时,可以使用此配置。 对于缩放操作或当使用群集自动缩放程序时,它还可提供更精细的控制。
注意
- 如果跨节点池部署单个工作负载,建议将
--balance-similar-node-groups
设置为true
,以在纵向扩展操作期间为工作负载保持区域间的节点均衡分布。
地区性(不使用可用性区域)
如果未在部署模板 ("zones"=[] or "zones"=null
) 中设置区域分配,则使用“地区性”模式。
在此配置中,节点池会创建地区性(非区域固定)实例,并在整个地区中隐式放置实例。 无法保证跨区域均衡或分布,也无法保证实例位于同一可用性区域中。
在发生罕见的完全区域性中断时,节点池中的任何或所有实例都可能受到影响。
若要验证节点位置,请运行以下命令:
kubectl describe nodes | grep -e "Name:" -e "topology.kubernetes.io/zone"
NAME REGION ZONE
aks-nodepool1-34917322-vmss000000 eastus eastus-1
aks-nodepool1-34917322-vmss000001 eastus eastus-2
aks-nodepool1-34917322-vmss000002 eastus eastus-3
部署
Pod
Kubernetes 了解 Azure 可用性区域,并且可以在不同区域中的节点之间平衡 Pod。 如果某个区域变得不可用,则 Kubernetes 会自动将 Pod 移离受影响的节点。
如已知标签、注释和排斥中所述,Kubernetes 使用 topology.kubernetes.io/zone
标签在可用的不同区域中自动分发复制控制器或服务中的 pod。
若要查看哪些 Pod 正在运行,请运行以下命令:
kubectl describe pod | grep -e "^Name:" -e "^Node:"
“maxSkew”参数描述 Pod 可能分布不均的程度。 假设有三个区域和三个副本,将此值设置为 1 可确保每个区域至少有一个 Pod 正在运行:
kind: Pod
apiVersion: v1
metadata:
name: myapp
spec:
replicas: 3
topologySpreadConstraints:
- maxSkew: 1
topologyKey: "topology.kubernetes.io/zone"
whenUnsatisfiable: DoNotSchedule # or ScheduleAnyway
containers:
- name: pause
image: registry.k8s.io/pause:3.1
存储和卷
默认情况下,Kubernetes 版本 1.29 及更高版本使用采用区域冗余存储 (ZRS) 的 Azure 托管磁盘进行永久性卷声明。
为了增强应用程序的复原能力,并保护数据免受数据中心故障的影响,会在区域之间复制这些磁盘。
在 ZRS 中使用标准 SSD 的永久性卷声明的示例:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: azure-managed-disk
spec:
accessModes:
- ReadWriteOnce
storageClassName: managed-csi
#storageClassName: managed-csi-premium
resources:
requests:
storage: 5Gi
对于区域对齐部署,你可以在将 skuname
参数设置为 LRS(本地冗余存储)的情况下创建新的存储类。
然后,可以在永久性卷声明 (PVC) 中使用这个新存储类。
虽然 LRS 磁盘成本较低,但它们不是区域冗余的,不支持将磁盘附加到不同区域中的节点。
LRS 标准 SSD 存储类的示例:
kind: StorageClass
metadata:
name: azuredisk-csi-standard-lrs
provisioner: disk.csi.azure.com
parameters:
skuname: StandardSSD_LRS
#skuname: PremiumV2_LRS
负载均衡器
Kubernetes 默认情况下会部署 Azure 标准负载均衡器,用于在一个地区中的所有区域之间均衡入站流量。 如果某个节点变得不可用,则负载均衡器会将流量重新路由到正常运行的节点。
使用 Azure 负载均衡器的示例服务:
apiVersion: v1
kind: Service
metadata:
name: example
spec:
type: LoadBalancer
selector:
app: myapp
ports:
- port: 80
targetPort: 8080
限制
使用可用性区域时,以下限制适用:
- 请参阅 AKS 中的配额、虚拟机大小限制和地区可用性。
- 创建节点池后,无法更改使用的可用性区域数。
- 大多数地区都支持可用性区域。 可在此处找到列表。
后续步骤
- 了解系统节点池
- 了解用户节点池
- 了解负载均衡器
- AKS 中业务连续性和灾难恢复的最佳做法