本文提供有关 Azure Kubernetes 服务 (AKS) 的某些最常见问题的解答。
AKS 在具有运行时间 SLA 功能的标准定价层中提供 SLA 保证。
平台支持是不受支持的“N-3”版本群集的缩减支持计划。 平台支持仅包括 Azure 基础结构支持。
有关详细信息,请参阅平台支持策略。
是的,AKS 会为不受支持的群集启动自动升级。 当 n-3 版本的群集(n 是支持的最新 AKS GA 次要版本)即将降至 n-4 时,AKS 会自动将群集升级到 n-2 以符合 AKS 支持策略。
有关详细信息,请参阅支持的 Kubernetes 版本、计划内维护时段,以及自动升级。
是的,AKS 还支持 Windows Server 容器。 有关详细信息,请参阅 AKS 上的 Windows Server 常见问题解答。
AKS 代理节点按标准 Azure 虚拟机计费。 如果你为在 AKS 中使用的 VM 大小购买了 Azure 预留,会自动应用这些折扣。
否,当前不支持在租户之间移动 AKS 群集。
否,当前不支持在订阅之间移动 AKS 群集。
否,不支持移动或重命名 AKS 群集及其关联的资源。
否,删除群集后将无法还原群集。 删除群集时,也会删除节点资源组及其所有资源。
如果要保留任何资源,请在删除群集之前将它们移到另一个资源组。 若要防止意外删除,可以使用节点资源组锁定锁定托管群集资源的 AKS 托管资源组。
可以完全停止正在运行的 AKS 群集,或将所有或特定的 User
节点池缩放或自动缩放为零。
你不能直接将系统节点池缩放为零。
否。不支持使用虚拟机规模集 API 进行缩放操作。 可以使用 AKS API (az aks scale
)。
否。不支持使用虚拟机规模集 API 进行缩放操作。 可以使用 AKS API 将非系统节点池缩放为零或停止群集。
否,这不是受支持的配置。 改为停止群集。
AKS 基于多个 Azure 基础结构资源生成(包括虚拟机规模集、虚拟网络和托管磁盘)。 通过这些集成,你可在 AKS 提供的托管 Kubernetes 环境内应用 Azure 平台的多个核心功能。 例如,大多数 Azure 虚拟机类型都可直接用于 AKS,而 Azure 预留可用于自动接收这些资源的折扣。
要启用此体系结构,每个 AKS 部署都需跨越两个资源组:
- 创建第一个资源组。 此组仅包含 Kubernetes 服务资源。 在部署期间,AKS 资源提供程序自动创建第二个资源组, 例如 MC_myResourceGroup_myAKSCluster_eastus。 如需了解如何指定第二个资源组的名称,请参阅下一节。
- 第二个资源组(称为节点资源组)包含与该群集相关联的所有基础结构资源。 这些资源包括 Kubernetes 节点 VM、虚拟网络和存储。 默认情况下,节点资源组的名称类似于 MC_myResourceGroup_myAKSCluster_eastus。 每次删除群集时,AKS 都会自动删除节点资源组。 应仅将此资源组用于共享群集生命周期的资源。
备注
修改 AKS 群集中节点资源组下的任何资源是不支持的操作,并且会导致群集操作失败。 可以通过阻止用户修改由 AKS 管理的资源来阻止对节点资源组进行更改。
默认情况下,AKS 会将节点资源组命名为 MC_resourcegroupname_clustername_location,但你可以提供自己的名称。
若要自行指定一个资源组名称,请安装 aks-preview Azure CLI 扩展版本 0.3.2 或更高版本。 使用 [az aks create
][az-aks-create] 命令创建 AKS 群集时,请使用 --node-resource-group
参数并指定资源组的名称。 如果使用 Azure 资源管理器模板部署 AKS 群集,可以使用 nodeResourceGroup 属性定义资源组名称。
- Azure 资源提供程序会自动创建辅助资源组。
- 只能在创建群集时指定自定义资源组名称。
请注意,对于节点资源组,不能执行以下操作:
- 不能为节点资源组指定现有资源组。
- 为节点资源组指定不同的订阅。
- 创建群集后更改节点资源组名称。
- 不能为节点资源组内的受管理资源指定名称。
- 不能修改或删除节点资源组内受管理资源中由 Azure 创建的标记。
如果修改或删除节点资源组中 Azure 创建的标记和其他资源属性,可能会遇到意外的缩放和升级错误。 使用 AKS,可以创建和修改由最终用户创建的自定义标记,还可以在创建节点池时添加这些标记。 例如,可以创建或修改标记,以分配业务单位或成本中心。 另一种选择是创建具有托管资源组范围的 Azure 策略。
Azure 创建的标记是为其各自的 Azure 服务创建的,应始终允许。 有用于 AKS 的 aks-managed
和 k8s-azure
标记。 在 AKS 群集中的节点资源组下修改资源上任何 Azure 创建的标记是不受支持的操作,这会中断服务级别目标 (SLO)。
备注
过去,标记名称“Owner”是为 AKS 保留的,用于管理分配在负载均衡器前端 IP 上的公共 IP。 现在,服务使用 aks-managed
前缀。 对于旧资源,请勿使用 Azure 策略来应用“Owner”标记名称。 否则,AKS 群集部署和更新操作上的所有资源都会中断。 这不适用于新创建的资源。
有关可用区域的完整列表,请参阅 AKS 区域和可用性。
否,AKS 群集是区域性资源,无法跨区域。 有关如何创建包括多个区域的体系结构的指南,请参阅用于实现业务连续性和灾难恢复的最佳做法。
是的,在支持可用性区域的区域中,可以在一个或跨多个可用性区域部署 AKS 群集。
能,可以通过创建多个节点池来在 AKS 群集中使用不同虚拟机大小。
AKS 不会对容器映像大小设置限制。 但是,重要的是要了解:映像越大,对内存的要求就越高。 再大的话可能超出资源限制或工作器节点的总体可用内存。 默认情况下,AKS 群集的 VM 大小 Standard_DS2_v2 的内存设置为 7 GiB。
当容器映像过大(如在 TB 范围)时,由于磁盘空间不足,kubelet 可能无法将其从容器注册表拉取到节点。
对于 Windows Server 节点,Windows 更新不会自动运行和应用最新的更新。 在 Windows 更新的发布周期和你自己的验证过程中,你需要定期升级 AKS 群集以及群集中的 Windows Server 节点池。 此升级过程会创建运行最新 Windows Server 映像和修补程序的节点,然后删除旧节点。 有关此过程的详细信息,请参阅升级 AKS 中的节点池。
以下映像具有“以根用户身份运行”的功能要求,并且任何策略都必须提交例外:
- mcr.microsoft.com/oss/kubernetes/coredns
- mcr.microsoft.com/azuremonitor/containerinsights/ciprod
- mcr.microsoft.com/oss/calico/node
- mcr.microsoft.com/oss/kubernetes-csi/azuredisk-csi
是的,可以通过以下两种方式限制对 API 服务器的访问:
- 如果希望保留 API 服务器的公共终结点但仅限对一组受信任的 IP 范围的访问,请使用 API 服务器授权的 IP 范围。
- 如要仅允许从你的虚拟网络内访问 API 服务器,请使用专用群集。
AKS 每周都会修补具有“供应商修补程序”的 CVE。 没有修补程序的 CVE 在进行修正之前会等待“供应商修补程序”。 AKS 映像会在 30 天内自动更新。 建议定期应用更新的节点映像,以确保应用补丁映像和 OS 补丁,并且它们都是最新版本。 可使用以下方法之一来执行此操作:
- 通过 Azure 门户或 Azure CLI 手动执行。
- 通过升级 AKS 群集。 群集自动升级 cordon 和 drain 节点,然后使用最新的 Ubuntu 映像和新修补程序版本或 Kubernetes 次要版本将新节点联机。 有关详细信息,请参阅升级 AKS 群集。
- 通过使用节点映像升级。
Microsoft 对通过 Microsoft Defender for Containers 等服务保护工作负载可以采取的其他操作提供了相关指导。 下面是你应该注意的与 AKS 和 Kubernetes 相关的安全威胁:
- 针对 Kubeflow 的全新大规模市场活动(2021 年 6 月 8 日)。
否,所有数据都存储在群集区域内。
通常情况下,如果 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:对卷权限更改的精细控制。
AKS 使用安全隧道通信,使 api-server 和单个节点 kubelets 即使在单独的虚拟网络上也能进行通信。 隧道通过 mTLS 加密进行保护。 AKS 使用的当前主隧道是 Konnectivity,以前称为 apiserver-network-proxy。 验证所有网络规则都遵循 Azure 所需的网络规则和 FQDN。
是的,你可以在 Pod 中添加注释 kubernetes.azure.com/set-kube-service-host-fqdn
,将 KUBERNETES_SERVICE_HOST
变量设置为 API 服务器的域名而不是群集内服务 IP。 这在群集出口通过第 7 层防火墙完成的情况下(例如将 Azure 防火墙与应用程序规则结合使用时)非常有用。
AKS 不会将网络安全组 (NSG) 应用于其子网,也不会修改与该子网相关的任何 NSG。 AKS 仅修改网络接口 NSG 设置。 如果要使用 CNI,还必须确保 NSG 中的安全规则允许节点和 pod CIDR 范围之间的通信。 如果使用的是 kubenet,还必须确保 NSG 中的安全规则允许节点和 Pod CIDR 之间的流量。 有关详细信息,请参阅网络安全组。
AKS 节点运行“chrony”服务,该服务从 localhost 拉取时间。 Pod 上运行的容器从 AKS 节点获取时间。 容器中启动的应用程序使用该 Pod 容器中的时间。
不可以,AKS 是托管服务,不支持操作 IaaS 资源。 若要安装自定义组件,请使用 Kubernetes API 和机制。 例如,使用 DaemonSets 安装所需组件。
AKS 支持以下许可控制器:
- NamespaceLifecycle
- LimitRanger
- ServiceAccount
- DefaultIngressClass
- DefaultStorageClass
- DefaultTolerationSeconds
- MutatingAdmissionWebhook
- ValidatingAdmissionWebhook
- ResourceQuota
- PodNodeSelector
- PodTolerationRestriction
- ExtendedResourceToleration
目前无法修改 AKS 中的准入控制器列表。
是,可以在 AKS 上使用准入控制器 Webhook。 建议排除带有 control-plane 标记的内部 AKS 命名空间。 例如:
namespaceSelector:
matchExpressions:
- key: control-plane
operator: DoesNotExist
AKS 对 API 服务器出口设置了防火墙,因此需要能够从群集内部访问许可控制器 Webhook。
为了保护系统的稳定性,并防止自定义的许可控制器影响 kube 系统中的内部服务,我们在命名空间 AKS 中设置了一个许可执行程序,它自动排除 kube 系统和 AKS 内部命名空间。 此服务确保自定义许可控制器不会影响在 kube 系统中运行的服务。
如果在某个关键用例中,需要在 kube-system 上部署一些内容(不推荐)以支持自定义准入 Webhook,则可添加以下标签或注释,这样准入执行器就会忽略该内容。
标签:"admissions.enforcer/disabled": "true"
,或注释:"admissions.enforcer/disabled": true
机密存储 CSI 驱动程序的 Azure Key Vault 提供程序将 Azure Key Vault 本地集成到 AKS。
基于 Linux 的节点池支持已启用 FIPS 的节点。 有关更多详细信息,请参阅添加已启用 FIPS 的节点池。
任何补丁(包括安全修补程序)都会自动应用于 AKS 群集。 如果有新版本可用,则更新群集时,会更新比修补程序更大的任何内容,例如主要或次要版本更改(可能对已部署的对象进行重大更改)。 请访问 AKS 发行说明,了解新版本何时可用。
AKS Linux 扩展是一种 Azure VM 扩展,用于在 Kubernetes 工作器节点上安装和配置监视工具。 该扩展安装在所有新的和现有的 Linux 节点上。 它配置以下监视工具:
- 节点导出器:从虚拟机收集硬件遥测数据,并使用指标终结点使其可用。 然后,Prometheus 等监视工具能够使这些指标无效。
- 节点问题检测器:旨在使各种节点问题对群集管理堆栈中的上游层可见。 它是在每个节点上运行的 systemd 单元,可检测节点问题,并使用事件和 NodeConditions 将问题报告给群集的 API 服务器。
- ig:一个 eBPF 支持的开源框架,用于调试和观察 Linux 和 Kubernetes 系统。 它提供了一组旨在收集相关信息的工具(或者说小工具),让用户能够识别性能问题、崩溃或其他异常的原因。 值得注意的是,它与 Kubernetes 的独立使用户还能够用它来调试控制平面问题。
这些工具有助于围绕许多节点运行状况相关问题提供可观测性,例如:
- 基础结构守护程序问题:NTP 服务中断
- 硬件问题:CPU、内存或磁盘错误
- 内核问题:内核死锁、文件系统损坏
- 容器运行时问题:运行时守护程序无响应
除了记录的 AKS 出口要求外,该扩展不需要对任何 URL、IP 地址或端口进行其他出站访问。 它不需要在 Azure 中授予的任何特殊权限。 它使用 kubeconfig 连接到 API 服务器以发送收集的监视数据。
大多数群集会根据用户请求删除。 在某些情况下,尤其是自带资源组或执行跨 RG 任务的情况下,删除可能需要更多时间,甚至会失败。 如果在删除时出现问题,请仔细检查,确保没有在 RG 上进行锁定、RG 之外的任何资源均已取消与 RG 的关联等等。
如果在创建和更新群集操作时遇到问题,请确保没有任何可能阻止 AKS 群集管理资源(如 VM、负载均衡器、标记等)的分配策略或服务约束。
可以,但我们不建议这样做。 应在群集状态已知且正常的情况下执行更新。
否。请删除/移除任何处于故障状态的节点,或者因其他原因从群集中移除,然后再进行升级。
最常见的情况是,如果你有一个或多个网络安全组 (NSG) 仍在使用中且与该群集相关联,则会出现此错误。 请将其移除,然后再次尝试删除操作。