Se hai utilizzato versioni relativamente recenti di OpenShift, devi esserti imbattuto in oc debug comando (oppure puoi controllare questa pagina man). Una delle cose interessanti del nuovo OpenShift è che suggerisce di non usare direttamente SSH (puoi vederlo in sshd_config sui nodi perché hanno PermitRootLogin no fissarli). Quindi, se dovessi eseguire oc debug node/node_name , creerà un pod per te e ti rilascerà nella shell (TTY) di questo pod.
[ Potrebbe interessarti anche: 5 motivi per cui dovresti sviluppare una strategia di container Linux ]
Sebbene sia un baccello, è un tipo speciale di baccello. Una volta avviato il pod, puoi aprire una seconda finestra di terminale ed eseguire oc get pods e trova il pod corrispondente chiamato node-name-debug e usa oc get -o yaml podName per visualizzare il suo output YAML.
Osserva l'output:
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 Ecco come appare lo YAML (ne ho tagliato alcune parti per brevità). Ho aggiunto #x numeri nello YAML. Ogni numero evidenzia un fatto specifico su questo pod di debug che è speciale rispetto ai normali pod dell'applicazione.
Riferimenti YAML
#1
name: ip-xx-x-xxx-xxxus-east-2computeinternal-debug #1
Questo mostra che il pod ottiene il nome che viene formato usando il nome del nodo. Nel mio caso il nome del nodo era ip-x-x-x-x-.us-east-2.compute.internal , quindi oc debug allega semplicemente -debug alla fine e sostituisce i punti con dei trattini.
#2
namespace: default #2 Potrebbe creare il pod in qualsiasi spazio dei nomi in cui ti trovi. In questo caso, lo spazio dei nomi è predefinito .
#3
securityContext: #3
privileged: true
runAsUser: 0
È qui che diventa interessante. Come sai, di solito non eseguirai i pod come pod privilegiato e come utente 0 (root). Tuttavia, poiché questo pod ha lo scopo di fornire un equivalente dell'accesso SSH al nodo come utente root, ha un tale securityContext impostare. Essere privilegiati aggiunge AllCapabilities (che fornisce un accesso altamente illimitato) a questo pod. Puoi vederli usando setpriv -d (output sotto) all'interno della shell di debug. Ciò ti fa ricevere un accesso quasi illimitato al nodo tramite questo pod. Inutile dire che questo pod sarà probabilmente programmato sul nodo di cui stai eseguendo il debug.
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 è impostato su true , il che significa che ottieni una shell interattiva per il pod subito dopo la creazione del pod.
#5 , #7
- mountPath: /host #5
path: / #7
Qui diventa ancora più interessante. Come puoi vedere, stai montando il volume denominato host nel percorso /host . Se guardi #7 vedrai che il volume dell'host è impostato sul percorso / sull'host, che è la directory principale. Ciò garantisce l'accesso completo al filesystem host tramite questo pod. Tuttavia, quando inizialmente salti nel tty di questo pod, non sei nel /host directory. Sei nel filesystem del contenitore con la sua radice (/ ) file system. Per passare al filesystem host come root, puoi usare chroot /host , che ti darebbe accesso a tutti i programmi installati sull'host e sembrerebbe identico a come ti sentiresti altrimenti se dovessi accedere a questo nodo tramite 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
Dal punto di vista della rete, questo pod utilizza un hostNetwork , che equivale a eseguire Docker o Podman con --net=host durante l'esecuzione di un container. In questo caso, viene utilizzato per far sembrare che i programmi all'interno del contenitore siano in esecuzione sull'host stesso dal punto di vista della rete. Consente al contenitore un accesso alla rete maggiore di quello che può ottenere normalmente. Di solito devi inoltrare le porte dalla macchina host a un container. Tuttavia, quando i container condividono la rete dell'host, qualsiasi attività di rete avviene direttamente sulla macchina host, proprio come accadrebbe se il programma fosse in esecuzione localmente sull'host anziché all'interno di un container. Con questo, stai ottenendo l'accesso alle reti host, che probabilmente sarebbero anche illimitate. È importante notare che il nodo host fornisce al contenitore l'accesso completo ai servizi di sistema locali come D-bus ed è quindi considerato non sicuro. Se guardi lo stato, puoi vedere l'hostIP , podIP e podIP i campi hanno un valore comune che corrisponde all'indirizzo IP originale del nodo. Ciò dimostra che stai effettivamente utilizzando un pod di rete host.
[ Ottieni questo ebook gratuito:Gestione dei cluster Kubernetes per i manichini. ]
Concludi
Questo articolo è una breve panoramica di come il oc debug il comando funzionerebbe per il debug di un nodo in un cluster OpenShift.