RTFM & Aleatoriedades - Container Network Troubleshooting
O intuito desse how to é apoiar na solução de problemas rede de containers
Disclaimer
Se caiu aqui no momento em que está tentando apagar um incêndio: você está no lugar errado!
- Mas retorne depois ... ;)
Requirements
Para fazer um debug descente, precisamos estar familiarizados com questões básicas!
Como as coisas "funfam" debaixo do capô da conteinerização
Namespaces Linux fornecem as tecnologias fundamentais da implementação de containers. Fornecendo isolamento de recursos globais entre processos independentes
- Namespaces fornece isolamento e não restrição ao hardware adjacente! Isso é papel do cgroups
São 8 namespaces até o momento
- Mount - Mount points
- cria uma hierarquia de diretórios isolado do sistema de arquivos do host, visível apenas pelo processo em execução nessa árvore de diretórios do namespace.
- UTS - Hostname and NIS domain name
- cria isolamento dos identificadores hostname e o NIS domain name que são definidos
usando sethostname(2), setdomainname(2) e pode ser recuperado usando uname(2) , gethostname(2) e getdomainname(2) .
- cria isolamento dos identificadores hostname e o NIS domain name que são definidos
- IPC - System V IPC, POSIX message queues
- isolam sysvipc(7) - System V Objetos IPC e mq_overview(7) - POSIX filas de mensagens. Dessa forma, o namespace tem seus identificadores IPC e filas de mensageria POSIX próprios, vistos apenas pelos processos que executam nele.
- PID - Process IDs
- Cria espaço do número de ID do processo isolados do host. Permite que o processo conteinerização faça uso do recurso bem legal, o Freezing of tasks que permite suspender um conjunto de processos de um contêiner e migralos para outro container, em outro host, enquanto os processos internos mantêm os mesmos PIDs...
- agradeça ao Freezing tasks pelas mágicas no seu notebook ao hibernar...
- Cria espaço do número de ID do processo isolados do host. Permite que o processo conteinerização faça uso do recurso bem legal, o Freezing of tasks que permite suspender um conjunto de processos de um contêiner e migralos para outro container, em outro host, enquanto os processos internos mantêm os mesmos PIDs...
- Network - Network devices, stacks, ports, etc.
- fornecem isolamento dos dispositivos de rede, pilhas de protocolos IP v4 e v6, tabelas de roteamento IP, regras de firewall, os diretórios /proc/net (link para _/proc/_pid /net ), /sys/class/net , arquivos em /proc/sys/net , soquetes etc... Bem como também dos soquetes abstratos do domain unix(7).
- Tanto uma interface de rede física, quanto uma veth(4)
- fornecem isolamento dos dispositivos de rede, pilhas de protocolos IP v4 e v6, tabelas de roteamento IP, regras de firewall, os diretórios /proc/net (link para _/proc/_pid /net ), /sys/class/net , arquivos em /proc/sys/net , soquetes etc... Bem como também dos soquetes abstratos do domain unix(7).
- User - User and group IDs
- Faz isolamento dos recursos credentials(7) que são os identificadores relacionados à segurança e atributos, em particular, IDs de usuário e IDs de grupo, o diretório raiz, keyrings(7) e capabilities(7).
- Cgroup - Cgroup root directory
- Faz o isolamento virtualizando a visão do cgroups(7) por um processo via /proc/pid/cgroup e /proc/pid/mountinfo. Dessa forma o namespace possui seu próprio conjunto de diretórios raiz cgroup, que são os caminhos relativos dos registros correspondentes no arquivo /proc/pid/cgroup, quando um processo cria um novo namespace usando clone(2) ou unshare(2) com a flag CLONE_NEWCGROUP...
- Time - Boot and monotonic clocks
- O time afeta afeta várias APIs como o clock_gettime(2), clock_nanosleep(2), nanosleep(2), timer_settime(2), timerfd_settime(2) e /proc/uptime, fazendo a virtualização isolada dos relógios de sistema:
- CLOCK_MONOTONIC (e também CLOCK_MONOTONIC_COARSE e CLOCK_MONOTONIC_RAW ), um relógio não configurável que representa um tempo monótono desde então(conforme descrito por POSIX - "algun ponto não especificado no passado").
- CLOCK_BOOTTIME (e também CLOCK_BOOTTIME_ALARM ), um relógio não configurável que é idêntico a CLOCK_MONOTONIC , exceto que também inclui qualquer momento em que o sistema está suspenso.
- O time afeta afeta várias APIs como o clock_gettime(2), clock_nanosleep(2), nanosleep(2), timer_settime(2), timerfd_settime(2) e /proc/uptime, fazendo a virtualização isolada dos relógios de sistema:
Dessa forma já conseguimos "tridimensionalizar" mentalmente que:
- A coisa toda é meio que um processo containerizado por recursos que o fazem rodar em um diretório onde existirá um sistema de arquivos, fazendo com que o processo o veja como o uma arvore filesystem, com seus pid/gid e pilha de rede, hostname e domainname / nisdomainname bem como as chamadas IPC e relógios de sistema isolados do host hospedeiro..
- Aqui vale lembrar que esses namespaces não são de propriedade do processo! Eles operam de forma independente
- qualquer outro processo pode ser containerizado nesses namespaces já existentes, dessa forma compatilhando-os... E de forma independente
- pois você pode executar um processo dentro de um namespace Network, sem que ele tenha um Mount e UTS por exemplo
- isso é massa porque é possível usar um comando que existe no Host, porém a execução será dentro de um namespace!
- por isso, não é necessário instalar uma tool em um Mount de um processo containerizado para fazer teste ou debug...
- isso é massa porque é possível usar um comando que existe no Host, porém a execução será dentro de um namespace!
- pois você pode executar um processo dentro de um namespace Network, sem que ele tenha um Mount e UTS por exemplo
- qualquer outro processo pode ser containerizado nesses namespaces já existentes, dessa forma compatilhando-os... E de forma independente
- Aqui vale lembrar que esses namespaces não são de propriedade do processo! Eles operam de forma independente
O que nos interessa é o namespace Network! Por isso, apesar de eu explorar outros pontos, nesse nivelamento: network é o nosso foco