Referenz zur AKS-Clusterkonfiguration

Um die Abonnement-ID zu erhalten, klicken Sie auf Alle Dienste in der linken Navigationsleiste. Klicken Sie dann auf Abonnements. Gehen Sie zu dem Namen des Abonnements, das Sie mit Ihrem Kubernetes-Cluster verknüpfen möchten, und kopieren Sie die Abonnement-ID.

Um die Client-ID zu erhalten, gehen Sie zum Azure-Portal, klicken Sie dann auf Azure Active Directory, dann auf App-Registrierungen, und klicken Sie auf den Namen des Dienstprinzipals. Die Client-ID wird auf der Detailseite der App-Registrierung als Anwendungs-(Client)-ID aufgeführt.

Sie können den Wert des Client-Geheimnisses nach seiner Erstellung nicht abrufen. Wenn Sie also noch keinen Wert für das Client-Geheimnis haben, müssen Sie ein neues Client-Geheimnis erstellen.

Um ein neues Client-Geheimnis zu erhalten, gehen Sie zum Azure-Portal, klicken Sie dann auf Azure Active Directory, dann auf App-Registrierungen, und klicken Sie auf den Namen des Dienstprinzipals.

Klicken Sie dann auf Zertifikate & Geheimnisse und klicken Sie auf Neues Client-Geheimnis. Klicken Sie auf Hinzufügen. Kopieren Sie dann den Wert des neuen Client-Geheimnisses.

Microsoft bietet mehrere Clouds zur Einhaltung regionaler Gesetze an, die Ihnen zur Verfügung stehen:

Die verfügbaren Kubernetes-Versionen werden dynamisch von der Azure-API abgerufen.

Eine Ressourcengruppe ist ein Container, der verwandte Ressourcen für eine Azure-Lösung enthält. Die Ressourcengruppe kann alle Ressourcen für die Lösung oder nur die Ressourcen enthalten, die Sie als Gruppe verwalten möchten. Sie entscheiden, wie Sie Ressourcen den Ressourcengruppen zuweisen möchten, basierend darauf, was für Ihre Organisation am sinnvollsten ist. Im Allgemeinen fügen Sie Ressourcen, die denselben Lebenszyklus teilen, derselben Ressourcengruppe hinzu, damit Sie sie als Gruppe einfach bereitstellen, aktualisieren und löschen können.

Verwenden Sie eine vorhandene Ressourcengruppe oder geben Sie einen Namen für eine Ressourcengruppe ein, und es wird eine für Sie erstellt.

Die Verwendung einer Ressourcengruppe, die einen vorhandenen AKS-Cluster enthält, erstellt eine neue Ressourcengruppe. Azure AKS erlaubt nur einen AKS-Cluster pro Ressourcengruppe.

Für Informationen zur Verwaltung von Ressourcengruppen siehe die Azure-Dokumentation.

Der Benutzername, der verwendet wird, um eine SSH-Verbindung zu den Linux-Knoten herzustellen.

Der Standardbenutzername für AKS-Knoten ist azureuser.

Der Schlüssel, der verwendet wird, um eine SSH-Verbindung zu den Linux-Knoten herzustellen.

Cluster-Tags können nützlich sein, wenn Ihre Organisation Tags als Möglichkeit zur Organisation von Ressourcen über mehrere Azure-Dienste hinweg verwendet. Diese Tags gelten nicht für Ressourcen innerhalb des Clusters.

Azure-Lastenausgleicher unterstützen sowohl Standard- als auch Basis-SKUs (Stock Keeping Units).

Für einen Vergleich zwischen Standard- und Basis-Lastenausgleichern siehe die offizielle Azure-Dokumentation. Microsoft empfiehlt den Standard-Lastenausgleicher.

Der Standard-Lastenausgleicher ist erforderlich, wenn Sie eine oder mehrere Verfügbarkeitszonen ausgewählt haben oder wenn Sie mehr als einen Knotenpool haben.

Alle Pods in einem AKS-Cluster können standardmäßig ohne Einschränkungen Datenverkehr senden und empfangen. Um die Sicherheit zu verbessern, können Sie Regeln definieren, die den Datenfluss steuern. Die Funktion der Netzwerkrichtlinie in Kubernetes ermöglicht es Ihnen, Regeln für den Ein- und Ausgangsverkehr zwischen Pods in einem Cluster zu definieren.

Azure bietet zwei Möglichkeiten zur Implementierung von Netzwerkrichtlinien. Sie wählen eine Option für Netzwerkrichtlinien, wenn Sie ein AKS-Cluster erstellen. Die Richtlinienoption kann nach der Erstellung des Clusters nicht mehr geändert werden:

Sie können auch wählen, keine Netzwerkrichtlinie zu haben.

Für weitere Informationen über die Unterschiede zwischen Azure- und Calico-Netzwerkrichtlinien und deren Fähigkeiten siehe die AKS-Dokumentation.

Geben Sie ein einzigartiges DNS-Präfix für den FQDN des Kubernetes-API-Servers Ihres Clusters ein.

Es gibt zwei Netzwerk-Plugins: kubenet und Azure CNI.

Das kubenet Kubernetes-Plugin ist die Standardkonfiguration für die Erstellung von AKS-Clustern. Wenn kubenet verwendet wird, erhält jeder Knoten im Cluster eine routbare IP-Adresse. Die Pods verwenden NAT, um mit anderen Ressourcen außerhalb des AKS-Clusters zu kommunizieren. Dieser Ansatz reduziert die Anzahl der IP-Adressen, die Sie in Ihrem Netzwerkbereich für die Verwendung durch Pods reservieren müssen.

Mit dem Azure CNI (erweitertes) Netzwerk-Plugin erhalten Pods vollständige Konnektivität im virtuellen Netzwerk und können direkt über ihre private IP-Adresse von verbundenen Netzwerken erreicht werden. Dieses Plugin benötigt mehr IP-Adressraum.

Für weitere Informationen zu den Unterschieden zwischen kubenet und Azure CNI siehe die AKS-Dokumentation.

Wenn aktiviert, erleichtert das HTTP-Anwendungsrouting-Add-On den Zugriff auf Anwendungen, die im AKS-Cluster bereitgestellt sind. Es werden zwei Komponenten bereitgestellt: ein Kubernetes Ingress-Controller und ein External-DNS Controller.

Für weitere Informationen siehe die AKS-Dokumentation.

Sie können den Zugriff auf den Kubernetes-API-Server mithilfe von autorisierten IP-Adressbereichen. sichern.

Der Kubernetes-API-Server stellt die Kubernetes-API zur Verfügung. Diese Komponente bietet die Interaktion für Verwaltungstools wie kubectl. AKS bietet eine Single-Tenant-Cluster-Steuerungsebene mit einem dedizierten API-Server. Standardmäßig wird dem API-Server eine öffentliche IP-Adresse zugewiesen, und Sie sollten den Zugriff darauf mithilfe von Kubernetes-basiertem oder Azure-basiertem RBAC steuern.

Um den Zugriff auf die ansonsten öffentlich zugängliche AKS-Steuerungsebene und den API-Server zu sichern, können Sie autorisierte IP-Bereiche aktivieren und verwenden. Diese autorisierten IP-Bereiche erlauben nur definierten IP-Adressbereichen die Kommunikation mit dem API-Server.

Wenn Sie autorisierte IP-Adressbereiche verwenden, sollten Sie dennoch Kubernetes RBAC oder Azure RBAC verwenden, um Benutzer und die von ihnen angeforderten Aktionen zu autorisieren.

Die Containerüberwachung bietet Ihnen Leistungsübersicht, indem sie Speicher- und Prozessormetriken von Controllern, Knoten und Containern sammelt, die über die Metrics API in Kubernetes verfügbar sind. Containerprotokolle werden ebenfalls gesammelt. Nachdem Sie die Überwachung aktiviert haben, werden Metriken und Protokolle automatisch für Sie über eine containerisierte Version des Log Analytics-Agenten für Linux gesammelt. Metriken werden im Metrik-Speicher geschrieben und Protokolldaten werden im Protokoll-Speicher geschrieben, der mit Ihrem Log Analytics Arbeitsbereich verbunden ist.

Die Ressourcengruppe, die den Log Analytics Arbeitsbereich enthält. Sie müssen mindestens einen Arbeitsbereich erstellen, um Azure Monitor-Protokolle zu verwenden.

Die von Azure Monitor-Protokollen gesammelten Daten werden in einem oder mehreren Log Analytics Arbeitsbereichen. gespeichert. Der Arbeitsbereich definiert den geografischen Standort der Daten, Zugriffsrechte, die festlegen, welche Benutzer auf die Daten zugreifen können, und Konfigurationseinstellungen wie die Preiskategorie und die Datenaufbewahrung.

Sie müssen mindestens einen Arbeitsbereich erstellen, um Azure Monitor-Protokolle zu verwenden. Ein einzelner Arbeitsbereich kann für alle Ihre Überwachungsdaten ausreichend sein, oder Sie können je nach Ihren Anforderungen mehrere Arbeitsbereiche erstellen. Zum Beispiel könnten Sie einen Arbeitsbereich für Ihre Produktionsdaten und einen anderen für Tests haben.

Für weitere Informationen zu Azure Monitor-Protokollen siehe die Azure-Dokumentation.

Typischerweise erhalten AKS-Arbeitsknoten keine öffentlichen IP-Adressen, unabhängig davon, ob der Cluster privat ist. In einem privaten Cluster hat die Steuerungsebene keinen öffentlichen Endpunkt.

Rancher kann auf einen privaten AKS-Cluster auf eine von zwei Arten zugreifen.

Der erste Weg, um sicherzustellen, dass Rancher auf demselben NAT wie die AKS-Knoten läuft.

Der zweite Weg besteht darin, einen Befehl auszuführen, um den Cluster bei Rancher zu registrieren. Sobald der Cluster bereitgestellt ist, können Sie den angezeigten Befehl überall dort ausführen, wo Sie eine Verbindung zur Kubernetes-API des Clusters herstellen können. Dieser Befehl wird in einem Pop-up angezeigt, wenn Sie einen AKS-Cluster mit einem aktivierten privaten API-Endpunkt bereitstellen.

Für weitere Informationen zur Verbindung mit einem privaten AKS-Cluster siehe die AKS-Dokumentation.

Die Azure-Oberfläche ermöglicht es Benutzern anzugeben, ob ein primärer Knotenpool entweder auf system (normalerweise für Steuerungsebenen verwendet) oder auf user (was typischerweise für Rancher benötigt wird) angewiesen ist.

Für primäre Knotenpools können Sie Modus, Betriebssystem, Anzahl und Größe angeben.

Systemknotenpools erfordern immer laufende Knoten, sodass sie nicht unter einen Knoten skaliert werden können. Mindestens ein Systemknotenpool ist erforderlich.

Für nachfolgende Knotenpools zwingt die Rancher-Benutzeroberfläche die Standardoption "Benutzer". Benutzerknotenpools ermöglichen es Ihnen, auf null Knoten zu skalieren. Benutzerknotenpools führen keinen Teil der Kubernetes-Steuerungsebene aus.

AKS gibt die Knoten, die die Komponenten der Kubernetes-Steuerungsebene ausführen, nicht preis.

Verfügbarkeitszonen sind einzigartige physische Standorte innerhalb einer Region. Jede Zone besteht aus einem oder mehreren Rechenzentren, die mit unabhängiger Stromversorgung, Kühlung und Netzwerktechnologie ausgestattet sind.

Nicht alle Regionen unterstützen Verfügbarkeitszonen. Für eine Liste der Azure-Regionen mit Verfügbarkeitszonen siehe die Azure-Dokumentation.

Wählen Sie eine Größe für jede VM im Knotenpool aus. Für Details zu jeder VM-Größe siehe diese Seite.

Die Knoten im Knotenpool können entweder verwaltete oder flüchtige Datenträger haben.

Flüchtige Betriebssystemdatenträger werden im lokalen Speicher der virtuellen Maschine erstellt und nicht im entfernten Azure-Speicher gespeichert. Flüchtige Betriebssystemdatenträger eignen sich gut für zustandslose Workloads, bei denen Anwendungen tolerant gegenüber einzelnen VM-Ausfällen sind, aber stärker von der Bereitstellungszeit der VM oder der Neuinstallation der einzelnen VM-Instanzen betroffen sind. Mit flüchtigen Betriebssystemdatenträgern erhalten Sie eine geringere Lese/Schreiblatenz zum Betriebssystemdatenträger und eine schnellere Neuinstallation der VM.

Verwaltete Azure-Datenträger sind blockbasierte Speicher-Volumes, die von Azure verwaltet werden und mit Azure-virtuellen Maschinen verwendet werden. Verwaltete Datenträger sind für eine Verfügbarkeit von 99,999 % ausgelegt. Verwaltete Datenträger erreichen dies, indem sie Ihnen drei Replikate Ihrer Daten zur Verfügung stellen, was eine hohe Haltbarkeit ermöglicht.

Die Größe in GB für die Festplatte für jeden Knoten.

Die Anzahl der Knoten im Knotenpool. Die maximale Anzahl von Knoten kann durch Ihr Azure-Abonnement. beschränkt sein.

Die maximale Anzahl von Pods pro Knoten beträgt standardmäßig 110, mit einem Maximum von 250.

Wenn Auto Scaling aktiviert ist, müssen Sie eine minimale und maximale Knotenzahl eingeben.

Wenn Auto Scaling aktiviert ist, können Sie den Knotenpool nicht manuell skalieren. Die Skalierung wird vom AKS-Autoscaler gesteuert.