ワーカー・ノードに SSH できないのはなぜですか?
仮想プライベート・クラウド クラシック・インフラストラクチャー
SSH 接続を使用してワーカー・ノードにアクセスすることはできません。
パスワードによる SSH は、ワーカー・ノードでは使用できません。
すべてのワーカーノードでアクションを実行するには、Kubernetesの「DaemonSet
」を使うか、1回限りのアクションにはジョブを使う。
デバッグおよびトラブルシューティングの目的でワーカー・ノードへのホスト・アクセスを取得するには、以下のオプションを確認します。
oc debug
を使用したデバッグ
oc debug node
コマンドを使用すると、特権的な securityContext
が設定されたポッドを、トラブルシューティングするワーカー・ノードにデプロイできます。
このデバッグ・ポッドは対話式シェルとともにデプロイされるので、ポッドが作成されたらすぐにワーカー・ノードにアクセスできます。 oc debug node
コマンドの動作について詳しくは、この Red Hat ブログ投稿 を参照してください。
-
アクセスするワーカー・ノードの名前を確認します。 CoreOS ワーカー・ノードの場合、名前はワーカーのホスト名です。 他のすべてのワーカー・ノードの場合、ワーカー・ノード名はプライベート IP アドレスです。
oc get nodes -o wide
-
ホスト・アクセスが可能なデバッグ・ポッドを作成します。 ポッドが作成されたら、ポッドの対話式シェルが自動的に開かれます。 この
oc debug node
コマンドが失敗する場合は、オプション 2 に進んでください。oc debug node/<NODE_NAME>
oc debug node/<NODE_NAME>
コマンドが失敗した場合、デフォルトのコンテナー・イメージのプルを妨げるセキュリティー・グループ、ACL、またはファイアウォールのルールが存在する可能性があります。--image=us.icr.io/armada-master/network-alpine:latest
オプションをつけてコマンドを再試行する。このコマンドでは、プライベート・ネットワーク経由でアクセス可能なIBM Cloud Container Registryの画像を使用する。 -
情報を収集して問題をトラブルシューティングするのに役立つデバッグ・コマンドを実行します。
tcpdump
、curl
、ip
、ifconfig
、nc
、ping
、ps
など、デバッグで一般的に使用されるコマンドが既にシェルに用意されています。 また、'mtr
や'conntrack
などの他のツールも、'yum install <tool>
を実行することでインストールできる。
kubectl exec
を使用したデバッグ
oc debug node
コマンドを使用できない場合は、特権的な securityContext
が設定された Alpine ポッドを作成し、kubectl exec
コマンドを使用して、そのポッドの対話式シェルからデバッグ・コマンドを実行することができます。
-
アクセスするワーカー・ノードの名前を確認します。 CoreOS ワーカー・ノードの場合、名前はワーカーのホスト名です。 他のすべてのワーカー・ノードの場合、ワーカー・ノード名はプライベート IP アドレスです。
oc get nodes -o wide
-
名前を環境変数にエクスポートします。
export NODE=<NODE_NAME>
-
ワーカー・ノード上にデバッグ・ポッドを作成します。 ここでは、Docker alpine のイメージを例として使用しています。 ワーカーノードがパブリックなネットワークアクセスを持っていない場合、デバッグ用のイメージのコピーを自分のICRリポジトリに保持したり、ニーズに合わせて他のツールでカスタマイズしたイメージを構築することができます。
kubectl apply -f - << EOF apiVersion: v1 kind: Pod metadata: name: debug-${NODE} namespace: default spec: tolerations: - operator: "Exists" hostNetwork: true containers: - args: ["-c", "sleep 20d"] command: ["/bin/sh"] image: us.icr.io/armada-master/network-alpine:latest imagePullPolicy: Always name: debug securityContext: privileged: true volumeMounts: - mountPath: /host name: host-volume volumes: - name: host-volume hostPath: path: / nodeSelector: kubernetes.io/hostname: ${NODE} restartPolicy: Never EOF
-
デバッグ・ポッドにログインします。 ポッドの対話式シェルが自動的に開かれます。
kubectl exec
コマンドが失敗した場合は、オプション 3 に進みます。kubectl exec -it debug-${NODE} -- sh
ワーカーノードからログやその他のファイルを取得するには、以下のフォーマットで'
**kubectl cp**
コマンドを使用する。 次の例は、ワーカーノードのホストファイルシステムから「/var/log/messages
ファイルを取得します。oc cp default/debug-${NODE}:/host/var/log/messages ./messages
以下のログを取得して、ワーカー・ノード上の問題を探します。
/var/log/messages /var/log/kubelet.log /var/log/crio.log /var/log/calico/cni/cni.log
-
情報を収集して問題をトラブルシューティングするのに役立つデバッグ・コマンドを実行します。
dig
、「tcpdump
、「mtr
、「curl
、「ip
、「ifconfig
、「nc
、「ping
、「ps
」など、デバッグに使うようなコマンドは、すでにシェルで利用できる。apk add <tool>
を実行することで、'conntrack
ような他のツールをインストールすることもできる。 例えば、「conntrack
追加するには、「apk add conntrack-tools
実行する。 -
デバッグ用に作成したホスト・アクセス・ポッドを削除します。
kubectl delete pod debug-${NODE}
ワーカー・ノードで root SSH アクセスを有効にしてデバッグする
oc debug node
コマンドも kubectl exec
コマンドも使用できない場合は (例えば、クラスター・マスターとワーカー・ノードの間の VPN 接続がダウンしている場合など)、root SSH アクセスが可能で、かつ SSH アクセスのために SSH 公開鍵をワーカー・ノードにコピーするポッドを作成することができます。
root SSH アクセスを許可することには、セキュリティー・リスクが伴います。 SSH アクセスを許可することがワーカー・ノードの問題をトラブルシューティングするために必要であり、他に方法がない場合にのみ許可してください。 トラブルシューティングが完了したら、必ず デバッグ後のクリーンアップ セクションの手順に従って SSH アクセスを無効にしてください。
-
既存の公開 SSH 鍵を選択するか、新しい公開 SSH 鍵を作成します。
ssh-keygen -f /tmp/id_rsa_cluster_worker -t rsa -b 4096 -C temp-worker-ssh-key -P '' ls /tmp
id_rsa_cluster_worker id_rsa_cluster_worker.pub
cat /tmp/id_rsa_cluster_worker.pub
-
アクセスするワーカー・ノードの名前を確認します。 CoreOS ワーカー・ノードの場合、名前はワーカーのホスト名です。 他のすべてのワーカー・ノードの場合、ワーカー・ノード名はプライベート IP アドレスです。
oc get nodes -o wide
-
デバッグ・ポッド用の以下の YAML ファイルを作成し、
enable-ssh.yaml
として保存します。<NODE_NAME>
をワーカー・ノード名に置き換え、SSH_PUBLIC_KEY
の例のvalue
を公開 SSH 鍵に置き換えます。 ここでは、Docker alpine のイメージを例として使用しています。 ワーカーノードがパブリックなネットワークアクセスを持っていない場合、デバッグ用のイメージのコピーを自分のICRリポジトリに保持したり、ニーズに合わせて他のツールでカスタマイズしたイメージを構築することができます。apiVersion: v1 kind: Pod metadata: name: enable-ssh-<NODE_NAME> labels: name: enable-ssh spec: tolerations: - operator: "Exists" hostNetwork: true hostPID: true hostIPC: true containers: - image: us.icr.io/armada-master/network-alpine:latest env: - name: SSH_PUBLIC_KEY value: "<ssh-rsa AAA...ZZZ temp-worker-ssh-key>" args: ["-c", "echo $(SSH_PUBLIC_KEY) | tee -a /root/.ssh/authorized_keys && sed -i 's/^#*PermitRootLogin.*/PermitRootLogin yes/g' /host/etc/ssh/sshd_config && sed -i 's/^#*PermitRootLogin.*/PermitRootLogin yes/g' /host/etc/ssh/sshd_config.d/40-rhcos-defaults.conf || true && killall -1 sshd || yes n | ssh-keygen -f /host/etc/ssh/ssh_host_rsa_key -t rsa -b 4096 -C temp-server-ssh-key -P '' && while true; do sleep 86400; done"] command: ["/bin/sh"] name: enable-ssh securityContext: privileged: true volumeMounts: - mountPath: /host name: host-volume - mountPath: /root/.ssh name: ssh-volume volumes: - name: host-volume hostPath: path: / - name: ssh-volume hostPath: path: /root/.ssh nodeSelector: kubernetes.io/hostname: <NODE_NAME> restartPolicy: Never
-
クラスター内にポッドを作成します。 このポッドの作成時、公開鍵がワーカー・ノードに追加され、root SSH ログインを許可するように SSH が構成されます。
oc apply -f enable-ssh.yaml
-
SSH 鍵を使用してワーカー・ノードにアクセスするには、プライベート・ネットワークまたはパブリック・ネットワークを使用します。
プライベート・ネットワーク上のワーカーへの SSH 接続
ワーカー・ノードと同じプライベート・ネットワークにアクセスできるサーバー・インスタンスを新規作成するか、既存のものから選択します。 VPCクラスタの場合、仮想サーバーインスタンスはワーカーノードと同じVPC内に存在する必要があります。
従来のクラスタでは、仮想ルータ機能(VRF) または VLAN スパニング が有効になっていれば、デバイスは任意のプライベート VLAN からワーカーノードにアクセスできます。 それ以外の場合、デバイスは、ワーカー・ノードと同じプライベート VLAN 上に存在する必要があります。
-
手順 1 の SSH 秘密鍵をローカル・マシンからこのサーバー・インスタンスにコピーします。
scp <SSH_private_key_location> <user@host>:/.ssh/id_rsa_worker_private
-
SSH 経由でサーバー・インスタンスに接続します。
-
コピーした SSH 秘密鍵を使用するために適切な許可を設定します。
chmod 400 ~/.ssh/id_rsa_worker_private
-
手順 2 で確認したワーカー・ノードに、秘密鍵を使用して SSH で接続します。
ssh -i ~/.ssh/id_rsa_worker_private root@<WORKER_PRIVATE_IP>
パブリック・ネットワーク上のワーカー・ノードに SSH 接続します。
ワーカー・ノードにログインして、パブリック VLAN に接続されているクラシック・クラスターをデバッグします。
-
Calico CLI をインストールおよび構成し、クラスターで Calico コマンドを実行するためのコンテキストを設定します。
-
ssh-open
という名前の Calico グローバル・ネットワーク・ポリシーを作成して、ポート 22 でのインバウンド SSH トラフィックを許可します。calicoctl apply -f - <<EOF apiVersion: projectcalico.org/v3 kind: GlobalNetworkPolicy metadata: name: ssh-open spec: selector: ibm.role == 'worker_public' ingress: - action: Allow protocol: TCP destination: ports: - 22 order: 1500 EOF
-
ワーカー・ノードのパブリック IP アドレスを取得します。
oc get nodes -o wide
-
パブリック IP アドレスを介してワーカー・ノードに SSH で接続します。
ssh -i <SSH_private_key_location> root@<WORKER_PUBLIC_IP>
-
ip
、'ifconfig
、'ping
、'ps
、'curl
などのデバッグコマンドを実行し、情報の収集や問題のトラブルシューティングに役立てます。yum install <tool>
を実行して、デフォルトでインストールされていない可能性がある他のツール (tcpdump
やnc
など) をインストールすることもできます。
デバッグ後のクリーンアップ
デバッグが終了したら、リソースをクリーンアップして SSH アクセスを無効にします。
-
SSH 有効化ポッドを削除します。
oc delete pod enable-ssh-<NODE_NAME>
-
パブリック・ネットワークを介してワーカー・ノードにアクセスした場合は、ポート 22 が再度ブロックされるように、Calico ポリシーを削除します。
calicoctl delete gnp ssh-open [-c <path_to_calicoctl_cfg>/calicoctl.cfg]
-
元の SSH 構成が使用され、追加された SSH 鍵が削除されるように、クラシック・ワーカー・ノードを再ロードするか、VPC ワーカー・ノードを置き換えます。