有关 Azure Kubernetes 服务 (AKS) 的常见问题解答

  • 项目

本文解答有关 Azure Kubernetes 服务 (AKS) 的常见问题。

哪些 Azure 区域目前提供 AKS？

有关可用区域的完整列表，请参阅 AKS 区域和可用性。

能否跨区域分布 AKS 群集？

否。 AKS 群集是区域性资源，不能跨区域。 有关如何创建包括多个区域的体系结构的指南，请参阅用于实现业务连续性和灾难恢复的最佳做法。

AKS 群集是否可以跨可用性区域？

可以。 在支持可用性区域的区域中，可以在一个或跨多个可用性区域部署 AKS 群集。

是否可以控制谁有权限访问 Kubernetes API 服务器？

可以。 可以通过以下两种方式限制对 API 服务器的访问：

  • 如果希望保留 API 服务器的公共终结点但仅限对一组受信任的 IP 范围的访问，请使用 API 服务器授权的 IP 范围。
  • 如要仅允许从你的虚拟网络内访问 API 服务器，请使用专用群集。

单个群集中 VM 的大小是否可以不同？

能，可以通过创建多个节点池来在 AKS 群集中使用不同虚拟机大小。

安全更新是否可应用于 AKS 代理节点？

AKS 每周都会修补具有“供应商修补程序”的 CVE。 没有修补程序的 CVE 在进行修正之前会等待“供应商修补程序”。 AKS 映像会在 30 天内自动更新。 建议定期应用更新的节点映像，以确保应用补丁映像和 OS 补丁，并且它们都是最新版本。 可使用以下方法之一来执行此操作：

  • 通过 Azure 门户或 Azure CLI 手动执行。
  • 通过升级 AKS 群集。 群集自动升级 cordon 和 drain 节点，然后使用最新的 Ubuntu 映像和新修补程序版本或 Kubernetes 次要版本将新节点联机。 有关详细信息，请参阅升级 AKS 群集。
  • 通过使用节点映像升级。

AKS 中容器映像的大小限制是多少？

AKS 不会对容器映像大小设置限制。 但是，重要的是要了解：映像越大，对内存的要求就越高。 再大的话可能超出资源限制或工作器节点的总体可用内存。 默认情况下，AKS 群集的 VM 大小 Standard_DS2_v2 的内存设置为 7 GiB。

当容器映像过大（如在 TB 范围）时，由于磁盘空间不足，kubelet 可能无法将其从容器注册表拉取到节点。

Windows Server 节点

对于 Windows Server 节点，Windows 更新不会自动运行和应用最新的更新。 在 Windows 更新的发布周期和你自己的验证过程中，你需要定期升级 AKS 群集以及群集中的 Windows Server 节点池。 此升级过程会创建运行最新 Windows Server 映像和修补程序的节点，然后删除旧节点。 有关此过程的详细信息，请参阅升级 AKS 中的节点池。

是否有我应该注意的针对 AKS 的安全威胁？

Azure 对通过 Microsoft Defender for Containers 等服务保护工作负载可以采取的其他操作提供了相关指导。 下面是你应该注意的与 AKS 和 Kubernetes 相关的安全威胁：

托管控制平面如何与节点通信？

AKS 使用安全隧道通信，使 api-server 和单个节点 kubelets 即使在单独的虚拟网络上也能进行通信。 隧道通过 mTLS 加密进行保护。 AKS 使用的当前主隧道是 Konnectivity，以前称为 apiserver-network-proxy。 验证所有网络规则都遵循 Azure 所需的网络规则和 FQDN。

我的 Pod 是否可以使用 API 服务器 FQDN 而不使用群集 IP？

是的，你可以在 Pod 中添加注释 kubernetes.azure.com/set-kube-service-host-fqdn，将 KUBERNETES_SERVICE_HOST 变量设置为 API 服务器的域名而不是群集内服务 IP。 这在群集出口通过第 7 层防火墙完成的情况下（例如将 Azure 防火墙与应用程序规则结合使用时）非常有用。

为什么使用 AKS 创建两个资源组？

AKS 基于多个 Azure 基础结构资源生成（包括虚拟机规模集、虚拟网络和托管磁盘）。 通过这些集成，你可在 AKS 提供的托管 Kubernetes 环境内应用 Azure 平台的多个核心功能。

要启用此体系结构，每个 AKS 部署都需跨越两个资源组：

  1. 创建第一个资源组。 此组仅包含 Kubernetes 服务资源。 在部署过程中，AKS 资源提供程序会自动创建第二个资源组。 例如，第二个资源组为 MC_myResourceGroup_myAKSCluster_chinaeast2。 有关如何指定这第二个资源组的名称，请参阅下一部分。

  2. 第二个资源组（称为节点资源组）包含与该群集相关联的所有基础结构资源。 这些资源包括 Kubernetes 节点 VM、虚拟网络和存储。 默认情况下，节点资源组的名称类似于 MC_myResourceGroup_myAKSCluster_eastus。 每次删除群集时，AKS 都会自动删除节点资源组。 应仅将此群集用于共享群集生命周期的资源。

    注意

    修改 AKS 群集中节点资源组下的任何资源是不支持的操作，并且会导致群集操作失败。 可以通过阻止用户修改由 AKS 管理的资源来阻止对节点资源组进行更改。

我是否可为 AKS 节点资源组提供自己的名称？

是的。 默认情况下，AKS 将节点资源组命名为 MC_resourcegroupname_clustername_location，但你也可以提供一个自定义名称。

若要自行指定一个资源组名称，请安装 aks-preview Azure CLI 扩展版本 0.3.2 或更高版本。 使用 az aks create 命令创建 AKS 群集时，请使用 --node-resource-group 参数并指定资源组的名称。 如果使用 Azure 资源管理器模板部署 AKS 群集，可以使用 nodeResourceGroup 属性定义资源组名称。

  • Azure 资源提供程序会自动创建辅助资源组。
  • 只能在创建群集时指定自定义资源组名称。

请注意，对于节点资源组，不能执行以下操作：

  • 不能为节点资源组指定现有资源组。
  • 为节点资源组指定不同的订阅。
  • 创建群集后更改节点资源组名称。
  • 不能为节点资源组内的受管理资源指定名称。
  • 不能修改或删除节点资源组内受管理资源中由 Azure 创建的标记。 其他信息详见下一部分。

是否可以修改节点资源组中 AKS 资源的标记和其他属性？

如果修改或删除节点资源组中 Azure 创建的标记和其他资源属性，可能会遇到意外的缩放和升级错误。 使用 AKS，可以创建和修改由最终用户创建的自定义标记，还可以在创建节点池时添加这些标记。 例如，可以创建或修改标记，以分配业务单位或成本中心。 另一种选择是创建具有托管资源组范围的 Azure 策略。

Azure 创建的标记是为其各自的 Azure 服务创建的，应始终允许。 有用于 AKS 的 aks-managed 和 k8s-azure 标记。 在 AKS 群集中的节点资源组下修改资源上任何 Azure 创建的标记是不受支持的操作，这会中断服务级别目标 (SLO)。 有关详细信息，请参阅 AKS 是否提供服务级别协议？

注意

过去，标记名称“Owner”是为 AKS 保留的，用于管理分配在负载均衡器前端 IP 上的公共 IP。 现在，服务使用 aks-managed 前缀。 对于旧资源，请勿使用 Azure 策略来应用“Owner”标记名称。 否则，AKS 群集部署和更新操作上的所有资源都会中断。 这不适用于新创建的资源。

AKS 支持哪些 Kubernetes 许可控制器？ 是否可以添加或删除许可控制器？

AKS 支持以下许可控制器：

  • NamespaceLifecycle
  • LimitRanger
  • ServiceAccount
  • DefaultIngressClass
  • DefaultStorageClass
  • DefaultTolerationSeconds
  • MutatingAdmissionWebhook
  • ValidatingAdmissionWebhook
  • ResourceQuota
  • PodNodeSelector
  • PodTolerationRestriction
  • ExtendedResourceToleration

目前无法修改 AKS 中的准入控制器列表。

是否可以在 AKS 上使用许可控制器 Webhook？

是，可以在 AKS 上使用准入控制器 Webhook。 建议排除带有 control-plane 标记的内部 AKS 命名空间。例如：

namespaceSelector:
    matchExpressions:
    - key: control-plane
      operator: DoesNotExist

AKS 对 API 服务器出口设置了防火墙，因此需要能够从群集内部访问许可控制器 Webhook。

许可控制器 Webhook 是否会影响 kube 系统和内部 AKS 命名空间？

为了保护系统的稳定性，并防止自定义的许可控制器影响 kube 系统中的内部服务，我们在命名空间 AKS 中设置了一个许可执行程序，它自动排除 kube 系统和 AKS 内部命名空间。 此服务确保自定义许可控制器不会影响在 kube 系统中运行的服务。

如果在某个关键用例中，需要在 kube-system 上部署一些内容（不推荐）以支持自定义准入 Webhook，则可添加以下标签或注释，这样准入执行器就会忽略该内容。

标签："admissions.enforcer/disabled": "true"，或注释："admissions.enforcer/disabled": true

不是，它没有与 Azure Key Vault 集成。

机密存储 CSI 驱动程序的 Azure Key Vault 提供程序将 Azure Key Vault 本地集成到 AKS。

是否可以在 AKS 上运行 Windows Server 容器？

是的，可以在 AKS 运行 Windows Server 容器。 若要在 AKS 中运行 Windows Server 容器，需创建一个将 Windows Server 作为来宾 OS 运行的节点池。 Windows Server 容器只能使用 Windows Server 2019。 若要开始使用，请创建包含单个节点池的 AKS 群集。

Windows Server 对节点池的支持具有一些限制，Kubernetes 项目中的上游 Windows Server 也具有这些限制。 有关这些限制的详细信息，请参阅在 AKS 中使用 Windows Server 容器的一些限制。

AKS 是否提供服务级别协议？

AKS 在具有运行时间 SLA 功能的标准定价层中提供 SLA 保证。

“免费”定价层没有关联的服务级别协议，但有 99.5% 的服务级别目标。 如果存在升级、基础节点运行不正常、平台维护或应用程序向 API 服务器频繁发送请求导致其不堪重负等情况，则会出现暂时性连接问题。如果工作负载是任务关键型工作负载和生产工作负载，或者工作负载不允许 API 服务器重启，建议使用标准层（其中包括运行时间 SLA）。

我可以在 Azure 租户之间移动/迁移群集吗？

当前不支持在租户之间移动 AKS 群集。

我可以在订阅之间移动/迁移群集吗？

目前不支持跨订阅移动群集。

是否可以将 AKS 群集从当前的 Azure 订阅移到另一个订阅？

不支持在 Azure 订阅之间移动 AKS 群集及其关联的资源。

是否可以将我的 AKS 群集或 AKS 基础结构资源移到其他资源组，或将它们重命名？

不支持移动或重命名 AKS 群集及其关联的资源。

为何群集删除需要如此长的时间？

大多数群集会根据用户请求删除。 在某些情况下，尤其是自带资源组或执行跨 RG 任务的情况下，删除可能需要更多时间，甚至会失败。 如果在删除时出现问题，请仔细检查，确保没有在 RG 上进行锁定、RG 之外的任何资源均已取消与 RG 的关联等等。

为什么创建/更新群集需要如此长的时间？

如果在创建和更新群集操作时遇到问题，请确保没有任何可能阻止 AKS 群集管理资源（如 VM、负载均衡器、标记等）的分配策略或服务约束。

删除群集后是否可以还原群集？

否，删除群集后无法还原群集。 删除群集时，也会删除节点资源组及其所有资源。 第二个资源组的示例为 MC_myResourceGroup_myAKSCluster_chinaeast3。

如果要保留任何资源，请在删除群集之前将它们移到另一个资源组。 若要防止意外删除，可以使用节点资源组锁定锁定托管群集资源的 AKS 托管资源组。

如果 Pod/部署处于“NodeLost”或“未知”状态，是否仍然可以升级群集？

可以，但我们不建议这样做。 应在群集状态已知且正常的情况下执行更新。

如果我有一个群集的一个或多个节点处于“运行不正常”状态或关闭状态，是否可以进行升级？

否。请删除/移除任何处于故障状态的节点，或者因其他原因从群集中移除，然后再进行升级。

我运行了群集删除操作，但出现错误：[Errno 11001] getaddrinfo failed

最常见的情况是，如果你有一个或多个网络安全组 (NSG) 仍在使用中且与该群集相关联，则会出现此错误。 请将其移除，然后再次尝试删除操作。

我运行了升级，但现在我的 Pod 处于崩溃循环中，且就绪情况探测失败。

请确认你的服务主体尚未过期。 请参阅：AKS 服务主体和 AKS 更新凭据。

我的群集在运行，但突然不能预配 LoadBalancer，不能装载 PVC，等等。

请确认你的服务主体尚未过期。 请参阅：AKS 服务主体和 AKS 更新凭据。

能否将 AKS 群集缩放为零？

可以完全停止正在运行的 AKS 群集，从而节省相应的计算成本。 此外，还可以选择将所有的或特定的 User 节点池缩放或自动缩放为 0，以仅维护必要的群集配置。

你不能直接将系统节点池缩放为零。

是否可以使用虚拟机规模集 API 手动进行缩放？

否。不支持使用虚拟机规模集 API 进行缩放操作。 请使用 AKS API (az aks scale)。

是否可以使用虚拟机规模集手动缩放为 0 个节点？

否。不支持使用虚拟机规模集 API 进行缩放操作。 可使用 AKS API 缩放到零个非系统节点池，或者改为停止群集。

是否可以停止或解除分配我的所有 VM？

虽然 AKS 有对抗此类配置并从其恢复的复原机制，但这不是受支持的配置。 改为停止群集。

是否可以使用自定义 VM 扩展？

不可以，AKS 是托管服务，不支持操作 IaaS 资源。 若要安装自定义组件，请使用 Kubernetes API 和机制。 例如，使用 DaemonSets 安装所需组件。

AKS 是否将任何客户数据存储在群集区域之外？

否，所有数据都存储在群集区域内。

AKS 映像是否需要以根用户身份运行？

以下映像具有“以根用户身份运行”的功能要求，并且任何策略都必须提交例外：

  • mcr.azk8s.cn/oss/kubernetes/coredns
  • mcr.azk8s.cn/azuremonitor/containerinsights/ciprod
  • mcr.azk8s.cn/oss/calico/node
  • mcr.azk8s.cn/oss/kubernetes-csi/azuredisk-csi

什么是 Azure CNI 透明模式与桥模式？

从版本 1.2.0 开始，Azure CNI 会将透明模式设置为单租户 Linux CNI 部署的默认模式。 透明模式将替换桥模式。 在以下桥模式和透明模式部分中，我们将详细介绍这两种模式之间的差异，以及 Azure CNI 中透明模式的优点和限制。

桥模式

Azure CNI 桥模式实时创建一个名为“azure0”的 L2 桥。 所有主机端 Pod veth 对接口都会连接到此桥。 Pod 到 Pod 内部 VM 通信和其余流量都通过此桥。 此桥是第 2 层虚拟设备，它自己无法接收或传输任何内容，除非你将一个或多个真实设备绑定到此桥。 因此，Linux VM 的 eth0 必须转换为“azure0”桥的下级，这会在 Linux VM 中创建复杂的网络拓扑。 故障表现是，CNI 必须处理其他网络功能，例如 DNS 服务器更新。

Bridge mode topology

以下示例显示了 IP 路由设置在桥模式下的情况。 不管节点有多少个 Pod，都只会有两个路由。 第一个路由显示流量（不包括 azure0 上的本地流量）通过 IP 为“src 10.240.0.4”（即节点主 IP）的接口流到子网的默认网关。 第二个路由显示内核的“10.20.x.x”Pod 空间供内核决定。

default via 10.240.0.1 dev azure0 proto dhcp src 10.240.0.4 metric 100
10.240.0.0/12 dev azure0 proto kernel scope link src 10.240.0.4
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
root@k8s-agentpool1-20465682-1:/#

透明模式

透明模式采用直截了当的方法来设置 Linux 网络。 在此模式下，Azure CNI 不会更改 Linux VM 中 eth0 接口的任何属性。 这种更改 Linux 网络属性的方法有助于减少群集在桥模式下可能会遇到的复杂极端情况问题。 在透明模式下，Azure CNI 会创建并添加将添加到主机网络的主机端 Pod veth 对接口。 内部 VM Pod 到 Pod 通信通过 CNI 添加的 IP 路由进行。 基本上，Pod 到 Pod 通信通过第 3 层进行，Pod 通信通过 L3 传递规则进行路由。

Transparent mode topology

以下示例显示了透明模式的 IP 路由设置。 每个 Pod 的接口都会附加一个静态路由，因此目标 IP 为 Pod 的流量会直接发送到 Pod 的主机端 veth 对接口。

10.240.0.216 dev azv79d05038592 proto static
10.240.0.218 dev azv8184320e2bf proto static
10.240.0.219 dev azvc0339d223b9 proto static
10.240.0.222 dev azv722a6b28449 proto static
10.240.0.223 dev azve7f326f1507 proto static
10.240.0.224 dev azvb3bfccdd75a proto static
168.63.129.16 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
169.254.169.254 via 10.240.0.1 dev eth0 proto dhcp src 10.240.0.4 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown

透明模式的优点

  • 针对 conntrack DNS 并行争用情况提供缓解措施，避免 5 秒 DNS 延迟问题，无需设置节点本地 DNS（出于性能方面的原因，你仍可以使用节点本地 DNS）。
  • 消除了 CNI 桥模式目前由于“实时”桥设置而引入的最初 5 秒 DNS 延迟。
  • 桥模式下的极端情况之一是，Azure CNI 无法不断更新用户添加到 VNET 或 NIC 的自定义 DNS 服务器列表。 这种情况会导致 CNI 仅选取 DNS 服务器列表的第一个实例。 此问题在透明模式下得到解决，因为 CNI 不更改任何 eth0 属性。 在此处了解详细信息。
  • 提供了更好的 UDP 流量处理，并且在 ARP 超时时可以缓解 UDP 数据风暴。在桥模式下，当桥在内部 VM Pod 到 Pod 通信中不知道目标 Pod 的 MAC 地址时，按照设计，这会导致所有端口都出现数据包风暴。 此问题在透明模式下得到解决，因为路径中没有 L2 设备。 在此处了解详细信息。
  • 与桥模式相比，在内部 VM Pod 到 Pod 通信中，透明模式在吞吐量和延迟方面的性能更佳。

当卷中有大量文件时，如何避免权限所有权设置缓慢问题？

通常情况下，如果 Pod 以非根用户（应为根用户）身份运行，则必须在 Pod 的安全性上下文中指定一个 fsGroup，才能使该卷可供 Pod 读取和写入。 此处将更详细地介绍此要求。

设置 fsGroup 的一个负面影响是，每次装载卷时，Kubernetes 都必须通过 chown() 和 chmod() 递归卷内的所有文件和目录（下面提到的一些情况例外）。 即使卷的组所有权已经与请求的 fsGroup 匹配，也会发生这种情况。 对于包含大量小型文件的更大卷来说，开销可能很高，这可能导致 Pod 启动耗时很长。 在 v1.20 之前，这种情况是一个已知问题，解决方法是将 Pod 设置为以根用户身份运行：

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 0
    fsGroup: 0

Kubernetes 版本 1.20 中已解决此问题。 有关详细信息，请参阅 Kubernetes 1.20：对卷权限更改的精细控制。

是否可以将 FIPS 加密库用于 AKS 上的部署？

基于 Linux 的节点池支持已启用 FIPS 的节点。 有关更多详细信息，请参阅添加已启用 FIPS 的节点池。

是否可以使用 AKS 配置 NSG？

AKS 不会将网络安全组 (NSG) 应用于其子网，也不会修改与该子网相关的任何 NSG。 AKS 仅修改网络接口 NSG 设置。 如果要使用 CNI，还必须确保 NSG 中的安全规则允许节点和 pod CIDR 范围之间的通信。 如果使用的是 kubenet，还必须确保 NSG 中的安全规则允许节点和 Pod CIDR 之间的流量。 有关详细信息，请参阅网络安全组。

时间同步在 AKS 中如何工作？

AKS 节点运行“chrony”服务，该服务从 localhost 拉取时间。 Pod 上运行的容器从 AKS 节点获取时间。 容器中启动的应用程序使用该 Pod 容器中的时间。

AKS 加载项如何更新？

任何补丁（包括安全修补程序）都会自动应用于 AKS 群集。 如果有新版本可用，则更新群集时，会更新比修补程序更大的任何内容，例如主要或次要版本更改（可能对已部署的对象进行重大更改）。 请访问 AKS 发行说明，了解新版本何时可用。

在 Linux 虚拟机规模集实例上安装的 AKS Linux 扩展有什么用途？

AKS Linux 扩展是一种 Azure VM 扩展，用于在 Kubernetes 工作器节点上安装和配置监视工具。 该扩展安装在所有新的和现有的 Linux 节点上。 它配置以下监视工具：

  • 节点导出器：从虚拟机收集硬件遥测数据，并使用指标终结点使其可用。 然后，Prometheus 等监视工具能够使这些指标无效。
  • 节点问题检测器：旨在使各种节点问题对群集管理堆栈中的上游层可见。 它是在每个节点上运行的 systemd 单元，可检测节点问题，并使用事件和 NodeConditions 将问题报告给群集的 API 服务器。
  • ig：一个 eBPF 支持的开源框架，用于调试和观察 Linux 和 Kubernetes 系统。 它提供了一组旨在收集相关信息的工具（或者说小工具），让用户能够识别性能问题、崩溃或其他异常的原因。 值得注意的是，它与 Kubernetes 的独立使用户还能够用它来调试控制平面问题。

这些工具有助于围绕许多节点运行状况相关问题提供可观测性，例如：

  • 基础结构守护程序问题：NTP 服务中断
  • 硬件问题：CPU、内存或磁盘错误
  • 内核问题：内核死锁、文件系统损坏
  • 容器运行时问题：运行时守护程序无响应

除了记录的 AKS 出口要求外，该扩展不需要对任何 URL、IP 地址或端口进行其他出站访问。 它不需要在 Azure 中授予的任何特殊权限。 它使用 kubeconfig 连接到 API 服务器以发送收集的监视数据。