[ad_1]
Pode ser difícil diagnosticar problemas com a execução de cargas de trabalho do Kubernetes. Você pode ter sorte e encontrar a causa nos logs do seu aplicativo, por meio do kubectl logs domínio. No entanto, em alguns casos, você não pode evitar uma sessão de depuração ao vivo, na qual você interage interativamente com seus pods para descobrir problemas.
a kubectl debug O comando simplifica essas tarefas de depuração fornecendo um novo contêiner efêmero em seu pod. Isso pode ser usado para inspecionar o ambiente do pod para que você possa começar a solucionar problemas que estão surgindo em seus contêineres existentes.
Preparando-se para usar a depuração Kubectl
kubectl debug foi lançado com a v1.18 do Kubernetes e Kubectl. Ele depende da disponibilidade de contêineres efêmeros em seu cluster. Os contêineres efêmeros se tornaram um recurso beta no Kubernetes v1.23 e agora estão habilitados por padrão. Você precisará habilitar manualmente o portão de recursos se seu cluster estiver executando uma versão mais antiga do Kubernetes.
Os contêineres efêmeros são projetados para tarefas transitórias em que você precisa anexar temporariamente um contêiner adicional a um pod existente. Isso é ideal para operações de depuração em que você deseja inspecionar com precisão um pod sem afetar as instâncias de contêiner ao vivo.
A maioria das imagens de contêiner não possui ferramentas de depuração; instalá-los dentro de um contêiner em execução alteraria seu ambiente e poderia causar efeitos colaterais. Anexar um contêiner efêmero ao seu Pod é uma maneira mais segura de depuração que oferece um ambiente de trabalho limpo. Você pode usar uma imagem mais pesada que inclua todas as ferramentas necessárias.
Embora os contêineres efêmeros se tornem parte do seu Host Pod, ainda há algumas diferenças a serem observadas. Os contêineres efêmeros não oferecem suporte a associações de portas, sondagens ou reservas de recursos, pois são apenas temporários por natureza. Eles nunca serão redefinidos automaticamente e não podem ser alterados depois de criados. Uma lista completa de recursos suportados está disponível na documentação.
Usando a depuração do Kubectl
Antes de continuar, crie uma implementação básica para usar para fins de teste:
$ kubectl create deployment nginx --image=nginx:latest deployment.apps/nginx created
Em seguida, use o get pods Comando para encontrar o nome do pod de sua implantação:
$ kubectl get pods NAME READY STATUS RESTARTS AGE nginx-55649fd747-qsnr2 1/1 Running 0 5s
O Pod de nossa implantação é chamado nginx-55649fd747-qsnr2.
Agora você pode usar o kubectl debug comando para iniciar uma sessão de depuração no seu pod:
$ kubectl debug -it --image=ubuntu:20.04 nginx-55649fd747-qsnr2
A sintaxe do comando é semelhante a um híbrido de kubectl create S kubectl debug. O argumento sem nome fornecido ao comando identifica um pod existente ao qual anexar. a --image O argumento especifica a imagem a ser usada para o novo contêiner. Nós estamos usando ubuntu:20.04 aqui para obter acesso aos comandos familiares incluídos na distribuição Ubuntu Linux.
a -it bandeira é equivalente a --stdin --tty. A inclusão desses argumentos atribuirá um TTY ao contêiner, o anexará e conectará o fluxo padrão do seu terminal. Isso fornece um shell interativo dentro de seu novo contêiner.
Agora você pode executar suas tarefas de depuração de dentro de seu contêiner efêmero.
copiando pods
Outra forma de usar kubectl debug está com um --copy-to enredo. Isso cria uma cópia do pod de destino e adiciona o contêiner efêmero à cópia. O Pod original é deixado intacto.
$ kubectl debug -it --image=ubuntu:20.04 --copy-to nginx-debug nginx-555649fd747-qsnr2
Esse recurso oferece uma garantia ainda maior de que as alterações feitas durante a depuração não afetarão diretamente seu aplicativo de produção.
Copiar o Pod também permite habilitar o compartilhamento do namespace do processo. Isso torna os processos existentes em seu pod visíveis para seu contêiner efêmero. Não pode ser usado com contêineres existentes como su spec.shareProcessNamespace o campo geralmente será definido como false. Corre kubectl debug com ele --copy-to S --share-processes flag permitirá o compartilhamento de processos no Pod copiado, tornando este procedimento muito mais intuitivo:
$ kubectl debug -it --image=ubuntu:20.04 --copy-to nginx-debug --share-processes nginx-555649fd747-qsnr2
A lista de processos visíveis para seu contêiner efêmero do Ubuntu agora incluirá um processo NGINX:
$ ps ax
PID USER TIME COMMAND
1 root 0:00 /pause
9 root 0:00 nginx: master process nginx -g daemon off;
Esse processo ainda está em execução no contêiner NGINX separado dentro do seu pod. O compartilhamento de namespace também fornece acesso ao sistema de arquivos do contêiner de destino por meio de /proc:
$ ls /proc/9/root/etc/nginx conf.d fastcgi_params mime.types modules nginx.conf ...
Portanto, copiar o Pod dessa maneira é uma ferramenta de depuração poderosa. Você pode inspecionar facilmente os arquivos e processos do Pod usando um contêiner separado preparado com ferramentas familiares.
Argumentos opcionais
a --copy-to sinalizador sempre deixa o Pod original intacto por padrão. Você pode fazer a operação funcionar como uma substituição em vez de usar --replace. Isso interromperá o primeiro Pod.
$ kubectl debug -it --image=ubuntu:20.04 --copy-to nginx-debug --replace nginx-555649fd747-qsnr2
O Kubernetes agendará o Pod copiado em qualquer aplicativo Node. Isso pode ser problemático se você quiser garantir um ambiente de teste consistente. adicionando --same-node irá agendar a cópia para o Pod Node existente, eliminando quaisquer diferenças que possam existir entre as máquinas em seu cluster.
$ kubectl debug -it --image=ubuntu:20.04 --copy-to nginx-debug --same-node nginx-555649fd747-qsnr2
Outra opção útil é --env para definir variáveis de ambiente adicionais em seu contêiner efêmero. Você pode precisar usar isso para configurar ferramentas de depuração ou substituir valores herdados do seu pod de destino.
$ kubectl debug -it --image=ubuntu:20.04 --copy-to nginx-debug --env EDITOR=/usr/bin/nano nginx-555649fd747-qsnr2
Por fim, lembre-se de que os contêineres criados por kubectl debug não precisa ser interativo. Você pode executar facilmente comandos exclusivos em seus pods usando kubectl exec-sintaxe semelhante. a --attach O argumento é suportado para controlar se seu shell está conectado ao contêiner quando não está sendo executado com -i (--stdin).
$ kubectl debug --image=ubuntu:20.04 --copy-to nginx-debug --share-processes --attach true nginx-555649fd747-qsnr2 -- ls /proc/9/root/etc/nginx conf.d fastcgi_params mime.types modules nginx.conf ...
conclusão
recipientes efêmeros e kubectl debug O comando fornece uma experiência de depuração simplificada para cargas de trabalho do Kubernetes. Você pode executar comandos dentro de um Pod usando uma imagem diferente de seus contêineres regulares. Isso permite acessar ferramentas de depuração que não estão incluídas na imagem do aplicativo.
kubectl debug Você também pode criar cópias de Pods e compartilhar seus processos com o original. Esse mecanismo permite inspecionar os processos nos contêineres do pod de destino, a partir de um contêiner efêmero separado sobre o qual você tem controle total. Fornece opções de depuração mais avançadas quando você precisa interrogar processos em execução.
[ad_2]
