Häufig gestellte Fragen (FAQ) zu LUIS

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

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.

Weitere Informationen finden Sie in den Plattformunterstützungsrichtlinien.

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.

Weitere Informationen finden Sie unter Unterstützten Kubernetes-Versionen, geplanten Wartungsfensternund automatischen Upgrades.

AKS unterstützt auch Windows Server-Container. Weitere Informationen finden Sie unter Häufig gestellte Fragen zu Windows Server auf AKS.

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.

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

Nein, das Verschieben Ihres AKS-Clusters zwischen Abonnements wird derzeit nicht unterstützt.

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

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.

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.

Sie können einen ausgeführten AKS-Cluster vollständig beenden oder alle oder bestimmte User Knotenpools automatisch auf Null skalieren oder skalieren.

Systemknotenpools können nicht direkt auf Null skaliert werden.

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

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.

Nein, dies ist keine unterstützte Konfiguration. Beenden Sie den Cluster stattdessen.

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.

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 createaz aks create--node-resource-group den Parameter, 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

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.

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

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.

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

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

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.

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.

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

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.

AKS patcht CVEs, für die es einen „Herstellerfix“ gibt wöchentlich. CVEs ohne Korrektur warten auf die Herstellerkorrektur 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.

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

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

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

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.

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.

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.

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.

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.

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.

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.

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

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

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

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.

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.

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.

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.

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

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

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.

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

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