Compartilhando o Namespace de Processo Entre Contêineres em um Pod

Esta página mostra como configurar o compartilhamento de namespace de processos para um Pod. Quando O compartilhamento de namespace de processos está ativado, os processos em um Contêiner são visíveis para todos os outros Contêineres no mesmo Pod.

Você pode usar este recurso para configurar Contêineres de cooperação, como um manipulador de log sidecar de contêiner, ou para solucionar problemas em imagens de contêiner que não incluem utilitários de depuração como um shell.

Antes de você começar

Você precisa ter um cluster do Kubernetes e a ferramenta de linha de comando kubectl deve estar configurada para se comunicar com seu cluster. É recomendado executar esse tutorial em um cluster com pelo menos dois nós que não estejam atuando como hosts de camada de gerenciamento. Se você ainda não possui um cluster, pode criar um usando o minikube ou pode usar um dos seguintes ambientes:

• iximiuz Labs
• Killercoda
• KodeKloud
• Play with Kubernetes

Configure um pod

O compartilhamento de namespace de processos é ativado usando o campo shareProcessNamespace da .spec para um Pod. Por exemplo:

pods/share-process-namespace.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  shareProcessNamespace: true
  containers:
  - name: nginx
    image: nginx
  - name: shell
    image: busybox:1.28
    securityContext:
      capabilities:
        add:
        - SYS_PTRACE
    stdin: true
    tty: true

1. Crie o pod nginx no seu cluster:

   kubectl apply -f https://k8s.io/examples/pods/share-process-namespace.yaml
   

2. Conecte ao shell do contêiner e execute o comando ps:

   kubectl exec -it nginx -c shell -- /bin/sh
   

   Se você não vir um prompt de comando, tente pressionar Enter. No shell do Contêiner execute:

   # execute este comando dentro do "shell" do contêiner
   ps ax
   

   A saída é semelhante a esta:

   PID   USER     TIME  COMMAND
       1 root      0:00 /pause
       8 root      0:00 nginx: master process nginx -g daemon off;
      14 101       0:00 nginx: worker process
      15 root      0:00 sh
      21 root      0:00 ps ax
   

Você pode sinalizar processos em outros Contêineres. Por exemplo, mandando SIGHUP ao nginx para restartar o processo worker. Isso requer a capacidade SYS_PTRACE.

# execute este comando dentro do "shell" do contêiner
kill -HUP 8   # substitua o "8" pelo PID do processo principal do nginx, se necessário
ps ax

A saída é semelhante a esta:

PID   USER     TIME  COMMAND
    1 root      0:00 /pause
    8 root      0:00 nginx: master process nginx -g daemon off;
   15 root      0:00 sh
   22 101       0:00 nginx: worker process
   23 root      0:00 ps ax

É até possível acessar o sistema de arquivos de outro contêiner usando o link /proc/$pid/root.

# execute este comando dentro do "shell" do contêiner
# substitua o "8" pelo PID do processo Nginx, se necessario
head /proc/8/root/etc/nginx/nginx.conf

A saída é semelhante a esta:

user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;

Compreendendo o compartilhamento de namespace de processos

Os Pods compartilham muitos recursos, por isso faz sentido que eles também compartilhem um namespace de processo. Alguns Contêineres podem esperar serem isolados de outros, no entanto, por isso, é importante entender as diferenças:

1. O processo de contêiner não tem mais o PID 1. Alguns Contêineres recusam começar sem o PID 1 (por exemplo, contêineres usando systemd) ou executando comandos como kill -HUP 1 para sinalizar o processo de Contêiner. Em pods com um namespace de processos compartilhado, kill -HUP 1 irá sinalizar a sandbox (/pause no exemplo acima).

2. Os processos são visíveis para outros contêineres no Pod. Isso inclui todas informações visíveis em /proc, como senhas que foram passadas como argumentos ou variáveis de ambiente. Estes são protegidos apenas por permissões regulares do Unix.

3. Sistema de arquivos do Contêiner são visíveis para outros Contêineres do pod através do link /proc/$pid/root. Isso facilita a depuração, mas também significa que os segredos do sistema de arquivos, são protegidos apenas por permissões de sistema de arquivos.