Wenn Sie relativ neue Versionen von OpenShift verwendet haben, müssen Sie auf oc debug gestoßen sein Befehl (oder Sie können diese Manpage überprüfen). Eines der interessanten Dinge am neuen OpenShift ist, dass es vorschlägt, SSH nicht direkt zu verwenden (Sie können dies in sshd_config sehen auf den Knoten, weil sie PermitRootLogin no haben auf sie setzen). Wenn Sie also oc debug node/node_name ausführen würden , wird es einen Pod für Sie erstellen und Sie in der Shell (TTY) dieses Pods ablegen.
[Das könnte Ihnen auch gefallen: 5 Gründe, warum Sie eine Linux-Container-Strategie entwickeln sollten]
Obwohl es sich um eine Schote handelt, ist es eine besondere Art von Schote. Sobald der Pod gestartet ist, können Sie ein zweites Terminalfenster öffnen und oc get pods ausführen und suchen Sie den entsprechenden Pod mit dem Namen node-name-debug und verwenden Sie oc get -o yaml podName um seine YAML-Ausgabe anzuzeigen.
Beachten Sie die Ausgabe:
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 So sieht die YAML aus (ich habe der Kürze halber einige Teile davon ausgeschnitten). Ich habe #x hinzugefügt Zahlen in der YAML. Jede Zahl hebt eine bestimmte Tatsache über diesen Debug-Pod hervor, die im Vergleich zu den regulären Anwendungs-Pods etwas Besonderes ist.
YAML-Referenzen
#1
name: ip-xx-x-xxx-xxxus-east-2computeinternal-debug #1
Dies zeigt, dass der Pod den Namen erhält, der aus dem Knotennamen gebildet wird. In meinem Fall war der Knotenname ip-x-x-x-x-.us-east-2.compute.internal , also oc debug hängt einfach -debug an am Ende und ersetzt Punkte durch Bindestriche.
#2
namespace: default #2 Es kann den Pod in einem beliebigen Namespace erstellen, in dem Sie sich befinden. In diesem Fall ist der Namespace default .
#3
securityContext: #3
privileged: true
runAsUser: 0
Hier wird es interessant. Wie Sie wissen, werden Sie Pods normalerweise nicht als privilegierter Pod und als Benutzer 0 (root) ausführen. Da dieser Pod Ihnen jedoch ein Äquivalent zum SSH-Zugriff auf den Knoten als Root-Benutzer bieten soll, hat er einen solchen securityContext aufstellen. Wenn Sie privilegiert sind, werden diesem Pod AllCapabilities (mit uneingeschränktem Zugriff) hinzugefügt. Sie können diese mit setpriv -d anzeigen (Ausgabe unten) innerhalb der Debug-Shell. Dies führt dazu, dass Sie über diesen Pod nahezu unbegrenzten Zugriff auf die Node erhalten. Unnötig zu erwähnen, dass dieser Pod wahrscheinlich auf dem Knoten geplant wird, den Sie debuggen.
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 ist auf true gesetzt , was bedeutet, dass Sie unmittelbar nach der Erstellung des Pods eine interaktive Shell für den Pod erhalten.
#5 , #7
- mountPath: /host #5
path: / #7
Hier wird es noch interessanter. Wie Sie sehen können, binden Sie das Volume mit dem Namen host ein auf dem Pfad /host . Wenn Sie sich #7 ansehen Sie werden sehen, dass das Host-Volume auf den Pfad / eingestellt ist auf dem Host, der das Root-Verzeichnis ist. Dadurch wird sichergestellt, dass Sie über diesen Pod vollen Zugriff auf das Host-Dateisystem haben. Wenn Sie jedoch zum ersten Mal in das tty dieses Pods springen, befinden Sie sich nicht in /host Verzeichnis. Sie befinden sich im Dateisystem des Containers mit eigenem Root (/ ) Dateisystem. Um als root auf das Host-Dateisystem zu wechseln, können Sie chroot /host verwenden , was Ihnen Zugriff auf alle auf dem Host installierten Programme geben würde, und es würde sich genauso anfühlen, wie Sie sich sonst fühlen würden, wenn Sie sich mit SSH in diesen Knoten einloggen würden.
#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
Vom Standpunkt des Netzwerks aus verwendet dieser Pod ein hostNetwork , was dem Ausführen von Docker oder Podman mit --net=host entspricht beim Ausführen eines Containers. In diesem Fall wird es verwendet, um die Programme im Container so aussehen zu lassen, als würden sie aus der Netzwerkperspektive auf dem Host selbst ausgeführt. Es ermöglicht dem Container einen größeren Netzwerkzugriff, als er normalerweise erhalten kann. Normalerweise müssen Sie Ports von der Hostmaschine in einen Container weiterleiten. Wenn sich die Container jedoch das Netzwerk des Hosts teilen, findet jede Netzwerkaktivität direkt auf dem Hostcomputer statt – genau so, als ob das Programm lokal auf dem Host statt in einem Container ausgeführt würde. Damit erhalten Sie Zugang zu Host-Netzwerken, die wahrscheinlich ebenfalls uneingeschränkt wären. Es ist wichtig zu beachten, dass der Host-Knoten dem Container vollen Zugriff auf lokale Systemdienste wie D-Bus gewährt und daher als unsicher gilt. Wenn Sie sich den Status ansehen, können Sie die hostIP sehen , podIP und podIPs -Felder haben einen gemeinsamen Wert, der mit der ursprünglichen IP-Adresse des Knotens übereinstimmt. Dies beweist, dass Sie tatsächlich einen Hostnetzwerk-Pod verwenden.
[ Holen Sie sich dieses kostenlose E-Book:Verwalten Ihrer Kubernetes-Cluster für Dummies. ]
Abschluss
Dieser Artikel gibt einen kurzen Überblick darüber, wie der oc debug Der Befehl würde für das Debuggen eines Knotens in einem OpenShift-Cluster funktionieren.