Cómo funciona el comando de depuración oc en OpenShift

Si ha utilizado versiones relativamente recientes de OpenShift, debe haber encontrado el oc debug comando (o puede consultar esta página del manual). Una de las cosas interesantes del nuevo OpenShift es que sugiere no usar SSH directamente (puedes ver esto en sshd_config en los nodos porque tienen PermitRootLogin no puesto sobre ellos). Entonces, si tuviera que ejecutar oc debug node/node_name , creará un pod para usted y lo colocará en el shell (TTY) de este pod.

[ También podría disfrutar: 5 razones por las que debería desarrollar una estrategia de contenedores de Linux ]

Aunque es una vaina, es un tipo especial de vaina. Una vez que se inicia el pod, puede abrir una segunda ventana de terminal y ejecutar oc get pods y busque el pod correspondiente llamado node-name-debug y use oc get -o yaml podName para mostrar su salida YAML.

Observe la salida:

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

Así es como se ve el YAML (he cortado algunas partes por brevedad). He añadido #x números en el YAML. Cada número resalta un hecho específico sobre este módulo de depuración que es especial en comparación con los módulos de aplicaciones normales.

Referencias YAML

#1

name: ip-xx-x-xxx-xxxus-east-2computeinternal-debug   #1

Esto muestra que el pod obtiene el nombre que se forma usando el nombre del nodo. En mi caso, el nombre del nodo era ip-x-x-x-x-.us-east-2.compute.internal , entonces oc debug simplemente adjunta -debug al final y reemplaza los puntos con guiones.

#2

 namespace: default #2

Puede crear el pod en cualquier espacio de nombres en el que se encuentre. En este caso, el espacio de nombres es predeterminado .

#3

securityContext: #3
           privileged: true
           runAsUser: 0

Aquí es donde se pone interesante. Como sabe, normalmente no ejecutará pods como un pod privilegiado y como usuario 0 (raíz). Sin embargo, dado que este pod está destinado a proporcionarle un equivalente al acceso SSH al nodo como usuario root, tiene un securityContext configurar. Ser privilegiado agrega AllCapabilities (lo que brinda un acceso altamente ilimitado) a este pod. Puede verlos usando setpriv -d  (salida a continuación) dentro del shell de depuración. Esto hace que reciba acceso casi ilimitado al nodo a través de este pod. No hace falta decir que este pod probablemente se programará en el nodo que está depurando.

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á establecido en verdadero , lo que significa que obtiene un shell interactivo para el pod inmediatamente después de que se crea el pod.

#5 , #7

 - mountPath: /host  #5

 path: /   #7

Aquí se pone aún más interesante. Como puede ver, está montando el volumen llamado host en la ruta /host . Si miras #7 verá que el volumen del host está configurado en la ruta / en el host, que es el directorio raíz. Esto garantiza que tenga acceso completo al sistema de archivos del host a través de este pod. Sin embargo, cuando salta inicialmente al tty de este pod, no está en el /host directorio. Estás en el sistema de archivos del contenedor con su propia raíz (/ ) sistema de archivos. Para cambiar al sistema de archivos host como root, puede usar chroot /host , lo que le daría acceso a todos los programas instalados en el host, y se sentiría idéntico a cómo se sentiría si fuera a SSH en este nodo.

#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

Desde el punto de vista de la red, este módulo utiliza una hostNetwork , que es equivalente a ejecutar Docker o Podman con --net=host cuando se ejecuta un contenedor. En este caso, se utiliza para hacer que los programas dentro del contenedor parezcan estar ejecutándose en el propio host desde la perspectiva de la red. Le permite al contenedor un mayor acceso a la red de lo que normalmente puede obtener. Por lo general, debe reenviar puertos desde la máquina host a un contenedor. Sin embargo, cuando los contenedores comparten la red del host, cualquier actividad de red ocurre directamente en la máquina host, tal como lo haría si el programa se ejecutara localmente en el host en lugar de dentro de un contenedor. Con esto, está obteniendo acceso a las redes de host, que probablemente tampoco estarían restringidas. Es importante tener en cuenta que el nodo host le da al contenedor acceso total a los servicios del sistema local como D-bus y, por lo tanto, se considera inseguro. Si observa el estado, puede ver la hostIP , podIP y podIP los campos tienen un valor común que coincide con la dirección IP original del nodo. Esto prueba que, de hecho, está utilizando un módulo de red de host.

[ Obtenga este libro electrónico gratuito:Administrar sus clústeres de Kubernetes para principiantes. ]

Resumir

Este artículo es una breve descripción general de cómo oc debug El comando funcionaría para la depuración de un nodo en un clúster de OpenShift.