有关 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 即使在单独的虚拟网络上也能进行通信。 隧道通过 TLS 加密进行保护。 AKS 使用的当前主隧道是 Konnectivity,以前称为 apiserver-network-proxy。 验证所有网络规则都遵循 Azure 所需的网络规则和 FQDN

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

AKS 基于多个 Azure 基础结构资源生成(包括虚拟机规模集、虚拟网络和托管磁盘)。 因此,你可以在 AKS 提供的托管 Kubernetes 环境内应用 Azure 平台的多个核心功能。

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

  1. 创建第一个资源组。 此组仅包含 Kubernetes 服务资源。 在部署过程中,AKS 资源提供程序会自动创建第二个资源组。 例如,第二个资源组为 MC_myResourceGroup_myAKSCluster_chinaeast2。 有关如何指定这第二个资源组的名称,请参阅下一部分。
  2. 第二个资源组(称为节点资源组)包含与该群集相关联的所有基础结构资源。 这些资源包括 Kubernetes 节点 VM、虚拟网络和存储。 默认情况下,节点资源组使用类似于 MC_myResourceGroup_myAKSCluster_chinaeast2 的名称。 每当删除群集时,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 策略来实现。

但是,在 AKS 群集中的节点资源组下修改任何 Azure 在资源中创建的标记是不受支持的操作,这会中断服务级别目标 (SLO)。 有关详细信息,请参阅 AKS 是否提供服务级别协议?

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

AKS 支持以下许可控制器

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

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

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

是的,可以在 AKS 上使用许可控制器 Webhook。 建议排除使用控制平面标签标记的内部 AKS 命名空间。例如,通过将以下内容添加到 Webhook 配置:

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 保障(可选功能)。

默认提供的免费 SKU 没有关联的服务级别协议,但具有 99.5% 的服务级别目标 。 如果存在升级、运行不正常的基础节点、平台维护或应用程序向 API 服务器频繁发送请求导致其不堪重负等情况,就会出现暂时性连接问题。如果工作负载不允许 API 服务器重启,建议使用运行时间 SLA。

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

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

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

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

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

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

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

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

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

大多数群集在用户发出请求后即会被删除。在某些情况下,尤其是客户使用自己的资源组或执行跨资源组任务时,删除群集可能会花费更多时间或失败。 如果在删除时出现问题,请仔细检查,确保没有在 RG 上进行锁定、RG 之外的任何资源均已取消与 RG 的关联,等等。

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

可以,但是 AKS 不建议这样做。 升级应该在群集状态已知且正常的情况下完成。

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

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

我运行了群集删除操作,但出现错误:[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 服务器更新等。

桥模式拓扑

下面是桥模式下的 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 路由规则进行路由。

透明模式拓扑

下面是透明模式的 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 发行说明,了解新版本何时可用。