Si vous avez utilisé des versions relativement récentes d'OpenShift, vous devez avoir rencontré le oc debug commande (ou vous pouvez consulter cette page de manuel). L'une des choses intéressantes à propos du nouvel OpenShift est qu'il suggère de ne pas utiliser SSH directement (vous pouvez le voir dans sshd_config sur les nœuds car ils ont PermitRootLogin no mis sur eux). Donc, si vous deviez exécuter oc debug node/node_name , il créera un pod pour vous et vous déposera dans le shell (TTY) de ce pod.
[ Vous pourriez également apprécier : 5 raisons pour lesquelles vous devriez développer une stratégie de conteneur Linux ]
Bien qu'il s'agisse d'une gousse, il s'agit d'un type particulier de gousse. Une fois le pod lancé, vous pouvez ouvrir une deuxième fenêtre de terminal et exécuter oc get pods et trouvez le pod correspondant nommé node-name-debug et utilisez oc get -o yaml podName pour afficher sa sortie YAML.
Observez la sortie :
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 Voici à quoi ressemble le YAML (j'en ai coupé certaines parties par souci de brièveté). J'ai ajouté #x numéros dans le YAML. Chaque numéro met en évidence un fait spécifique sur ce pod de débogage qui est spécial par rapport aux pods d'application réguliers.
Références YAML
#1
name: ip-xx-x-xxx-xxxus-east-2computeinternal-debug #1
Cela montre que le pod obtient le nom formé à l'aide du nom de nœud. Dans mon cas, le nom du nœud était ip-x-x-x-x-.us-east-2.compute.internal , donc oc debug attache simplement -debug à la fin et remplace les points par des tirets.
#2
Espace de noms
namespace: default #2 Il peut créer le pod dans n'importe quel espace de noms dans lequel vous vous trouvez. Dans ce cas, l'espace de noms est default .
#3
securityContext: #3
privileged: true
runAsUser: 0
C'est là que ça devient intéressant. Comme vous le savez, vous n'exécuterez généralement pas les pods en tant que pod privilégié et en tant qu'utilisateur 0 (root). Cependant, comme ce pod est censé vous fournir un équivalent de l'accès SSH au nœud en tant qu'utilisateur root, il a un tel securityContext d'installation. Être privilégié ajoute AllCapabilities (donnant un accès hautement illimité) à ce pod. Vous pouvez les voir en utilisant setpriv -d (sortie ci-dessous) dans le shell de débogage. Cela vous permet de recevoir un accès presque illimité au nœud via ce pod. Inutile de dire que ce pod sera probablement planifié sur le nœud que vous déboguez.
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 est défini sur true , ce qui signifie que vous obtenez un shell interactif pour le pod immédiatement après sa création.
#5 , #7
- mountPath: /host #5
path: / #7
Ici, cela devient encore plus intéressant. Comme vous pouvez le voir, vous montez le volume nommé host sur le chemin /host . Si vous regardez #7 vous verrez que le volume de l'hôte est défini sur le chemin / sur l'hôte, qui est le répertoire racine. Cela garantit que vous avez un accès complet au système de fichiers hôte via ce pod. Cependant, lorsque vous sautez initialement dans le tty de ce pod, vous n'êtes pas dans le /host annuaire. Vous êtes dans le système de fichiers du conteneur avec sa propre racine (/ ) système de fichiers. Pour passer au système de fichiers hôte en tant que root, vous pouvez utiliser chroot /host , ce qui vous donnerait accès à tous les programmes installés sur l'hôte, et cela ressemblerait à ce que vous ressentiriez autrement si vous vous connectiez en SSH à ce nœud.
#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
Du point de vue de la mise en réseau, ce pod utilise un hostNetwork , ce qui équivaut à exécuter Docker ou Podman avec --net=host lors de l'exécution d'un conteneur. Dans ce cas, il est utilisé pour donner l'impression que les programmes à l'intérieur du conteneur s'exécutent sur l'hôte lui-même du point de vue du réseau. Il permet au conteneur un accès réseau supérieur à celui qu'il peut normalement obtenir. Vous devez généralement transférer les ports de la machine hôte vers un conteneur. Cependant, lorsque les conteneurs partagent le réseau de l'hôte, toute activité réseau se produit directement sur la machine hôte, comme si le programme s'exécutait localement sur l'hôte plutôt qu'à l'intérieur d'un conteneur. Avec cela, vous accédez aux réseaux hôtes, qui seraient probablement également illimités. Il est important de noter que le nœud hôte donne au conteneur un accès complet aux services système locaux tels que D-bus et est donc considéré comme non sécurisé. Si vous regardez le statut, vous pouvez voir le hostIP , podIP , et podIP les champs ont une valeur commune qui correspond à l'adresse IP d'origine du nœud. Cela prouve que vous utilisez bien un module de réseau hôte.
[ Obtenez cet ebook gratuit :Gérer vos clusters Kubernetes pour les nuls. ]
Récapitulez
Cet article est un bref aperçu de la façon dont le oc debug La commande fonctionnerait pour un nœud de débogage dans un cluster OpenShift.