Delen via

Veelgestelde vragen over AKS (Azure Kubernetes Service)

  • Artikel

In dit artikel worden veelgestelde vragen over AKS (Azure Kubernetes Service) behandeld.

Welke Azure-regio's bieden momenteel AKS?

Zie AKS-regio's en beschikbaarheid voor een volledige lijst met beschikbare regio's.

Kan ik een AKS-cluster over regio's verdelen?

Nee AKS-clusters zijn regionale resources en kunnen geen regio's omvatten. Zie best practices voor bedrijfscontinuïteit en herstel na noodgevallen voor hulp bij het maken van een architectuur met meerdere regio's.

Kan ik een AKS-cluster verspreiden over beschikbaarheidszones?

Ja. U kunt een AKS-cluster implementeren in een of meer beschikbaarheidszones in regio's die deze ondersteunen.

Kan ik beperken wie toegang heeft tot de Kubernetes API-server?

Ja. Er zijn twee opties voor het beperken van de toegang tot de API-server:

  • Gebruik geautoriseerde IP-bereiken van API Server als u een openbaar eindpunt voor de API-server wilt onderhouden, maar de toegang tot een set vertrouwde IP-bereiken wilt beperken.
  • Gebruik een privécluster als u wilt beperken dat de API-server alleen toegankelijk is vanuit uw virtuele netwerk.

Kan ik verschillende VM-grootten in één cluster hebben?

Ja, u kunt verschillende grootten van virtuele machines in uw AKS-cluster gebruiken door meerdere knooppuntgroepen te maken.

Worden beveiligingsupdates toegepast op AKS-agentknooppunten?

AKS patches CV's die elke week een 'leverancieroplossing' hebben. CV's zonder een oplossing wachten op een 'leverancieroplossing' voordat deze kan worden hersteld. De AKS-installatiekopieën worden binnen 30 dagen automatisch bijgewerkt. U wordt aangeraden een bijgewerkte knooppuntinstallatiekopie regelmatig toe te passen om ervoor te zorgen dat de meest recente patchinstallatiekopieën en besturingssysteempatches allemaal worden toegepast en actueel zijn. U kunt dit doen met een van de volgende methoden:

  • Handmatig, via De Azure-portal of de Azure CLI.
  • Door uw AKS-cluster te upgraden. Het cluster werkt cordon- en drain-knooppunten automatisch bij en brengt vervolgens een nieuw knooppunt online met de nieuwste Ubuntu-installatiekopie en een nieuwe patchversie of een secundaire Kubernetes-versie. Zie Een AKS-cluster upgraden voor meer informatie.
  • Door de upgrade van de knooppuntinstallatiekopieën te gebruiken.

Wat is de groottelimiet voor een containerinstallatiekopieën in AKS?

AKS stelt geen limiet in voor de grootte van de containerinstallatiekopieën. Het is echter belangrijk om te begrijpen dat hoe groter de afbeelding, hoe hoger de vraag naar geheugen. Een grotere grootte kan mogelijk de resourcelimieten overschrijden of het totale beschikbare geheugen van werkknooppunten. Standaard is geheugen voor VM-grootte Standard_DS2_v2 voor een AKS-cluster ingesteld op 7 GiB.

Wanneer een containerinstallatiekopie te groot is, zoals in het bereik Van Terabyte (TB's), kan kubelet deze mogelijk niet ophalen uit het containerregister naar een knooppunt vanwege onvoldoende schijfruimte.

Windows Server-knooppunten

Voor Windows Server-knooppunten wordt Windows Update niet automatisch uitgevoerd en worden de meest recente updates toegepast. Volgens een regelmatig schema rond de releasecyclus van Windows Update en uw eigen validatieproces moet u een upgrade uitvoeren op het cluster en de Windows Server-knooppuntgroep(en) in uw AKS-cluster. Met dit upgradeproces worden knooppunten gemaakt waarop de meest recente Windows Server-installatiekopieën en patches worden uitgevoerd, waarna de oudere knooppunten worden verwijderd. Zie Een knooppuntgroep upgraden in AKS voor meer informatie over dit proces.

Zijn er beveiligingsrisico's gericht op AKS waar ik rekening mee moet houden?

Microsoft biedt richtlijnen voor andere acties die u kunt ondernemen om uw workloads te beveiligen via services zoals Microsoft Defender for Containers. De volgende beveiligingsrisico's zijn gerelateerd aan AKS en Kubernetes waarvan u rekening moet houden:

Hoe communiceert het beheerde besturingsvlak met mijn knooppunten?

AKS maakt gebruik van een beveiligde tunnelcommunicatie om de kubelets van de API-server en afzonderlijke knooppunten te laten communiceren, zelfs op afzonderlijke virtuele netwerken. De tunnel wordt beveiligd via mTLS-versleuteling. De huidige hoofdtunnel die door AKS wordt gebruikt, is Konnectivity, voorheen bekend als apiserver-network-proxy. Controleer of alle netwerkregels voldoen aan de vereiste netwerkregels en FQDN's van Azure.

Kunnen mijn pods de FQDN van de API-server gebruiken in plaats van het IP-adres van het cluster?

Ja, u kunt de aantekening kubernetes.azure.com/set-kube-service-host-fqdn toevoegen aan pods om de KUBERNETES_SERVICE_HOST variabele in te stellen op de domeinnaam van de API-server in plaats van het IP-adres van de in-clusterservice. Dit is handig in gevallen waarin het uitgaand verkeer van uw cluster wordt uitgevoerd via een firewall van laag 7, zoals bij het gebruik van Azure Firewall met toepassingsregels.

Waarom worden twee resourcegroepen gemaakt met AKS?

AKS bouwt voort op veel Azure-infrastructuurbronnen, waaronder Virtuele-machineschaalsets, virtuele netwerken en beheerde schijven. Met deze integraties kunt u veel van de kernmogelijkheden van het Azure-platform toepassen binnen de beheerde Kubernetes-omgeving die wordt geleverd door AKS. De meeste typen virtuele Azure-machines kunnen bijvoorbeeld rechtstreeks worden gebruikt met AKS en Azure-reserveringen kunnen worden gebruikt om automatisch kortingen op deze resources te ontvangen.

Als u deze architectuur wilt inschakelen, omvat elke AKS-implementatie twee resourcegroepen:

  1. U maakt de eerste resourcegroep. Deze groep bevat alleen de Kubernetes-serviceresource. De AKS-resourceprovider maakt automatisch de tweede resourcegroep tijdens de implementatie. Een voorbeeld van de tweede resourcegroep is MC_myResourceGroup_myAKSCluster_eastus. Zie de volgende sectie voor informatie over het opgeven van de naam van deze tweede resourcegroep.

  2. De tweede resourcegroep, ook wel de knooppuntresourcegroep genoemd, bevat alle infrastructuurresources die aan het cluster zijn gekoppeld. Deze resources omvatten de Kubernetes-knooppunt-VM's, virtuele netwerken en opslag. De resourcegroep van het knooppunt heeft standaard een naam zoals MC_myResourceGroup_myAKSCluster_eastus. AKS verwijdert automatisch de knooppuntresourcegroep wanneer u het cluster verwijdert. U moet dit cluster alleen gebruiken voor resources die de levenscyclus van het cluster delen.

    Notitie

    Het wijzigen van een resource onder de knooppuntresourcegroep in het AKS-cluster is een niet-ondersteunde actie en veroorzaakt fouten in de clusterbewerking. U kunt voorkomen dat wijzigingen worden aangebracht in de knooppuntresourcegroep door te blokkeren dat gebruikers resources wijzigen die worden beheerd door het AKS-cluster.

Kan ik mijn eigen naam opgeven voor de AKS-knooppuntresourcegroep?

Ja. AKS noemt standaard de resourcegroep van het knooppunt MC_resourcegroupname_clustername_location, maar u kunt ook uw eigen naam opgeven.

Als u de naam van uw eigen resourcegroep wilt opgeven, installeert u de Azure CLI-extensie aks-preview versie 0.3.2 of hoger. Wanneer u een AKS-cluster maakt met behulp van de az aks create opdracht, gebruikt u de --node-resource-group parameter en geeft u een naam op voor de resourcegroep. Als u een Azure Resource Manager-sjabloon gebruikt om een AKS-cluster te implementeren, kunt u de naam van de resourcegroep definiëren met behulp van de eigenschap nodeResourceGroup .

  • De Azure-resourceprovider maakt automatisch de secundaire resourcegroep.
  • U kunt alleen een aangepaste resourcegroepnaam opgeven wanneer u het cluster maakt.

Wanneer u met de knooppuntresourcegroep werkt, moet u er rekening mee houden dat u het volgende niet kunt doen:

  • Geef een bestaande resourcegroep op voor de knooppuntresourcegroep.
  • Geef een ander abonnement op voor de knooppuntresourcegroep.
  • Wijzig de naam van de knooppuntresourcegroep nadat het cluster is gemaakt.
  • Geef namen op voor de beheerde resources in de knooppuntresourcegroep.
  • Door Azure gemaakte tags van beheerde resources in de knooppuntresourcegroep wijzigen of verwijderen. Zie aanvullende informatie in de volgende sectie.

Kan ik tags en andere eigenschappen van de AKS-resources in de knooppuntresourcegroep wijzigen?

Mogelijk krijgt u onverwachte schaal- en upgradefouten als u door Azure gemaakte tags en andere resource-eigenschappen in de knooppuntresourcegroep wijzigt of verwijdert. Met AKS kunt u aangepaste tags maken en wijzigen die door eindgebruikers zijn gemaakt en u kunt deze tags toevoegen bij het maken van een knooppuntgroep. U kunt aangepaste tags maken of wijzigen, bijvoorbeeld om een bedrijfseenheid of kostenplaats toe te wijzen. Een andere optie is om Azure-beleid te maken met een bereik voor de beheerde resourcegroep.

Door Azure gemaakte tags worden gemaakt voor hun respectieve Azure-services en moeten altijd worden toegestaan. Voor AKS zijn er de aks-managed en k8s-azure tags. Het wijzigen van door Azure gemaakte tags op resources onder de knooppuntresourcegroep in het AKS-cluster is een niet-ondersteunde actie die de serviceniveaudoelstelling (SLO) onderbreekt. Zie Voor meer informatie, biedt AKS een service level agreement?

Notitie

In het verleden is de tagnaam 'Eigenaar' gereserveerd voor AKS voor het beheren van het openbare IP-adres dat is toegewezen aan front-end-IP van de loadbalancer. Services gebruiken nu het aks-managed voorvoegsel. Gebruik voor verouderde resources geen Azure-beleid om de tagnaam Eigenaar toe te passen. Anders worden alle resources in uw AKS-clusterimplementatie en updatebewerkingen verbroken. Dit geldt niet voor nieuw gemaakte resources.

Welke Kubernetes-toegangscontrollers ondersteunt AKS? Kunnen toegangscontrollers worden toegevoegd of verwijderd?

AKS ondersteunt de volgende toegangscontrollers:

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

Op dit moment kunt u de lijst met toegangscontrollers in AKS niet wijzigen.

Kan ik toegangscontrollerwebhooks op AKS gebruiken?

Ja, u kunt toegangscontrollerwebhooks op AKS gebruiken. Het is raadzaam om interne AKS-naamruimten uit te sluiten, die zijn gemarkeerd met het label besturingsvlak. Bijvoorbeeld:

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

AKS-firewalls uitgaand verkeer van de API-server, zodat de webhooks van de toegangscontroller toegankelijk moeten zijn vanuit het cluster.

Kunnen toegangscontrollerwebhooks invloed hebben op kube-system en interne AKS-naamruimten?

Om de stabiliteit van het systeem te beschermen en te voorkomen dat aangepaste toegangscontrollers van invloed zijn op interne services in het kube-systeem, heeft naamruimte AKS een toegangsafdwinger, die automatisch kube-system- en AKS-interne naamruimten uitsluit. Deze service zorgt ervoor dat de aangepaste toegangscontrollers geen invloed hebben op de services die worden uitgevoerd in kube-system.

Als u een kritieke use-case hebt voor het implementeren van iets op kube-system (niet aanbevolen) ter ondersteuning van uw aangepaste toegangswebhook, kunt u het volgende label of de volgende aantekening toevoegen, zodat de toegangsafdwinger dit negeert.

Label: "admissions.enforcer/disabled": "true" of Aantekening: "admissions.enforcer/disabled": true

Is Azure Key Vault geïntegreerd met AKS?

Azure Key Vault-provider voor Secrets Store CSI Driver biedt systeemeigen integratie van Azure Key Vault in AKS.

Kan ik Windows Server-containers uitvoeren op AKS?

Ja, Windows Server-containers zijn beschikbaar op AKS. Als u Windows Server-containers wilt uitvoeren in AKS, maakt u een knooppuntgroep waarop Windows Server wordt uitgevoerd als gastbesturingssystemen. Windows Server-containers kunnen alleen Windows Server 2019 gebruiken. Zie Een AKS-cluster maken met een Windows Server-knooppuntgroep om aan de slag te gaan.

Windows Server-ondersteuning voor knooppuntgroep bevat enkele beperkingen die deel uitmaken van de upstream Windows Server in het Kubernetes-project. Zie Windows Server-containers in AKS-beperkingen voor meer informatie over deze beperkingen.

Biedt AKS een service level agreement?

AKS biedt SLA-garanties in de prijscategorie Standard met de functie UPTIME SLA.

De gratis prijscategorie heeft geen gekoppelde Service Level Agreement, maar heeft een serviceniveaudoelstellingvan 99,5%. Tijdelijke verbindingsproblemen worden waargenomen als er een upgrade, beschadigde onderlayknooppunten, platformonderhoud, een toepassing de API-server overweldigt met aanvragen, enzovoort. Voor bedrijfskritieke en productieworkloads, of als uw workload het opnieuw opstarten van DE API-server niet tolereert, raden we u aan de Standard-laag te gebruiken, waaronder de SLA uptime.

Kan ik Azure-reserveringskortingen toepassen op mijn AKS-agentknooppunten?

AKS-agentknooppunten worden gefactureerd als standaard virtuele Azure-machines. Als u Azure-reserveringen hebt aangeschaft voor de VM-grootte die u in AKS gebruikt, worden deze kortingen automatisch toegepast.

Kan ik mijn cluster verplaatsen/migreren tussen Azure-tenants?

Het verplaatsen van uw AKS-cluster tussen tenants wordt momenteel niet ondersteund.

Kan ik mijn cluster verplaatsen/migreren tussen abonnementen?

Het verplaatsen van clusters tussen abonnementen wordt momenteel niet ondersteund.

Kan ik mijn AKS-clusters van het huidige Azure-abonnement naar een ander verplaatsen?

Het verplaatsen van uw AKS-cluster en de bijbehorende resources tussen Azure-abonnementen wordt niet ondersteund.

Kan ik mijn AKS-cluster- of AKS-infrastructuurresources verplaatsen naar andere resourcegroepen of de naam ervan wijzigen?

Het verplaatsen of wijzigen van de naam van uw AKS-cluster en de bijbehorende resources wordt niet ondersteund.

Waarom duurt het verwijderen van mijn cluster zo lang?

De meeste clusters worden verwijderd op verzoek van de gebruiker. In sommige gevallen, met name wanneer u uw eigen resourcegroep meeneemt of cross-RG-taken uitvoert, kan het verwijderen langer duren of zelfs mislukken. Als u een probleem hebt met verwijderen, controleert u of u geen vergrendelingen op de RG hebt, of alle resources buiten de RG worden ontkoppeld van de RG, enzovoort.

Waarom duurt het maken/bijwerken van mijn cluster zo lang?

Als u problemen ondervindt met het maken en bijwerken van clusterbewerkingen, moet u ervoor zorgen dat u geen toegewezen beleidsregels of servicebeperkingen hebt die het beheer van resources zoals VM's, load balancers, tags, enzovoort kunnen blokkeren voor uw AKS-cluster.

Kan ik mijn cluster herstellen na het verwijderen?

Nee, u kunt het cluster niet herstellen nadat u het hebt verwijderen. Wanneer u uw cluster verwijdert, worden ook de knooppuntresourcegroep en alle bijbehorende resources verwijderd. Een voorbeeld van de tweede resourcegroep is MC_myResourceGroup_myAKSCluster_eastus.

Als u een van uw resources wilt behouden, verplaatst u deze naar een andere resourcegroep voordat u het cluster verwijdert. Als u wilt beveiligen tegen onbedoelde verwijderingen, kunt u de beheerde AKS-resourcegroep vergrendelen die als host fungeert voor uw clusterresources met behulp van vergrendeling van de knooppuntresourcegroep.

Wat is platformondersteuning en wat omvat het?

Platformondersteuning is een verminderd ondersteuningsplan voor niet-ondersteunde N-3-versieclusters. Platformondersteuning omvat alleen ondersteuning voor Azure-infrastructuur. Platformondersteuning bevat niets met betrekking tot het volgende:

  • Kubernetes-functionaliteit en -onderdelen
  • Cluster- of knooppuntgroep maken
  • Hotfixes
  • Bugfixes
  • Beveiligingspatches
  • Buiten gebruik gestelde onderdelen

Zie het platformondersteuningsbeleid voor meer informatie over beperkingen.

AKS is afhankelijk van de releases en patches van Kubernetes, een Open Source-project dat alleen een schuifvenster van drie secundaire versies ondersteunt. AKS kan alleen volledige ondersteuning garanderen terwijl deze versies upstream worden onderhouden. Omdat er geen patches meer worden geproduceerd, kan AKS deze versies ongepatcht of fork achterlaten. Vanwege deze beperking biedt platformondersteuning geen ondersteuning voor het gebruik van kubernetes upstream.

Worden mijn niet-ondersteunde clusters automatisch bijgewerkt met AKS?

AKS initieert automatische upgrades voor niet-ondersteunde clusters. Wanneer een cluster in een n-3-versie (waarbij n de meest recente ondersteunde secundaire AKS GA-versie is) op het punt staat om te worden verwijderd naar n-4, wordt het cluster automatisch bijgewerkt naar n-2 om in een AKS-ondersteuningsbeleid te blijven. Het automatisch upgraden van een platform ondersteund cluster naar een ondersteunde versie is standaard ingeschakeld.

Kubernetes v1.25-upgrades naar v1.26 bijvoorbeeld tijdens de algemene versie van v1.29. Als u onderbrekingen wilt minimaliseren, stelt u onderhoudsvensters in. Zie automatische upgrade voor meer informatie over automatische upgradekanalen.

Als ik pods/implementaties heb met de status NodeLost of Onbekend, kan ik mijn cluster nog steeds upgraden?

Dat kan, maar we raden het niet aan. U moet updates uitvoeren wanneer de status van het cluster bekend en in orde is.

Kan ik een upgrade uitvoeren als ik een cluster heb met een of meer knooppunten met een slechte status of als ik de status Niet in orde heb?

Nee, verwijder of verwijder knooppunten met een mislukte status of anderszins uit het cluster voordat u een upgrade uitvoert.

Ik heb een cluster verwijderd, maar zie de fout [Errno 11001] getaddrinfo failed

Deze fout treedt meestal op als u nog een of meer netwerkbeveiligingsgroepen (NSG's) gebruikt die zijn gekoppeld aan het cluster. Verwijder ze en probeer de verwijdering opnieuw uit te voeren.

Ik heb een upgrade uitgevoerd, maar nu zijn mijn pods in crashlussen en mislukken gereedheidstests?

Controleer of uw service-principal niet is verlopen. Zie: AKS-service-principal en AKS-referenties bijwerken.

Mijn cluster werkte, maar kan plotseling geen LoadBalancers inrichten, HPC's koppelen, enzovoort?

Controleer of uw service-principal niet is verlopen. Zie: AKS-service-principal en AKS-referenties bijwerken.

Kan ik mijn AKS-cluster schalen naar nul?

U kunt een actief AKS-cluster volledig stoppen, wat bespaart op de respectieve rekenkosten. Daarnaast kunt u er ook voor kiezen om alle of specifieke User knooppuntgroepen te schalen of automatisch te schalen naar 0, waarbij alleen de benodigde clusterconfiguratie wordt onderhouden.

U kunt systeemknooppuntgroepen niet rechtstreeks schalen naar nul.

Kan ik de API's van de virtuele-machineschaalset gebruiken om handmatig te schalen?

Nee, schaalbewerkingen met behulp van de API's voor virtuele-machineschaalsets worden niet ondersteund. Gebruik de AKS-API's (az aks scale).

Kan ik virtuele-machineschaalsets gebruiken om handmatig te schalen naar nul knooppunten?

Nee, schaalbewerkingen met behulp van de API's voor virtuele-machineschaalsets worden niet ondersteund. U kunt de AKS-API gebruiken om te schalen naar nul niet-systeemknooppuntgroepen of om uw cluster te stoppen.

Kan ik al mijn VM's stoppen of de toewijzing ervan ongedaan maken?

Hoewel AKS tolerantiemechanismen heeft om bestand te zijn tegen een dergelijke configuratie en deze te herstellen, is het geen ondersteunde configuratie. Stop in plaats daarvan uw cluster .

Kan ik aangepaste VM-extensies gebruiken?

Nee, AKS is een beheerde service en het bewerken van de IaaS-resources wordt niet ondersteund. Als u aangepaste onderdelen wilt installeren, gebruikt u de Kubernetes-API's en mechanismen. Gebruik bijvoorbeeld DaemonSets om vereiste onderdelen te installeren.

Worden er klantgegevens opgeslagen buiten de regio van het cluster?

Nee, alle gegevens worden opgeslagen in de regio van het cluster.

Zijn AKS-installatiekopieën vereist voor uitvoering als hoofdmap?

De volgende installatiekopieën hebben functionele vereisten voor 'Uitvoeren als root' en uitzonderingen moeten worden opgeslagen voor elk beleid:

  • 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

Wat is Azure CNI Transparent Mode versus Bridge Mode?

Vanaf versie 1.2.0 stelt Azure CNI de transparante modus in als standaard voor linux CNI-implementaties met één tenancy. De transparante modus vervangt de brugmodus. In de volgende secties bridgemodus en transparante modus bespreken we meer over de verschillen tussen beide modi en de voordelen en beperkingen voor de transparante modus in Azure CNI.

Brugmodus

Azure CNI Bridge-modus maakt een L2-brug met de naam 'azure0' op een 'just-in-time'-manier. Alle podpaarinterfaces aan de hostzijde veth zijn verbonden met deze brug. Pod-Pod intra VM-communicatie en het resterende verkeer gaat via deze brug. De brug is een virtueel laag 2-apparaat dat zelf niets kan ontvangen of verzenden, tenzij u een of meer echte apparaten eraan bindt. Om deze reden moet eth0 van de Linux-VM worden omgezet in een onderliggende naar 'azure0'-brug, die een complexe netwerktopologie binnen de Linux-VM maakt. Als symptoom moest CNI andere netwerkfuncties verwerken, zoals DNS-serverupdates.

Bridge mode topology

In het volgende voorbeeld ziet u hoe de ip-route-instelling eruitziet in de bridgemodus. Ongeacht het aantal pods dat het knooppunt heeft, zijn er slechts twee routes. De eerste route zegt dat verkeer (met uitzondering van lokaal op azure0) via de interface met ip 'src 10.240.0.4' naar de standaardgateway van het subnet gaat. Dit is primair IP-adres van knooppunt. De tweede zegt "10.20.x.x" Pod ruimte naar kernel voor kernel om te beslissen.

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

Transparante modus

Transparante modus biedt een eenvoudige benadering voor het instellen van Linux-netwerken. In deze modus wijzigt Azure CNI geen eigenschappen van eth0-interface in de Linux-VM. Deze benadering van het wijzigen van de Eigenschappen van Linux-netwerken helpt complexe problemen met hoekcases te verminderen die clusters kunnen tegenkomen met de Bridge-modus. In de transparante modus maakt en voegt Azure CNI interfaces voor podpaar veth aan de hostzijde toe die worden toegevoegd aan het hostnetwerk. Intra VM Pod-to-Pod-communicatie verloopt via IP-routes die door de CNI worden toegevoegd. In wezen is pod-naar-pod-communicatie meer dan laag 3 en L3-routeringsregels voor het routeren van podverkeer.

Transparent mode topology

In het volgende voorbeeld ziet u een IP-route-instelling van de transparante modus. De interface van elke pod krijgt een statische route gekoppeld, zodat verkeer met het eerste IP-adres, omdat de pod rechtstreeks naar de interface van de hostzijde veth van de pod wordt verzonden.

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

Voordelen van transparante modus

  • Biedt beperking voor conntrack parallelle DNS-racevoorwaarde en vermijding van 5 sec DNS-latentieproblemen zonder dat u lokale DNS van knooppunten hoeft in te stellen (u kunt nog steeds lokale knooppunt-DNS gebruiken om prestatieredenen).
  • Elimineert de initiële CNI-brugmodus van 5 seconden DNS-latentie die vandaag wordt geïntroduceerd vanwege de 'Just-In-Time'-bruginstallatie.
  • Een van de hoekcases in de Bridge-modus is dat de Azure CNI de aangepaste DNS-server niet kan bijwerken met lijsten die gebruikers toevoegen aan VNET of NIC. Dit scenario resulteert in het ophalen van alleen het eerste exemplaar van de lijst met DNS-servers in CNI. Dit probleem wordt opgelost in de transparante modus, omdat CNI geen eth0-eigenschappen wijzigt. Zie hier meer.
  • Biedt een betere verwerking van UDP-verkeer en -beperking voor UDP-overstromingsstorm wanneer er een time-out optreedt in ARP. In de Bridge-modus, wanneer bridge geen MAC-adres van de doelpod in intra-VM Pod-to-Pod-communicatie kent, resulteert dit in storm van het pakket naar alle poorten. Dit probleem wordt opgelost in de transparante modus, omdat er geen L2-apparaten in het pad zijn. Zie hier meer.
  • Transparante modus presteert beter in intra-VM Pod-naar-Pod-communicatie in termen van doorvoer en latentie in vergelijking met de Bridge-modus.

Problemen met het instellen van machtigingseigendom voorkomen wanneer het volume meerdere bestanden heeft?

Traditioneel als uw pod wordt uitgevoerd als een niet-basisgebruiker (wat u moet doen), moet u een fsGroup binnen de beveiligingscontext van de pod opgeven, zodat het volume kan worden gelezen en beschrijfbaar door de pod. Deze vereiste wordt hier uitvoeriger besproken.

Een neveneffect van het instellen fsGroup is dat telkens wanneer een volume wordt gekoppeld, Kubernetes recursief en alle bestanden en mappen binnen het volume moet recursief chown()chmod() zijn (met enkele uitzonderingen die hieronder worden vermeld). Dit scenario gebeurt zelfs als het groepseigendom van het volume al overeenkomt met de aangevraagde fsGroup. Het kan duur zijn voor grotere volumes met veel kleine bestanden, waardoor het opstarten van pods lang kan duren. Dit scenario is een bekend probleem geweest voor v1.20 en de tijdelijke oplossing is het instellen van de Pod als root:

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

Het probleem is opgelost met Kubernetes versie 1.20. Zie Kubernetes 1.20 voor meer informatie: Gedetailleerde controle over wijzigingen in volumemachtigingen.

Kan ik cryptografische FIPS-bibliotheken gebruiken met implementaties in AKS?

Knooppunten met FIPS-functionaliteit worden nu ondersteund in linux-knooppuntgroepen. Zie Een FIPS-knooppuntgroep toevoegen voor meer informatie.

Kan ik NSG's configureren met AKS?

AKS past geen netwerkbeveiligingsgroepen (NSG's) toe op het subnet en wijzigt geen NSG's die aan dat subnet zijn gekoppeld. AKS wijzigt alleen de NSG-instellingen voor netwerkinterfaces. Als u CNI gebruikt, moet u er ook voor zorgen dat de beveiligingsregels in de NSG's verkeer toestaan tussen het knooppunt en de CIDR-bereiken voor pods. Als u kubenet gebruikt, moet u er ook voor zorgen dat de beveiligingsregels in de NSG's verkeer toestaan tussen het knooppunt en de CIDR van de pod. Zie Netwerkbeveiligingsgroepen voor meer informatie.

Hoe werkt tijdsynchronisatie in AKS?

AKS-knooppunten voeren de 'chrony'-service uit, die tijd ophaalt van de localhost. Containers die worden uitgevoerd op pods krijgen de tijd van de AKS-knooppunten. Toepassingen die in een container worden gestart, gebruiken tijd van de container van de pod.

Hoe worden AKS-invoegtoepassingen bijgewerkt?

Elke patch, inclusief een beveiligingspatch, wordt automatisch toegepast op het AKS-cluster. Alles wat groter is dan een patch, zoals belangrijke of secundaire versiewijzigingen (die belangrijke wijzigingen in uw geïmplementeerde objecten kunnen hebben), wordt bijgewerkt wanneer u uw cluster bijwerkt als er een nieuwe release beschikbaar is. U kunt vinden wanneer er een nieuwe release beschikbaar is door naar de opmerkingen bij de AKS-release te gaan.

Wat is het doel van de AKS Linux-extensie die ik zie geïnstalleerd op mijn exemplaren van virtuele Linux-machineschaalsets?

De AKS Linux-extensie is een Azure VM-extensie waarmee bewakingshulpprogramma's op Kubernetes-werkknooppunten worden geïnstalleerd en geconfigureerd. De extensie wordt geïnstalleerd op alle nieuwe en bestaande Linux-knooppunten. Hiermee configureert u de volgende bewakingshulpprogramma's:

  • Knooppuntexporteur: verzamelt hardwaretelemetrie van de virtuele machine en maakt deze beschikbaar met behulp van een eindpunt voor metrische gegevens. Vervolgens kan een bewakingsprogramma, zoals Prometheus, deze metrische gegevens schrooten.
  • Node-problem-detector: is bedoeld om verschillende knooppuntproblemen zichtbaar te maken voor upstream-lagen in de clusterbeheerstack. Het is een systeemeenheid die op elk knooppunt wordt uitgevoerd, knooppuntproblemen detecteert en deze rapporteert aan de API-server van het cluster met behulp van Events en NodeConditions.
  • ig: Een opensource-framework met eBPF voor foutopsporing en het observeren van Linux- en Kubernetes-systemen. Het biedt een set hulpprogramma's (of gadgets) die zijn ontworpen om relevante informatie te verzamelen, zodat gebruikers de oorzaak van prestatieproblemen, crashes of andere afwijkingen kunnen identificeren. Met name de onafhankelijkheid van Kubernetes stelt gebruikers in staat om het ook te gebruiken voor foutopsporing van besturingsvlakproblemen.

Deze hulpprogramma's bieden waarneembaarheid rond veel problemen met betrekking tot de status van knooppunten, zoals:

  • Problemen met infrastructuurdemon: NTP-service is offline
  • Hardwareproblemen: Ongeldige CPU, geheugen of schijf
  • Kernelproblemen: kernel impasse, beschadigd bestandssysteem
  • Problemen met containerruntime: Niet-reagerende runtime-daemon

Voor de extensie is geen extra uitgaande toegang vereist tot URL's, IP-adressen of poorten buiten de gedocumenteerde AKS-vereisten voor uitgaand verkeer. Er zijn geen speciale machtigingen vereist die zijn verleend in Azure. Kubeconfig wordt gebruikt om verbinding te maken met de API-server om de verzamelde bewakingsgegevens te verzenden.