No final do ano passado, o Reddit
introduziu um plugin para o kubectl, que ajuda a depurar os pods do cluster
Kubernetes -
kubectl-debug . Essa ideia imediatamente pareceu interessante e útil para nossos engenheiros, por isso decidimos analisar sua implementação e estamos felizes em compartilhar nossos resultados com os leitores do hubr.
Por que isso é necessário?
No momento, há um sério inconveniente no processo de depuração de algo dentro da estrutura dos pods. O principal objetivo ao montar a imagem do contêiner é
minimizá- la, ou seja, faça o menor tamanho possível e contenha o mínimo possível de "excesso" no interior. No entanto, quando se trata de problemas na operação do software final em contêineres ou depuração de sua comunicação com outros serviços no cluster / fora ... o minimalismo nos engana - porque não há
nada nos contêineres para o processo real de encontrar problemas. Como regra, utilitários como netstat / ip / ping / curl / wget etc. não estão disponíveis.
E muitas vezes tudo termina com o fato de o engenheiro preparar o software necessário diretamente no contêiner em execução para "ver" e ver o problema. É nesses casos que o plug-in kubectl-debug parecia ser uma ferramenta muito útil - porque evita dores urgentes.
Com sua ajuda, você pode
iniciar um contêiner com todas as ferramentas necessárias a bordo no contexto de um
pod de problemas
com um comando e estudar todos os processos "de fora", estando dentro. Se você já encontrou a solução de problemas do Kubernetes, isso parece atraente, não é?
O que é este plugin?
Em termos gerais, a arquitetura desta solução parece um pacote do
plug -
in para o kubectl e um
agente que começa a usar o controlador DaemonSet. O plug-in serve comandos que começam com
kubectl debug … e interage com agentes nos nós do cluster. O agente, por sua vez, é executado na rede host e o host docker.sock é montado no pod do agente para obter acesso total aos contêineres neste servidor.
Assim, ao solicitar o lançamento de um contêiner de depuração no pod especificado:
existe um processo para identificar o
hostIP do
hostIP e uma solicitação é enviada ao agente (trabalhando em um host adequado) para iniciar um contêiner de depuração nos namespaces correspondentes ao pod de destino.
Uma visão mais detalhada dessas etapas está disponível na
documentação do
projeto .
O que é necessário para o trabalho?
O autor do kubectl-debug afirma ser compatível com as versões do cliente / cluster
Kubernetes 1.12.0+ , no entanto, eu tinha o K8s 1.10.8 em mãos, no qual tudo funcionava sem problemas visíveis ... com uma única nota: para a equipe de
kubectl debug do
kubectl debug trabalhar neste formulário, a versão do
kubectl é exatamente
1.12+ . Caso contrário, todos os comandos são semelhantes, mas são chamados apenas através do
kubectl-debug …Ao iniciar o modelo DaemonSet descrito em
README não se esqueça da mancha usada nos nós: sem as tolerâncias apropriadas, os pods do agente não serão instalados lá e, como resultado, você não poderá usar os pods que vivem nesses nós pode se conectar com um depurador.
A Ajuda do depurador é muito abrangente e parece descrever todas as possibilidades atuais para iniciar / configurar o plug-in. Em geral, o utilitário agrada a um grande número de diretivas a serem executadas: você pode anexar certificados, especificar o contexto do kubectl, especificar uma configuração separada do kubectl ou o endereço do servidor da API do cluster e muito mais.
Trabalhar com um depurador
A instalação até o momento “tudo funciona” é reduzida para duas etapas:
- execute o
kubectl apply -f agent_daemonset.yml ; - instale diretamente o próprio plug-in - em geral, tudo é como descrito aqui .
Como usá-lo? Suponha que tenhamos o seguinte problema: as métricas de um dos serviços no cluster não são coletadas - e queremos verificar se há problemas de rede entre o Prometheus e o serviço de destino. Como você pode imaginar, a imagem do Prometheus não possui as ferramentas necessárias.
Vamos tentar conectar-se ao contêiner com o Prometheus (se houver vários contêineres no pod, você precisará especificar qual deles se conectar, caso contrário, o depurador selecionará o primeiro por padrão):
kubectl-debug --namespace kube-prometheus prometheus-main-0 Defaulting container name to prometheus. pulling image nicolaka/netshoot:latest... latest: Pulling from nicolaka/netshoot 4fe2ade4980c: Already exists ad6ddc9cd13b: Pull complete cc720038bf2b: Pull complete ff17a2bb9965: Pull complete 6fe9f5dade08: Pull complete d11fc7653a2e: Pull complete 4bd8b4917a85: Pull complete 2bd767dcee18: Pull complete Digest: sha256:897c19b0b79192ee5de9d7fb40d186aae3c42b6e284e71b93d0b8f1c472c54d3 Status: Downloaded newer image for nicolaka/netshoot:latest starting debug container... container created, open tty... [1] → root @ /
Anteriormente, descobrimos que o serviço problemático fica no endereço 10.244.1.214 e escuta na porta 8080. Naturalmente, também podemos verificar a disponibilidade dos hosts, no entanto, para um processo de depuração confiável, essas operações devem ser reproduzidas em condições idênticas (ou o mais próximas possível). Portanto, a verificação de um pod / contêiner com o Prometheus é a melhor opção. Vamos começar com um simples:
[1] → ping 10.244.1.214 PING 10.244.1.214 (10.244.1.214) 56(84) bytes of data. 64 bytes from 10.244.1.214: icmp_seq=1 ttl=64 time=0.056 ms 64 bytes from 10.244.1.214: icmp_seq=2 ttl=64 time=0.061 ms 64 bytes from 10.244.1.214: icmp_seq=3 ttl=64 time=0.047 ms 64 bytes from 10.244.1.214: icmp_seq=4 ttl=64 time=0.049 ms ^C --- 10.244.1.214 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 61ms rtt min/avg/max/mdev = 0.047/0.053/0.061/0.007 ms
Está tudo bem. Talvez a porta esteja indisponível?
[1] → curl -I 10.244.1.214:8080 HTTP/1.1 200 OK Date: Sat, 12 Jan 2019 14:01:29 GMT Content-Length: 143 Content-Type: text/html; charset=utf-8
E não há problema. Em seguida, verificaremos se a comunicação real entre o Prometheus e o terminal com métricas ocorre:
[2] → tcpdump host 10.244.1.214 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 14:04:19.234101 IP prometheus-main-0.prometheus-operated.kube-prometheus.svc.cluster.local.36278 > 10.244.1.214.8080: Flags [P.], seq 4181259750:4181259995, ack 2078193552, win 1444, options [nop,nop,TS val 3350532304 ecr 1334757657], length 245: HTTP: GET /metrics HTTP/1.1 14:04:19.234158 IP 10.244.1.214.8080 > prometheus-main-0.prometheus-operated.kube-prometheus.svc.cluster.local.36278: Flags [.], ack 245, win 1452, options [nop,nop,TS val 1334787600 ecr 3350532304], length 0 14:04:19.290904 IP 10.244.1.214.8080 > prometheus-main-0.prometheus-operated.kube-prometheus.svc.cluster.local.36278: Flags [P.], seq 1:636, ack 245, win 1452, options [nop,nop,TS val 1334787657 ecr 3350532304], length 635: HTTP: HTTP/1.1 200 OK 14:04:19.290923 IP prometheus-main-0.prometheus-operated.kube-prometheus.svc.cluster.local.36278 > 10.244.1.214.8080: Flags [.], ack 636, win 1444, options [nop,nop,TS val 3350532361 ecr 1334787657], length 0 ^C 4 packets captured 4 packets received by filter 0 packets dropped by kernel
Pedidos de respostas vêm. Com base nos resultados dessas operações, podemos concluir que não há problemas no nível de interação da rede, o que significa (provavelmente) que você precisa procurar pelo lado aplicado. Nós nos conectamos ao contêiner com o exportador (também, é claro, usando o depurador em questão, porque os exportadores sempre têm imagens extremamente minimalistas) e ... ficamos surpresos ao descobrir que há um problema na configuração do serviço - por exemplo, esquecemos de direcionar o exportador para o correto Endereço do Aplicativo de Destino
O caso está resolvido!Obviamente, outras formas de depuração são possíveis na situação descrita aqui, mas as deixaremos fora do escopo do artigo. O resultado é que o kubectl-debug tem muitas oportunidades de uso: você pode executar qualquer imagem no trabalho e, se desejar, pode até montar uma específica (com o conjunto de ferramentas necessário).
Que outras aplicações vêm imediatamente à sua mente?
- Um aplicativo "silencioso", para o qual desenvolvedores
prejudiciais não implementaram o log normal. Mas ele tem a capacidade de conectar-se à porta de serviço e depurar com uma ferramenta específica, que, é claro, não deve ser colocada na imagem final. - Inicie próximo ao aplicativo de combate idêntico no modo “manual”, mas com a depuração ativada - para verificar a interação com os serviços vizinhos.
Em geral, é óbvio que existem muito mais situações em que essa ferramenta pode ser útil. Os engenheiros que os encontram no trabalho todos os dias poderão avaliar o potencial da empresa em termos de depuração "ao vivo".
Conclusões
O Kubectl-debug é uma ferramenta útil e promissora. Obviamente, existem clusters e aplicativos do Kubernetes para os quais não faz muito sentido, mas ainda existem casos mais prováveis em que ele fornecerá assistência valiosa na depuração - especialmente se se tratar do ambiente de combate e da necessidade de encontrar rapidamente os motivos, aqui e agora o problema que você encontrou.
A primeira experiência de uso revelou uma necessidade urgente da capacidade de conectar-se a um pod / contêiner, que não inicia até o fim (por exemplo, trava no
CrashLoopbackOff ), apenas para verificar
CrashLoopbackOff os motivos do aplicativo não iniciar. Nesta ocasião, criei um
problema correspondente no repositório do projeto, ao qual o desenvolvedor respondeu positivamente e prometeu a implementação em um futuro próximo. Muito satisfeito com o feedback rápido e adequado. Por isso, aguardamos ansiosamente novos recursos do utilitário e seu desenvolvimento adicional!
PS
Leia também em nosso blog: