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

  • Artikel
  • 17 Minuten Lesedauer

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:

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.

Sollten Kunden 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 Kunden beachten:

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 TLS-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.

Warum werden zwei Ressourcengruppen mit AKS erstellt?

AKS basiert auf vielen Azure-Infrastrukturressourcen, einschließlich VM-Skalierungsgruppen, virtuellen Netzwerken und verwalteten Datenträgern, die es Ihnen ermöglichen, viele der Kernfunktionen der Azure-Plattform in der von AKS bereitgestellten verwalteten Kubernetes-Umgebung anzuwenden. 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 automatisch die Knotenressourcengruppe, wenn der Cluster gelöscht wird. Sie sollte daher nur für Ressourcen verwendet werden, die den gleichen Lebenszyklus wie der Cluster haben.

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.

  • Die sekundäre Ressourcengruppe wird automatisch vom Azure-Ressourcenanbieter in Ihrem eigenen Abonnement erstellt.
  • 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 Ergebnissen wie 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 für Ressourcen unter der Knotenressourcengruppe im AKS-Cluster dürfen dagegen 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?

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
  • 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 kann der Vorgang zusätzliche Zeit in Anspruch nehmen oder fehlerhaft sein, insbesondere bei Kunden, die ihre eigene Ressourcengruppe verwenden, oder beim Löschen von RG-übergreifenden Aufgaben. 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.

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 einen Cluster löschen, werden auch die zugeordnete Ressourcengruppe und alle zugehörigen Ressourcen gelöscht. Wenn Sie Ihre Ressourcen beibehalten möchten, verschieben Sie sie in eine andere Ressourcengruppe, bevor Sie den Cluster löschen. Wenn Sie über die integrierte Rolle Besitzer oder Benutzerzugriffsadministrator verfügen, können Sie Azure-Ressourcen sperren, um sie vor versehentlichen Löschungen und Änderungen zu schützen. Weitere Informationen finden Sie unter Sperren von Ressourcen zum Schutz Ihrer Infrastruktur.

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

Das können Sie, aber wir raten davon ab. Upgrades sollten ausgeführt werden, 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“ aufweisen oder anderweitig aus dem Cluster entfernt wurden, bevor Sie das Upgrade ausführen.

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

Dies wird in der Regel dadurch verursacht, dass eine oder mehrere Netzwerksicherheitsgruppen (NSGs) noch von Benutzern verwendet werden und 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 den Cluster stattdessen 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 diesem Abschnitt werden die Unterschiede der beiden Modi und die Vorteile bzw. Einschränkungen für die Verwendung des transparenten Modus in Azure CNI erörtert.

Bridge-Modus

Wie der Name vermuten lässt, erstellt Azure CNI im Brückenmodus „just in time“ eine L2-Brücke mit dem Namen „azure0“. 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 fragliche 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 ein untergeordnetes Element für die „azure0“-Bridge konvertiert werden. Dadurch wird eine komplexe Netzwerktopologie innerhalb der Linux-VM erstellt, und als Symptom musste CNI andere Netzwerkfunktionen wie DNS-Serverupdates usw. übernehmen.

Topologie des Bridge-Modus

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 besagt, dass der gesamte Datenverkehr mit Ausnahme des lokalen Datenverkehrs in azure0 über die Schnittstelle mit der IP „src 10.240.0.4“ (die primäre IP-Adresse des Knotens) an das Standardgateway des Subnetzes geleitet wird, und die zweite besagt, dass „10.20.x.x“ Pod-zu-Kernel ist, und der Kernel entscheidet.

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 minimalen 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 IP-Routen, die CNI hinzufügt. Im Wesentlichen erfolgt die Kommunikation zwischen Pods über Ebene 3, und Poddatenverkehr wird durch L3-Routingregeln weitergeleitet.

Topologie des transparenten Modus

Das folgende Beispiel zeigt eine IP-Routeneinrichtung des transparenten Modus. An die Schnittstelle jedes Pods wird eine statische Route angefügt, sodass der 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. Dies 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 per Root-Benutzer 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 schreibbar 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). Dies ist auch der Fall,wenn der Gruppenbesitz des Volumes bereits mit der angeforderten fsGroup übereinstimmt. Für größere Volumes mit vielen kleinen Dateien, bei denen das Starten des Pods lange dauert, kann dies zu hohen Kosten führen. 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 Sicherheitspatches, 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-VMSS-Instanzen installiert sehe?

Die AKS-Linux-Erweiterung ist eine Azure-VM-Erweiterung, deren Zweck darin besteht, Überwachungstools auf Kubernetes-Workerknoten zu installieren und zu konfigurieren. 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. Diese Metriken können dann von einem Überwachungstool wie Prometheus ausgelesen werden.
  • 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.
  • Lokales Gadget: Verwendet eBPF-Hilfsprogramme im Kernel, um Ereignisse zu überwachen, die sich hauptsächlich auf Systemaufrufe aus Programmen im Benutzerbereich eines Pods beziehen.

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.