Freigeben über

Supportrichtlinien für von Azure Arc aktivierte AKS

  • Artikel

Gilt für: AKS auf Azure Stack HCI 22H2, AKS unter Windows Server

Dieser Artikel enthält Details zu technischen Supportrichtlinien und Einschränkungen für von Arc aktivierte AKS. Der Artikel beschreibt auch die Clusterknotenverwaltung, Steuerungsebenenkomponenten, Open-Source-Komponenten von Drittanbietern und Die Sicherheits- oder Patchverwaltung.

Dienstupdates und -versionen

  • Microsoft bietet ein Supportfenster von 1 Jahr für jede Kubernetes-Nebenversion ab dem ersten Veröffentlichungsdatum. Während dieses Zeitraums veröffentlicht AKS Arc nachfolgende Neben- oder Patchversionen, um den laufenden Support sicherzustellen.
  • Ein Kubernetes-Cluster, der auf einer veralteten Nebenversion arbeitet, muss auf eine unterstützte Version aktualisiert werden, um für den Support berechtigt zu sein.
  • Sobald eine Nebenversion veraltet ist, funktionieren weiterhin alle Cluster, die auf dieser Version ausgeführt werden. Sie können weiterhin Vorgänge ausführen, z. B. die Skalierung nach oben oder unten, aber AKS Arc zeigt während clustervorgängen eine Warnung an.
  • Sobald eine Nebenversion veraltet ist, wird sie von den Microsoft-Servern entfernt. Zu diesem Zeitpunkt können Kubernetes-Cluster, die diese Version verwenden, keine Kubernetes- oder Betriebssystemversionen aktualisieren und auf die neueste Version aktualisiert werden. In einigen Fällen kann dieses Upgrade auch eine vollständige erneute Bereitstellung bedeuten, wenn sich das System nicht in einem fehlerfreien Zustand befindet.

Versionsinformationen finden Sie in den Versionshinweisen zu AKS Arc. Informationen zu Features in der Vorschau finden Sie unter AKS Arc Preview-Features.

Verwaltete Features in AKS Arc

Als AKS Arc-Benutzer haben Sie eingeschränkte Anpassungs- und Bereitstellungsoptionen. Sie müssen sich jedoch keine Gedanken machen oder Kubernetes-Clustersteuerungsebene und -installation direkt verwalten. Cloudkomponenten der Basisinfrastruktur as-a-Service (IaaS), z. B. Compute- oder Netzwerkkomponenten, ermöglichen den Zugriff auf Steuerelemente und Anpassungsoptionen auf niedriger Ebene.

Im Gegensatz dazu bietet AKS Arc eine schlüsselfertige Kubernetes-Bereitstellung, die Ihnen die gemeinsamen Konfigurationen und Funktionen bietet, die Sie für Ihren Cluster benötigen. Mit AKS Arc erhalten Sie eine teilweise 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 alle Kubernetes-Komponenten.

Microsoft verwaltet die folgenden Komponenten über den Verwaltungscluster und die zugehörigen Basisimages für virtuelle Computer:

  • kubelet oder Kubernetes-API-Server.
  • etcd oder einen kompatiblen Schlüsselwertspeicher, der Quality of Service (QoS), Skalierbarkeit und Laufzeit bereitstellt.
  • DNS-Dienste (z. B kube-dns . CoreDNS).
  • Kubernetes-Proxy oder Netzwerk.
  • Alle anderen Add-On- oder Systemkomponenten, die kube-system im Namespace ausgeführt werden.

AKS Arc ist keine Platform-as-a-Service (PaaS)-Lösung. Einige Komponenten, z. B. Workloadcluster, Steuerungsebene und Arbeitsknoten, haben gemeinsame Verantwortung. Benutzer müssen dabei helfen, den Kubernetes-Cluster zu verwalten. Benutzereingaben sind beispielsweise erforderlich, um einen Betriebssystemsicherheitspatch oder ein Update auf eine neuere Kubernetes-Version anzuwenden.

Die Dienste werden in dem Sinne verwaltet , dass Microsoft und das AKS-Team die Tools bereitstellen, die den Verwaltungscluster, die Steuerungsebene und die Agentknoten für Workloadcluster bereitstellen. Sie können diese verwalteten Komponenten nicht ändern. Microsoft beschränkt die Anpassung, um eine konsistente und skalierbare Benutzererfahrung zu gewährleisten. Eine vollständig anpassbare Lösung in der Cloud finden Sie im AKS-Modul.

Unterstützte Versionsrichtlinie

Kubernetes-Versionen in AKS Arc folgen der Kubernetes-Versionsrichtlinie.

AKS Arc stellt keine Laufzeitgarantien (oder andere) Für Cluster außerhalb der Liste der unterstützten Versionen zur Verfügung. "Außerhalb des Supports" bedeutet folgendes:

  • Ihr Cluster wird auf einer veralteten Nebenversion ausgeführt. Die Version, die Sie ausführen, befindet sich nicht auf der Liste der unterstützten Versionen.
  • Sie werden aufgefordert, den Cluster auf eine unterstützte Version zu aktualisieren, wenn Sie Support anfordern.

Informationen zu den unterstützten Kubernetes-Versionen finden Sie unter Unterstützte Kubernetes-Versionen.

AKS Arc folgt den Plattformversionsunterstützungszeitrahmen für diese Produkte. Das heißt, AKS Arc wird in nicht unterstützten Versionen dieser Produkte nicht unterstützt. Weitere Informationen finden Sie in den jeweiligen Unterstützungsrichtlinien:

Gemeinsame Verantwortung

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

Da Ihre Agentknoten private Code ausführen und vertrauliche Daten speichern, hat Microsoft-Support eingeschränkten Zugriff darauf. Microsoft-Support können sich nicht anmelden, um Befehle auszuführen, oder Protokolle für diese Knoten anzeigen, ohne Ihre ausdrückliche Berechtigung oder Unterstützung. Jede direkte Änderung der Agentknoten mithilfe einer der IaaS-APIs rendert den Cluster nicht unterstützt. Alle Änderungen an den Agentknoten müssen mithilfe von Kubernetes-nativen Mechanismen wie Daemon Setsz. B. erfolgen.

Ebenso können Sie dem Cluster und Knoten alle Metadaten, z. B. Tags und Bezeichnungen, hinzufügen, indem Sie alle vom System erstellten Metadaten ändern, der Cluster wird nicht unterstützt.

AKS Arc-Unterstützungsabdeckung

Microsoft bietet technischen Support für die folgenden Features und Komponenten:

  • Konnektivität mit allen Kubernetes-Komponenten, die vom Kubernetes-Dienst bereitgestellt und unterstützt werden (beispielsweise der API-Server).
  • Kubernetes-Steuerungsebenendienste (z. B. Kubernetes-Steuerungsebene, API-Server usw. und CoreDNS).
  • etcd-Datenspeicher.
  • Integration in Azure Arc und den Azure-Abrechnungsdienst.
  • Fragen oder Probleme zur Anpassung von Komponenten der Steuerungsebene wie Kubernetes-API-Server, etcd und coreDNS.
  • Probleme mit Netzwerk, Netzwerkzugriff und Funktionalität. Probleme können die DNS-Auflösung, den Paketverlust und das Routing umfassen. Microsoft unterstützt verschiedene Netzwerkszenarien:
    • Grundlegende Installationsunterstützung für Flannel und Calico CNI. Diese CNIs werden von der Community gesteuert und unterstützt. Microsoft-Support bietet nur grundlegende Installations- und Konfigurationsunterstützung.
    • Konnektivität mit anderen Azure-Diensten und -Anwendungen
    • Eingangscontroller und Konfiguration des Eingangs- oder Lastenausgleichs.
    • Netzwerkleistung und Latenz.

Hinweis

Alle Clusteraktionen von Microsoft AKS Arc-Supportteams werden mit Zustimmung und Unterstützung des Benutzers vorgenommen. Microsoft-Support sich nicht bei Ihrem Cluster anmelden, es sei denn, Sie konfigurieren den Zugriff für den Supporttechniker.

Microsoft bietet keinen technischen Support für die folgenden Bereiche:

  • 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

    Microsoft-Support können Clusterfunktionen, Anpassungen und Optimierungen in AKS Arc beraten, z. B. Kubernetes-Betriebsprobleme und -verfahren.

  • Open-Source-Projekte von Drittanbietern, die nicht als Teil der Kubernetes-Steuerungsebene bereitgestellt oder bereitgestellt werden, wenn Cluster in AKS Arc erstellt werden. Diese Projekte können Istio, Helm, Envoy oder andere umfassen.

    Hinweis

    Microsoft kann den bestmöglichen Support für Open-Source-Projekte von Drittanbietern wie Helm bereitstellen. Wenn das Open-Source-Tool von Drittanbietern in Kubernetes oder andere AKS Arc-spezifische Fehler 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.

  • Netzwerkanpassungen außer den in der AKS Arc-Dokumentation aufgeführten Anpassungen.

AKS Arc-Unterstützungsabdeckung für Agentknoten

Microsoft-Zuständigkeiten für AKS Arc-Agentknoten

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

  • Das Basisbetriebssystemimage erforderte Ergänzungen (z. B. Überwachung und Netzwerk-Agents).
  • Die Agentknoten erhalten Betriebssystempatches automatisch.
  • Probleme mit den Komponenten der Kubernetes-Steuerungsebene, die auf den Agentknoten ausgeführt werden, werden während des Updatezyklus oder beim erneuten Bereitstellen eines Agentknotens automatisch behandelt. Zu diesen Komponenten gehören:
    • kube-proxy
    • Netzwerktunnel, die Kommunikationspfade zu den Kubernetes-Hauptkomponenten bereitstellen:
      • kubelet
      • Moby oder ContainerD

Hinweis

Wenn ein Agentknoten nicht betriebsbereit ist, startet AKS Arc möglicherweise einzelne Komponenten oder den gesamten Agentknoten neu. Diese automatisierten Neustartvorgänge bieten eine automatische Behebung für häufige Probleme.

Kundenverantwortung für AKS Arc-Agentknoten

Microsoft stellt monatlich Patches und neue Images für Ihre Imageknoten bereit, patcht sie aber standardmäßig nicht automatisch. Damit Ihr Agentknotenbetriebssystem und Die Laufzeitkomponenten gepatcht bleiben, sollten Sie einen regelmäßigen Upgradezeitplan beibehalten oder das Patchen automatisieren.

Ebenso veröffentlicht AKS Arc regelmäßig neue Kubernetes-Patches und Nebenversionen. Diese Updates können Verbesserungen der Sicherheit oder Funktionalität von Kubernetes enthalten. Sie sind dafür verantwortlich, die Kubernetes-Version Ihres Clusters gemäß der Von AKS Arc unterstützten Versionsrichtlinie aktualisiert zu lassen.

Benutzeranpassung von Agentknoten

Hinweis

AKS Arc-Agentknoten werden in Hyper-V als normale virtuelle Computerressourcen angezeigt. Diese virtuellen Computer werden mit einem benutzerdefinierten Betriebssystemimage bereitgestellt und werden von Kubernetes-Komponenten unterstützt und verwaltet. Sie können mit den HyperV-APIs- oder -Ressourcen keine Änderungen am Basisbetriebssystemimage oder direkte Anpassungen an diesen Knoten vornehmen. Alle benutzerdefinierten Änderungen, die nicht über die AKS-HCI-API ausgeführt werden, werden nicht über ein Upgrade, eine Skalierung, aktualisierung oder einen Neustart beibehalten und können den Cluster nicht unterstützt rendern. Nehmen Sie keine Änderungen an den Agentknoten vor, es sei denn, Sie werden vom Microsoft-Support zum Vornehmen von Änderungen angewiesen.

AKS Arc verwaltet den Lebenszyklus und die Vorgänge von Agentknotenimages in Ihrem Auftrag. Das Ändern der ressourcen, die den Agentknoten zugeordnet sind, wird nicht unterstützt. Beispielsweise wird das Anpassen der Netzwerkeinstellungen eines virtuellen Computers durch manuelles Ändern von Konfigurationen über die Hyper-V-API oder -Tools nicht unterstützt.

Für workloadspezifische Konfigurationen oder Pakete sollten Sie Kubernetes-Daemonsätze verwenden.

Wenn Sie Kubernetes-Privilegierte daemon sets und Init-Container verwenden, können Sie Software von Drittanbietern auf Cluster-Agent-Knoten optimieren/ändern oder installieren. Sie können z. B. benutzerdefinierte Sicherheitsüberprüfungssoftware oder Updateeinstellungen sysctl hinzufügen. Obwohl dieser Pfad empfohlen wird, wenn die vorherigen Anforderungen gelten, kann AKS Arc Engineering und Support nicht bei der Problembehandlung oder Diagnose von Änderungen helfen, die den Knoten aufgrund einer benutzerdefinierten Bereitstellung daemon setnicht verfügbar machen.

Sicherheitsprobleme und -patches

Wenn in einer oder mehreren verwalteten Komponenten von AKS Arc ein Sicherheitsfehler gefunden wird, werden alle betroffenen Betriebssystemimages vom AKS Arc-Team gepatcht, um das Problem zu beheben, und das Team bietet Benutzern Anleitungen zum Upgrade.

Bei Agentknoten, die von einem Sicherheitsfehler betroffen sind, benachrichtigt Microsoft Sie mit Details zu den Auswirkungen und den Schritten zum Beheben oder Beheben des Sicherheitsproblems. In der Regel umfassen die Schritte ein Knotenimageupgrade oder ein Clusterpatchupgrade.

Knotenwartung und -zugriff

Obwohl Sie sich anmelden und Agentknoten ändern können, wird dieser Vorgang abgeraten, da Änderungen einen Cluster nicht unterstützen können.

Netzwerkports, IP-Pools und Zugriff

Sie können netzwerkeinstellungen nur mithilfe von AKS Arc definierten Subnetzen anpassen. Sie können keine Netzwerkeinstellungen auf der NIC-Ebene der Agentknoten anpassen. AKS Arc verfügt über Ausgangsanforderungen für bestimmte Endpunkte, um den Ausgang zu steuern und die erforderliche Konnektivität sicherzustellen. Weitere Informationen finden Sie unter den Systemanforderungen von AKS Arc.

Beendete oder getrennte Cluster

Wie zuvor beschrieben, rendert die manuelle Dezuordnung aller Clusterknoten über die Hyper-V-APIs, CLI oder MMC den Cluster außerhalb der Unterstützung.

Cluster, die länger als 90 Tage angehalten werden, können nicht mehr aktualisiert werden. Die Steuerungsebenen für Cluster in diesem Zustand sind nach 30 Tagen nicht mehr unterstützt, und sie können nicht auf die neueste Version aktualisiert werden.

Der Verwaltungscluster in AKS Arc muss mindestens alle 30 Tage eine Verbindung mit Azure über HTTPS ausgehenden Datenverkehr mit bekannten Azure-Endpunkten herstellen können, um Tag 2-Vorgänge wie Upgrade- und Knotenpoolskalierung zu verwalten. Wenn der Verwaltungscluster innerhalb des Zeitraums von 30 Tagen getrennt wird, werden Workloads weiterhin ausgeführt und funktionieren wie erwartet, bis der Verwaltungscluster und oder azure Local erneut eine Verbindung mit Azure herstellen und synchronisieren. Nach der erneuten Verbindung sollten alle tag 2 Vorgänge wie erwartet wie erwartet wiederhergestellt und fortgesetzt werden. Weitere Informationen finden Sie unter Azure Local Azure Connectivity Requirements . Nach 30 Tagen verhindert Azure Local die Erstellung neuer virtueller Computer.

Wenn der Cluster unter Windows Server 2019 oder Windows Server 2022 ausgeführt wird, verfügt die zugrunde liegende Hostplattform nicht über die Anforderung der 30-tägigen wiederkehrenden Verbindung.

Hinweis

Der Anfang/Ende des 30-Tage-Zeitraums unterscheidet sich möglicherweise vom Gültigkeitszeitraum von AKS Arc und Azure Local. Durch manuelles Beenden oder Aufheben der Zuordnung aller Clusterknoten über die Hyper-V-APIs/CLI/MMC für längere Zeiträume, die größer als 30 Tage sind, und außerhalb der regulären Wartungsprozeduren wird der Cluster nicht mehr unterstützt.

Gelöschtes oder ausgesetztes Abonnement

Wenn Ihr Azure-Abonnement angehalten oder gelöscht wird, werden Ihre AKS-Cluster nach 60 Tagen nicht mehr unterstützt, es sei denn, das Abonnement wird vor Erreichen des 60-Tage-Grenzwerts wieder eingestellt. Alle anderen zuvor beschriebenen Einschränkungen gelten ebenfalls. Nachdem das Abonnement gelöscht wurde, kann die Clusterverbindung mit Azure nicht wiederhergestellt werden, und Azure Local und AKS Arc müssen erneut bereitgestellt werden, um eine erneute Verbindung mit Azure herstellen zu können.

Nicht unterstützte Vorschau- und Beta-Kubernetes-Features

AKS Arc unterstützt nur stabile und Beta-Features im Upstream-Kubernetes-Projekt. Sofern nicht anders dokumentiert, unterstützt AKS Arc keine Vorschaufeatures, 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. Berücksichtigen Sie diese Vorabversions- oder Betafeatures. 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 erhalten "best effort"-Unterstützung, da diese Features in der Vorschau sind und nicht für die Produktion vorgesehen sind. Diese Features werden nur während der Geschäftszeiten von den technischen Supportteams von AKS Arc unterstützt. Weitere Informationen finden Sie in den häufig gestellten Fragen (FAQ) 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 nicht gepatcht oder im AKS Arc-System bearbeitet werden. Stattdessen erfordern Fehlerbehebungen größere Patches für Upstream-Projekte (z. B. Kubernetes, Betriebssysteme für Knoten oder Agents sowie Kernel). Für Komponenten, die Microsoft besitzt (z. B. die Cluster-API-Anbieter für Azure Local), sind AKS Arc und Azure-Mitarbeiter verpflichtet, Probleme vorgelagert in der Community zu beheben.

Wenn ein technisches Supportproblem durch einen oder mehrere Upstreamfehler verursacht wird, führen AKS Arc-Support- und Engineeringteams die folgenden Aktionen 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 im lokalen Azure- und Windows Server-Repository abgelegt. In der Einreichung bekannter Probleme wird erläutert:
    • Das Problem, einschließlich Links zu upstream-Fehlern.
    • Die Problemumgehung und Details zu einem Upgrade oder einer anderen Option für die Lösung.
    • Grober Zeitplan für die Einbeziehung des Problems auf der Grundlage des Upstream-Releaserhythmus.

Nächste Schritte