比較的新しいバージョンのOpenShiftを使用したことがある場合は、oc debugに出くわしたはずです。 コマンド（またはこのマニュアルページを確認できます）。新しいOpenShiftの興味深い点の1つは、SSHを直接使用しないことを提案していることです（これはsshd_configで確認できます）。 ノードにはPermitRootLoginnoがあるため それらに設定）。したがって、oc debug node/node_nameを実行する場合 、それはあなたのためのポッドを作成し、このポッドのシェル（TTY）にあなたをドロップします。
[次のこともお楽しみいただけます：Linuxコンテナ戦略を開発する必要がある5つの理由]
ポッドですが、特殊なポッドです。ポッドが起動したら、2番目のターミナルウィンドウを開いてoc get podsを実行できます。 node-name-debugという名前の対応するポッドを見つけます oc get -o yaml podNameを使用します YAML出力を表示します。
出力を観察します：
apiVersion: v1
kind: Pod
metadata:
name: ip-xx-x-xxx-xxxus-east-2computeinternal-debug #1
namespace: default #2
...
<snip>
....
spec:
containers:
- command:
- /bin/sh
image: quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:57e87210a3f3a3ba4fc85dde180c76988a5f68445f705fd07855003986c75ab0
name: container-00
...
securityContext: #3
privileged: true
runAsUser: 0
...
tty: true #4
volumeMounts:
- mountPath: /host #5
name: host
- mountPath: /var/run/secrets/kubernetes.io/serviceaccount
name: default-token-dnkrx
readOnly: true
...
hostNetwork: true #6
...
volumes:
- hostPath:
path: / #7
type: Directory
name: host
- name: default-token-dnkrx
secret:
defaultMode: 420
secretName: default-token-dnkrx
status: #8
…
hostIP: 10.0.111.111
phase: Running
podIP: 10.0.111.111
podIPs:
- ip: 10.0.111.111 これはYAMLがどのように見えるかです（簡潔にするためにその一部を切り取っています）。 #xを追加しました YAMLの番号。それぞれの数字は、通常のアプリケーションポッドと比較して特別なこのデバッグポッドに関する特定の事実を強調しています。
YAMLリファレンス
＃1
name: ip-xx-x-xxx-xxxus-east-2computeinternal-debug #1
これは、ポッドがノード名を使用して形成された名前を取得することを示しています。私の場合、ノード名はip-x-x-x-x-.us-east-2.compute.internalでした。 、したがってoc debug -debugを添付するだけです 最後に、ドットをダッシュに置き換えます。
＃2
namespace: default #2 使用している名前空間にポッドが作成される場合があります。この場合、名前空間はデフォルトです。 。
＃3
securityContext: #3
privileged: true
runAsUser: 0
これはそれが面白くなるところです。ご存知のように、通常、ポッドを特権ポッドおよびユーザー0（ルート）として実行することはありません。ただし、このポッドは、rootユーザーとしてノードへのSSHアクセスに相当するものを提供することを目的としているため、このような securityContext 設定。特権を持つと、このポッドにAllCapabilitiesが追加されます（非常に無制限のアクセスが可能になります）。 setpriv -d を使用してそれらを確認できます （以下の出力）デバッグシェル内。これにより、このポッドを介してノードへのほぼ無制限のアクセスを受け取ることができます。言うまでもなく、このポッドは、デバッグしているノードでスケジュールされる可能性があります。
sh-4.4# setpriv -d
uid: 0
euid: 0
gid: 0
egid: 0
Supplementary groups: [none]
no_new_privs: 0
Inheritable capabilities: chown,dac_override,dac_read_search,fowner,fsetid,kill,setgid,setuid,setpcap,linux_immutable,net_bind_service,net_broadcast,net_admin,net_raw,ipc_lock,ipc_owner,sys_module,sys_rawio,sys_chroot,sys_ptrace,sys_pacct,sys_admin,sys_boot,sys_nice,sys_resource,sys_time,sys_tty_config,mknod,lease,audit_write,audit_control,setfcap,mac_override,mac_admin,syslog,wake_alarm,block_suspend,audit_read
Ambient capabilities: chown,dac_override,dac_read_search,fowner,fsetid,kill,setgid,setuid,setpcap,linux_immutable,net_bind_service,net_broadcast,net_admin,net_raw,ipc_lock,ipc_owner,sys_module,sys_rawio,sys_chroot,sys_ptrace,sys_pacct,sys_admin,sys_boot,sys_nice,sys_resource,sys_time,sys_tty_config,mknod,lease,audit_write,audit_control,setfcap,mac_override,mac_admin,syslog,wake_alarm,block_suspend,audit_read
Capability bounding set: chown,dac_override,dac_read_search,fowner,fsetid,kill,setgid,setuid,setpcap,linux_immutable,net_bind_service,net_broadcast,net_admin,net_raw,ipc_lock,ipc_owner,sys_module,sys_rawio,sys_chroot,sys_ptrace,sys_pacct,sys_admin,sys_boot,sys_nice,sys_resource,sys_time,sys_tty_config,mknod,lease,audit_write,audit_control,setfcap,mac_override,mac_admin,syslog,wake_alarm,block_suspend,audit_read
Securebits: [none]
SELinux label: system_u:system_r:spc_t:s0 ＃4
tty: true #4 TTYはtrueに設定されています 、つまり、ポッドが作成された直後にポッドのインタラクティブシェルを取得します。
＃5 、＃7
- mountPath: /host #5
path: / #7
ここでさらに面白くなります。ご覧のとおり、hostという名前のボリュームをマウントしています パス/host 。 ＃7を見ると ホストボリュームがパス/に設定されていることがわかります ルートディレクトリであるホスト上。これにより、このポッドを介してホストファイルシステムに完全にアクセスできるようになります。ただし、最初にこのポッドのttyにジャンプしたときは、/hostにはいません。 ディレクトリ。独自のルート（/を持つコンテナのファイルシステムにいます ） ファイルシステム。ルートとしてホストファイルシステムに変更するには、chroot /hostを使用できます。 、これにより、ホストにインストールされているすべてのプログラムにアクセスできるようになり、このノードにSSHで接続した場合と同じように感じられます。
＃6 、＃8
hostNetwork: true #6
status: #8
…
hostIP: 10.0.111.111
phase: Running
podIP: 10.0.111.111
podIPs:
- ip: 10.0.111.111
ネットワークの観点から、このポッドは hostNetworkを使用します 、これは、DockerまたはPodmanを--net=hostで実行するのと同じです。 コンテナを実行するとき。この場合、ネットワークの観点から、コンテナ内のプログラムがホスト自体で実行されているように見せるために使用されます。これにより、コンテナは通常よりも多くのネットワークアクセスが可能になります。通常、ポートをホストマシンからコンテナに転送する必要があります。ただし、コンテナがホストのネットワークを共有している場合、プログラムがコンテナ内ではなくホスト上でローカルに実行されている場合と同様に、ネットワークアクティビティはホストマシン上で直接発生します。これにより、おそらく制限のないホストネットワークにアクセスできるようになります。ホストノードはコンテナにDバスなどのローカルシステムサービスへのフルアクセスを提供するため、安全でないと見なされることに注意することが重要です。ステータスを見ると、 hostIPがわかります。 、 podIP 、および podIPs フィールドには、ノードの元のIPアドレスと一致する共通の値があります。これは、実際にホストネットワークポッドを使用していることを証明しています。
[この無料の電子書籍を入手する：ダミーのKubernetesクラスターを管理する。 ]
まとめ
この記事は、oc debugの概要です。 コマンドは、OpenShiftクラスターでのノードデバッグに対して機能します。