Herstellen einer Verbindung mit Azure Kubernetes Service-Clusterknoten (AKS) zur Wartung oder Problembehandlung

Während des Lebenszyklus des Azure Kubernetes Service-Clusters (AKS) müssen Sie irgendwann direkt auf einen AKS-Knoten zugreifen. Dieser Zugriff kann zur Wartung, Protokollsammlung oder für Vorgänge der Problembehandlung erforderlich sein.

Sie greifen auf einen Knotenpunkt über eine Authentifizierung zu, deren Methoden je nach Knotenbetriebssystem und Verbindungsmethode variieren. Die sichere Authentifizierung bei AKS Linux- und Windows-Knoten erfolgt über zwei Optionen, die in diesem Artikel beschrieben werden. Die eine erfordert, dass Sie Zugriff auf die Kubernetes-API haben, und die andere erfolgt über die AKS-ARM-API, die direkte private IP-Informationen bereitstellt. Aus Sicherheitsgründen werden AKS-Knoten nicht im Internet verfügbar gemacht. Um eine direkte Verbindung mit einem AKS-Knoten herzustellen, müssen Sie entweder kubectl debug oder die private IP-Adresse des Hosts verwenden.

Zugriff auf Knoten über die Kubernetes-API

Diese Methode erfordert die Verwendung des kubectl debug-Befehls.

Voraussetzungen

In diesem Leitfaden erfahren Sie, wie Sie eine Verbindung mit einem AKS-Knoten erstellen und den SSH-Schlüssel Ihres AKS-Clusters aktualisieren. Um die Schritte auszuführen, müssen Sie die Azure CLI verwenden, die Version 2.0.64 oder höher unterstützt. Führen Sie az --version aus, um die Version zu prüfen. Informationen zum Durchführen einer Installation oder eines Upgrades finden Sie bei Bedarf unter Installieren der Azure CLI.

Führen Sie diese Schritte aus, wenn Sie keinen SSH-Schlüssel haben. Erstellen Sie abhängig von Ihrem Knotenbetriebssystem-Image einen SSH-Schlüssel, für macOS und Linux oder Windows. Achten Sie darauf, dass Sie das Schlüsselpaar im OpenSSH-Format speichern und vermeiden Sie nicht unterstützte Formate wie .ppk. Lesen Sie als Nächstes unter Verwalten der SSH-Konfiguration nach, wie der Schlüssel Ihrem Cluster hinzugefügt wird.

Linux und macOS

Linux- und macOS-Benutzer*innen können den Zugriff auf ihren Knoten über kubectl debug oder ihre private IP-Adresse verwenden. Windows-Benutzer sollten zum Abschnitt „Windows Server-Proxy“ springen, der eine Problemumgehung für SSH über Proxy enthält.

Verbinden mithilfe von kubectl debug

Verwenden Sie den Befehl kubectl debug, um einen privilegierten Container in Ihrem Knoten auszuführen, um eine interaktive Shellverbindung herzustellen.

Verwenden Sie den kubectl get nodes-Befehl, um Ihre Knoten aufzulisten:

kubectl get nodes -o wide

Beispielausgabe:

NAME                                STATUS   ROLES   AGE    VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE
aks-nodepool1-37663765-vmss000000   Ready    agent   166m   v1.25.6   10.224.0.33   <none>        Ubuntu 22.04.2 LTS
aks-nodepool1-37663765-vmss000001   Ready    agent   166m   v1.25.6   10.224.0.4    <none>        Ubuntu 22.04.2 LTS
aksnpwin000000                      Ready    agent   160m   v1.25.6   10.224.0.62   <none>        Windows Server 2022 Datacenter

Verwenden Sie den Befehl kubectl debug, um einen privilegierten Container auf Ihrem Knoten zu starten und eine Verbindung damit herzustellen.
```
kubectl debug node/aks-nodepool1-37663765-vmss000000 -it --image=mcr.microsoft.com/cbl-mariner/busybox:2.0
```
Beispielausgabe:
```
Creating debugging pod node-debugger-aks-nodepool1-37663765-vmss000000-bkmmx with container debugger on node aks-nodepool1-37663765-vmss000000.
If you don't see a command prompt, try pressing enter.
root@aks-nodepool1-37663765-vmss000000:/#
```
Sie haben nun Zugriff auf den Knoten über einen privilegierten Container als Debugpod.

Hinweis

Sie können mit der Knotensitzung interagieren, indem Sie chroot /host über den privilegierten Container ausführen.

Beenden des kubectl-Debugmodus

Wenn Sie mit Ihrem Knoten fertig sind, geben Sie den Befehl exit ein, um die interaktive Shellsitzung zu beenden. Nachdem die interaktive Containersitzung geschlossen wurde, löschen Sie den mit kubectl delete pod verwendeten Debugpod.

kubectl delete pod node-debugger-aks-nodepool1-37663765-vmss000000-bkmmx

Windows Server-Proxyverbindung für SSH

Führen Sie die folgenden Schritte als Problemumgehung aus, um eine Verbindung mit SSH auf einem Windows Server-Knoten herzustellen.

Erstellen eines Proxyservers

Derzeit können Sie mithilfe von SSH keine direkte Verbindung mit einem Windows Server-Knoten mittels kubectl debug herstellen. Stattdessen müssen Sie zunächst mit kubectl eine Verbindung mit einem anderen Knoten im Cluster herstellen und dann von diesem Knoten über SSH eine Verbindung mit dem Windows Server-Knoten herstellen.

Verwenden Sie den kubectl debug-Befehl, um eine Verbindung mit einem anderen Knoten im Cluster herzustellen. Für weitere Informationen folgen Sie den oben genannten Schritten im Abschnitt „kubectl“. Verwenden Sie die SSH-Schlüssel, die sie beim Erstellen des AKS-Clusters erhalten haben, und die interne IP-Adresse des Windows Server-Knotens, um die SSH-Verbindung mit dem Windows Server-Knoten von einem anderen Knoten aus herzustellen.

Wichtig

Die folgenden Schritte zum Erstellen der SSH-Verbindung mit dem Windows Server-Knoten über einen anderen Knoten können nur verwendet werden, wenn Sie Ihren AKS-Cluster mithilfe der Azure CLI mit dem Parameter --generate-ssh-keys erstellt haben. Wenn Sie stattdessen Ihre eigenen SSH-Schlüssel verwenden möchten, können Sie az aks update verwenden, um SSH-Schlüssel in einem vorhandenen AKS-Cluster zu verwalten. Weitere Informationen finden Sie unter Verwalten Zugriffs auf SSH-Knoten.

Hinweis

Wenn Ihr Linux-Proxyknoten ausfällt oder nicht reagiert, verwenden Sie stattdessen die Azure Bastion-Methode für die Verbindung.

Verwenden Sie den Befehl kubectl debug, um einen privilegierten Container auf Ihrem Proxyknoten (Linux) zu starten und eine Verbindung damit herzustellen.

kubectl debug node/aks-nodepool1-37663765-vmss000000 -it --image=mcr.microsoft.com/cbl-mariner/busybox:2.0

Beispielausgabe:

Creating debugging pod node-debugger-aks-nodepool1-37663765-vmss000000-bkmmx with container debugger on node aks-nodepool1-37663765-vmss000000.
If you don't see a command prompt, try pressing enter.
root@aks-nodepool1-37663765-vmss000000:/#

Öffnen Sie ein neues Terminalfenster, und verwenden Sie den kubectl get pods-Befehl, um den Namen des Pods zu erhalten, der von gestartet kubectl debug wurde.
```
kubectl get pods
```
Beispielausgabe:
```
NAME                                                    READY   STATUS    RESTARTS   AGE
node-debugger-aks-nodepool1-37663765-vmss000000-bkmmx   1/1     Running   0          21s
```
in der Beispielausgabe ist node-debugger-aks-nodepool1-37663765-vmss000000-bkmmx der Name des Pods, der von kubectl debug gestartet wurde.
Verwenden Sie den kubectl port-forward-Befehl, um eine Verbindung mit dem bereitgestellten Pod zu öffnen:
```
kubectl port-forward node-debugger-aks-nodepool1-37663765-vmss000000-bkmmx 2022:22
```
Beispielausgabe:
```
Forwarding from 127.0.0.1:2022 -> 22
Forwarding from [::1]:2022 -> 22
```
Im vorherigen Beispiel wird der Netzwerkdatenverkehr von Port 2022 auf Ihrem Entwicklungscomputer an Port 22 auf dem bereitgestellten Pod weitergeleitet. Wenn Sie mit kubectl port-forward eine Verbindung öffnen und den Netzwerkdatenverkehr weiterleiten, bleibt die Verbindung offen, bis Sie den Befehl kubectl port-forward beenden.
Öffnen Sie ein neues Terminal, und zeigen Sie mit dem kubectl get nodes-Befehl die interne IP-Adresse des Windows Server-Knotens an:
```
kubectl get no -o custom-columns=NAME:metadata.name,'INTERNAL_IP:status.addresses[?(@.type == \"InternalIP\")].address'
```
Beispielausgabe:
```
NAME                                INTERNAL_IP
aks-nodepool1-19409214-vmss000003   10.224.0.8
```
Im vorherigen Beispiel ist 10.224.0.62 die interne IP-Adresse des Windows Server-Knotens.
Erstellen Sie mithilfe der internen IP-Adresse eine SSH-Verbindung mit dem Windows Server-Knoten, und stellen Sie eine Verbindung mit Port 22 bis Port 2022 auf Ihrem Entwicklungscomputer her. Auch hier lautet der Standardbenutzername für AKS-Knoten azureuser. Bestätigen Sie die Aufforderung zum Fortsetzen der Verbindungsherstellung. Anschließend wird die Bash-Eingabeaufforderung Ihres Windows Server-Knotens angezeigt:
```
ssh -o 'ProxyCommand ssh -p 2022 -W %h:%p azureuser@127.0.0.1' azureuser@10.224.0.62
```
Beispielausgabe:
```
The authenticity of host '10.224.0.62 (10.224.0.62)' can't be established.
ECDSA key fingerprint is SHA256:1234567890abcdefghijklmnopqrstuvwxyzABCDEFG.
Are you sure you want to continue connecting (yes/no)? yes
```
Hinweis

Wenn Sie die Kennwortauthentifizierung bevorzugen, beziehen Sie den Parameter -o PreferredAuthentications=password ein. Beispiel:
```
 ssh -o 'ProxyCommand ssh -p 2022 -W %h:%p azureuser@127.0.0.1' -o PreferredAuthentications=password azureuser@10.224.0.62
```

Verwenden Sie einen Hostprozesscontainer, um auf Windows-Knoten zuzugreifen.

Führen Sie das folgende Skript aus, um hostprocess.yaml zu erstellen. Ersetzen Sie im Skript AKSWINDOWSNODENAME durch den Namen des AKS Windows-Knotens.

Diese Spezifikation verwendet das Nanoserver-Basisimage. Das Basisimage verfügt nicht über PowerShell, aber da es als Hostprozesscontainer (HPC) ausgeführt wird, ist PowerShell in der zugrunde liegenden VM verfügbar.

apiVersion: v1
kind: Pod
metadata:
  labels:
    pod: hpc
  name: hpc
spec:
  securityContext:
    windowsOptions:
      hostProcess: true
      runAsUserName: "NT AUTHORITY\\SYSTEM"
  hostNetwork: true
  containers:
    - name: hpc
      image: mcr.microsoft.com/windows/nanoserver:ltsc2022 # Use nanoserver:1809 for WS2019
      command:
        - powershell.exe
        - -Command
        - "Start-Sleep 2147483"
      imagePullPolicy: IfNotPresent
  nodeSelector:
    kubernetes.io/os: windows
    kubernetes.io/hostname: AKSWINDOWSNODENAME
  tolerations:
    - effect: NoSchedule
      key: node.kubernetes.io/unschedulable
      operator: Exists
    - effect: NoSchedule
      key: node.kubernetes.io/network-unavailable
      operator: Exists
    - effect: NoExecute
      key: node.kubernetes.io/unreachable
      operator: Exists

Führen Sie kubectl apply -f hostprocess.yaml aus, um Windows HPC auf dem angegebenen Windows-Knoten bereitzustellen.
Verwenden Sie kubectl exec -it [HPC-POD-NAME] -- powershell.
Sie können alle PowerShell-Befehle innerhalb des HPC-Containers ausführen, um auf den Windows-Knoten zuzugreifen.

Hinweis

Im HPC-Container müssen Sie den Stammordner zu C:\ wechseln, um auf die Dateien im Windows-Knoten zuzugreifen.

SSH mit Azure Bastion für Windows

Wenn Ihr Linux-Proxyknoten nicht erreichbar ist, ist die Verwendung von Azure Bastion als Proxy eine Alternative. Für diese Methode müssen Sie einen Azure Bastion-Host für das virtuelle Netzwerk einrichten, in dem sich der Cluster befindet. Weitere Details finden Sie unter Herstellen einer Verbindung mit Azure Bastion.

SSH mit privaten IPs aus der AKS-API

Wenn Sie keinen Zugriff auf die Kubernetes-API haben, können Sie über die AKS agent pool API, (verfügbar in stabilen Versionen 07-01-2024 oder höher) Zugriff auf Eigenschaften wie Node IP und Node Name erhalten, um eine Verbindung mit AKS-Knoten herzustellen.

Erstellen einer interaktiven Shellverbindung mit einem Knoten mithilfe der IP-Adresse

Aus Gründen der Einfachheit werden AKS-Knoten über private IP-Adressen im virtuellen Netzwerk des Clusters verfügbar gemacht. Sie müssen sich jedoch im virtuellen Netzwerk des Clusters befinden, um über SSH eine Verbindung mit dem Knoten herzustellen. Wenn Sie noch keine Umgebung konfiguriert haben, können Sie Azure Bastion verwenden, um einen Proxy einzurichten, von dem Sie über SSH eine Verbindung mit Clusterknoten herstellen können. Stellen Sie sicher, dass Azure Bastion im selben virtuellen Netzwerk wie der Cluster bereitgestellt ist.

Rufen Sie private IPs mithilfe des Befehls az aks machine list ab, wobei alle virtuellen Computer in einem bestimmten Knotenpool mit dem Flag --nodepool-name das Ziel sind.

az aks machine list --resource-group myResourceGroup  --cluster-name myAKSCluster --nodepool-name nodepool1 -o table

Die folgende Beispielausgabe zeigt die internen IP-Adressen aller Knoten im Knotenpool:

Name                               Ip           Family
---------------------------------  -----------  -----------
aks-nodepool1-33555069-vmss000000  10.224.0.5   IPv4
aks-nodepool1-33555069-vmss000001  10.224.0.6   IPv4
aks-nodepool1-33555069-vmss000002  10.224.0.4   IPv4

Zum Festlegen eines bestimmten Knotens innerhalb des Knotenpools als Ziel verwenden Sie das Flag --machine-name:

az aks machine show --cluster-name myAKScluster --nodepool-name nodepool1 -g myResourceGroup --machine-name aks-nodepool1-33555069-vmss000000 -o table

Die folgende Beispielausgabe zeigt die interne IP-Adresse aller angegebenen Knoten:

Name                               Ip         Family
---------------------------------  -----------  -----------
aks-nodepool1-33555069-vmss000000  10.224.0.5   IPv4

Stellen Sie mithilfe der privaten IP-Adresse, die Sie im vorherigen Schritt abgerufen haben, über SSH eine Verbindung mit dem Knoten her. Dieser Schritt gilt nur für Linux-Computer. Informationen zu Windows-Computern finden Sie unter Herstellen einer Verbindung mit Azure Bastion.
```
ssh -i /path/to/private_key.pem azureuser@10.224.0.33
```

Nächste Schritte

Falls Sie weitere Daten für die Problembehandlung benötigen, können Sie die Kubelet-Protokolle anzeigen oder die Kubernetes-Steuerungsebenenprotokolle anzeigen.

Informationen zum Verwalten Ihrer SSH-Schlüssel finden Sie unter Verwalten der SSH-Konfiguration.

Feedback

War diese Seite hilfreich?

Last updated on 2025-11-07