Kubernetes braucht einen Cluster? AKS erstellen und mit kubectl verbinden

Kubernetes verwaltet Container-Workloads auf einer Gruppe von Rechnern, dem Cluster. Du beschreibst den gewünschten Zustand, etwa drei Kopien einer Anwendung. Kubernetes verteilt und betreut diese Workloads. Azure Kubernetes Service (AKS) stellt eine verwaltete Kubernetes-Steuerungsebene und Azure-Worker-Nodes bereit.

Bestandteil	Aufgabe
Control Plane	Stellt die Kubernetes-API bereit, plant Workloads und koordiniert den Clusterzustand; Azure verwaltet sie
Node	Worker-VM, auf der Pods laufen
Node Pool	Gruppe gleich konfigurierter Nodes
Pod	Kleinste bereitstellbare Kubernetes-Einheit mit einem oder mehreren Containern
kubectl	Client zum Senden von Anfragen an die Kubernetes-API

Dieser Trip erstellt den Cluster und prüft den Zugriff. Die Anwendung folgt im nächsten Schritt. Deine ACR bleibt in ihrer eigenen Ressourcengruppe; für die Clusterverbindung wird sie nicht benötigt.

Verwende das Azure-Portal für Clustererstellung und Berechtigungen sowie Azure Cloud Shell → Bash für kubectl. Eine lokale Kubernetes-Installation oder ein Docker-Desktop-Kubernetes-Cluster ist nicht nötig. Du brauchst Rechte zum Erstellen von AKS-Ressourcen und Zuweisen von Azure-Rollen, beispielsweise Owner im Lab-Abonnement.

Cluster im Portal erstellen

Suche nach Kubernetes services → Create → Kubernetes cluster. Falls AKS Automatic und AKS Standard angeboten werden, wähle Standard, um die Node Pools selbst zu konfigurieren. Diese Auswahl ist unabhängig vom Management-Preistarif unten.

Unter Basics:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-aks-test-weu (neu)
Cluster preset configuration: Dev/Test
Kubernetes cluster name: aks-ctlab-weu
Region: UK West
Availability zones: None für dieses Lab
AKS pricing tier: Free
Kubernetes version: vom Portal empfohlene unterstützte stabile Version

Free bedeutet keine Gebühr für den Cluster-Management-Tarif; Worker-VMs, Datenträger und zugehörige Netzwerkressourcen kosten weiterhin Geld. Prüfe die Kostenschätzung vor dem Erstellen. Wähle für dieses Einführungslab keine Kubernetes-Vorschauversion.

Wähle unter Authentication and authorization auf Basics oder einer eigenen Registerkarte Microsoft Entra ID authentication with Azure RBAC. Verwende die verwaltete Clusteridentität für die Azure-Ressourcenverwaltung. Das sind unterschiedliche Identitäten: Dein Entra-Benutzer greift auf Kubernetes zu; die Clusteridentität verwaltet Azure-Infrastruktur.

Node Pool und Netzwerk konfigurieren

Bearbeite unter Node pools den vorhandenen System-Pool:

Pool name: agentpool (abweichenden Standardnamen beibehalten)
Mode: System
OS: Linux / Ubuntu
VM size: Standard_D4as_v6 oder eine verfügbare x64-D-Serien-Größe mit mindestens 4 vCPUs
Scale method: Manual
Node count: 2

Ein System-Pool führt Kubernetes-Infrastruktur-Pods aus. Behalte für dieses Einführungslab nur diesen Pool und füge noch keinen User-Pool hinzu. Verwende hier keine B-Serien- oder ARM-VMs. Falls die Voreinstellung einen weiteren Pool hinzufügt, entferne ihn vor der Bereitstellung. Verfügbarkeit und Kontingente variieren: Das Beispiel benötigt mindestens 8 vCPUs für zwei Nodes; bei Upgrades kann zusätzliches Kontingent nötig sein.

Unter Networking:

API server access: Public
Private cluster: Disabled
Network configuration: Azure CNI Overlay
Virtual network: Create new / generiertes Netzwerk
Load balancer: Standard

Lass für dieses temporäre Lab die autorisierten API-Server-IP-Bereiche unkonfiguriert, damit die browserbasierte Cloud Shell zugreifen kann. Auch ein öffentlicher API-Endpunkt verlangt Authentifizierung und Autorisierung. In einer echten Umgebung beschränkst du den Netzwerkzugriff entsprechend deinem Konzept.

Lass unter Integrations / Monitoring die ACR-Integration zunächst unkonfiguriert. Deaktiviere optionale Container Insights, Managed Prometheus, Managed Grafana und kostenpflichtige Defender-Erweiterungen, falls ausgewählt. Dafür gibt es separate Labs. Behalte unterstützte Standard-Upgrade-Einstellungen bei.

Wähle Review + create → Create. Öffne nach erfolgreicher Bereitstellung aks-ctlab-weu → Overview und Node pools, um Cluster und Pool zu prüfen.

Azure erstellt zusätzlich eine Node-Ressourcengruppe, deren Name meist mit MC_ beginnt. Sie enthält verwaltete VMs, Datenträger und Netzwerkressourcen. Ändere oder lösche diese Ressourcen während der Clusternutzung nicht manuell.

Deinem Benutzer Clusterzugriff geben

Öffne aks-ctlab-weu → Access control (IAM) → Add → Add role assignment. Weise deinem angemeldeten Benutzer diese Rollen im Gültigkeitsbereich der AKS-Ressource zu:

Rolle	Zweck
Azure Kubernetes Service Cluster User Role	Erlaubt das Abrufen der Benutzer-Verbindungskonfiguration; eine zusätzliche Zuweisung ist bei bereits gleichwertiger Azure-Rolle nicht nötig
Azure Kubernetes Service RBAC Cluster Admin	Gibt Kubernetes-Administrationsrechte für diesen isolierten Lab-Cluster und die folgenden Bereitstellungsübungen

Wähle jeweils User, group, or service principal → Select members, deinen Benutzer und Review + assign. Die zweite Rolle enthält RBAC im Namen. Verwechsle sie nicht mit Azure Kubernetes Service Cluster Admin Role, die lokale Administratorzugangsdaten zugänglich macht.

Azure-Abonnementbesitz und Kubernetes-Berechtigungen sind unterschiedliche Bereiche. Warte einige Minuten auf die Rollenübernahme. In einer Teamumgebung vergibst du passend zu den Aufgaben eingeschränkte Rollen.

Mit kubectl verbinden

Öffne Cloud Shell über >_ oben im Azure-Portal und wähle Bash. Verwende das Konto mit den zuvor zugewiesenen Rollen. Cloud Shell ist bereits angemeldet und enthält die Kubernetes-Werkzeuge. Wähle bei einer Abonnementabfrage CloudTrips TEST. Für diese Prüfungen reicht eine temporäre Sitzung ohne persistenten Speicher.

Führe aus:

az account set --subscription "CloudTrips TEST"
az aks get-credentials \
  --resource-group rg-cloudtrips-aks-test-weu \
  --name aks-ctlab-weu
kubelogin convert-kubeconfig -l azurecli
kubectl config current-context
kubectl get nodes -o wide

az aks get-credentials ergänzt die Clusterverbindung in ~/.kube/config in Cloud Shell. Es erstellt keinen Cluster. kubelogin verwendet die aktuelle Azure-CLI-Sitzung zur Entra-Authentifizierung. Der aktuelle Kontext bestimmt, welchen Cluster kubectl anspricht; er sollte aks-ctlab-weu identifizieren.

Erwartet werden zwei Node-Zeilen mit STATUS Ready. Namen und Kubernetes-Version hängen von der Bereitstellung ab. ROLES ist bei AKS-Worker-Nodes normal und bedeutet nicht, dass deinem Benutzer Rechte fehlen. Die verwaltete Control Plane erscheint nicht als Worker-Node.

Cluster prüfen

kubectl cluster-info
kubectl get namespaces
kubectl get pods -n kube-system

cluster-info bestätigt die Erreichbarkeit der API. Namespaces gruppieren Kubernetes-Ressourcen. kube-system enthält Infrastruktur-Pods; Pods vor der ersten eigenen Anwendung sind deshalb normal. Die meisten dauerhaft laufenden System-Pods sollten Running anzeigen; abgeschlossene Jobs können Completed sein. Wiederholte Fehler oder dauerhaft wartende Pods musst du untersuchen.

Wenn kubectl Nodes und Systemressourcen auflistet, funktioniert die Verbindung. Nach dem Ende einer temporären Cloud-Shell-Sitzung öffnest du sie erneut und wiederholst die Verbindungsbefehle.

Pausieren oder abschließen

Behalte den Cluster für die nächsten Kubernetes-Trips. Wähle zwischen Sitzungen aks-ctlab-weu → Overview → Stop, warte auf den Abschluss und verwende vor der nächsten Verbindung Start. Stoppen reduziert Computekosten; gespeicherte Datenträger und weitere Ressourcen können weiterhin Kosten verursachen.

Lösche nach Abschluss rg-cloudtrips-aks-test-weu im Portal. AKS entfernt normalerweise auch seine verwaltete Node-Ressourcengruppe. Prüfe den abgeschlossenen Löschvorgang und untersuche verbleibende Ressourcen. Behalte die separate Registry-Gruppe, wenn du deren Images noch brauchst.