Supportrichtlinien für Azure Kubernetes Service

In diesem Artikel werden Richtlinien und Einschränkungen des technischen Supports für Azure Kubernetes Service (AKS) beschrieben. Außerdem werden die Verwaltung von Agentknoten, Komponenten der verwalteten Control Plane, Open-Source-Komponenten, die nicht von Microsoft stammen, sowie die Sicherheits- bzw. Patchverwaltung beschrieben.

Dienstupdates und -versionen

• Versionsinformationen finden Sie unter AKS-Versionshinweise.
• Informationen zu Vorschaufeatures finden Sie in der Roadmap AKS.

Verwaltete Features in AKS

AKS ist eine Mischung aus Infrastructure as a Service (IaaS) und Platform as a Service (PaaS). Basis-IaaS-Cloudkomponenten wie Compute- oder Netzwerkkomponenten bieten Zugriff auf Steuerelemente und Anpassungsoptionen auf niedriger Ebene. Im Gegensatz dazu bietet AKS eine betriebsbereite Kubernetes-Bereitstellung, die Ihnen die üblichen erforderlichen Konfigurationen und Funktionen für Ihren Cluster zur Verfügung stellt. Als AKS-Benutzer verfügen Sie über eingeschränkte Anpassungs- und Bereitstellungsoptionen und verwalten Kubernetes-Cluster nicht direkt.

Mit AKS erhalten Sie eine vollständig verwaltete Steuerungsebene. Die Steuerungsebene enthält alle Komponenten und Dienste, die Sie benötigen, um die Kubernetes-Cluster zu betreiben und den Endbenutzern zur Verfügung zu stellen. Microsoft verwaltet und betreibt alle Kubernetes-Komponenten.

Microsoft verwaltet und überwacht die folgenden Komponenten über die Steuerungsebene:

• Der Kubernetes-API-Server und kubelet.
• etcd oder einen kompatiblen Schlüsselwertspeicher, der Quality of Service (QoS), Skalierbarkeit und Laufzeit bereitstellt.
• DNS-Dienste wie CoreDNS.
• kube-proxy und Clusternetzwerke, außer wenn BYOCNI verwendet wird.
• Alle zusätzlichen Add-Ons oder Systemkomponenten, die im „kube-system“-Namespace ausgeführt werden.

Einige Komponenten, z. B. Agentknoten, haben gemeinsame Verantwortung, wo Sie beim Verwalten des AKS-Clusters helfen müssen. Benutzereingaben sind z. B. erforderlich, um einen Sicherheitspatch für das Betriebssystem (OS) eines Agentknotens anzuwenden.

Die Dienste sind managed in dem Sinne, dass Microsoft und das AKS-Team die Dienstverfügbarkeit und -funktionalität bereitstellen, betreiben und dafür verantwortlich sind. Kunden können diese verwalteten Komponenten nicht ändern. Microsoft beschränkt die Anpassung, um eine konsistente und skalierbare Benutzererfahrung sicherzustellen.

Gemeinsame Verantwortung

Wenn Sie einen Cluster erstellen, definieren Sie die Kubernetes-Agentknoten, die AKS erstellt. Ihre Workloads werden auf diesen Knoten ausgeführt. Beachten Sie die folgenden Agentknoteneinschränkungen:

• Microsoft-Support hat eingeschränkten Zugriff. Da Ihre Agentknoten private Code ausführen und vertrauliche Daten speichern, können Microsoft-Support sich nicht bei diesen Knoten anmelden, Befehle ausführen oder Protokolle für diese Knoten anzeigen, ohne Ihre ausdrückliche Berechtigung oder Unterstützung.
• Verwenden Sie kubernetes-native Mechanismen für Änderungen. Jegliche Änderungen, die direkt über die IaaS-APIs an den Agentknoten vorgenommen werden, führen dazu, dass der Cluster nicht mehr unterstützt wird. Wenden Sie Änderungen mit Kubernetes-nativen Mechanismen wie einem DaemonSet an.
• Ändern Sie vom System erstellte Metadaten nicht. Sie können Metadaten wie Tags und Bezeichnungen hinzufügen, aber durch Ändern von vom System erstellten Metadaten wird der Cluster nicht unterstützt.

Aufteilung der Verantwortung

Die folgende Matrix fasst die Unterstützungsverantwortung in einem AKS-Cluster zusammen und kontrastiert AKS mit selbstverwalteten Kubernetes, die Sie lokal ausführen. In AKS verwaltet Microsoft die Steuerungsebene und die Kernplattform. Sie verwalten Ihre Knotenkonfiguration, Workloads, Netzwerkkonfiguration und Daten. Freigegebene Bereiche sind der Ort, an dem Microsoft eine Funktion bereitstellt und verwaltet, und Sie aktivieren, konfigurieren oder planen. Verwenden Sie die Matrix als schnellen Überblick, und lesen Sie anschließend die folgenden detaillierten Abschnitte mit Einzelheiten zum Support.

Verwenden Sie den folgenden Schlüssel, um die Matrix zu lesen:

Für die freigegebenen Bereiche in der folgenden Matrix zeigt die Tabelle, was Microsoft bereitstellt und wofür Sie verantwortlich sind:

AKS-Supportabdeckung

In den folgenden Abschnitten werden die unterstützten und nicht unterstützten Szenarien für den technischen Support von AKS beschrieben.

Unterstützte Szenarien

Microsoft bietet technischen Support für die folgenden Beispiele:

Alle Clusteraktionen, die von Microsoft oder AKS ausgeführt werden, werden mit Ihrer Zustimmung unter einer integrierten Kubernetes-Rolle aks-service und einer integrierten Rollenbindung aks-service-rolebindingvorgenommen, die die Rolle an die aks-support Microsoft-Support Dienstidentität bindet. Diese Rolle ermöglicht AKS die Problembehandlung und Diagnose von Clusterproblemen, kann jedoch keine Berechtigungen ändern oder Rollen oder Rollenbindungen erstellen oder andere Aktionen mit hohen Berechtigungen ausführen. Der Rollenzugriff ist nur unter aktiven Supporttickets mit Just-in-time-Zugriff (JIT) aktiviert.

Nicht unterstützte Szenarien

Microsoft bietet keinen technischen Support für die folgenden Szenarien.

Einige dieser Szenarien haben mehr Nuancen darüber, was Microsoft weiterhin unterstützen können. Weitere Informationen finden Sie unter Details zu nicht unterstützten Szenarien.

Details zu nicht unterstützten Szenarien

Mehrere nicht unterstützte Szenarien haben Nuancen darüber hinzugefügt, was Microsoft weiterhin helfen kann:

• Verwenden von Kubernetes. Microsoft-Support bietet keine Ratschläge zum Erstellen von benutzerdefinierten Eingangscontrollern, zum Verwenden von Anwendungsworkloads oder zum Anwenden von Nicht-Microsoft- oder Open-Source-Softwarepaketen oder -tools. Microsoft-Support kann zu AKS-Clusterfunktionen, Anpassungen und Optimierungen beraten (z. B. bei Problemen und Verfahren im Kubernetes-Betrieb).
• Nicht Microsoft Open Source-Projekte. Diese Projekte werden nicht als Teil der Kubernetes-Steuerebene bereitgestellt oder mit AKS-Clustern bereitgestellt und können Istio, Helm, Envoy oder andere umfassen. Microsoft kann für Projekte wie Helm Support im Rahmen des Möglichen bieten. Wenn das Tool mit dem Kubernetes-Cloudanbieter für Azure integriert ist oder andere AKS-spezifische Fehler auftreten, unterstützt Microsoft Beispiele und Anwendungen aus der Microsoft-Dokumentation.
• Netzwerkanpassungen. Für Anpassungen, die nicht in der AKS-Dokumentation aufgeführt sind, können Microsoft-Support keine Geräte oder virtuellen Appliances konfigurieren, die ausgehenden Datenverkehr für den Cluster bereitstellen sollen, z. B. VPNs oder Firewalls. Im Rahmen des Möglichen kann der Microsoft-Support Hinweise zur für Azure Firewall erforderlichen Konfiguration geben, jedoch nicht für andere Nicht-Microsoft-Geräte.
• Nicht-Microsoft-Ingress-Controller. Bei Controllern wie nginx, kong oder traefik umfasst dies Funktionsprobleme, die nach AKS-spezifischen Vorgängen auftreten, z. B. wenn ein Ingress-Controller nach einem Upgrade der Kubernetes-Version nicht mehr funktioniert, was auf Inkompatibilitäten zwischen der Version des Ingress-Controllers und der neuen Kubernetes-Version zurückzuführen sein kann. Als vollständig unterstützte Option sollten Sie eine von Microsoft verwaltete Ingress-Controller-Option in Betracht ziehen.
• Benutzerdefinierte DaemonSet-Skripts. Obwohl die Verwendung von DaemonSet der empfohlene Ansatz zum Anpassen, Ändern oder Installieren von Nicht-Microsoft-Software auf Agentknoten ist, wenn Konfigurationsdateiparameter nicht ausreichen, kann der Microsoft-Support aufgrund ihres benutzerdefinierten Charakters keine Probleme behandeln, die durch die benutzerdefinierten Skripts entstehen.
• Bereitschafts- und proaktive Unterstützung. Microsoft-Support bietet reaktive Unterstützung, um aktive Probleme zu lösen. Standby- oder proaktive Unterstützung, um betriebsbedingte Risiken zu beseitigen, die Verfügbarkeit zu erhöhen und die Leistung zu optimieren, wird nicht abgedeckt. Berechtigte Kunden können sich an ihr Kontoteam wenden, um für Azure Event Management Service, einen kostenpflichtigen Dienst, der eine proaktive Lösungsrisikobewertung und Abdeckung während des Ereignisses umfasst, nominiert zu werden.
• CVEs, die nicht älter als 30 Tage sind. Solange Sie die aktualisierte VHD ausführen, sollten Sie keine Containerimage-CVEs mit einem Anbieter-Fix haben, der älter als 30 Tage ist. Sie sind dafür verantwortlich, die VHD zu aktualisieren, anschließend den CVE-Bericht zu filtern und dem Microsoft-Support eine Liste bereitzustellen, die nur die CVEs mit einem vom Anbieter bereitgestellten Fix enthält, der älter als 30 Tage ist. Microsoft arbeitet dann intern daran, Komponenten mit einem Anbieter-Fix zu adressieren, der vor mehr als 30 Tagen veröffentlicht wurde. Microsoft bietet nur CVE-bezogene Unterstützung für Microsoft verwaltete Komponenten, z. B. AKS-Knotenimages und verwaltete Containerimages, die während der Clustererstellung oder über ein verwaltetes Add-On bereitgestellt werden. Weitere Informationen finden Sie unter Sicherheitsrisikoverwaltung für Azure Kubernetes Service (AKS).
• Benutzerdefinierte Codebeispiele. Microsoft-Support können kleine Codebeispiele in einem Supportfall bereitstellen und überprüfen, um zu veranschaulichen, wie Features eines Microsoft Produkts verwendet werden, aber keine benutzerdefinierten Codebeispiele für Ihre Umgebung oder Anwendung bereitstellen können.
• Benutzerdefinierte Azure Policy Logik. Microsoft-Support können allgemeine Anleitungen dazu bereitstellen, wie benutzerdefinierte Azure Policy Definitionen in AKS angewendet und ausgewertet werden. Die eingehende Fehleranalyse kundenseitig erstellter Richtlinienlogik (einschließlich Rego-basierter Richtlinien), etwa warum eine bestimmte Richtlinie einen Workload zulässt oder ablehnt, fällt im Allgemeinen nicht in den Supportumfang.

Bringen Sie Ihre eigenen CNI-Supportgrenzen mit

Wenn Sie mithilfe von --network-plugin none einen Cluster mit Bring Your Own CNI (BYOCNI) bereitstellen, kann Ihnen der Microsoft-Support bei CNI-bezogenen Problemen nicht helfen. Sie sind für den CNI-Plug-In-Lebenszyklus verantwortlich, und Sie sollten unterstützung vom CNI-Plug-In-Anbieter suchen. Microsoft unterstützt weiterhin Probleme, die nicht mit dem CNI zusammenhängen.

Weitere Informationen finden Sie unter Bring your own CNI (BYOCNI).

AKS-Supportabdeckung für Agentknoten

In den folgenden Abschnitten werden die Verantwortlichkeiten von Microsoft und die des Kunden für AKS-Agentknoten beschrieben.

In der folgenden Tabelle sind die Verantwortlichkeiten des Agentknotens auf einen Blick zusammengefasst. Die folgenden Abschnitte enthalten die Details.

Microsoft-Verantwortungen für AKS-Agentenknoten

Microsoft und Sie teilen die Verantwortung für Kubernetes-Agentknoten.

• Das Basis Image des Betriebssystems verfügt über notwendige Ergänzungen wie Überwachungs- und Netzwerk Agents.
• Die Agentknoten erhalten Betriebssystempatches automatisch.
• Das System behebt automatisch Probleme mit den Control-Plane-Komponenten von Kubernetes, die auf den Agent-Knoten ausgeführt werden. Zu diesen Komponenten gehören die folgenden Elemente:
  • kube-proxy
  • Netzwerktunnel, die Kommunikationspfade zur Kubernetes-Steuerungsebene bereitstellen
  • kubelet
  • containerd

Wenn ein Agentknoten nicht betriebsbereit ist, startet AKS möglicherweise einzelne Komponenten oder den gesamten Agentknoten neu. Diese Neustartvorgänge sind automatisiert und stellen eine Autoremediation für häufige Probleme bereit. Weitere Informationen zu den Autoremediationsmechanismen finden Sie unter Node Auto-Repair.

Kundenzuständigkeiten für AKS-Agentknoten

Microsoft stellt wöchentlich Patches und neue Bilder für Ihre Bildknoten bereit. Damit Ihr Agentknotenbetriebssystem und die Laufzeitkomponenten auf dem neuesten Stand sind, sollten Sie diese Patches und Updates regelmäßig manuell oder automatisch anwenden. Microsoft unterstützt keine Knotenimages, die älter als 90 Tage sind. Weitere Informationen finden Sie unter

• Aktualisieren Sie AKS-Knotenimages manuell.
• Automatisches Upgrade von AKS-Knotenimages.

AKS veröffentlicht zudem regelmäßig Releases neuer Kubernetes-Patches und -Nebenversionen. Diese Updates können Verbesserungen der Sicherheit oder Funktionalität von Kubernetes enthalten. Sie sind dafür verantwortlich, dass die Kubernetes-Version Ihres Clusters stets aktualisiert wird und der Richtlinie zur Unterstützung der AKS Kubernetes-Version entspricht.

Benutzeranpassung von Agentknoten

AKS verwaltet den Lebenszyklus und die Vorgänge von Agent-Knoten für Sie. Das Ändern der IaaS-Ressourcen, die den Agent-Knoten zugeordnet sind, wird nicht unterstützt. Ein Beispiel für einen nicht unterstützten Vorgang ist das Anpassen eines Skalierungsmaßstabs eines Knotenpools durch manuelles Ändern von Konfigurationen im Azure-Portal oder aus der API.

Für Workload-spezifische Konfigurationen oder Pakete empfiehlt AKS die Verwendung eines Kubernetes DaemonSet.

Die Verwendung von privilegierten Kubernetes-DaemonSet- und init-Containern ermöglicht es Ihnen, Nicht-Microsoft-Software auf Cluster-Agent-Knoten anzupassen, zu ändern oder zu installieren. Beispiele für solche Anpassungen sind das Hinzufügen von benutzerdefinierter Software für Sicherheitsscans oder das Aktualisieren von sysctl-Einstellungen.

Obwohl dieser Pfad empfohlen wird, wenn die oben genannten Anforderungen gelten, kann das AKS-Engineering und der -Support nicht bei der Problembehandlung oder Diagnose von Änderungen helfen, die den Knoten aufgrund einer benutzerdefinierten Bereitstellung DaemonSet nicht verfügbar machen.

Sicherheitsprobleme und -patches

Wenn ein Sicherheitsproblem in einer oder mehreren verwalteten Komponenten von AKS auftritt, wird das AKS-Team alle betroffenen Cluster patchen, um das Problem zu beheben. Alternativ erhalten Sie vom AKS-Team eine Anleitung zum Upgrade.

Bei Agentknoten, die von einem Sicherheitsfehler betroffen sind, werden Sie von Microsoft über die Auswirkungen und die Schritte zum Beheben oder Abschwächen des Sicherheitsproblems benachrichtigt.

Knotenwartung und -zugriff

Obwohl Sie sich an Agent-Knoten anmelden und Änderungen daran vornehmen können, führen Sie diesen Vorgang nicht durch. Änderungen können dazu führen, dass ein Cluster nicht mehr unterstützt werden kann.

Netzwerkports, Zugriff und NSGs

Sie können Netzwerksicherheitsgruppen (NSGs) nur für benutzerdefinierte Subnetze anpassen. Die folgende Tabelle zeigt, wo Sie NSGs anpassen können:

AKS hat Anforderungen für ausgehenden Datenverkehr an bestimmte Endpunkte. Um den ausgehenden Datenverkehr zu kontrollieren und die erforderliche Konnektivität sicherzustellen, siehe ausgehenden Datenverkehr begrenzen. Für Ingress richten sich die Anforderungen nach den Anwendungen, die Sie im Cluster bereitstellen.

Knoten mit Status „Beendet“, „Zuordnung aufgehoben“ und „Nicht bereit“

Die folgende Tabelle fasst zusammen, was mit einem AKS-Cluster in den einzelnen Phasen des Lebenszyklus und innerhalb des zugehörigen Zeitrahmens geschieht:

Wenn Ihre AKS-Workloads nicht kontinuierlich ausgeführt werden müssen, beenden Sie den AKS-Cluster, der alle Knotenpools und die Kontrollebene stoppt, und starten Sie sie bei Bedarf erneut. Das manuelle Freigeben von Knoten über die IaaS-APIs, die Azure CLI oder das Azure-Portal ist keine unterstützte Methode, um einen Cluster zu beenden.

AKS behält sich das Recht vor, Control Planes zu archivieren, die seit 30 Tagen oder länger nicht den Supportrichtlinien entsprechen. AKS verwaltet Sicherungen von Clustermetadaten etcd und kann den Cluster in jedem PUT-Vorgang neu gliedern, der ihn wieder unterstützt, z. B. ein Upgrade oder eine Skalierung auf aktive Agentknoten.

Nicht unterstützte Kubernetes-Features der Alpha- und Betaversion

AKS unterstützt stabile und Betafeatures innerhalb des upstream-Kubernetes-Projekts, jedoch keine Alpha-Features, sofern nicht anders dokumentiert. In der folgenden Tabelle wird die Unterstützung nach Featuretyp zusammengefasst:

Previewfunktionen oder Featureflags

Für Features und Funktionen, die erweiterte Tests und Benutzerfeedback erfordern, veröffentlicht Microsoft neue Vorschaufeatures oder Features hinter einer Featurekennzeichnung. Betrachten Sie diese Features als Features einer Vorab- oder Betaversion.

Previewfunktionen oder Features mit Featureflag sind nicht für die Produktionsumgebung vorgesehen. Kontinuierliche Änderungen an APIs und am Verhalten, Fehlerbehebungen und andere Änderungen können zu instabilen Clustern und Ausfallzeiten führen.

Features in der öffentlichen Vorschau fallen unter Best-Effort-Support, da sich diese Funktionen in der Vorschauphase befinden und nicht für den produktiven Einsatz vorgesehen sind. Die technischen Supportteams von AKS unterstützen nur während der Geschäftszeiten. Weitere Informationen finden Sie unter Azure Support faq.

Upstream-Fehler und -Probleme

Angesichts des hohen Tempos bei der Entwicklung im Upstream-Kubernetes-Projekt können immer wieder Fehler auftreten. Einige dieser Fehler können innerhalb des AKS-Systems nicht gepatcht oder umgangen werden. Stattdessen erfordern Bugfixes größere Patches für Upstreamprojekte (z. B. Kubernetes, Knoten- oder Agentbetriebssysteme und Kernel). Für Komponenten, die Microsoft besitzt (z. B. der Azure Cloud-Dienstanbieter), sind AKS- und Azure-Mitarbeiter verpflichtet, Probleme in der Community upstream zu lösen.

Sollte ein technisches Supportproblem auf einen oder mehrere Upstream-Fehler zurückzuführen sein, führen die Support- und Entwicklungsteams von AKS folgende Schritte aus:

• Identifizieren und Verknüpfen aller Upstream-Fehler mit unterstützenden Details, die Aufschluss darüber geben, warum sich dadurch Auswirkungen für Ihren Cluster und/oder Ihre Workload ergeben. Kunden erhalten Links zu den erforderlichen Repositorys, damit sie die Probleme überwachen und sehen können, wann eine neue Version Korrekturen bereitstellt.
• Bereitstellen möglicher Problemumgehungen oder Gegenmaßnahmen. Wenn das Problem behoben werden kann, wird ein bekanntes Problem im AKS-Repository erfasst. In der Meldung über bekannte Probleme wird erklärt:
  • Das Problem, einschließlich Links zu upstream-Fehlern.
  • Die Problemumgehung und Details zu einem Upgrade oder einer anderen Persistenz der Lösung.
  • Grober Zeitplan für die Einbeziehung des Problems auf der Grundlage des Upstream-Releaserhythmus.

Verwandte Inhalte

• AKS-Preisniveaus
• Unterstützte Kubernetes-Versionen in AKS
• Langfristige Unterstützung für AKS
• Automatisches Upgraden eines AKS-Clusters
• AKS-Knotenbetriebssystemimages automatisch aktualisieren
• Sicherheitsrisikoverwaltung für AKS
• Automatische AKS-Knotenreparatur
• Bring your own CNI (BYOCNI)