メンテナンスまたはトラブルシューティングのために Azure Kubernetes Service (AKS) クラスター ノードに接続する
Azure Kubernetes Service (AKS) クラスターのライフサイクル全体を通じて、最終的には AKS ノードに直接アクセスする必要があります。 このアクセスは、メンテナンス、ログ収集、トラブルシューティング操作のためのアクセスである場合があります。
認証を通じてノードにアクセスします。認証方法は、お使いのノード OS と接続方法によって異なります。 この記事で説明する 2 つのオプションを使用して、AKS Linux と Windows の各ノードに対して安全に認証します。 1 つは Kubernetes API アクセス権を持っている必要があり、もう 1 つは、直接プライベート IP 情報を提供する AKS ARM API を介して行う必要があります。 セキュリティ上の理由により、AKS ノードはインターネットに公開されません。 代わりに、AKS ノードに直接接続するには、kubectl debug
またはホストのプライベート IP アドレスを使用する必要があります。
Kubernetes API を使用してノードにアクセスする
この方法では kubectl debug
コマンドを使用する必要があります。
開始する前に
このガイドでは、AKS ノードへの接続を作成し、ご使用の AKS クラスターの SSH キーを更新する方法を説明します。 この手順に従うには、バージョン 2.0.64 以降をサポートする Azure CLI を使用する必要があります。 バージョンを確認するには、az --version
を使用します。 インストールまたはアップグレードする必要がある場合は、Azure CLI のインストールに関するページを参照してください。
SSH キーがない場合は、次の手順を実行します。 お使いのノード OS イメージ (macOS および Linux、または Windows) に応じて SSH キーを作成します。 キー ペアは必ず OpenSSH 形式で保存し、.ppk
などのサポートされていない形式は避けてください。 次に、SSH 構成の管理に関するページを参照して、クラスターにキーを追加します。
Linux と macOS
Linux ユーザーと macOS ユーザーは、kubectl debug
または自身のプライベート IP アドレスを使用して、ノードにアクセスできます。 Windows ユーザーは、プロキシ経由の SSH の回避策について、Windows Server プロキシ セクションに進んでください。
kubectl debug を使用して接続する
対話型シェル接続を作成するには、kubectl debug
コマンドを使用してノード上で特権コンテナーを実行します。
ノードを一覧表示するには、
kubectl get nodes
コマンドを使用します。kubectl get nodes -o wide
サンプル出力:
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
kubectl debug
コマンドを使用して、ノードで特権コンテナーを起動し、それに接続します。kubectl debug node/aks-nodepool1-37663765-vmss000000 -it --image=mcr.microsoft.com/cbl-mariner/busybox:2.0
サンプル出力:
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:/#
これで、特権コンテナーを介してデバッグ ポッドとしてノードにアクセスできるようになりました。
Note
特権コンテナーから
chroot /host
を実行することで、ノード セッションと対話できます。
kubectl debug モードを終了する
ノードの操作が完了したら、exit
コマンドを入力して対話型シェル セッションを終了します。 対話型コンテナー セッションが閉じたら、kubectl delete pod
で使用されているデバッグ ポッドを削除します。
kubectl delete pod node-debugger-aks-nodepool1-37663765-vmss000000-bkmmx
SSH 用 Windows Server プロキシ接続
Windows Server ノードで SSH を使用した接続を回避するには、次の手順に従います。
プロキシ サーバーを作成する
現時点では、kubectl debug
を使用して、Windows Server ノードに直接接続することはできません。 代わりに、まず kubectl
を使用してクラスター内の別のノードに接続してから、SSH を使用してそのノードから Windows Server ノードに接続する必要があります。
クラスター内の別のノードに接続するには、kubectl debug
コマンドを使用します。 詳細については、上記の kubectl セクションの手順に従ってください。 AKS クラスターの作成時に提供された SSH キーと Windows Server ノードの内部 IP アドレスを使用して、別のノードから Windows Server ノードへの SSH 接続を作成します。
重要
別のノードから Windows Server ノードへの SSH 接続を作成するための次の手順は、Azure CLI を --generate-ssh-keys
パラメータとともに使用して AKS クラスターを作成した場合にのみ使用できます。 代わりに独自の SSH キーを使用する場合は、az aks update
を使用して、既存の AKS クラスターで SSH キーを管理できます。 詳細については、SSH ノード アクセスの管理に関するページを参照してください。
Note
Linux プロキシ ノードがダウンしているか応答していない場合は、代わりに Azure Bastion メソッドを使用して接続します。
kubectl debug
コマンドを使用して、プロキシ (Linux) ノードで特権コンテナーを起動し、それに接続します。kubectl debug node/aks-nodepool1-37663765-vmss000000 -it --image=mcr.microsoft.com/cbl-mariner/busybox:2.0
サンプル出力:
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:/#
新しいターミナル ウィンドウを開き、
kubectl get pods
コマンドを使用して、kubectl debug
によって起動されたポッドの名前を取得します。kubectl get pods
サンプル出力:
NAME READY STATUS RESTARTS AGE node-debugger-aks-nodepool1-37663765-vmss000000-bkmmx 1/1 Running 0 21s
サンプル出力では、node-debugger-aks-nodepool1-37663765-vmss000000-bkmmx は
kubectl debug
によって起動されたポッドの名前です。kubectl port-forward
コマンドを使用して、デプロイされたポッドへの接続を開きます。kubectl port-forward node-debugger-aks-nodepool1-37663765-vmss000000-bkmmx 2022:22
サンプル出力:
Forwarding from 127.0.0.1:2022 -> 22 Forwarding from [::1]:2022 -> 22
前の例では、お使いの開発用コンピューターのポート
2022
から、デプロイされているポッドのポート22
にネットワーク トラフィックの転送を開始します。kubectl port-forward
を使用して接続を開き、ネットワーク トラフィックを転送する場合、接続はkubectl port-forward
コマンドを停止するまで開いたままです。新しいターミナルを開き、
kubectl get nodes
コマンドを実行して、Windows Server ノードの内部 IP アドレスを表示します。kubectl get no -o custom-columns=NAME:metadata.name,'INTERNAL_IP:status.addresses[?(@.type == \"InternalIP\")].address'
サンプル出力:
NAME INTERNAL_IP aks-nodepool1-19409214-vmss000003 10.224.0.8
前の例では、10.224.0.62 が、Windows Server ノードの内部 IP アドレスです。
内部 IP アドレスを使用して Windows Server ノードへの SSH 接続を作成し、開発用コンピューターのポート
22
からポート2022
に接続します。 AKS ノードの既定のユーザー名は、azureuser です。 接続を続行するプロンプトを受け入れます。 次に、Windows Server ノードの bash プロンプトが提供されます。ssh -o 'ProxyCommand ssh -p 2022 -W %h:%p azureuser@127.0.0.1' azureuser@10.224.0.62
サンプル出力:
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
Note
パスワード認証を使用する場合は、
-o PreferredAuthentications=password
パラメーターを含めます。 次に例を示します。ssh -o 'ProxyCommand ssh -p 2022 -W %h:%p azureuser@127.0.0.1' -o PreferredAuthentications=password azureuser@10.224.0.62
ホスト プロセス コンテナーを使用して Windows ノードにアクセスする
次の内容で
hostprocess.yaml
を作成します。AKSWINDOWSNODENAME
は AKS Windows ノードの名前に置き換えます。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/servercore:ltsc2022 # Use servercore: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
kubectl apply -f hostprocess.yaml
を実行して、指定した Windows ノードに Windows ホスト プロセス コンテナー (HPC) をデプロイします。kubectl exec -it [HPC-POD-NAME] -- powershell
を使用してください。HPC コンテナー内で任意の PowerShell コマンドを実行して、Windows ノードにアクセスできます。
Note
Windows ノード内のファイルにアクセスするには、ルート フォルダーを HPC コンテナー内の C:\
に切り替える必要があります。
Azure Bastion for Windows を使用した SSH
Linux プロキシ ノードに到達できない場合は、代わりに Azure Bastion をプロキシとして使用します。 この方法では、クラスターが存在する仮想ネットワーク用に Azure Bastion ホストを設定する必要があります。 詳細については、Azure Bastion との接続に関するページを参照してください。
AKS API からのプライベート IP を使用した SSH (プレビュー)
Kubernetes API にアクセスできない場合は、AKS ノードに接続するために、AKS エージェント プール API (プレビュー) (プレビュー バージョン 07-02-2023
以降で利用可能) を使用して Node IP
や Node Name
などのプロパティにアクセスできます。
重要
AKS のプレビュー機能は、セルフサービスのオプトイン単位で利用できます。 プレビューは、"現状有姿" および "利用可能な限度" で提供され、サービス レベル アグリーメントおよび限定保証から除外されるものとします。 AKS プレビューは、ベストエフォート ベースでカスタマー サポートによって部分的にカバーされます。 そのため、これらの機能は、運用環境での使用を意図していません。 詳細については、次のサポート記事を参照してください。
IP アドレスを使用してノードへの対話型シェル接続を作成する
便宜上、AKS ノードはプライベート IP アドレスを介してクラスターの仮想ネットワーク上に公開されます。 ただし、ノードに SSH 接続するには、クラスターの仮想ネットワーク内にいる必要があります。 環境をまだ構成していない場合は、Azure Bastion を使用して、クラスター ノードに SSH 接続できるプロキシを確立できます。 Azure Bastion がクラスターと同じ仮想ネットワークにデプロイされていることを確認します。
az aks machine list
コマンドを使用してプライベート IP を取得し、--nodepool-name
フラグを使用して特定のノード プール内のすべての VM をターゲットにします。az aks machine list --resource-group myResourceGroup --cluster-name myAKSCluster --nodepool-name nodepool1 -o table
次の出力例は、ノード プール内のすべてのノードの内部 IP アドレスを示しています。
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
ノード プール内の特定のノードをターゲットにするには、
--machine-name
フラグを使用します。az aks machine show --cluster-name myAKScluster --nodepool-name nodepool1 -g myResourceGroup --machine-name aks-nodepool1-33555069-vmss000000 -o table
次の出力例は、指定されたすべてのノードの内部 IP アドレスを示しています。
Name Ip Family --------------------------------- ----------- ----------- aks-nodepool1-33555069-vmss000000 10.224.0.5 IPv4
前の手順で取得したプライベート IP アドレスを使用して、ノードに SSH 接続します。 この手順は Linux マシンにのみ適用されます。 Windows マシンについては、Azure Bastion を使用した接続に関するページを参照してください。
ssh -i /path/to/private_key.pem azureuser@10.224.0.33
次のステップ
トラブルシューティングのデータがさらに必要な場合は、kubelet ログを表示するか、Kubernetes コントロール プレーン ログを表示することができます。
SSH キーの管理については、SSH 構成の管理に関するページを参照してください。
Azure Kubernetes Service