Alternativas do Kubernetes aos comandos do Docker

O Docker geralmente fornece a primeira introdução do desenvolvedor aos contêineres. O Kubernetes é uma plataforma de orquestração que resolve os desafios relacionados à execução de contêineres na produção. Veja como os comandos do Docker são mapeados para suas contrapartes do Kubernetes.

Você não pode usar a CLI do docker para interagir com contêineres em execução no Kubernetes. O Kubernetes fornece sua própria interface de linha de comando, kubectl, para ajudá-lo a gerenciar seu cluster. Leia nosso guia de primeiros passos com kubectl se você não estiver familiarizado com a ferramenta.

Nenhum dos comandos do docker tem o mesmo nome em kubectl. O Kubernetes expõe a funcionalidade à sua maneira. As próprias cargas de trabalho são fundamentalmente diferentes – O Docker foi projetado para funcionar com um único contêiner por vez, enquanto o Kubernetes permite a orquestração de várias réplicas.

O primeiro ponto a apreciar é a mudança na terminologia. Docker refere-se a “ contêineres ” enquanto o Kubernetes usa “ pods ”. Um pod pode executar um contêiner ou várias réplicas gerenciadas como uma única unidade. Este detalhe à parte, quando você vir “ container ” no Docker, você deve pensar em um “ pod ” do Kubernetes. Os termos serão usados ​​de forma intercambiável no restante deste artigo.

Obtendo detalhes de seus contêineres

No Docker, você usa docker ps -a para ver todos os contêineres em sua máquina.

O equivalente mais próximo do Kubernetes é kubectl get pods.

A saída dos dois comandos é bastante diferente. O Docker mostra mais informações sobre a carga de trabalho que o contêiner está executando.

O Kubernetes fornecerá detalhes sobre a imagem e o comando ao usar o comando describe pod. Você precisa passar o nome do pod. Isso fornece informações muito mais detalhadas, usando uma lista em vez de uma tabela.

Executando comandos em contêineres

O Docker permite que você execute um comando em um contêiner em execução usando docker exec.

O equivalente do Kubernetes também é chamado de exec. Use o nome do pod do Kubernetes em vez do nome do contêiner do Docker. O comando é especificado de forma ligeiramente diferente – deve ser separado do nome do pod por uma sequência -.

Você pode usar os sinalizadores -it para obter acesso interativo da mesma maneira que o Docker. Este é um atalho para --stdin --tty e deve ser usado sempre que você deseja iniciar um shell dentro de um pod. Especifique o nome do shell, como bash, como o comando.

O Kubectl suporta o comando attach para quando você deseja anexar a um processo em um contêiner que já está em execução. Ele funciona de maneira semelhante ao docker attach, mas você deve passar os sinalizadores -it se precisar de acesso interativo.

Visualização de registros de contêiner

Para visualizar os registros de um contêiner com o Docker, use o comando docker logs. Adicionar a opção -f “ seguirá ” os registros para que eles sejam novamente transmitidos continuamente para o seu terminal.

O comando logs do

Kubectl &’ tem a mesma sintaxe. Forneça um nome de pod da mesma maneira que o Docker aceita um nome de contêiner.

Tanto o Docker quanto o Kubernetes coletam registros da saída padrão e fluxos de erro padrão (stdout / stderr) de contêineres em execução. O Kubernetes lida com as reinicializações do contêiner de maneira diferente do Docker. Enquanto no Docker um contêiner reiniciado anexa seus registros aos existentes, o Kubernetes cria um novo registro para cada execução. Você pode obter os logs de um contêiner substituído adicionando a sinalização --previous ao comando logs.

Criando contêineres

Os contêineres do Docker são criados com o comando run. Veja como você pode iniciar um servidor nginx com Docker:

 docker run -d --name nginx --restart = always -p 80:80 nginx 

Isso cria um contêiner usando a imagem de base do nginx e o configura para reiniciar automaticamente. O servidor está vinculado à porta HTTP padrão 80.

O Kubernetes exige que você pense em abstrações de nível superior ao adicionar contêineres ao seu cluster. Em vez de executar um contêiner, você está criando uma implantação para representar sua carga de trabalho:

 kubectl create deployment --image = nginx nginx 

Isso criará uma implantação do nginx. Um pod é iniciado automaticamente; dentro do pod, haverá um contêiner executando o servidor da web.

A criação de uma implantação não vincula seus contêineres a nenhuma porta. O servidor recém-criado ainda não está acessível. As portas devem ser expostas por meio de um serviço. Os pods são efêmeros e podem conter vários contêineres replicados. Os serviços definem uma coleção lógica de pods e permitem que você atribua a eles recursos de rede, como um endereço IP e uma porta.

Expor a implantação do nginx na porta 80 permitirá que o servidor seja acessado:

 kubectl expose deployment nginx --port = 80 --name nginx-http 

Tentar acessar a porta 80 no endereço IP padrão do cluster agora deve direcioná-lo para o servidor nginx.

O Kubectl não oferece suporte direto a outras opções de execução do docker, como criação de volume e montagens de ligação. Os contêineres que requerem armazenamento persistente precisarão ter volumes configurados manualmente por meio de comandos kubectl ou um manifesto de volume.

Removendo recipientes

Os contêineres do Docker são removidos usando o comando docker rm com o ID do contêiner.

O Kubernetes não permite que você exclua contêineres diretamente. Em vez disso, você trabalha com a implantação que criou o pod. Use o comando kubectl delete deployment, passando o nome da implantação.

O Docker permite que você interrompa um contêiner em vez de removê-lo. O Kubernetes removeu o suporte para esta ação. A maneira recomendada de suspender temporariamente uma implantação é dimensionar sua contagem de réplicas até 0. Sem pods em execução, a carga de trabalho é efetivamente interrompida.

 escala kubectl --replicas = 0 implantação / my-deployment 

Quando você estiver pronto para retomar a implantação, execute o comando de escala novamente. Defina a nova contagem de réplicas para 1 ou mais. Usar mais réplicas pode aumentar a disponibilidade de sua carga de trabalho.

Conclusão

Não há paralelos diretos entre o Docker CLI e o kubectl. A maioria dos comandos do Kubernetes tem uma sintaxe diferente de suas contrapartes do Docker. Você precisará aprender novos termos e opções antes de fazer a transição de fluxos de trabalho baseados em Docker para o Kubernetes.

Em muitos casos, não há alternativa kubectl para um recurso Docker CLI. A funcionalidade do Docker está focada no conceito de contêiner. O Kubernetes pega isso e o coloca no centro de um ecossistema de recursos amplamente expandido.

Os contêineres raramente são tratados isoladamente. Em vez disso, você precisará trabalhar com recursos como implantações, serviços e conjuntos de réplicas. É por isso que aprender Kubernetes pode parecer desafiador quando abordado da perspectiva de um usuário Docker.

Se você estiver familiarizado com os fundamentos do Docker, a transição para o Kubernetes deve ser relativamente simples. A principal diferença é que o que o Docker vê como um contêiner geralmente é acessado como um “ pod ” agregado; no Kubernetes. Os pods são criados por “ implantações ” que representam as cargas de trabalho em seu cluster. Em caso de dúvida, consulte a documentação do kubectl para encontrar uma correspondência adequada para um comando do Docker.