Pokud jste používali relativně nedávné verze OpenShift, museli jste narazit na oc debug (nebo se můžete podívat na tuto manuálovou stránku). Jednou ze zajímavých věcí na novém OpenShift je, že navrhuje nepoužívat SSH přímo (můžete to vidět v sshd_config na uzlech, protože mají PermitRootLogin no nastavit na ně). Pokud byste tedy spustili oc debug node/node_name , vytvoří pro vás pod a upustí vás do pouzdra (TTY) tohoto pod.
[ Také by vás mohlo zajímat: 5 důvodů, proč byste měli vyvinout strategii kontejnerů pro Linux ]
Přestože se jedná o lusk, je to zvláštní druh lusku. Jakmile je modul spuštěn, můžete otevřít druhé okno terminálu a spustit oc get pods a najděte odpovídající modul s názvem node-name-debug a použijte oc get -o yaml podName k zobrazení jeho výstupu YAML.
Sledujte výstup:
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 Takto vypadá YAML (některé jeho části jsem pro stručnost odstřihl). Přidal jsem #x čísla v YAML. Každé číslo zdůrazňuje konkrétní fakt o tomto ladicím modulu, který je ve srovnání s běžnými moduly aplikací zvláštní.
Reference YAML
#1
name: ip-xx-x-xxx-xxxus-east-2computeinternal-debug #1
To ukazuje, že pod získá název, který je vytvořen pomocí názvu uzlu. V mém případě byl název uzlu ip-x-x-x-x-.us-east-2.compute.internal , takže oc debug jednoduše připojí -debug na konci a nahradí tečky pomlčkami.
#2
namespace: default #2 Může vytvořit pod v jakémkoli jmenném prostoru, ve kterém se nacházíte. V tomto případě je jmenný prostor výchozí .
#3
securityContext: #3
privileged: true
runAsUser: 0
Tady to začíná být zajímavé. Jak víte, pody obvykle nespustíte jako privilegovaný pod a jako uživatel 0 (root). Protože však tento modul má poskytnout určitý ekvivalent přístupu SSH k uzlu jako uživateli root, má takový securityContext založit. Být privilegovaný přidává do tohoto modulu AllCapabilities (poskytuje vysoce neomezený přístup). Můžete je zobrazit pomocí setpriv -d (výstup níže) v ladicím prostředí. To způsobí, že prostřednictvím tohoto modulu získáte téměř neomezený přístup k uzlu. Netřeba dodávat, že tento modul bude pravděpodobně naplánován na uzlu, který ladíte.
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 je nastaven na true , což znamená, že získáte interaktivní shell pro pod ihned po vytvoření pod.
#5 , #7
- mountPath: /host #5
path: / #7
Tady to začíná být ještě zajímavější. Jak vidíte, připojujete svazek s názvem host na cestě /host . Pokud se podíváte na #7 uvidíte, že svazek hostitele je nastaven na cestu / na hostiteli, což je kořenový adresář. To zajišťuje, že máte plný přístup k hostitelskému souborovému systému prostřednictvím tohoto modulu. Když však na začátku skočíte do tty tohoto modulu, nejste v /host adresář. Nacházíte se v souborovém systému kontejneru s jeho vlastním kořenem (/ ) souborový systém. Chcete-li přejít na souborový systém hostitele jako root, můžete použít chroot /host , což by vám umožnilo přístup ke všem programům nainstalovaným na hostiteli a bylo by to stejné, jako byste se jinak cítili, kdybyste do tohoto uzlu použili 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
Z hlediska sítě tento modul používá hostNetwork , což je ekvivalentní spuštění Dockeru nebo Podmana s --net=host při provozu kontejneru. V tomto případě se používá k tomu, aby programy uvnitř kontejneru vypadaly, jako by běžely na samotném hostiteli z pohledu sítě. Umožňuje kontejneru větší přístup k síti, než může normálně získat. Obvykle musíte přesměrovat porty z hostitelského počítače do kontejneru. Když však kontejnery sdílejí síť hostitele, jakákoli síťová aktivita probíhá přímo na hostitelském počítači – stejně jako by tomu bylo, kdyby program běžel lokálně na hostiteli namísto uvnitř kontejneru. Tím získáte přístup k hostitelským sítím, které by pravděpodobně byly také neomezené. Je důležité poznamenat, že hostitelský uzel poskytuje kontejneru plný přístup k místním systémovým službám, jako je D-bus, a je proto považován za nezabezpečený. Pokud se podíváte na stav, můžete vidět hostIP , podIP a podIP pole mají společnou hodnotu, která odpovídá původní IP adrese uzlu. To dokazuje, že skutečně používáte hostitelský síťový modul.
[ Získejte tuto bezplatnou e-knihu:Správa clusterů Kubernetes pro figuríny. ]
Sbalit
Tento článek je stručným přehledem toho, jak oc debug příkaz by fungoval pro ladění uzlů v clusteru OpenShift.