有关 Azure Kubernetes 服务 (AKS) 的常见问题解答Frequently asked questions about Azure Kubernetes Service (AKS)

本文解答有关 Azure Kubernetes 服务 (AKS) 的常见问题。This article addresses frequent questions about Azure Kubernetes Service (AKS).

哪些 Azure 区域目前提供 AKS?Which Azure regions currently provide AKS?

有关可用区域的完整列表,请参阅 AKS 区域和可用性For a complete list of available regions, see AKS regions and availability.

能否跨区域分布 AKS 群集?Can I spread an AKS cluster across regions?

否。No. AKS 群集是区域性资源,不能跨区域。AKS clusters are regional resources and can't span regions. 有关如何创建包括多个区域的体系结构的指南,请参阅用于实现业务连续性和灾难恢复的最佳做法See best practices for business continuity and disaster recovery for guidance on how to create an architecture that includes multiple regions.

能否限制哪些人员可以访问 Kubernetes API 服务器?Can I limit who has access to the Kubernetes API server?

可以。Yes. 可以通过以下两种方式限制对 API 服务器的访问:There are two options for limiting access to the API server:

  • 如果希望保留 API 服务器的公共终结点但仅限对一组受信任的 IP 范围的访问,请使用 API 服务器授权的 IP 范围Use API Server Authorized IP Ranges if you want to maintain a public endpoint for the API server but restrict access to a set of trusted IP ranges.
  • 如要仅允许从你的虚拟网络内访问 API 服务器,请使用专用群集Use a private cluster if you want to limit the API server to only be accessible from within your virtual network.

单个群集中 VM 的大小是否可以不同?Can I have different VM sizes in a single cluster?

能,可以通过创建多个节点池来在 AKS 群集中使用不同虚拟机大小。Yes, you can use different virtual machine sizes in your AKS cluster by creating multiple node pools.

安全更新是否可应用于 AKS 代理节点?Are security updates applied to AKS agent nodes?

Azure 会按照夜间计划自动将安全修补程序应用于群集中的 Linux 节点。Azure automatically applies security patches to the Linux nodes in your cluster on a nightly schedule. 但是,你需要负责确保这些 Linux 节点根据需要重新启动。However, you're responsible for ensuring that those Linux nodes are rebooted as required. 可以使用多个选项来重新启动节点:You have several options for rebooting nodes:

  • 通过 Azure 门户或 Azure CLI 手动执行。Manually, through the Azure portal or the Azure CLI.
  • 通过升级 AKS 群集。By upgrading your AKS cluster. 群集自动升级 cordon 和 drain 节点,然后使用最新的 Ubuntu 映像和新修补程序版本或 Kubernetes 次要版本将新节点联机。The cluster upgrades cordon and drain nodes automatically and then bring a new node online with the latest Ubuntu image and a new patch version or a minor Kubernetes version. 有关详细信息,请参阅升级 AKS 群集For more information, see Upgrade an AKS cluster.
  • 通过使用节点映像升级By using node image upgrade.

Windows Server 节点Windows Server nodes

对于 Windows Server 节点,Windows 更新不会自动运行和应用最新的更新。For Windows Server nodes, Windows Update does not automatically run and apply the latest updates. 在 Windows 更新的发布周期和你自己的验证过程中,你需要定期升级 AKS 群集以及群集中的 Windows Server 节点池。On a regular schedule around the Windows Update release cycle and your own validation process, you should perform an upgrade on the cluster and the Windows Server node pool(s) in your AKS cluster. 此升级过程会创建运行最新 Windows Server 映像和修补程序的节点,然后删除旧节点。This upgrade process creates nodes that run the latest Windows Server image and patches, then removes the older nodes. 有关此过程的详细信息,请参阅升级 AKS 中的节点池For more information on this process, see Upgrade a node pool in AKS.

为什么使用 AKS 创建两个资源组?Why are two resource groups created with AKS?

AKS 在多个 Azure 基础结构资源之上构建,包括虚拟机规模集、虚拟网络和托管磁盘。AKS builds upon a number of Azure infrastructure resources, including virtual machine scale sets, virtual networks, and managed disks. 这使你能够在 AKS 提供的托管 Kubernetes 环境中利用 Azure 平台的许多核心功能。This enables you to leverage many of the core capabilities of the Azure platform within the managed Kubernetes environment provided by AKS.

为了启用此体系结构,每个 AKS 部署跨越两个资源组:To enable this architecture, each AKS deployment spans two resource groups:

  1. 创建第一个资源组。You create the first resource group. 此组仅包含 Kubernetes 服务资源。This group contains only the Kubernetes service resource. 在部署过程中,AKS 资源提供程序会自动创建第二个资源组。The AKS resource provider automatically creates the second resource group during deployment. 例如,第二个资源组为 MC_myResourceGroup_myAKSCluster_chinaeast2An example of the second resource group is MC_myResourceGroup_myAKSCluster_chinaeast2. 有关如何指定这第二个资源组的名称,请参阅下一部分。For information on how to specify the name of this second resource group, see the next section.

  2. 第二个资源组(称为节点资源组)包含与该群集相关联的所有基础结构资源。The second resource group, known as the node resource group, contains all of the infrastructure resources associated with the cluster. 这些资源包括 Kubernetes 节点 VM、虚拟网络和存储。These resources include the Kubernetes node VMs, virtual networking, and storage. 默认情况下,节点资源组使用类似于 MC_myResourceGroup_myAKSCluster_chinaeast2 的名称。By default, the node resource group has a name like MC_myResourceGroup_myAKSCluster_chinaeast2. 每当删除群集时,AKS 会自动删除节点资源,因此,仅应对生命周期与群集相同的资源使用 AKS。AKS automatically deletes the node resource whenever the cluster is deleted, so it should only be used for resources that share the cluster's lifecycle.

我是否可为 AKS 节点资源组提供自己的名称?Can I provide my own name for the AKS node resource group?

是的。Yes. 默认情况下,AKS 将节点资源组命名为 MC_resourcegroupname_clustername_location,但你也可以提供自己的名称。By default, AKS will name the node resource group MC_resourcegroupname_clustername_location, but you can also provide your own name.

若要自行指定一个资源组名称,请安装 aks-preview Azure CLI 扩展版本 0.3.2 或更高版本。To specify your own resource group name, install the aks-preview Azure CLI extension version 0.3.2 or later. 使用 az aks create 命令创建 AKS 群集时,请使用 --node-resource-group 参数并指定资源组的名称。When you create an AKS cluster by using the az aks create command, use the --node-resource-group parameter and specify a name for the resource group. 如果使用 Azure 资源管理器模板部署 AKS 群集,则可以使用 nodeResourceGroup 属性定义资源组名称。If you use an Azure Resource Manager template to deploy an AKS cluster, you can define the resource group name by using the nodeResourceGroup property.

  • Azure 资源提供程序会在你自己的订阅中自动创建辅助资源组。The secondary resource group is automatically created by the Azure resource provider in your own subscription.
  • 只能在创建群集时指定自定义资源组名称。You can specify a custom resource group name only when you're creating the cluster.

请注意,对于节点资源组,不能执行以下操作:As you work with the node resource group, keep in mind that you can't:

  • 不能为节点资源组指定现有资源组。Specify an existing resource group for the node resource group.
  • 为节点资源组指定不同的订阅。Specify a different subscription for the node resource group.
  • 创建群集后更改节点资源组名称。Change the node resource group name after the cluster has been created.
  • 不能为节点资源组内的受管理资源指定名称。Specify names for the managed resources within the node resource group.
  • 不能修改或删除节点资源组内受管理资源中由 Azure 创建的标记。Modify or delete Azure-created tags of managed resources within the node resource group. (请参阅下一部分的附加信息。)(See additional information in the next section.)

是否可以修改节点资源组中 AKS 资源的标记和其他属性?Can I modify tags and other properties of the AKS resources in the node resource group?

如果修改或删除节点资源组中 Azure 创建的标记和其他资源属性,可能会出现意外的结果,例如缩放和升级错误。If you modify or delete Azure-created tags and other resource properties in the node resource group, you could get unexpected results such as scaling and upgrading errors. 使用 AKS,可以创建和修改由最终用户创建的自定义标记,还可以在创建节点池时添加这些标记。AKS allows you to create and modify custom tags created by end users, and you can add those tags when creating a node pool. 例如,可以创建或修改标记,以分配业务单位或成本中心。You might want to create or modify custom tags, for example, to assign a business unit or cost center. 这也可以通过在托管资源组上创建具有作用域的 Azure 策略来实现。This can also be achieved by creating Azure Policies with a scope on the managed resource group.

但是,在 AKS 群集中的节点资源组下修改任何 Azure 在资源中创建的标记是不受支持的操作,这会中断服务级别目标 (SLO)。However, modifying any Azure-created tags on resources under the node resource group in the AKS cluster is an unsupported action, which breaks the service-level objective (SLO). 有关详细信息,请参阅 AKS 是否提供服务级别协议?For more information, see Does AKS offer a service-level agreement?

AKS 支持哪些 Kubernetes 许可控制器?What Kubernetes admission controllers does AKS support? 是否可以添加或删除许可控制器?Can admission controllers be added or removed?

AKS 支持以下许可控制器AKS supports the following admission controllers:

  • NamespaceLifecycleNamespaceLifecycle
  • LimitRangerLimitRanger
  • ServiceAccountServiceAccount
  • DefaultStorageClassDefaultStorageClass
  • DefaultTolerationSecondsDefaultTolerationSeconds
  • MutatingAdmissionWebhookMutatingAdmissionWebhook
  • ValidatingAdmissionWebhookValidatingAdmissionWebhook
  • ResourceQuotaResourceQuota
  • PodNodeSelectorPodNodeSelector
  • PodTolerationRestrictionPodTolerationRestriction
  • ExtendedResourceTolerationExtendedResourceToleration

目前无法修改 AKS 中的准入控制器列表。Currently, you can't modify the list of admission controllers in AKS.

是否可以在 AKS 上使用许可控制器 Webhook?Can I use admission controller webhooks on AKS?

是的,可以在 AKS 上使用许可控制器 Webhook。Yes, you may use admission controller webhooks on AKS. 建议排除带有 control-plane 标记的内部 AKS 命名空间。It's recommended you exclude internal AKS namespaces, which are marked with the control-plane label. 例如,可以将以下内容添加到 Webhook 配置:For example, by adding the below to the webhook configuration:

    - key: control-plane
      operator: DoesNotExist

AKS 对 API 服务器出口设置了防火墙,因此需要能够从群集内部访问许可控制器 Webhook。AKS firewalls the API server egress so your admission controller webhooks need to be accessible from within the cluster.

许可控制器 Webhook 是否会影响 kube 系统和内部 AKS 命名空间?Can admission controller webhooks impact kube-system and internal AKS namespaces?

为了保护系统的稳定性,并防止自定义的许可控制器影响 kube 系统中的内部服务,我们在命名空间 AKS 中设置了一个 许可执行程序,它自动排除 kube 系统和 AKS 内部命名空间。To protect the stability of the system and prevent custom admission controllers from impacting internal services in the kube-system, namespace AKS has an Admissions Enforcer, which automatically excludes kube-system and AKS internal namespaces. 此服务确保自定义许可控制器不会影响在 kube 系统中运行的服务。This service ensures the custom admission controllers don't affect the services running in kube-system.

如果你有一个用于在 kube 系统上部署某些内容的关键用例(不建议这样做),并且需要使用自定义许可 Webhook 来涵盖该系统,则可添加以下标签或注释,这样许可执行程序就会忽略该系统。If you have a critical use case for having something deployed on kube-system (not recommended) which you require to be covered by your custom admission webhook, you may add the below label or annotation so that Admissions Enforcer ignores it.

标签:"admissions.enforcer/disabled": "true",或注释:"admissions.enforcer/disabled": trueLabel: "admissions.enforcer/disabled": "true" or Annotation: "admissions.enforcer/disabled": true

不是,它没有与 Azure Key Vault 集成。Is Azure Key Vault integrated with AKS?

AKS 目前尚未与 Azure Key Vault 本机集成。AKS isn't currently natively integrated with Azure Key Vault. 但是,适用于 CSI 机密存储的 Azure Key Vault 提供程序支持从 Kubernetes pod 到 Key Vault 机密的直接集成。However, the Azure Key Vault provider for CSI Secrets Store enables direct integration from Kubernetes pods to Key Vault secrets.

是否可以在 AKS 上运行 Windows Server 容器?Can I run Windows Server containers on AKS?

是的,可以在 AKS 运行 Windows Server 容器。Yes, Windows Server containers are available on AKS. 若要在 AKS 中运行 Windows Server 容器,需创建一个将 Windows Server 作为来宾 OS 运行的节点池。To run Windows Server containers in AKS, you create a node pool that runs Windows Server as the guest OS. Windows Server 容器只能使用 Windows Server 2019。Windows Server containers can use only Windows Server 2019. 若要开始使用,请创建包含单个节点池的 AKS 群集To get started, see Create an AKS cluster with a Windows Server node pool.

Windows Server 对节点池的支持具有一些限制,Kubernetes 项目中的上游 Windows Server 也具有这些限制。Windows Server support for node pool includes some limitations that are part of the upstream Windows Server in Kubernetes project. 有关这些限制的详细信息,请参阅在 AKS 中使用 Windows Server 容器的一些限制For more information on these limitations, see Windows Server containers in AKS limitations.

AKS 是否提供服务级别协议?Does AKS offer a service-level agreement?

AKS 通过运行时间 SLA 提供 SLA 保障(可选的附加功能)。AKS provides SLA guarantees as an optional add on feature with Uptime SLA.

我可以在 Azure 租户之间移动/迁移群集吗?Can I move/migrate my cluster between Azure tenants?

当前不支持在租户之间移动 AKS 群集。Moving your AKS cluster between tenants is currently unsupported.

我可以在订阅之间移动/迁移群集吗?Can I move/migrate my cluster between subscriptions?

目前不支持跨订阅移动群集。Movement of clusters between subscriptions is currently unsupported.

是否可以将 AKS 群集从当前的 Azure 订阅移到另一个订阅?Can I move my AKS clusters from the current Azure subscription to another?

不支持在 Azure 订阅之间移动 AKS 群集及其关联的资源。Moving your AKS cluster and its associated resources between Azure subscriptions isn't supported.

是否可以将我的 AKS 群集或 AKS 基础结构资源移到其他资源组,或将它们重命名?Can I move my AKS cluster or AKS infrastructure resources to other resource groups or rename them?

不支持移动或重命名 AKS 群集及其关联的资源。Moving or renaming your AKS cluster and its associated resources isn't supported.

为何群集删除需要如此长的时间?Why is my cluster delete taking so long?

大多数群集是按用户请求删除的;某些情况下,尤其是在客户引入自己的资源组或执行跨 RG 任务的情况下,删除操作可能需要更多的时间,或者可能会失败。Most clusters are deleted upon user request; in some cases, especially where customers are bringing their own Resource Group, or doing cross-RG tasks deletion can take additional time or fail. 如果在删除时出现问题,请仔细检查,确保没有在 RG 上进行锁定、RG 之外的任何资源均已取消与 RG 的关联,等等。If you have an issue with deletes, double-check that you do not have locks on the RG, that any resources outside of the RG are disassociated from the RG, and so on.

如果 Pod/部署处于“NodeLost”或“未知”状态,是否仍然可以升级群集?If I have pod / deployments in state 'NodeLost' or 'Unknown' can I still upgrade my cluster?

可以,但是 AKS 不建议这样做。You can, but AKS doesn't recommend this. 升级应该在群集状态已知且正常的情况下完成。Upgrades should be performed when the state of the cluster is known and healthy.

如果我有一个群集的一个或多个节点处于“运行不正常”状态或关闭状态,是否可以进行升级?If I have a cluster with one or more nodes in an Unhealthy state or shut down, can I perform an upgrade?

否。请删除/移除任何处于故障状态的节点或因为其他原因从群集中移除的节点,然后再进行升级。No, delete/remove any nodes in a failed state or otherwise removed from the cluster prior to upgrading.

我运行了群集删除操作,但出现错误:[Errno 11001] getaddrinfo failedI ran a cluster delete, but see the error [Errno 11001] getaddrinfo failed

这种情况最可能的原因是用户有一个或多个网络安全组 (NSG) 仍在使用并与群集相关联。Most commonly, this is caused by users having one or more Network Security Groups (NSGs) still in use and associated with the cluster. 请将其移除,然后再次尝试删除操作。Remove them and attempt the delete again.

我运行了升级,但现在我的 Pod 处于崩溃循环中,且就绪情况探测失败。I ran an upgrade, but now my pods are in crash loops, and readiness probes fail?

请确认你的服务主体尚未过期。Confirm your service principal hasn't expired. 请参阅:AKS 服务主体AKS 更新凭据See: AKS service principal and AKS update credentials.

我的群集在运行,但突然不能预配 LoadBalancer,不能装载 PVC,等等。My cluster was working, but suddenly can't provision LoadBalancers, mount PVCs, etc.?

请确认你的服务主体尚未过期。Confirm your service principal hasn't expired. 请参阅:AKS 服务主体AKS 更新凭据See: AKS service principal and AKS update credentials.

能否将 AKS 群集缩放为零?Can I scale my AKS cluster to zero?

可以选择将所有的或特定的 User 节点池缩放或自动缩放为 0,以仅维护必要的群集配置。You may choose to scale or autoscale all or specific User node pools to 0, maintaining only the necessary cluster configuration. 你不能直接将系统节点池缩放为零。You can't directly scale system node pools to zero.

是否可以使用虚拟机规模集 API 手动进行缩放?Can I use the virtual machine scale set APIs to scale manually?

否。使用虚拟机规模集 API 进行的缩放操作不受支持。No, scale operations by using the virtual machine scale set APIs aren't supported. 请使用 AKS API (az aks scale)。Use the AKS APIs (az aks scale).

是否可以使用虚拟机规模集手动缩放为 0 个节点?Can I use virtual machine scale sets to manually scale to zero nodes?

否。使用虚拟机规模集 API 进行的缩放操作不受支持。No, scale operations by using the virtual machine scale set APIs aren't supported. 可以使用 AKS API 缩放到零个非系统节点池。You can use the AKS API to scale to zero non-system node pools.

是否可以停止或解除分配我的所有 VM?Can I stop or de-allocate all my VMs?

虽然 AKS 有对抗此类配置并从其恢复的复原机制,但这不是受支持的配置。While AKS has resilience mechanisms to withstand such a config and recover from it, this isn't a supported configuration.

是否可以使用自定义 VM 扩展?Can I use custom VM extensions?

支持 Log Analytics 代理,因为它是由 Azure 管理的扩展。The Log Analytics agent is supported because it's an extension managed by Azure. 在其他情况下不支持。AKS 是一项托管服务,不支持操作 IaaS 资源。Otherwise no, AKS is a managed service, and manipulation of the IaaS resources isn't supported. 若要安装自定义组件,请使用 Kubernetes API 和机制。To install custom components, use the Kubernetes APIs and mechanisms. 例如,使用 DaemonSets 安装所需组件。For example, use DaemonSets to install required components.

AKS 是否将任何客户数据存储在群集区域之外?Does AKS store any customer data outside of the cluster's region?

不是。No. 客户数据存储在异地。customer data is stored in Geo.

AKS 映像是否需要以根用户身份运行?Are AKS images required to run as root?

除了以下两个映像之外,其他 AKS 映像不需要以根用户身份运行:Except for the following two images, AKS images aren't required to run as root:

  • mcr.microsoft.com/oss/kubernetes/corednsmcr.microsoft.com/oss/kubernetes/coredns
  • mcr.microsoft.com/azuremonitor/containerinsights/ciprodmcr.microsoft.com/azuremonitor/containerinsights/ciprod

什么是 Azure CNI 透明模式与桥模式?What is Azure CNI Transparent Mode vs. Bridge Mode?

从 v1.2.0 开始,Azure CNI 会将透明模式作为单租户 Linux CNI 部署的默认模式。From v1.2.0 Azure CNI will have Transparent mode as default for single tenancy Linux CNI deployments. 透明模式将替换桥模式。Transparent mode is replacing bridge mode. 在本部分,我们将详细讨论这两种模式的差异,以及在 Azure CNI 中使用透明模式的优点/限制。In this section, we will discuss more about the differences about both modes and what are the benefits/limitation for using Transparent mode in Azure CNI.

桥模式Bridge mode

顾名思义,桥模式 Azure CNI 会以“实时”方式创建一个名为“azure0”的 L2 桥。As the name suggests, bridge mode Azure CNI, in a "just in time" fashion, will create a L2 bridge named "azure0". 所有主机端 Pod veth 对接口都会连接到此桥。All the host side pod veth pair interfaces will be connected to this bridge. 因此,Pod 到 Pod 内部 VM 通信和其余流量都通过此桥。So Pod-Pod intra VM communication and the remaining traffic goes through this bridge. 所涉及的桥是一个第 2 层虚拟设备,它自己无法接收或传输任何内容,除非你将一个或多个真实设备绑定到该桥。The bridge in question is a layer 2 virtual device that on its own cannot receive or transmit anything unless you bind one or more real devices to it. 因此,Linux VM 的 eth0 必须转换为“azure0”桥的下级。For this reason, eth0 of the Linux VM has to be converted into a subordinate to "azure0" bridge. 这会在 Linux VM 中创建复杂的网络拓扑,一个征兆就是,CNI 必须处理其他网络功能,例如 DNS 服务器更新等。This creates a complex network topology within the Linux VM and as a symptom CNI had to take care of other networking functions like DNS server update and so on.


下面是桥模式下的 IP 路由设置示例。Below is an example of how the ip route setup looks like in Bridge mode. 不管节点有多少个 Pod,都只会有两个路由。Regardless of how many pods the node has, there will only ever be two routes. 第一个路由:azure0 上除本地流量以外的所有流量都将通过 IP 为“src”(即节点主 IP)的接口进入子网的默认网关;第二个路由:从“10.20.x.x”Pod 空间到内核,由内核决定。The first one saying, all traffic excluding local on azure0 will go to the default gateway of the subnet through the interface with ip "src" (which is Node primary IP) and the second one saying "10.20.x.x" Pod space to kernel for kernel to decide.

default via dev azure0 proto dhcp src metric 100 dev azure0 proto kernel scope link src dev docker0 proto kernel scope link src linkdown

透明模式Transparent mode

透明模式采用直截了当的方法来设置 Linux 网络。Transparent mode takes a straight forward approach to setting up Linux networking. 在此模式下,Azure CNI 不会更改 Linux VM 中 eth0 接口的任何属性。In this mode, Azure CNI won't change any properties of eth0 interface in the Linux VM. 这种对 Linux 网络属性更改最少的方法有助于减少群集在桥模式下可能会遇到的复杂极端情况问题。This minimal approach of changing the Linux networking properties helps reduce complex corner case issues that clusters could face with Bridge mode. 在透明模式下,Azure CNI 会创建并添加那些将添加到主机网络的主机端 Pod veth 对接口。In Transparent Mode, Azure CNI will create and add host-side pod veth pair interfaces that will be added to the host network. 内部 VM Pod 到 Pod 通信通过 CNI 会添加的 IP 路由进行。Intra VM Pod-to-Pod communication is through ip routes that the CNI will add. 基本上,Pod 到 Pod 通信通过第 3 层进行,Pod 通信通过 L3 路由规则进行路由。Essentially Pod-to-Pod communication is over layer 3 and pod traffic is routed by L3 routing rules.


下面是透明模式的 IP 路由设置示例,每个 Pod 的接口都会连接一个静态路由,这样,目标 IP 为 Pod 的流量会直接发送到 Pod 的主机端 veth 对接口。Below is an example ip route setup of transparent mode, each Pod's interface will get a static route attached so that traffic with dest IP as the Pod will be sent directly to the Pod's host side veth pair interface. dev azv79d05038592 proto static dev azv8184320e2bf proto static dev azvc0339d223b9 proto static dev azv722a6b28449 proto static dev azve7f326f1507 proto static dev azvb3bfccdd75a proto static via dev eth0 proto dhcp src metric 100 via dev eth0 proto dhcp src metric 100 dev docker0 proto kernel scope link src linkdown

透明模式的优点Benefits of transparent mode

  • 针对 conntrack DNS 并行争用情况提供缓解措施,避免 5 秒 DNS 延迟问题,无需设置节点本地 DNS(出于性能方面的原因,你仍可以使用节点本地 DNS)。Provides mitigation for conntrack DNS parallel race condition and avoidance of 5-sec DNS latency issues without the need to set up node local DNS (you may still use node local DNS for performance reasons).
  • 消除了 CNI 桥模式目前由于“实时”桥设置而引入的最初 5 秒 DNS 延迟。Eliminates the initial 5-sec DNS latency CNI bridge mode introduces today due to "just in time" bridge setup.
  • 桥模式下的极端情况之一是,Azure CNI 无法不断更新用户添加到 VNET 或 NIC 的自定义 DNS 服务器列表。One of the corner cases in bridge mode is that the Azure CNI can't keep updating the custom DNS server lists users add to either VNET or NIC. 这会导致 CNI 仅选取 DNS 服务器列表的第一个实例。This results in the CNI picking up only the first instance of the DNS server list. 此问题在透明模式下得到解决,因为 CNI 不更改任何 eth0 属性。Solved in Transparent mode as CNI doesn't change any eth0 properties. 此处了解详细信息。See more here.
  • 提供了更好的 UDP 流量处理,并且在 ARP 超时时可以缓解 UDP 数据风暴。在桥模式下,当桥在 VM 内部 Pod 到 Pod 通信中不知道目标 Pod 的 MAC 地址时,按照设计,这会导致所有端口都出现数据包风暴。Provides better handling of UDP traffic and mitigation for UDP flood storm when ARP times out. In bridge mode, when bridge doesn't know a MAC address of destination pod in intra-VM Pod-to-Pod communication, by design, this results in storm of the packet to all ports. 此问题在透明模式下得到解决,因为路径中没有 L2 设备。Solved in Transparent mode as there are no L2 devices in path. 此处了解详细信息。See more here.
  • 与桥模式相比,在内部 VM Pod 到 Pod 通信中,透明模式在吞吐量和延迟方面的性能更佳。Transparent mode performs better in Intra VM Pod-to-Pod communication in terms of throughput and latency when compared to bridge mode.

当卷中有很多文件时,如何避免权限所有权设置缓慢问题?How to avoid permission ownership setting slow issues when the volume has a lot of files?

通常情况下,如果 Pod 以非根用户(应为根用户)身份运行,则必须在 Pod 的安全上下文中指定一个 fsGroup,才能使该卷可供 Pod 读取和写入。Traditionally if your pod is running as a non-root user (which you should), you must specify a fsGroup inside the pod's security context so that the volume can be readable and writable by the Pod. 此处将更详细地介绍此要求。This requirement is covered in more detail in here.

但是设置 fsGroup 的一个影响是,每次装载卷时,Kubernetes 都必须通过 chown()chmod() 递归卷内的所有文件和目录(下面提到的一些情况例外)。But one side-effect of setting fsGroup is that, each time a volume is mounted, Kubernetes must recursively chown() and chmod() all the files and directories inside the volume - with a few exceptions noted below. 即使卷的组所有权已经与请求的 fsGroup 匹配,也会发生这种情况,而对于包含大量小文件的较大卷来说,价格可能会非常高昂,这会导致 Pod 需要花费很长时间才能启动。This happens even if group ownership of the volume already matches the requested fsGroup, and can be pretty expensive for larger volumes with lots of small files, which causes pod startup to take a long time. 在 v1.20 之前,这种情况是一个已知问题,解决方法是将 Pod 设置为以根用户身份运行:This scenario has been a known problem before v1.20 and the workaround is setting the Pod run as root:

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

此问题已由 Kubernetes v1.20 解决,有关详细信息,请参阅 Kubernetes 1.20:批量许可更改的粒度控制The issue has been resolved by Kubernetes v1.20, refer Kubernetes 1.20: Granular Control of Volume Permission Changes for more details.