Vanliga frågor om Azure Kubernetes Service (AKS)Frequently asked questions about Azure Kubernetes Service (AKS)

Den här artikeln behandlar vanliga frågor om Azure Kubernetes service (AKS).This article addresses frequent questions about Azure Kubernetes Service (AKS).

Vilka Azure-regioner tillhandahåller AKS för närvarande?Which Azure regions currently provide AKS?

En fullständig lista över tillgängliga regioner finns i AKS regioner och tillgänglighet.For a complete list of available regions, see AKS regions and availability.

Kan jag sprida ett AKS-kluster över flera regioner?Can I spread an AKS cluster across regions?

Nej.No. AKS-kluster är regionala resurser och kan inte omfatta regioner.AKS clusters are regional resources and can't span regions. Se metod tips för verksamhets kontinuitet och haveri beredskap för vägledning om hur du skapar en arkitektur som innehåller flera regioner.See best practices for business continuity and disaster recovery for guidance on how to create an architecture that includes multiple regions.

Kan jag sprida ett AKS-kluster mellan tillgänglighets zoner?Can I spread an AKS cluster across availability zones?

Ja.Yes. Du kan distribuera ett AKS-kluster över en eller flera tillgänglighets zoner i regioner som stöder dem.You can deploy an AKS cluster across one or more availability zones in regions that support them.

Kan jag begränsa vem som har åtkomst till Kubernetes API-servern?Can I limit who has access to the Kubernetes API server?

Ja.Yes. Det finns två alternativ för att begränsa åtkomsten till API-servern:There are two options for limiting access to the API server:

  • Använd tillåtna IP-intervall för API-Server om du vill behålla en offentlig slut punkt för API-servern men begränsa åtkomsten till en uppsättning betrodda IP-intervall.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.
  • Använd ett privat kluster om du vill begränsa API-servern till att endast vara tillgänglig från det virtuella nätverket.Use a private cluster if you want to limit the API server to only be accessible from within your virtual network.

Kan jag ha olika storlekar på virtuella datorer i ett enda kluster?Can I have different VM sizes in a single cluster?

Ja, du kan använda olika storlekar för virtuella datorer i AKS-klustret genom att skapa flera noder.Yes, you can use different virtual machine sizes in your AKS cluster by creating multiple node pools.

Används säkerhets uppdateringar för AKS-agent-noder?Are security updates applied to AKS agent nodes?

Azure tillämpar automatiskt säkerhets korrigeringar på Linux-noderna i klustret enligt ett natt schema.Azure automatically applies security patches to the Linux nodes in your cluster on a nightly schedule. Men du är ansvarig för att se till att de Linux-noderna startas om efter behov.However, you're responsible for ensuring that those Linux nodes are rebooted as required. Du har flera alternativ för att starta om noder:You have several options for rebooting nodes:

Windows Server-noderWindows Server nodes

För Windows Server-noder körs Windows Update inte automatiskt och tillämpar de senaste uppdateringarna.For Windows Server nodes, Windows Update does not automatically run and apply the latest updates. I ett reguljärt schema kring Windows Updates lanserings cykel och din egen verifierings process bör du utföra en uppgradering på klustret och Windows Server-pool (er) i ditt AKS-kluster.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. Den här uppgraderings processen skapar noder som kör den senaste Windows Server-avbildningen och uppdateringar och tar sedan bort de äldre noderna.This upgrade process creates nodes that run the latest Windows Server image and patches, then removes the older nodes. Mer information om den här processen finns i uppgradera en Node-pool i AKS.For more information on this process, see Upgrade a node pool in AKS.

Varför skapas två resurs grupper med AKS?Why are two resource groups created with AKS?

AKS bygger på ett antal Azure-infrastruktur resurser, inklusive skalnings uppsättningar för virtuella datorer, virtuella nätverk och hanterade diskar.AKS builds upon a number of Azure infrastructure resources, including virtual machine scale sets, virtual networks, and managed disks. På så sätt kan du utnyttja många av kärn funktionerna i Azure-plattformen i den hanterade Kubernetes-miljön som tillhandahålls av AKS.This enables you to leverage many of the core capabilities of the Azure platform within the managed Kubernetes environment provided by AKS. De flesta typer av virtuella Azure-datorer kan till exempel användas direkt med AKS och Azure Reservations kan användas för att ta emot rabatter på dessa resurser automatiskt.For example, most Azure virtual machine types can be used directly with AKS and Azure Reservations can be used to receive discounts on those resources automatically.

För att aktivera den här arkitekturen omfattar varje AKS-distribution två resurs grupper:To enable this architecture, each AKS deployment spans two resource groups:

  1. Du skapar den första resurs gruppen.You create the first resource group. Den här gruppen innehåller endast Kubernetes-Tjänsteresursen.This group contains only the Kubernetes service resource. AKS Resource Provider skapar automatiskt den andra resurs gruppen under distributionen.The AKS resource provider automatically creates the second resource group during deployment. Ett exempel på den andra resurs gruppen är MC_myResourceGroup_myAKSCluster_eastus.An example of the second resource group is MC_myResourceGroup_myAKSCluster_eastus. Information om hur du anger namnet på den här andra resurs gruppen finns i nästa avsnitt.For information on how to specify the name of this second resource group, see the next section.
  2. Den andra resurs gruppen, som kallas resurs gruppen för noden, innehåller alla infrastruktur resurser som är associerade med klustret.The second resource group, known as the node resource group, contains all of the infrastructure resources associated with the cluster. Dessa resurser omfattar Kubernetes-nodens virtuella datorer, virtuella nätverk och lagring.These resources include the Kubernetes node VMs, virtual networking, and storage. Som standard har resurs gruppen ett namn som MC_myResourceGroup_myAKSCluster_eastus.By default, the node resource group has a name like MC_myResourceGroup_myAKSCluster_eastus. AKS tar automatiskt bort nodens resurs när klustret tas bort, så den bör endast användas för resurser som delar klustrets livs cykel.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.

Kan jag ange mitt eget namn för AKS-nodens resurs grupp?Can I provide my own name for the AKS node resource group?

Ja.Yes. Som standard namnger AKS resurs MC_resourcegroupname_clustername_location gruppen för noden, men du kan också ange ett eget namn.By default, AKS will name the node resource group MC_resourcegroupname_clustername_location, but you can also provide your own name.

Om du vill ange ett eget namn på en resurs grupp installerar du AKS-Preview Azure CLI-tillägget version 0.3.2 eller senare.To specify your own resource group name, install the aks-preview Azure CLI extension version 0.3.2 or later. När du skapar ett AKS-kluster med hjälp av kommandot AZ AKS Create använder du --node-resource-group parametern och anger ett namn för resurs gruppen.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. Om du använder en Azure Resource Manager-mall för att distribuera ett AKS-kluster kan du definiera resurs gruppens namn genom att använda egenskapen 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.

  • Den sekundära resurs gruppen skapas automatiskt av Azure Resource Provider i din egen prenumeration.The secondary resource group is automatically created by the Azure resource provider in your own subscription.
  • Du kan bara ange ett namn på en anpassad resurs grupp när du skapar klustret.You can specify a custom resource group name only when you're creating the cluster.

När du arbetar med resurs gruppen för noden bör du tänka på att du inte kan:As you work with the node resource group, keep in mind that you can't:

  • Ange en befintlig resurs grupp för resurs gruppen för noden.Specify an existing resource group for the node resource group.
  • Ange en annan prenumeration för resurs gruppen för noden.Specify a different subscription for the node resource group.
  • Ändra resurs grupp namnet för noden när klustret har skapats.Change the node resource group name after the cluster has been created.
  • Ange namn för de hanterade resurserna i resurs gruppen för noden.Specify names for the managed resources within the node resource group.
  • Ändra eller ta bort Azure-skapade Taggar av hanterade resurser i resurs gruppen för noden.Modify or delete Azure-created tags of managed resources within the node resource group. (Mer information finns i nästa avsnitt.)(See additional information in the next section.)

Kan jag ändra Taggar och andra egenskaper för AKS-resurserna i nodens resurs grupp?Can I modify tags and other properties of the AKS resources in the node resource group?

Om du ändrar eller tar bort Azure-skapade Taggar och andra resurs egenskaper i resurs gruppen resurs kan du få oväntade resultat som skalning och uppgradering av fel.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. Med AKS kan du skapa och ändra anpassade taggar som skapats av slutanvändarna och du kan lägga till dessa taggar när du skapar en Node-pool.AKS allows you to create and modify custom tags created by end users, and you can add those tags when creating a node pool. Du kanske vill skapa eller ändra anpassade taggar, till exempel för att tilldela en affär senhet eller ett kostnads ställe.You might want to create or modify custom tags, for example, to assign a business unit or cost center. Detta kan också uppnås genom att du skapar Azure-principer med ett omfång i den hanterade resurs gruppen.This can also be achieved by creating Azure Policies with a scope on the managed resource group.

Att ändra alla Azure-skapade Taggar för resurser under nodens resurs grupp i AKS-klustret är dock en åtgärd som inte stöds, vilket bryter service nivå målet (service nivå mål).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). Mer information finns i AKS erbjuder ett service nivå avtal?For more information, see Does AKS offer a service-level agreement?

Vilka Kubernetes-kontrollanter stöder AKS?What Kubernetes admission controllers does AKS support? Kan åtkomst kontrol Lanterna läggas till eller tas bort?Can admission controllers be added or removed?

AKS stöder följande styrenheter för åtkomstkontroll:AKS supports the following admission controllers:

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

För närvarande kan du inte ändra listan över åtkomst kontrol listor i AKS.Currently, you can't modify the list of admission controllers in AKS.

Kan jag använda Webhooks för Admission Controller på AKS?Can I use admission controller webhooks on AKS?

Ja, du kan använda Webhooks för Admission Controller på AKS.Yes, you may use admission controller webhooks on AKS. Vi rekommenderar att du exkluderar interna AKS-namnområden, som är markerade med kontroll Plans etiketten.It's recommended you exclude internal AKS namespaces, which are marked with the control-plane label. Till exempel genom att lägga till följande i webhook-konfigurationen:For example, by adding the below to the webhook configuration:

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

AKS-brandväggar att API-servern utfaller så att dina åtkomst kontrolls-webhookar måste vara tillgängliga i klustret.AKS firewalls the API server egress so your admission controller webhooks need to be accessible from within the cluster.

Kan inspelade Webhooks påverkar Kube-system och interna AKS-namnområden?Can admission controller webhooks impact kube-system and internal AKS namespaces?

För att skydda systemets stabilitet och förhindra att anpassade kontroll enheter påverkar de interna tjänsterna i Kube-systemet, har namn området AKS en- tvång, som automatiskt undantar Kube-system och AKS interna namn områden.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. Den här tjänsten säkerställer att de anpassade åtkomst kontrol Lanterna inte påverkar de tjänster som körs i Kube-system.This service ensures the custom admission controllers don't affect the services running in kube-system.

Om du har ett kritiskt användnings fall där något har distribuerats på Kube (rekommenderas inte) som du behöver omfattas av din anpassade-webhook, kan du lägga till nedanstående etikett eller antecknings anteckning så att inträde-tvång ignorerar den.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.

Etikett: "admissions.enforcer/disabled": "true" eller anteckning: "admissions.enforcer/disabled": trueLabel: "admissions.enforcer/disabled": "true" or Annotation: "admissions.enforcer/disabled": true

Är Azure Key Vault integrerat med AKS?Is Azure Key Vault integrated with AKS?

AKS är för närvarande inte inbyggt i Azure Key Vault.AKS isn't currently natively integrated with Azure Key Vault. Azure Key Vault leverantören för CSI hemligheter-butiken gör det dock möjligt att direkt integrera från Kubernetes poddar till Key Vault hemligheter.However, the Azure Key Vault provider for CSI Secrets Store enables direct integration from Kubernetes pods to Key Vault secrets.

Kan jag köra Windows Server-behållare på AKS?Can I run Windows Server containers on AKS?

Ja, Windows Server-behållare finns på AKS.Yes, Windows Server containers are available on AKS. Om du vill köra Windows Server-behållare i AKS skapar du en resurspool som kör Windows Server som gäst operativ system.To run Windows Server containers in AKS, you create a node pool that runs Windows Server as the guest OS. Windows Server-behållare kan endast använda Windows Server 2019.Windows Server containers can use only Windows Server 2019. Information om hur du kommer igång finns i skapa ett AKS-kluster med en pool för Windows Server-noder.To get started, see Create an AKS cluster with a Windows Server node pool.

Windows Server-stöd för Node-pool innehåller vissa begränsningar som ingår i den överordnade Windows Server i Kubernetes-projektet.Windows Server support for node pool includes some limitations that are part of the upstream Windows Server in Kubernetes project. Mer information om dessa begränsningar finns i Windows Server-behållare i AKS-begränsningar.For more information on these limitations, see Windows Server containers in AKS limitations.

Erbjuder AKS ett service nivå avtal?Does AKS offer a service-level agreement?

AKS tillhandahåller SLA-garantier som en valfri tilläggs funktion med SLA för drift tid.AKS provides SLA guarantees as an optional add-on feature with Uptime SLA.

Kan jag använda Azure reservation-rabatter på mina AKS-agent-noder?Can I apply Azure reservation discounts to my AKS agent nodes?

AKS agent-noder faktureras som standard virtuella Azure-datorer, så om du har köpt Azure-reservationer för den VM-storlek som du använder i AKS tillämpas dessa rabatter automatiskt.AKS agent nodes are billed as standard Azure virtual machines, so if you've purchased Azure reservations for the VM size that you're using in AKS, those discounts are automatically applied.

Kan jag flytta/migrera mitt kluster mellan Azure-klienter?Can I move/migrate my cluster between Azure tenants?

Det finns för närvarande inte stöd för att flytta AKS-kluster mellan klient organisationer.Moving your AKS cluster between tenants is currently unsupported.

Kan jag flytta/migrera mitt kluster mellan prenumerationer?Can I move/migrate my cluster between subscriptions?

Det finns för närvarande inte stöd för att flytta kluster mellan prenumerationer.Movement of clusters between subscriptions is currently unsupported.

Kan jag flytta mina AKS-kluster från den aktuella Azure-prenumerationen till en annan?Can I move my AKS clusters from the current Azure subscription to another?

Det finns inte stöd för att flytta AKS-klustret och dess associerade resurser mellan Azure-prenumerationer.Moving your AKS cluster and its associated resources between Azure subscriptions isn't supported.

Kan jag flytta mitt AKS-kluster eller AKS-infrastruktur resurser till andra resurs grupper eller byta namn på dem?Can I move my AKS cluster or AKS infrastructure resources to other resource groups or rename them?

Det finns inte stöd för att flytta eller byta namn på ditt AKS-kluster och dess associerade resurser.Moving or renaming your AKS cluster and its associated resources isn't supported.

Varför tar min kluster borttagning att ta lång tid?Why is my cluster delete taking so long?

De flesta kluster tas bort vid användar förfrågan. i vissa fall, särskilt när kunder tar emot sin egen resurs grupp, eller om du utför RG uppgifter kan borttagningen ta ytterligare tid eller misslyckande.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. Om du har problem med borttagningarna måste du kontrol lera att du inte har lås på RG, att alla resurser utanför RG är kopplade till RG och så vidare.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.

Om jag har Pod/distributioner i status "NodeLost" eller "okänd" kan jag fortfarande uppgradera mitt kluster?If I have pod / deployments in state 'NodeLost' or 'Unknown' can I still upgrade my cluster?

Du kan, men AKS rekommenderar inte detta.You can, but AKS doesn't recommend this. Uppgraderingar bör utföras när kluster tillståndet är känt och felfritt.Upgrades should be performed when the state of the cluster is known and healthy.

Kan jag utföra en uppgradering om jag har ett kluster med en eller flera noder i ett ohälsosamt tillstånd eller stänger av?If I have a cluster with one or more nodes in an Unhealthy state or shut down, can I perform an upgrade?

Nej, ta bort/ta bort alla noder i ett felaktigt tillstånd eller ta bort dem från klustret innan du uppgraderar.No, delete/remove any nodes in a failed state or otherwise removed from the cluster prior to upgrading.

Jag har kört ett kluster borttagnings fel men ser felet [Errno 11001] getaddrinfo failedI ran a cluster delete, but see the error [Errno 11001] getaddrinfo failed

Oftast orsakas detta av användare som har en eller flera nätverks säkerhets grupper (NSG: er) som fortfarande används och som är kopplade till klustret.Most commonly, this is caused by users having one or more Network Security Groups (NSGs) still in use and associated with the cluster. Ta bort dem och försök att ta bort dem igen.Remove them and attempt the delete again.

Jag körde en uppgradering, men nu finns det poddar i krascher och det går inte att söka efter beredskap?I ran an upgrade, but now my pods are in crash loops, and readiness probes fail?

Bekräfta att tjänstens huvud namn inte har upphört att gälla.Confirm your service principal hasn't expired. Se: AKS-tjänstens huvud namn och AKS uppdatera autentiseringsuppgifter.See: AKS service principal and AKS update credentials.

Mitt kluster fungerade men det går inte att etablera belastningsutjämnare, montera PVC: er osv.My cluster was working, but suddenly can't provision LoadBalancers, mount PVCs, etc.?

Bekräfta att tjänstens huvud namn inte har upphört att gälla.Confirm your service principal hasn't expired. Se: AKS-tjänstens huvud namn och AKS uppdatera autentiseringsuppgifter.See: AKS service principal and AKS update credentials.

Kan jag skala mitt AKS-kluster till noll?Can I scale my AKS cluster to zero?

Du kan helt stoppa ett pågående AKS-klusteroch Spara på respektive beräknings kostnader.You can completely stop a running AKS cluster, saving on the respective compute costs. Dessutom kan du också välja att skala eller Autoskala alla eller vissa User resurspooler till 0, och endast underhålla den nödvändiga kluster konfigurationen.Additionally, you may also choose to scale or autoscale all or specific User node pools to 0, maintaining only the necessary cluster configuration. Du kan inte skala system-nodkonfigurationer direkt till noll.You can't directly scale system node pools to zero.

Kan jag använda API: erna för skalnings uppsättningen för virtuella datorer för att skala manuellt?Can I use the virtual machine scale set APIs to scale manually?

Nej, skalnings åtgärder med hjälp av API: er för skalnings uppsättningen för virtuella datorer stöds inte.No, scale operations by using the virtual machine scale set APIs aren't supported. Använd AKS-API: er ( az aks scale ).Use the AKS APIs (az aks scale).

Kan jag använda skalnings uppsättningar för virtuella datorer för att manuellt skala till noll noder?Can I use virtual machine scale sets to manually scale to zero nodes?

Nej, skalnings åtgärder med hjälp av API: er för skalnings uppsättningen för virtuella datorer stöds inte.No, scale operations by using the virtual machine scale set APIs aren't supported. Du kan använda AKS-API: et för att skala till noll pooler för icke-system eller stoppa klustret i stället.You can use the AKS API to scale to zero non-system node pools or stop your cluster instead.

Kan jag stoppa eller ta bort alla mina virtuella datorer?Can I stop or de-allocate all my VMs?

Även om AKS har återhämtnings metoder för att motstå en sådan konfiguration och återställa från den, är detta inte en konfiguration som stöds.While AKS has resilience mechanisms to withstand such a config and recover from it, this isn't a supported configuration. Stoppa klustret i stället.Stop your cluster instead.

Kan jag använda anpassade VM-tillägg?Can I use custom VM extensions?

Log Analytics agent stöds eftersom det är ett tillägg som hanteras av Microsoft.The Log Analytics agent is supported because it's an extension managed by Microsoft. Annars är inte AKS en hanterad tjänst och manipulering av IaaS-resurser stöds inte.Otherwise no, AKS is a managed service, and manipulation of the IaaS resources isn't supported. Om du vill installera anpassade komponenter använder du Kubernetes-API: er och mekanismer.To install custom components, use the Kubernetes APIs and mechanisms. Använd till exempel DaemonSets för att installera nödvändiga komponenter.For example, use DaemonSets to install required components.

Lagrar AKS kund information utanför klustrets region?Does AKS store any customer data outside of the cluster's region?

Funktionen för att aktivera lagring av kund information i en enda region är för närvarande bara tillgänglig i Sydostasien region (Singapore) för Asien och stillahavsområdet geo.The feature to enable storing customer data in a single region is currently only available in the Southeast Asia Region (Singapore) of the Asia Pacific Geo. För alla andra regioner lagras kund information på Geo.For all other regions, customer data is stored in Geo.

Krävs AKS-avbildningar för att köras som rot?Are AKS images required to run as root?

Förutom följande två avbildningar krävs inte AKS-avbildningar för att köras som rot: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

Vad är ett transparent läge i Azure CNI jämfört med Bridge-läge?What is Azure CNI Transparent Mode vs. Bridge Mode?

Från v 1.2.0 Azure CNI har transparent läge som standard för enskilda innehav Linux CNI-distributioner.From v1.2.0 Azure CNI will have Transparent mode as default for single tenancy Linux CNI deployments. Transparent läge ersätter Bridge-läge.Transparent mode is replacing bridge mode. I det här avsnittet ska vi diskutera mer om skillnaderna mellan båda lägena och vilka är fördelarna/begränsningarna med genomskinligt läge i 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-lägeBridge mode

Som namnet antyder skapar Bridge-läget Azure-CNI, i en "just-Time-Time", en L2-brygga med namnet "azure0".As the name suggests, bridge mode Azure CNI, in a "just in time" fashion, will create a L2 bridge named "azure0". Alla värd sidans Pod veth par-gränssnitt kommer att anslutas till den här bryggan.All the host side pod veth pair interfaces will be connected to this bridge. Så Pod-Pod intra VM-kommunikation och återstående trafik går genom den här bryggan.So Pod-Pod intra VM communication and the remaining traffic goes through this bridge. Bryggan i fråga är en virtuell Layer 2-enhet som inte kan ta emot eller överföra något om du inte binder en eller flera riktiga enheter till den.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. Därför måste eth0 för den virtuella Linux-datorn konverteras till en underordnad "azure0"-brygga.For this reason, eth0 of the Linux VM has to be converted into a subordinate to "azure0" bridge. Detta skapar en komplex nätverkstopologi i den virtuella Linux-datorn och som en symptom-CNI behövde ta hand om andra nätverksfunktioner som DNS-Server uppdatering och så vidare.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.

Topologi för brygga läge

Nedan visas ett exempel på hur IP-väg installationen ser ut i Bridge-läge.Below is an example of how the ip route setup looks like in Bridge mode. Oavsett hur många poddar noden har finns det bara två vägar.Regardless of how many pods the node has, there will only ever be two routes. Det första som säger, all trafik exklusive lokal på azure0 kommer att gå till standard-gatewayen för under nätet via gränssnittet med IP "src 10.240.0.4" (som är primär IP-adress) och den andra som säger "10.20. x. x" Pod utrymme till kernel för att kernel ska kunna avgöra.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 10.240.0.4" (which is Node primary IP) and the second one saying "10.20.x.x" Pod space to kernel for kernel to decide.

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:/#

Transparent lägeTransparent mode

Transparent läge tar en rak metod för att konfigurera Linux-nätverk.Transparent mode takes a straight forward approach to setting up Linux networking. I det här läget ändrar inte Azure-CNI några egenskaper för eth0-gränssnittet i den virtuella Linux-datorn.In this mode, Azure CNI won't change any properties of eth0 interface in the Linux VM. Den här minimala metoden för att ändra egenskaperna för Linux-nätverk hjälper till att minska problem med komplexa hörn fall som kluster kan riktas mot Bridge-läge.This minimal approach of changing the Linux networking properties helps reduce complex corner case issues that clusters could face with Bridge mode. I transparent läge skapar Azure-CNI och lägger till Pod-adresspar på värd sidan veth som läggs till i värd nätverket.In Transparent Mode, Azure CNI will create and add host-side pod veth pair interfaces that will be added to the host network. Intra VM Pod-to-Pod-kommunikation sker via IP-vägar som CNI ska lägga till.Intra VM Pod-to-Pod communication is through ip routes that the CNI will add. I stort sett Pod-till-Pod-kommunikationen är över Layer 3 och Pod-trafiken dirigeras av L3-routningsregler.Essentially Pod-to-Pod communication is over layer 3 and pod traffic is routed by L3 routing rules.

Topologi för transparent läge

Nedan visas ett exempel på en IP Route-installation av transparent läge, varje Pod-gränssnitt kommer att få en statisk väg ansluten så att trafik med mål-IP-adress som Pod skickas direkt till Pod värdens veth gränssnitts gränssnitt.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.

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

Förmåner för genomskinligt lägeBenefits of transparent mode

  • Ger en minskning conntrack av DNS-parallellt konkurrens villkor och undvikande av 5-sec problem med DNS-latens utan att behöva konfigurera en lokal DNS-DNS-svars tid (du kan fortfarande använda lokala DNS-noder för prestanda skäl).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).
  • Eliminerar det inledande 5-s DNS-latens CNI Bridge-läget i dag på grund av "just-in-Time"-installationen.Eliminates the initial 5-sec DNS latency CNI bridge mode introduces today due to "just in time" bridge setup.
  • Ett av hörn fallen i Bridge-läge är att Azure-CNI inte kan fortsätta uppdatera den anpassade DNS-servern som visar användare som ska läggas till i VNET eller NIC.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. Detta resulterar i att CNI-plockningen bara är den första instansen av listan DNS-server.This results in the CNI picking up only the first instance of the DNS server list. Löst i transparent läge eftersom CNI inte ändrar några eth0-egenskaper.Solved in Transparent mode as CNI doesn't change any eth0 properties. Läs mer här.See more here.
  • Ger bättre hantering av UDP-trafik och minskning av UDP-dataöversvämmade Storm när ARP-timeout. I Bridge-läge, när Bridge inte känner till en MAC-adress för mål Pod i pod-till-Pod-kommunikation i flera virtuella datorer, resulterar detta i storm av paketet på alla portar.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. Löst i transparent läge eftersom det inte finns några L2-enheter i sökvägen.Solved in Transparent mode as there are no L2 devices in path. Läs mer här.See more here.
  • Transparent läge fungerar bättre i intra VM Pod-to-Pod-kommunikation med avseende på data flöde och svars tid jämfört med Bridge-läge.Transparent mode performs better in Intra VM Pod-to-Pod communication in terms of throughput and latency when compared to bridge mode.

Hur undviker du behörighets ägande inställningen långsamma problem när volymen har många filer?How to avoid permission ownership setting slow issues when the volume has a lot of files?

Traditionellt om din POD körs som en icke-rotkatalog (som du bör) måste du ange en fsGroup i säkerhets kontexten för Pod så att volymen kan läsas och skrivas av 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. Detta krav beskrivs mer detaljerat här.This requirement is covered in more detail in here.

Men en sida-effekt fsGroup är att när en volym monteras måste Kubernetes rekursivt chown() och chmod() alla filer och kataloger i volymen – med några undantag anges nedan.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. Detta inträffar även om grupp ägarskapet för volymen redan matchar begärd fsGroup , och det kan vara dyrt för större volymer med många små filer, vilket gör att Pod-starten tar lång tid.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. Det här scenariot har varit ett känt problem före v-1.20 och lösningen ställer in Pod kör som-roten:This scenario has been a known problem before v1.20 and the workaround is setting the Pod run as root:

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

Problemet har lösts av Kubernetes v 1.20, se Kubernetes 1,20: detaljerad kontroll av volym behörighets ändringar för mer information.The issue has been resolved by Kubernetes v1.20, refer Kubernetes 1.20: Granular Control of Volume Permission Changes for more details.