Unterstützungsrichtlinien für Azure Kubernetes Service

Dieser Artikel enthält Details zu den Richtlinien und Einschränkungen für den technischen Support von Azure Kubernetes Service (AKS). Der Artikel beschreibt auch die Agentknotenverwaltung, verwaltete Steuerungsebenenkomponenten, Open-Source-Komponenten von Drittanbietern sowie die Sicherheits- oder Patchverwaltung.

Dienstupdates und -versionen

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

Verwaltete Features in AKS

IaaS-Cloudkomponenten (Infrastructure-as-a-Service) der Basisinfrastruktur, z. B. Compute- oder Netzwerkkomponenten, bieten Ihnen 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. Allerdings müssen Sie sich nicht direkt um Kubernetes-Cluster kümmern oder diese verwalten.

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:

• Kubelet- oder Kubernetes-API-Server
• Etcd oder ein kompatibler Schlüssel-Wert-Speicher, der Servicequalität (QoS, Quality of Service), Skalierbarkeit und Laufzeit bietet
• DNS-Dienste (z. B. kube-dns oder CoreDNS)
• Kubernetes-Proxy oder -Netzwerk, außer bei Verwendung von BYOCNI
• Alle zusätzlichen Add-Ons oder Systemkomponenten, die im „kube-system“-Namespace ausgeführt werden.

AKS ist keine PaaS-Lösung (Platform-as-a-Service). Einige Komponenten, z. B. Agentknoten, weisen eine gemeinsame Verantwortung auf, wobei Sie bei der Verwaltung 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 in dem Sinne verwaltet, dass Microsoft und das AKS-Team die Dienste bereitstellen, betreiben und für deren Verfügbarkeit und Funktionalität verantwortlich sind. Kunden können diese verwalteten Komponenten nicht ändern. Microsoft beschränkt die Anpassung, um eine konsistente und skalierbare Benutzererfahrung zu gewährleisten.

Gemeinsame Verantwortung

Wenn ein Cluster erstellt wird, definieren Sie die Kubernetes-Agentknoten, die von AKS erstellt werden. Auf diesen Knoten werden Ihre Workloads ausgeführt.

Da die Agentknoten privaten Code ausführen und vertrauliche Daten speichern, kann der Microsoft-Support nur eingeschränkt darauf zugreifen. Der Microsoft-Support kann sich ohne Ihre ausdrückliche Genehmigung oder Hilfe nicht bei diesen Knoten anmelden, Befehle ausführen oder Protokolle anzeigen.

Jede Änderung, die mithilfe einer der IaaS-APIs direkt an den Agentknoten vorgenommen wird, führt dazu, dass der Cluster nicht mehr unterstützt werden kann. Jede Änderung an den Agentknoten muss mithilfe nativer Kubernetes-Mechanismen, z. B. Daemon Sets, vorgenommen werden.

Ebenso führt das Ändern der vom System erstellten Metadaten dazu, dass der Cluster nicht mehr unterstützt werden kann. Sie können jedoch dem Cluster und den Knoten Metadaten, z. B. Tags und Bezeichnungen, hinzufügen.

AKS-Supportabdeckung

Unterstützte Szenarios

In den folgenden Beispielen bietet Microsoft technischen Support:

• Konnektivität mit allen Kubernetes-Komponenten, die vom Kubernetes-Dienst bereitgestellt und unterstützt werden (beispielsweise der API-Server).
• Verwaltung, Betriebszeit, QoS und Vorgänge der Kubernetes-Steuerungsebenendienste (beispielsweise Kubernetes-Steuerungsebene, API-Server, etcd und coreDNS).
• etcd-Datenspeicher. Der Support beinhaltet automatisierte, transparente Sicherungen sämtlicher etcd-Daten im 30-Minuten-Takt für die Planung der Notfallwiederherstellung und die Wiederherstellung des Clusterzustands. Diese Sicherungen sind für Sie und andere Benutzer nicht direkt verfügbar. Sie stellen die Zuverlässigkeit und Konsistenz der Daten sicher. On-Demand-Rollback oder eine Wiederherstellung wird als Feature nicht unterstützt.
• Alle Integrationspunkte im Azure-Cloudanbietertreiber für Kubernetes. Dazu gehören Integrationen in andere Azure-Dienste wie Lastenausgleichsmodule, persistente Volumes oder Netzwerke (Kubernetes und Azure CNI), außer bei Verwendung von BYOCNI.
• Fragen oder Probleme zur Anpassung von Komponenten der Steuerungsebene wie Kubernetes-API-Server, etcd und coreDNS.
• Probleme bei Netzwerken, z. B. Azure CNI, Kubenet oder andere Probleme in Verbindung mit Netzwerkzugriff und -funktionalität, außer bei Verwendung von BYOCNI. Probleme können DNS-Auflösung, Paketverluste, Routing usw. umfassen. Microsoft unterstützt verschiedene Netzwerkszenarien:
  • Kubenet und Azure CNI mit verwalteten VNETs oder benutzerdefinierten Subnetzen (Bring Your Own).
  • Konnektivität mit anderen Azure-Diensten und -Anwendungen
  • Von Microsoft verwaltete Eingangscontroller oder Konfigurationen des Lastenausgleichs
  • Netzwerkleistung und Wartezeit
  • Von Microsoft verwaltete Netzwerkrichtlinien – Komponenten und Funktionen

Hinweis

Alle von Microsoft/AKS ausgeführten Clusteraktionen werden mit Benutzereinwilligung unter der integrierten Kubernetes-Rolle aks-service und der integrierten Rollenbindung aks-service-rolebinding durchgeführt. Diese Rolle ermöglicht es AKS, Clusterprobleme zu beheben und zu diagnostizieren, damit können jedoch keine Berechtigungen geändert oder Rollen bzw. Rollenbindungen erstellt oder andere Aktionen mit hohen Berechtigungen ausgeführt werden. Der Rollenzugriff ist nur unter aktiven Supporttickets mit Just-in-time-Zugriff (JIT) aktiviert.

Nicht unterstützte Szenarien

In den folgenden Szenarien bietet Microsoft keinen technischen Support:

• Fragen zur Verwendung von Kubernetes. Der Microsoft-Support bietet z. B. keine Empfehlungen zur Erstellung benutzerdefinierter Eingangscontroller, zur Verwendung von Anwendungsworkloads oder zur Anwendung von Open-Source-Softwarepaketen oder -Tools bzw. zu Softwarepaketen oder Tools von Drittanbietern.

  Hinweis

  Der Microsoft-Support kann Sie hinsichtlich der AKS-Clusterfunktionalität, der Anpassung und der Optimierung beraten (z. B. Kubernetes-Betriebsprobleme und -verfahren).

• Open-Source-Projekte von Drittanbietern, die nicht im Rahmen der Kubernetes-Steuerungsebene bereitgestellt oder mit AKS-Clustern bereitgestellt wurden. Diese Projekte können Istio, Helm, Envoy und andere einbeziehen.

  Hinweis

  Microsoft kann den bestmöglichen Support für Open-Source-Projekte von Drittanbietern wie Helm bereitstellen. Wenn das Open-Source-Tool eines Drittanbieters mit den vom Kubernetes Azure-Cloudanbieter stammenden oder anderen AKS-spezifischen Fehlern integriert wird, unterstützt Microsoft Beispiele und Anwendungen aus der Microsoft-Dokumentation.

• Closed-Source-Software von Drittanbietern. Diese Software kann z. B. Tools für Sicherheitsscans und Netzwerkgeräte oder -software umfassen.

• Konfigurieren oder Behandeln von anwendungsspezifischem Code oder Verhalten von Anwendungen oder Tools von Drittanbietern, die im AKS-Cluster ausgeführt werden. Dies schließt Bereitstellungsprobleme von Anwendungen ein, die sich nicht auf die AKS-Plattform selbst beziehen.

• Ausstellung, Verlängerung oder Verwaltung von Zertifikaten für Anwendungen, die auf AKS ausgeführt werden.

• Andere als die in der AKS-Dokumentation aufgeführten Netzwerkanpassungen. Der Microsoft-Support kann beispielsweise keine Geräte oder virtuelle Appliances konfigurieren, die ausgehenden Datenverkehr für den AKS-Cluster bereitstellen sollen, z. B. VPNs oder Firewalls.

  Hinweis

  Nach bestmöglichem Bemühen kann der Microsoft-Support bei der Frage nach der erforderlichen Konfiguration für Azure Firewall beraten, jedoch nicht für Drittanbietergeräte.

• Benutzerdefinierte CNI-Plug-Ins oder CNI-Plug-Ins von Drittanbietern, die im BYOCNI-Modus verwendet werden.

• Konfigurieren oder Beheben von Netzwerkrichtlinien, die nicht von Microsoft verwaltet werden. Während die Verwendung von Netzwerkrichtlinien unterstützt wird, kann der Microsoft-Support keine Probleme untersuchen, die sich aus benutzerdefinierten Netzwerkrichtlinienkonfigurationen ergeben.

• Konfigurieren oder Beheben von Eingangscontrollern, die nicht von Microsoft verwaltet werden (z. B. nginx, kong und traefik). Dies umfasst die Behandlung von Funktionalitätsproblemen, die nach AKS-spezifischen Vorgängen auftreten, z. B. ein Eingangscontroller, der nach einem Kubernetes-Versionsupgrade nicht mehr funktioniert. Solche Probleme können sich aus Inkompatibilitäten zwischen der Eingangscontrollerversion und der neuen Kubernetes-Version ergeben. Für eine vollständig unterstützte Option sollten Sie eine von Microsoft verwaltete Eingangscontrolleroption nutzen.

• Konfigurieren oder Problembehandlung von DaemonSets (einschließlich Skripts), die zum Anpassen von Knotenkonfigurationen verwendet werden. Obwohl die Verwendung von DaemonSets der empfohlene Ansatz zum Optimieren, Ändern oder Installieren von Drittanbietersoftware auf Cluster-Agent-Knoten bei unzureichenden Konfigurationsdateiparametern ist, kann der Microsoft-Support aufgrund ihrer benutzerdefinierten Natur keine Probleme beheben, die aus den in DaemonSets verwendeten benutzerdefinierten Skripts entstehen.

• Standby- und proaktive Szenarien. Microsoft-Support bietet reaktive Unterstützung, um aktive Probleme rechtzeitig und professionell zu lösen. Standby- oder proaktiver Support, der Ihnen hilft, betriebsbedingte Risiken zu beseitigen, die Verfügbarkeit zu erhöhen und die Leistung zu optimieren, wird jedoch nicht abgedeckt. Berechtigte Kunden können sich an ihr Kontoteam wenden, um für den Azure Event Management Service nominiert zu werden. Es handelt sich um einen kostenpflichtigen Dienst, der von Microsoft-Supporttechnikern bereitgestellt wird und eine proaktive Lösungsrisikobewertung und -abdeckung während der Veranstaltung umfasst.

• Sicherheitsrisiken/CVEs mit einem Herstellerfix, der weniger als 30 Tage alt ist. Solange Sie die aktualisierte VHD ausführen, sollten Ihre Containerimages keine Sicherheitsrisiken/CVEs aufweisen, deren Herstellerfix älter als 30 Tage ist. Es liegt in der Verantwortung des Kunden, die VHD zu aktualisieren und dem Microsoft-Support gefilterte Listen bereitzustellen. Nachdem Sie Ihre VHD aktualisiert haben, liegt es in Ihrer Verantwortung, den Bericht zu Sicherheitsrisiken/CVEs zu filtern und eine Liste der Sicherheitsrisiken/CVEs mit Herstellerfix bereitzustellen, der älter als 30 Tage ist. In diesem Fall stellt der Microsoft-Support sicher, dass intern ein Fix für Komponenten erarbeitet wird, deren Herstellerfix älter als 30 Tage ist. Darüber hinaus bietet Microsoft spezifischen Support zu Sicherheitsrisiken/CVEs für nur von Microsoft verwaltete Komponenten (d. h. AKS-Knotenimages, verwaltete Containerimages für Anwendungen, die bei der Clustererstellung oder der Installation eines verwalteten Add-Ons bereitgestellt werden). Weitere Informationen zum Sicherheitsrisikomanagement für AKS finden Sie auf dieser Seite.

• Benutzerdefinierte Codebeispiele oder Skripts. Der Microsoft-Support kann zwar in einem Supportfall kleine Codebeispiele und Rezensionen kleiner Codebeispiele bereitstellen, um zu veranschaulichen, wie Features eines Microsoft-Produkts verwendet werden können, er kann jedoch keine benutzerdefinierten Codebeispiele bereitstellen, die für Ihre Umgebung oder Anwendung spezifisch sind.

AKS-Supportabdeckung für Agentknoten

Zuständigkeiten von Microsoft für AKS-Agentknoten

Microsoft und die Benutzer teilen sich die Verantwortung für die Kubernetes-Agentknoten, für die Folgendes gilt:

• Das Basisbetriebssystem-Image verfügt über die erforderlichen Ergänzungen (wie etwa Überwachungs- und Netzwerk-Agents)
• Die Agentknoten erhalten Betriebssystempatches automatisch.
• Probleme bei Komponenten der Kubernetes-Steuerungsebene, die auf den Agentknoten ausgeführt werden, werden automatisch behoben. Zu diesen Komponenten gehören die folgenden:
  • Kube-proxy
  • Netzwerktunnel zur Bereitstellung von Kommunikationspfaden zu Kubernetes-Masterkomponenten
  • Kubelet
  • containerd

Hinweis

Wenn ein Agentknoten nicht funktionstüchtig ist, kann AKS einzelne Komponenten oder den gesamten Agentknoten neu starten. Diese Neustartvorgänge sind automatisiert und ermöglichen eine automatische Wiederherstellung bei häufigen Problemen. Weitere Informationen zu den Mechanismen für die automatische Wiederherstellung finden Sie unter Automatisches Reparieren von AKS-Knoten.

Kundenzuständigkeiten für AKS-Agentknoten

Microsoft stellt für Ihre Knotenimages wöchentlich Patches und neue Images zur Verfügung. Damit Ihr Agentknotenbetriebssystem und die Laufzeitkomponenten auf dem neuesten Stand sind, sollten Sie diese Patches und Updates regelmäßig manuell oder automatisch anwenden. Weitere Informationen finden Sie unter:

• Manuelles Upgrade von AKS-Knotenimages
• 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

Hinweis

AKS-Agentknoten werden im Azure Portal als standardmäßige Azure IaaS-Ressourcen angezeigt. Diese virtuellen Computer werden jedoch in einer benutzerdefinierten Azure-Ressourcengruppe bereitgestellt (mit dem Präfix MC_*). Sie können mit den IaaS-APIs- oder -Ressourcen keine Änderungen am Basisbetriebssystemimage oder direkte Anpassungen an diesen Knoten vornehmen. Benutzerdefinierte Änderungen, die nicht über die AKS-API erfolgen, werden nicht beibehalten, wenn Upgrades, Skalierungen, Updates oder Neustarts durchgeführt werden. Außerdem kann jede Änderung an den Erweiterungen der Knoten wie CustomScriptExtension zu unerwartetem Verhalten führen und sollte nicht zulässig sein. Nehmen Sie keine Änderungen an den Agentknoten vor, es sei denn, Sie werden vom Microsoft-Support zum Vornehmen von Änderungen angewiesen.

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 einer VM-Skalierungsgruppe eines Knotenpools durch manuelles Ändern der Konfigurationen über das VMSS-Portal oder die VMSS-API.

Für workloadspezifische Konfigurationen oder Pakete empfiehlt AKS die Verwendung von Kubernetesdaemon sets.

Durch die Verwendung von privilegierten Kubernetes-daemon sets und -Startcontainern können Sie Software von Drittanbietern auf Cluster-Agentknoten optimieren, ändern oder installieren. Beispiele für solche Anpassungen sind das Hinzufügen von benutzerdefinierter Software für Sicherheitsscans oder das Aktualisieren von sysctl-Einstellungen.

Dieser Ansatz wird empfohlen, wenn die oben genannten Anforderungen zutreffen. Das AKS-Engineeringteam und der AKS-Support können Sie nicht bei der Diagnose oder Behebung von Problemen unterstützen, durch die der Knoten aufgrund eines bereitgestellten benutzerdefinierten daemon set nicht verfügbar ist.

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 Sicherheitsrisiko betroffen sind, werden Sie von Microsoft ausführlich über die Auswirkungen und die Schritte zum Beheben oder Mindern des Sicherheitsproblems benachrichtigt.

Knotenwartung und -zugriff

Obwohl Sie sich bei Agentknoten anmelden und diese ändern können, ist dies nicht empfehlenswert, da Änderungen dazu führen können, dass ein Cluster nicht mehr unterstützt wird.

Netzwerkports, Zugriff und NSGs

Sie können die NGSs nur für benutzerdefinierte Subnetze anpassen. NSGs können nicht in verwalteten Subnetzen oder auf NIC-Ebene der Agentknoten angepasst werden. In AKS gelten Anforderungen für ausgehenden Datenverkehr an bestimmte Endpunkte, um den ausgehenden Datenverkehr zu steuern und die erforderliche Konnektivität sicherzustellen. Weitere Informationen finden Sie unter Steuern des ausgehenden Datenverkehrs für Clusterknoten in Azure Kubernetes Service (AKS). Für eingehenden Datenverkehr basieren die Anforderungen auf den Anwendungen, die Sie im Cluster bereitgestellt haben.

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

Wenn Ihre AKS-Workloads nicht kontinuierlich ausgeführt werden müssen, können Sie den AKS-Cluster beenden. Dadurch werden alle Knotenpools und die Steuerungsebene beendet. Sie können ihn bei Bedarf erneut starten. Wenn Sie einen Cluster mithilfe des Befehls az aks stop beenden, wird der Clusterstatus bis zu zwölf Monate lang beibehalten. Nach zwölf Monaten werden der Clusterstatus und alle zugehörigen Ressourcen gelöscht.

Das manuelle Aufheben der Zuordnung aller Clusterknoten aus den IaaS-APIs, der Azure CLI oder dem Azure-Portal wird nicht unterstützt, um einen AKS-Cluster oder -Knotenpool zu beenden. Der Cluster wird als nicht unterstützt betrachtet und von AKS nach 30 Tagen beendet. Die Cluster unterliegen dann der gleichen zwölfmonatigen Beibehaltungsrichtlinie wie ein ordnungsgemäß beendeter Cluster.

Cluster mit 30 Knoten mit dem Status Bereit (oder Cluster, in denen alle Knoten den Status Nicht bereit haben) und 0 ausgeführten VMs werden nach 30 Tagen beendet.

AKS behält sich vor, Steuerungsebenen zu archivieren, die außerhalb der Supportrichtlinien für verlängerte Zeiträume ab 30 Tagen konfiguriert wurden. AKS verwaltet Sicherungen von etcd-Metadaten der Cluster und kann den Cluster jederzeit neu zuweisen. Diese erneute Zuweisung kann mit jedem PUT-Vorgang initiiert werden, der den Cluster wieder unterstützungsfähig macht, z. B. durch ein Upgrade oder eine Skalierung auf aktive Agent-Knoten.

Alle Cluster in einem angehaltenen Abonnement werden sofort beendet und nach 90 Tagen gelöscht. Alle Cluster in einem gelöschten Abonnement werden sofort gelöscht.

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

AKS bietet nur Support für stabile Features und Betafeatures im Rahmen des Upstream-Kubernetes-Projekts. Sofern nicht anderweitig dokumentiert, unterstützt AKS keine Alphafeatures, die im Upstream-Kubernetes-Projekt verfügbar sind.

Previewfunktionen oder Featureflags

Für Features und Funktionen, die ausführliche Tests und Benutzerfeedback erfordern, veröffentlicht Microsoft neue Previewfunktionen oder Features hinter einem Featureflag. 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 die Unterstützung für optimale Anstrengungen, da sich diese Features in der Vorschau befinden und nicht für die Produktion vorgesehen sind. Die technischen Supportteams von AKS bieten Support nur während der Geschäftszeiten. Weitere Informationen finden Sie unter Häufig gestellte Fragen zum Azure-Support.

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 Fehlerbehebungen größere Patches für Upstream-Projekte (z. B. Kubernetes, Betriebssysteme für Knoten oder Agents sowie Kernel). Bei Komponenten, die sich im Besitz von Microsoft befinden (z. B. der Azure-Cloudanbieter), kümmern sich die AKS-/Azure-Mitarbeiter um die Upstream-Behebung des Problems in der Community.

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 beobachten und feststellen können, wann eine neue Version die Fehlerbehebung ermöglicht.

• Bereitstellen möglicher Problemumgehungen oder Gegenmaßnahmen. Wenn das Problem behoben werden kann, wird ein bekanntes Problem im AKS-Repository erfasst. Bei der Erfassung des „Bekannten Problems“ wird Folgendes erläutert:

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