Azure Kubernetes Service (AKS) クラスターのライフサイクル全体を通じて、最終的には AKS ノードに直接アクセスする必要があります。 このアクセスは、メンテナンス、ログ収集、トラブルシューティング操作のためのアクセスである場合があります。
この記事では、AKS Linux と Windows ノードに対するセキュリティで保護された接続の 2 つのオプションについて説明します。 1 つは Kubernetes API アクセス権を持っている必要があり、もう 1 つは、直接プライベート IP 情報を提供する AKS ARM API を介して行う必要があります。 セキュリティ上の理由により、AKS ノードはインターネットに公開されません。 代わりに、AKS ノードに直接接続するには、 またはホストのプライベート IP アドレスを使用する必要があります。
Kubernetes API を使用してノードにアクセスする
このメソッドには、 コマンドが必要です。
開始する前に
このガイドでは、AKS ノードへの接続を作成し、ご使用の AKS クラスターの SSH キーを更新する方法を説明します。 これらの手順を実行するには、バージョン 2.0.64 以降Azure CLI必要があります。 バージョンを確認するには、コマンド "
SSH キーがない場合は、次の手順を実行します。 ノード OS イメージに応じて、macOS および Linux、または Windows に応じて SSH キーを作成します。 キー ペアを OpenSSH 形式で保存し、 などのサポートされていない形式は避けてください。 次に、SSH 構成の管理に関するページを参照して、クラスターにキーを追加します。
Linux と macOS
Linux および macOS ユーザーは、 またはプライベート IP アドレスを使用してノードにアクセスできます。 Windowsユーザーは、プロキシ経由の SSH の回避策については、「Windows Server プロキシ」セクションに進む必要があります。
kubectl デバッグを使用して接続する
対話型シェル接続を作成するには、 コマンドを使用してノード上で特権コンテナーを実行します。
ノードを一覧表示するには、 コマンドを使用します。
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 node/aks-nodepool1-37663765-vmss000000 -it --image=mcr.microsoft.com/azurelinux/busybox:1.36サンプル出力:
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 debug モードを終了する
ノードの操作が完了したら、 コマンドを入力して対話型シェル セッションを終了します。 対話型コンテナー セッションが閉じたら、 で使用されているデバッグ ポッドを削除します。
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 セクションの前の手順に従ってください。 AKS クラスターの作成時に提供される SSH キーと、Windows Server ノードの内部 IP アドレスを使用して、別のノードから Windows Server ノードへの SSH 接続を作成します。
重要
別のノードから Windows Server ノードへの SSH 接続を作成する次の手順は、--generate-ssh-keys パラメーターを使用してAzure CLIを使用して AKS クラスターを作成した場合にのみ使用できます。 代わりに独自の SSH キーを使用する場合は、 を使用して、既存の AKS クラスターで SSH キーを管理できます。 詳細については、SSH ノード アクセスの管理に関するページを参照してください。
注記
Linux プロキシ ノードがダウンしているか応答しない場合は、代わりに Azure Bastion メソッドを使用して接続します。
コマンドを使用して、プロキシ (Linux) ノードで特権コンテナーを起動し、それに接続します。
kubectl debug node/aks-nodepool1-37663765-vmss000000 -it --image=mcr.microsoft.com/azurelinux/busybox:1.36サンプル出力:
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サンプル出力:
NAME READY STATUS RESTARTS AGE node-debugger-aks-nodepool1-37663765-vmss000000-bkmmx 1/1 Running 0 21sサンプル出力の は、 によって開始されたポッドの名前です。
コマンドを使用して、デプロイされたポッドへの接続を開きます。
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前の例では、お使いの開発用コンピューターのポート から、デプロイされているポッドのポート にネットワーク トラフィックの転送を開始します。 を使用して接続を開き、ネットワーク トラフィックを転送する場合、接続は コマンドを停止するまで開いたままです。
新しいターミナルを開き、コマンド
kubectl get nodesを実行して、Windows Server ノードの内部 IP アドレスを表示します。kubectl get nodes -o custom-columns='NAME:metadata.name,INTERNAL_IP:status.addresses[?(@.type == "InternalIP")].address'サンプル出力:
NAME INTERNAL_IP aks-nodepool1-19409214-vmss000003 10.224.0.8 aksnpwin000000 10.224.0.62前の例では、
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注記
パスワード認証を使用する場合は、 パラメーターを含めます。 次に例を示します。
ssh -o 'ProxyCommand ssh -p 2022 -W %h:%p azureuser@127.0.0.1' -o PreferredAuthentications=password azureuser@10.224.0.62
ホストプロセスコンテナーを使用してWindowsノードにアクセスする
次のスクリプトを実行して、 を作成します。 スクリプトで、
AKSWINDOWSNODENAMEを AKS Windows ノード名に置き換えます。この仕様では、nanoserver 基本イメージを使用します。 基本イメージには PowerShell はありませんが、ホスト プロセス コンテナー (HPC) として実行されるため、基になる VM で PowerShell を使用できます。
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: Existskubectl apply -f hostprocess.yamlを実行して、指定したWindows ノードにWindows HPC をデプロイします。インスタンス (静的ではない) メソッド、プロパティ、フィールド
HPC コンテナー内で任意の PowerShell コマンドを実行して、Windows ノードにアクセスできます。
注記
Windows ノード内のファイルにアクセスするには、HPC コンテナー内のルート フォルダーを C:\ に切り替える必要があります。
Azure Bastionを使用した SSH
Linux プロキシ ノードに到達できない場合は、Azure Bastionをプロキシとして使用する方法があります。 この方法では、クラスターが存在する仮想ネットワークのAzure Bastion ホストを設定する必要があります。 詳細については、「Connect with Azure Bastion」を参照してください。
クラスターの仮想ネットワークからのプライベート IP を使用した SSH
便宜上、AKS ノードはプライベート IP アドレスを介してクラスターの仮想ネットワーク上に公開されます。 ただし、ノードに SSH 接続するには、クラスターの仮想ネットワーク内にいる必要があります。
Kubernetes API にアクセスできない場合は、API ( 以上の安定したバージョンで使用可能) を使用して、AKS ノードに接続するやなどのプロパティにアクセスできます。 コマンドを使用してプライベート IP を取得し、 フラグを使用して特定のノード プール内のすべての 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ノード プール内の特定のノードをターゲットにするには、 フラグを使用します。
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 ノードにのみ適用されます。
ssh -i /path/to/private_key.pem azureuser@10.224.0.33
次のステップ
トラブルシューティングのデータがさらに必要な場合は、kubelet ログを表示するか、Kubernetes コントロール プレーン ログを表示することができます。
SSH キーの管理については、SSH 構成の管理に関するページを参照してください。