Häufig gestellte Fragen zu Azure Kubernetes Service (AKS)

Dieser Artikel behandelt häufig gestellte Fragen zu Azure Kubernetes Service (AKS).

In welchen Azure-Regionen wird AKS derzeit zur Verfügung gestellt?

Eine vollständige Liste der verfügbaren Regionen finden Sie unter AKS-Regionen und Verfügbarkeit.

Kann ich einen AKS-Cluster regionsübergreifend verteilen?

Nein. AKS-Cluster sind regionale Ressourcen und können sich nicht über mehrere Regionen erstrecken. Eine Anleitung zum Erstellen einer Architektur, die mehrere Regionen umfasst, finden Sie unter Bewährte Methoden für Geschäftskontinuität und Notfallwiederherstellung.

Kann ich einen AKS-Cluster über Verfügbarkeitszonen hinweg verteilen?

Ja. Sie können einen AKS-Cluster über eine oder mehrere Verfügbarkeitszonen hinweg in Regionen bereitstellen, die diese unterstützen.

Kann ich einschränken, wer Zugriff auf den Kubernetes-API-Server hat?

Ja. Es gibt zwei Optionen zum Einschränken des Zugriffs auf den API-Server:

• Verwenden Sie vom API-Server autorisierte IP-Bereiche, wenn Sie einen öffentlichen Endpunkt für den API-Server verwalten, aber den Zugriff auf eine Reihe von vertrauenswürdigen IP-Bereichen beschränken möchten.
• Verwenden Sie einen privaten Cluster, wenn Sie den API-Server darauf beschränken möchten, dass er nur von Ihrem virtuellen Netzwerk aus zugänglich ist.

Kann ich unterschiedliche VM-Größen in einem einzigen Cluster verwenden?

Ja. Sie können virtuelle Computer unterschiedlicher Größen in Ihrem AKS-Cluster verwenden, indem Sie mehrere Knotenpools erstellen.

Werden Sicherheitsupdates auf AKS-Agent-Knoten angewendet?

AKS patcht CVEs, für die es einen „Herstellerfix“ gibt wöchentlich. CVEs ohne Fix warten auf einen „Herstellerfix“, bevor sie behoben werden können. Die AKS-Images werden automatisch innerhalb von 30 Tagen aktualisiert. Wir empfehlen Ihnen, in regelmäßigen Abständen ein aktualisiertes Knotenimage anzuwenden, um sicherzustellen, dass die neuesten gepatchten Images und Betriebssystempatches angewendet werden und aktuell sind. Hierfür können Sie eine der folgenden Methoden verwenden:

• Manuell über das Azure-Portal oder die Azure-CLI.
• Durch ein Upgrade des AKS-Clusters. Durch Clusterupgrades werden Knoten automatisch abgesperrt und ausgeglichen. Anschließend werden neue Knoten mit dem neuesten Ubuntu-Image und einer neuen Patchversion oder einer Kubernetes-Nebenversion online geschaltet. Weitere Informationen finden Sie unter Aktualisieren eines AKS-Clusters.
• Durch Verwenden eines Knotenimageupgrades.

Was ist die Größenbeschränkung für ein Containerimage in AKS?

AKS legt keinen Grenzwert für die Größe des Containerimages fest. Es ist jedoch wichtig zu verstehen, dass das Image größer ist, je höher der Speicherbedarf ist. Eine höhere Größe könnte potenziell Ressourcenlimits oder den gesamten verfügbaren Arbeitsspeicher von Workerknoten überschreiten. Standardmäßig ist der Arbeitsspeicher für die VM-Größe Standard_DS2_v2 für einen AKS-Cluster auf 7 GiB festgelegt.

Wenn ein Containerimage übermäßig groß ist, etwa im Terabytebereich (TBs) liegt, kann Kubelet es möglicherweise nicht aus Ihrer Containerregistrierung auf einen Knoten pullen, da kein Speicherplatz auf dem Datenträger vorhanden ist.

Windows Server-Knoten

Für Windows Server-Knoten werden die neuesten Updates von Windows Update nicht automatisch ausgeführt und angewendet. Sie sollten in regelmäßigen Abständen ein Upgrade für den Cluster und die Windows Server-Knotenpools in Ihrem AKS-Cluster durchführen, passend zum Windows Update-Freigabezyklus und Ihrem eigenen Validierungsprozess. Während dieses Upgrades werden Knoten erstellt, die das neueste Windows Server-Image und die neuesten Windows Server-Patches ausführen und die älteren Knoten entfernen. Weitere Informationen zu diesem Prozess finden Sie unter Durchführen eines Upgrades für einen Knotenpool in AKS.

Sollte ich Sicherheitsbedrohungen für AKS beachten?

Microsoft bietet Anleitungen zu zusätzlichen Aktionen, mit denen Sie Ihre Workloads durch Dienste wie Microsoft Defender für Container schützen können. Die folgende Sicherheitsbedrohung im Zusammenhang mit AKS und Kubernetes sollten Sie beachten:

• Neue umfangreiche Kampagne für Kubeflow (8. Juni 2021).

Wie kommuniziert die verwaltete Steuerungsebene mit meinen Knoten?

AKS verwendet sichere Tunnelkommunikation, damit der API-Server und einzelne Knoten-Kubelets auch in separaten virtuellen Netzwerken kommunizieren können. Der Tunnel wird über mTLS-Verschlüsselung gesichert. Der aktuelle Haupttunnel, der von AKS verwendet wird, ist Konnectivity, zuvor als apiserver-network-proxy bezeichnet. Stellen Sie sicher, dass alle Netzwerkregeln den erforderlichen Azure-Netzwerkregeln und -FQDNs entsprechen.

Können meine Pods den FQDN des API-Servers anstelle der Cluster-IP-Adresse verwenden?

Ja, Sie können Pods die Anmerkung kubernetes.azure.com/set-kube-service-host-fqdn hinzufügen, um die Variable KUBERNETES_SERVICE_HOST auf den Domänennamen des API-Servers anstelle der IP-Adresse des Clusterdiensts festzulegen. Dies ist nützlich in Fällen, in denen der Clusterausgang über eine Firewall der Schicht 7 erfolgt, z. B. bei Verwendung von Azure Firewall mit Anwendungsregeln.

Warum werden zwei Ressourcengruppen mit AKS erstellt?

AKS baut auf vielen Azure-Infrastrukturressourcen auf, einschließlich VM-Skalierungsgruppen, virtueller Netzwerke und verwalteter Datenträger. Diese Integrationen ermöglichen Ihnen, viele der Kernfunktionen der Azure-Plattform in der von AKS bereitgestellten verwalteten Kubernetes-Umgebung zu nutzen. Beispielsweise können die meisten Typen von virtuellen Azure-Computern direkt mit AKS verwendet werden, und Azure Reservations können zum automatischen Empfang von Rabatten für diese Ressourcen verwendet werden.

Um diese Architektur zu ermöglichen, umfass jede AKS-Bereitstellung zwei Ressourcengruppen:

1. Die erste Ressourcengruppe wird von Ihnen erstellt. Diese Gruppe enthält nur die Kubernetes-Dienstressource. Der AKS-Ressourcenanbieter erstellt während der Bereitstellung automatisch die zweite Ressourcengruppe. MC_myResourceGroup_myAKSCluster_eastus ist ein Beispiel für die zweite Ressourcengruppe. Informationen dazu, wie Sie den Namen dieser zweiten Ressourcengruppe angeben, finden Sie im nächsten Abschnitt.

2. Die zweite Ressourcengruppe, als Knotenressourcengruppe bezeichnet, enthält alle Infrastrukturressourcen für den Cluster. Diese Ressourcen umfassen die virtuellen Computer des Kubernetes-Knotens, virtuelle Netzwerke und Speicher. Standardmäßig lautet der Name der Knotenressourcengruppe z. B. MC_myResourceGroup_myAKSCluster_eastus. AKS löscht die Knotenressourcengruppe automatisch, wenn Sie den Cluster löschen. Sie sollten diesen Cluster nur für Ressourcen verwenden, die den Lebenszyklus des Clusters gemeinsam nutzen.

   Hinweis

   Das Ändern einer Ressource unter der Knotenressourcengruppe im AKS-Cluster ist eine nicht unterstützte Aktion und führt zu Fehlern im Clusterbetrieb. Sie können verhindern, dass Änderungen an der Knotenressourcengruppe vorgenommen werden, indem Sie Benutzer daran hindern, vom AKS-Cluster verwaltete Ressourcen zu ändern.

Kann ich einen eigenen Namen für die AKS-Knotenressourcengruppe angeben?

Ja. In AKS wird der Knotenressourcengruppe standardmäßig der Name MC_resourcegroupname_clustername_location zugewiesen, Sie können jedoch auch einen eigenen Namen angeben.

Installieren Sie die aks-preview-Erweiterungsversion 0.3.2 oder höher der Azure CLI, wenn Sie einen eigenen Ressourcengruppennamen angeben möchten. Verwenden Sie bei der Erstellung eines AKS-Clusters mit dem Befehl az aks create den Parameter --node-resource-group, und geben Sie einen Namen für die Ressourcengruppe an. Wenn Sie eine Azure Resource Manager-Vorlage verwenden, um einen AKS-Cluster bereitzustellen, können Sie die nodeResourceGroup-Eigenschaft verwenden, um den Namen der Ressourcengruppe zu definieren.

• Der Azure-Ressourcenanbieter erstellt automatisch die sekundäre Ressourcengruppe.
• Sie können nur einen benutzerdefinierten Namen für die Ressourcengruppe angeben, wenn Sie den Cluster erstellen.

Denken Sie bei der Arbeit mit der Knotenressourcengruppe daran, dass Folgendes nicht möglich ist:

• Angeben einer vorhandenen Ressourcengruppe als Knotenressourcengruppe
• Angeben eines anderen Abonnements für die Knotenressourcengruppe
• Ändern des Namens der Knotenressourcengruppe, nachdem der Cluster erstellt wurde
• Angeben von Namen für die verwalteten Ressourcen innerhalb der Knotenressourcengruppe
• Ändern oder Löschen von Azure erstellter Tags für verwaltete Ressourcen innerhalb der Knotenressourcengruppe Weitere Informationen finden Sie im nächsten Abschnitt.

Kann ich Tags und andere Eigenschaften der AKS-Ressourcen in der Knotenressourcengruppe ändern?

Wenn Sie die in Azure erstellten Tags und andere Ressourceneigenschaften in der Knotenressourcengruppe ändern oder löschen, kann dies zu unerwarteten Skalierungs- und Aktualisierungsfehlern führen. In AKS können Sie benutzerdefinierte Tags, die von Endbenutzern erstellt wurden, erstellen und ändern, und Sie können diese Tags hinzufügen, wenn Sie einen Knotenpool erstellen. Sie können benutzerdefinierte Tags erstellen oder ändern, um beispielsweise eine Geschäftseinheit oder eine Kostenstelle zuzuweisen. Eine weitere Option besteht darin, Azure Policies mit einem Bereich zu erstellen, der die verwaltete Ressourcengruppe abdeckt.

Von Azure erstellte Tags werden für die jeweiligen Azure-Dienste erstellt und sollten immer zugelassen werden. Für AKS gibt es die Tags aks-managed und k8s-azure. Von Azure erstellte Tags für Ressourcen unter der Knotenressourcengruppe im AKS-Cluster dürfen nicht geändert werden, da dies zu einer Verletzung des Servicelevelziels (Service-Level Objective, SLO) führt. Weitere Informationen finden Sie unter Bietet AKS eine Vereinbarung zum Servicelevel?

Hinweis

In der Vergangenheit wurde der Tagname „Owner“ für AKS reserviert, um die öffentliche IP-Adresse zu verwalten, die der Front-End-IP-Adresse des Lastenausgleichs zugewiesen ist. Jetzt verwenden Dienste das Präfix aks-managed. Verwenden Sie bei Legacyressourcen keine Azure-Richtlinien, um den Tagnamen „Owner“ anzuwenden. Andernfalls treten bei allen Ressourcen für Ihre AKS-Clusterbereitstellungs- und -Updatevorgänge Fehler auf. Dies gilt nicht für neu erstellte Ressourcen.

Welche Kubernetes-Zugangssteuerungen werden von AKS unterstützt? Können Zulassungscontroller hinzugefügt oder entfernt werden?

AKS unterstützt die folgenden Zugangssteuerungen:

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

Derzeit können Sie die Liste der Zugriffssteuerungen in AKS nicht ändern.

Kann ich in AKS Zugangscontrollerwebhooks verwenden?

Ja, Sie können Zugangscontrollerwebhooks in AKS verwenden. Es wird empfohlen, interne AKS-Namespaces auszuschließen, die mit der Bezeichnung control-plane gekennzeichnet sind. Zum Beispiel:

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

AKS dient als eine Art Firewall für den ausgehenden Datenverkehr des API-Servers, sodass der Zugriff auf Ihre Zugangscontrollerwebhooks vom Cluster aus möglich sein muss.

Können Zugangscontrollerwebhooks Auswirkungen auf „kube-system“ und interne AKS-Namespaces haben?

Der AKS-Namespace verfügt über einen Admissions Enforcer, der die internen „kube-system“- und AKS-Namespaces automatisch ausschließt, um die Stabilität des Systems zu schützen und zu verhindern, dass benutzerdefinierte Zugangscontroller „kube-system“ und interne AKS-Namespaces beeinträchtigen. Dieser Dienst stellt sicher, dass die benutzerdefinierten Zugangscontroller keine Auswirkungen auf die in „kube-system“ ausgeführten Dienste haben.

Bei einem kritischen Anwendungsfall für eine Bereitstellung im „kube-system“ (nicht empfohlen) zur Unterstützung Ihres benutzerdefinierten Zugangscontroller-Webhooks müssen Sie ggf. die folgende Bezeichnung oder Anmerkung hinzufügen, sodass der Admissions Enforcer diese ignoriert.

Bezeichnung: "admissions.enforcer/disabled": "true" oder Anmerkung: "admissions.enforcer/disabled": true

Ist Azure Key Vault in AKS integriert?

Der Azure Key Vault-Anbieter für den Secrets Store CSI-Treiber ermöglicht die native Integration von Azure Key Vault in AKS.

Kann ich Windows Server-Container unter AKS ausführen?

Ja, Windows Server-Container sind in AKS verfügbar. Erstellen Sie einen Knotenpool, der Windows Server als Gastbetriebssystem ausführt, um Windows Server-Container in AKS auszuführen. Windows Server-Container können nur Windows Server 2019 verwenden. Informationen zu den ersten Schritten finden Sie unter Erstellen eines AKS-Clusters mit einem Windows Server-Knotenpool.

Die Windows Server-Unterstützung für Knotenpools umfasst einige Einschränkungen, die Teil des Upstreamprojekts „Windows Server in Kubernetes“ sind. Weitere Informationen zu diesen Einschränkungen finden Sie unter Aktuelle Einschränkungen für Windows Server-Knotenpools und Anwendungsworkloads in Azure Kubernetes Service (AKS).

Bietet AKS eine Vereinbarung zum Servicelevel?

AKS bietet SLA-Garantien im Tarif „Standard“ mit der Funktion „Uptime SLA“.

Dem kostenlosen Tarif („Free“) ist keine Vereinbarung zum Servicelevel (SLA) zugeordnet, er besitzt aber ein Servicelevelziel von 99,5 %. Vorübergehende Konnektivitätsprobleme können bei Upgrades, fehlerhaften zugrunde liegenden Knoten, Wartungsarbeiten an der Plattform, den API-Server überlastenden Anwendungen usw. auftreten. Für unternehmenskritische und Produktionsworkloads, oder wenn Ihre Workload keine Neustarts des API-Servers toleriert, empfehlen wir die Verwendung des Tarifs „Standard“, der eine „Uptime SLA“ umfasst.

Kann ich Rabatte für Azure-Reservierungen auf meine AKS-Agent-Knoten anwenden?

AKS-Agentknoten werden als standardmäßige virtuelle Azure-Computer abgerechnet. Wenn Sie also Azure-Reservierungen für die von Ihnen in AKS verwendete VM-Größe erworben haben, werden diese Rabatte automatisch angewendet.

Kann ich meinen Cluster zwischen Azure-Mandanten verschieben/migrieren?

Das Verschieben Ihres AKS-Clusters zwischen Mandanten wird derzeit nicht unterstützt.

Kann ich meinen Cluster zwischen Abonnements verschieben/migrieren?

Das Verschieben von Clustern zwischen Abonnements wird derzeit nicht unterstützt.

Kann ich meine AKS-Cluster aus dem aktuellen Azure-Abonnement in ein anderes verschieben?

Das Verschieben Ihres AKS-Clusters und der zugehörigen Ressourcen zwischen Azure-Abonnements wird nicht unterstützt.

Kann ich meine AKS-Cluster- oder AKS-Infrastrukturressourcen in andere Ressourcengruppen verschieben oder sie umbenennen?

Das Verschieben oder Umbenennen Ihres AKS-Clusters und der zugehörigen Ressourcen wird nicht unterstützt.

Warum dauert das Löschen meines Clusters so lange?

Die meisten Cluster werden auf Benutzeranforderung gelöscht. In einigen Fällen, insbesondere wenn Sie Ihre eigene Ressourcengruppe mitbringen oder RG-übergreifende Aufgaben ausführen, kann das Löschen mehr Zeit in Anspruch nehmen oder sogar fehlschlagen. Wenn Sie ein Problem mit Löschvorgängen haben, vergewissern Sie sich, dass keine Sperren für die Ressourcengruppen vorliegen, dass alle Verknüpfungen mit Ressourcen außerhalb der Ressourcengruppe aufgehoben wurden usw.

Warum dauert das Erstellen/Aktualisieren meines Clusters so lange?

Wenn Sie Probleme mit Clustervorgängen für das Erstellen und Aktualisieren haben, stellen Sie sicher, dass Sie keine zugewiesenen Richtlinien oder Diensteinschränkungen haben, die Ihre AKS-Cluster bei der Verwaltung von Ressourcen wie VMs, Lastenausgleichsmodulen, Tags usw. blockieren können.

Kann ich meinen Cluster wiederherstellen, nachdem ich ihn gelöscht habe?

Nein, Sie können Ihren Cluster nach dem Löschen nicht wiederherstellen. Wenn Sie den Cluster löschen, werden auch die Knotenressourcengruppe und alle zugehörigen Ressourcen gelöscht. MC_myResourceGroup_myAKSCluster_eastus ist ein Beispiel für die zweite Ressourcengruppe.

Wenn Sie Ihre Ressourcen beibehalten möchten, verschieben Sie sie in eine andere Ressourcengruppe, bevor Sie den Cluster löschen. Wenn Sie vor versehentlichen Löschvorgängen schützen möchten, können Sie die verwaltete AKS-Ressourcengruppe sperren, die Ihre Clusterressourcen hostet, indem Sie Sperrmodus der Knotenressourcengruppe verwenden.

Was ist Plattformunterstützung, und was beinhaltet sie?

Plattformunterstützung ist ein reduzierter Supportplan für nicht unterstützte Cluster der Version N-3. Plattformunterstützung umfasst nur Unterstützung für die Azure-Infrastruktur. Die Plattformunterstützung umfasst nichts im Zusammenhang mit Folgendem:

• Kubernetes-Funktionen und -Komponenten
• Cluster- oder Knotenpoolerstellung
• Hotfixes
• Behebung von Programmfehlern
• Sicherheitspatches
• Eingestellte Komponenten

Weitere Informationen zu Einschränkungen finden Sie in der Richtlinie für die Plattformunterstützung.

AKS basiert auf den Releases und Patches von Kubernetes, einem Open Source-Projekt, das nur ein gleitendes Fenster mit drei Nebenversionen unterstützt. AKS kann nur vollständige Unterstützung garantieren, wenn diese Versionen im Upstream gepflegt werden. Da im Upstream keine Patches mehr erstellt werden, kann AKS diese Versionen entweder ungepatcht lassen oder forken. Aufgrund dieser Einschränkung gilt die Plattformunterstützung nicht für Elemente, die auf einem Kubernetes-Upstream basieren.

Führt AKS ein automatisches Upgrade für meine nicht unterstützten Cluster durch?

AKS initiiert automatische Upgrades für nicht unterstützte Cluster. Wenn ein Cluster in der Version n-3 (wobei n die letzte unterstützte GA-Nebenversion von AKS ist) im Begriff ist, auf n-4 zu fallen, aktualisiert AKS den Cluster automatisch auf n-2, um die AKS-Unterstützungsrichtlinie beizubehalten. Das automatische Upgrade eines Clusters mit Plattformunterstützung auf eine unterstützte Version ist standardmäßig aktiviert.

Zum Beispiel wird Kubernetes v1.25 während des Release von v1.29 GA auf v1.26 aktualisiert. Um Unterbrechungen zu minimieren, richten Sie Wartungsfenster ein. Ausführlichere Informationen zu Kanälen für automatische Upgrades finden Sie unter Automatisches Upgrade für einen AKS-Cluster (Azure Kubernetes Service).

Wenn Pods/Bereitstellungen den Zustand „NodeLost“ oder „Unbekannt“ aufweisen, kann ich meinen Cluster trotzdem aktualisieren?

Das können Sie, aber wir raten davon ab. Sie sollten Updates ausführen, wenn der Zustand des Clusters bekannt und fehlerfrei ist.

Kann ich ein Upgrade ausführen, wenn ein Cluster mit einem oder mehreren Knoten einen fehlerhaften Zustand aufweisen oder heruntergefahren wurden?

Nein. Löschen/Entfernen Sie alle Knoten, die den Status „Fehler“ oder Ähnliches aufweisen, bevor Sie das Upgrade ausführen.

Ich habe eine Clusterlöschung ausgeführt, aber der Fehler [Errno 11001] getaddrinfo failed wird angezeigt.

In der Regel tritt dieser Fehler auf, wenn Sie noch eine oder mehrere Netzwerksicherheitsgruppen (NSGs) verwenden, die dem Cluster zugeordnet sind. Entfernen Sie diese, und versuchen Sie erneut, den Löschvorgang auszuführen.

Ich habe ein Upgrade ausgeführt, aber jetzt befinden sich die Pods in Absturzschleifen, und Bereitschaftstests schlagen fehl.

Vergewissern Sie sich, dass der Dienstprinzipal nicht abgelaufen ist. Siehe: AKS-Dienstprinzipal und Aktualisieren der AKS-Anmeldeinformationen.

Mein Cluster hat funktioniert, kann aber plötzlich keine LoadBalancer bereitstellen, keine PVCs einbinden usw.

Vergewissern Sie sich, dass der Dienstprinzipal nicht abgelaufen ist. Siehe: AKS-Dienstprinzipal und Aktualisieren der AKS-Anmeldeinformationen.

Kann ich meinen AKS-Cluster auf 0 (null) skalieren?

Sie können einen AKS-Cluster, der gerade ausgeführt wird, vollständig beenden und so die entsprechenden Computekosten einsparen. Außerdem können Sie alle oder bestimmte User-Knotenpools auch auf 0 skalieren oder automatisch skalieren und nur die erforderliche Clusterkonfiguration beibehalten.

Systemknotenpools können nicht direkt auf Null skaliert werden.

Kann ich die VM-Skalierungsgruppen-APIs für eine manuelle Skalierung verwenden?

Nein, Skalierungsvorgänge mithilfe der VM-Skalierungsgruppen-APIs werden nicht unterstützt. Verwenden Sie die AKS-APIs (az aks scale).

Kann ich VM-Skalierungsgruppen verwenden, um manuell auf null Knoten zu skalieren?

Nein, Skalierungsvorgänge mithilfe der VM-Skalierungsgruppen-APIs werden nicht unterstützt. Sie können die AKS-API verwenden, um eine Skalierung auf null Nicht-System-Knotenpools durchzuführen, oder stattdessen den Cluster beenden.

Kann ich alle meine VMs beenden oder deren Zuordnung aufheben?

AKS verfügt zwar über Resilienzmechanismen, um eine solche Konfiguration zu überstehen und eine Wiederherstellung vorzunehmen. Dies ist aber keine unterstützte Konfiguration. Beenden Sie den Cluster stattdessen.

Kann ich benutzerdefinierte VM-Erweiterungen verwenden?

Nein. AKS ist ein verwalteter Dienst, und die Bearbeitung der IaaS-Ressourcen wird nicht unterstützt. Nutzen Sie die Kubernetes-APIs und -Mechanismen zum Installieren benutzerdefinierter Komponenten. Verwenden Sie beispielsweise DaemonSets, um erforderliche Komponenten zu installieren.

Speichert AKS Kundendaten außerhalb der Region des Clusters?

Nein, alle Daten werden in der Region des Clusters gespeichert.

Sind AKS-Images für eine Ausführung als root erforderlich?

Die folgenden Images weisen funktionsbezogene Anforderungen hinsichtlich der Ausführung als Root-Benutzer auf, und Ausnahmen müssen für alle Richtlinien angegeben werden:

• 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

Was ist der transparente Azure CNI-Modus im Vergleich zum Bridge-Modus?

Ab 1.2.0 ist der transparente Modus der Standard bei Azure CNI für Linux-CNI-Bereitstellungen mit einem Mandanten. Der transparente Modus ersetzt den Bridge-Modus. In den folgenden Abschnitten Bridge-Modus und Transparenter Modus werden die Unterschiede zwischen beiden Modi sowie die Vorteile und Einschränkungen für den transparenten Modus in Azure CNI erläutert.

Bridge-Modus

Der Azure CNI-Bridge-Modus erstellt eine L2-Bridge namens „azure0“ auf „Just-in-Time“-Weise. Alle hostseitigen Pod-veth-Paarschnittstellen werden mit dieser Bridge verbunden. Die Kommunikation zwischen Pods in der VM und der verbleibende Datenverkehr durchlaufen diese Bridge. Die Bridge ist ein virtuelles Gerät der Ebene 2, das selbst keine Daten empfangen oder übertragen kann, es sei denn, Sie binden mindestens ein reales Gerät an dieses Gerät. Aus diesem Grund muss eth0 der Linux-VM in eine untergeordnete „azure0“-Bridge konvertiert werden, die eine komplexe Netzwerktopologie innerhalb der Linux-VM erstellt. Als Symptom musste CNI andere Netzwerkfunktionen verarbeiten, z. B. DNS-Serverupdates.

Das folgende Beispiel zeigt, wie die IP-Routeneinrichtung im Brückenmodus aussieht. Unabhängig davon, wie viele Pods der Knoten aufweist, gibt es immer nur zwei Routen. Die erste Route besagt, dass Datenverkehr (außer lokal in azure0) über die Schnittstelle mit der IP-Adresse „src 10.240.0.4“, also der primären IP-Adresse des Node, an das Standardgateway des Subnetzes geleitet wird. Der zweite sagt „10.20.x.x“ Podspeicherplatz zum Kernel, damit der Kernel entscheiden kann.

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

Transparenter Modus

Der transparente Modus verwendet einen geradlinigen Ansatz zum Einrichten von Linux-Netzwerken. In diesem Modus ändert Azure CNI keine Eigenschaften der eth0-Schnittstelle in der Linux-VM. Dank dieses Ansatzes zum Ändern der Linux-Netzwerkeigenschaften können komplexe Eckfallprobleme reduziert werden, die für Cluster im Bridge-Modus auftreten können. Im transparenten Modus erstellt Azure CNI hostseitige Pod-veth-Paarschnittstellen, die dem Hostnetzwerk hinzugefügt werden. Die Kommunikation zwischen Pods im Cluster erfolgt über die von der CNI hinzugefügten IP-Routen. Im Wesentlichen erfolgt die Kommunikation zwischen Pods über Ebene 3, und L3-Routingregeln leiten Poddatenverkehr weiter.

Das folgende Beispiel zeigt eine IP-Routeneinrichtung des transparenten Modus. An die Schnittstelle jedes Pods wird eine statische Route angefügt, sodass Datenverkehr mit der Ziel-IP des Pods direkt an die hostseitige veth-Paarschnittstelle des Pods gesendet wird.

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

Vorteile des transparenten Modus

• Dieser Modus bietet eine Entschärfung für eine parallele conntrack-DNS-Racebedingung und die Vermeidung von Problemen durch DNS-Latenz von 5 Sekunden, ohne dass DNS des lokalen Knotens eingerichtet werden muss (Sie können aus Leistungsgründen DNS des lokalen Knotens ggf. trotzdem verwenden).
• Er eliminiert die anfängliche 5-sekündige DNS-Latenz, die der CNI-Bridge-Modus heute aufgrund der Bridge-Einrichtung verursacht, die „Just-in-Time“ erfolgt.
• Einer der Eckfälle im Bridge-Modus ist, dass Azure CNI die benutzerdefinierten DNS-Server-Listen, die Benutzer dem VNET oder der NIC hinzufügen, nicht ständig aktualisieren kann. Dieses Szenario führt dazu, dass CNI nur die erste Instanz der DNS-Serverliste auswählt. Dieses Problem wird im transparenten Modus gelöst, weil CNI keine eth0-Eigenschaften ändert. Weitere Informationen finden Sie hier.
• Dieser Modus bietet eine bessere Verarbeitung von UDP-Datenverkehr und Entschärfung für UDP-Überflutung bei einem Timeout von ARP. Wenn die Bridge im Bridge-Modus eine MAC-Adresse des Ziel-Pods bei der Kommunikation zwischen Pods in der VM nicht kennt, führt dies zu einem Paketsturm an alle Ports. Dieses Problem ist im transparenten Modus gelöst, da sich keine L2-Geräte im Pfad befinden. Weitere Informationen finden Sie hier.
• Der transparente Modus ist in Bezug auf Durchsatz und Latenz bei der Kommunikation zwischen Pods in der VM im Vergleich zum Bridge-Modus leistungsfähiger.

Wie kann ich Probleme vermeiden, bei denen das Festlegen des Berechtigungsbesitzes lange dauert, wenn das Volume viele Dateien enthält?

Wenn Ihr Pod nicht als Root-Benutzer*in ausgeführt wird (was ratsam ist), müssen Sie eine fsGroup im Sicherheitskontext des Pods angeben, damit das Volume für den Pod lesbar und beschreibbar ist. Eine ausführlichere Beschreibung dieser Anforderung finden Sie hier.

Ein Nebeneffekt beim Festlegen von fsGroup ist, dass von Kubernetes bei jeder Bereitstellung eines Volumes rekursiv die Vorgänge chown() und chmod() für alle Dateien und Verzeichnisse des Volumes durchgeführt werden müssen (mit einigen Ausnahmen, die unten angegeben sind). Dieses Szenario tritt auch dann auf, wenn der Gruppenbesitz des Volumes bereits mit der angeforderten fsGroup übereinstimmt. Das kann für größeres Volumes mit vielen kleinen Dateien teuer sein und dazu führen, dass der Podstartup lange dauert. Dieses Szenario war bis zur Version 1.20 ein bekanntes Problem. Die Problemumgehung besteht darin, für den Pod die Ausführung als „Root“ festzulegen:

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

Das Problem wurde mit Kubernetes-Version 1.20 behoben. Weitere Informationen finden Sie unter Kubernetes 1.20: Granular Control of Volume Permission Changes (Kubernetes 1.20: Differenzierte Steuerung der Volumenberechtigungsänderungen).

Kann ich kryptografische FIPS-Bibliotheken bei Bereitstellungen in AKS verwenden?

FIPS-fähige Knoten werden nun in Linux-basierten Knotenpools unterstützt. Weitere Informationen finden Sie unter Hinzufügen eines FIPS-fähigen Knotenpools.

Kann ich Netzwerksicherheitsgruppen mit AKS konfigurieren?

AKS wendet keine Netzwerksicherheitsgruppen (NSGs) auf sein Subnetz an und ändert keine der NSGs, die diesem Subnetz zugeordnet sind. AKS ändert nur die Einstellungen von Netzwerkschnittstellen-NSGs. Wenn Sie CNI verwenden, müssen Sie außerdem sicherstellen, dass die Sicherheitsregeln in den Netzwerksicherheitsgruppen Datenverkehr zwischen den CIDR-Bereichen der Knoten und Pods zulassen. Wenn Sie kubenet verwenden, müssen Sie außerdem sicherstellen, dass die Sicherheitsregeln in den Netzwerksicherheitsgruppen Datenverkehr zwischen dem CIDR der Knoten und Pods zulassen. Weitere Informationen finden Sie unter Netzwerksicherheitsgruppen.

Wie funktioniert die Zeitsynchronisierung in AKS?

AKS-Knoten führen den „chrony“-Dienst aus, der die Zeit vom Localhost pullt. Container, die auf Pods ausgeführt werden, erhalten die Zeit von den AKS-Knoten. Anwendungen, die innerhalb eines Containers gestartet werden, verwenden die Zeit aus dem Container des Pods.

Wie werden AKS-Add-Ons aktualisiert?

Alle Patches, einschließlich ein Sicherheitspatch, werden automatisch auf den AKS-Cluster angewendet. Umfassendere Änderungen, die über einen Patch hinausgehen, etwa Änderungen an der Haupt- oder Nebenversion (z. B. Breaking Changes an Ihren bereitgestellten Objekten), werden implementiert, wenn Sie Ihren Cluster bei Verfügbarkeit eines neuen Release aktualisieren. Informationen dazu, wann ein neues Release verfügbar ist, finden Sie in den AKS-Versionshinweisen.

Was ist der Zweck der AKS Linux-Erweiterung, die ich auf meinen Linux Virtual Machine Scale Sets-Instanzen installiert sehe?

Die AKS-Linux-Erweiterung ist eine Azure-VM-Erweiterung, die Überwachungstools auf Kubernetes-Workerknoten installiert und konfiguriert. Die Erweiterung ist auf allen neuen und vorhandenen Linux-Knoten installiert. Sie konfiguriert die folgenden Überwachungstools:

• Knotenexporter: Sammelt Hardwaretelemetriedaten von der VM und stellt sie mithilfe eines Metrikendpunkts zur Verfügung. Dann kann ein Überwachungstool wie Prometheus diese Metriken verschrotten.
• Knotenproblemerkennung: Zielt darauf ab, verschiedene Knotenprobleme für Upstream-Ebenen im Clusterverwaltungsstapel sichtbar zu machen. Es handelt sich um eine Systemeinheit, die auf jedem Knoten ausgeführt wird, Knotenprobleme erkennt und diese mithilfe von Ereignissen und Knotenbedingungen an den API-Server des Clusters meldet.
• ig: Ein eBPF-gestütztes Open-Source-Framework zum Debuggen und Beobachten von Linux- und Kubernetes-Systemen. Es stellt eine Reihe von Tools (oder Gadgets) zur Verfügung, mit denen Sie relevante Informationen sammeln und so die Ursache von Leistungsproblemen, Abstürzen oder anderen Anomalien ermitteln können. Dank seiner Unabhängigkeit von Kubernetes können Benutzer*innen es auch zur Fehlersuche bei Problemen auf der Steuerungsebene einsetzen.

Diese Tools helfen bei der Bereitstellung von Einblicken für viele Probleme im Zusammenhang mit der Knotenintegrität, z. B.:

• Infrastrukturdaemonprobleme: NTP-Dienst ausgefallen
• Hardwareprobleme: Fehlerhafte CPU, Arbeitsspeicher oder Datenträger
• Kernelprobleme: Kernel-Deadlock, beschädigtes Dateisystem
• Container-Runtime-Probleme: Nicht reagierender Runtime-Daemon

Die Erweiterung erfordert keinen zusätzlichen ausgehenden Zugriff auf URLs, IP-Adressen oder Ports, die über die dokumentierten ausgehenden AKS-Anforderungen hinausgehen. Es sind keine besonderen in Azure erteilten Berechtigungen erforderlich. Sie verwendet kubeconfig, um eine Verbindung mit dem API-Server herzustellen, um die gesammelten Überwachungsdaten zu senden.