Nota perev. : Nós escrevemos mais de uma vez sobre o contêiner e outros tempos de execução para o Kubernetes. A nova publicação é uma tradução do recente anúncio de um marco importante no desenvolvimento do container, publicado no blog oficial do projeto Kubernetes. O texto foi escrito por funcionários do Google e IBM, os quais (é claro, juntamente com a Docker Inc) contribuem significativamente para a melhoria do contêiner.No início do blog - na nota, o
Containerd traz mais opções de tempo de execução de contêiner para o Kubernetes - introduzimos uma versão alfa da integração do container com o Kubernetes. Os próximos 6 meses de desenvolvimento levaram ao fato de que a integração se tornou pública! Isso significa que agora você pode usar o
containerd 1.1 como o tempo de execução dos contêineres nos clusters do Kubernetes em produção.
O Containerd 1.1 funciona com o Kubernetes versão 1.10 e superior, suporta todos os recursos do Kubernetes. Na infraestrutura de teste do Kubernetes, a cobertura dos testes de integração de contêineres no Google Cloud Platform se tornou a mesma da integração com o Docker (consulte
o painel de teste ).
“Estamos muito satisfeitos em ver a containererd alcançar rapidamente esse marco significativo. Na Alibaba Cloud, começamos a usar o Containerd ativamente desde seus primeiros dias e, graças à sua ênfase na simplicidade e confiabilidade, tornamos o Containerd o mecanismo de contêiner padrão em nosso produto Serverless Kubernetes, que exige muito desempenho e estabilidade. Sem dúvida, o Containerd será o principal motor da era dos contêineres e levará ao desenvolvimento da inovação. ” - Xinwei, engenheiro em tempo integral da Alibaba Cloud
Melhorias arquitetônicas
A arquitetura para integrar o container com o Kubernetes mudou duas vezes. Cada uma de suas etapas evolutivas estabilizou e melhorou a eficiência da pilha.
Containerd 1.0 - CRI-Containerd (deixou de existir)
No
contemerd 1.0, o daemon cri-
containserd era necessário para a interação entre o
Kubelet e o container
(escrevemos sobre isso no final deste artigo - aprox. Transl. ) . Esse daemon atendeu solicitações à
Interface de Tempo de Execução do
Contêiner (CRI) do
Kubelet e usou o container para gerenciar adequadamente os contêineres e as imagens do contêiner. Essa abordagem eliminou um link adicional na pilha quando comparado à implementação do Docker CRI (
dockershim ) -
veja a ilustração acima .
No entanto, cri-containserd e containserd 1.0 foram dois daemons separados interagindo no GRPC. Um daemon adicional neste pacote dificultou a vida dos usuários no entendimento do dispositivo e durante a implantação, além de gerar sobrecarga desnecessária para a interação.
Containerd 1.1 - plugin CRI (versão atual)
Na versão 1.1, o daemon cri-containserd foi refeito no plug-in CRI da interface. Este plug-in está embutido no Containerd 1.1 e é ativado por padrão. Ao contrário de cri-containserd, o plug-in interage com o container, invocando diretamente as funções necessárias. A nova arquitetura tornou a integração mais estável e produtiva, eliminando outro link (GRPC) da pilha. Agora o containerd 1.1 pode ser usado diretamente no Kubernetes, e o daemon cri-containserd não é mais necessário.
Desempenho
Um dos principais objetivos do Containerd 1.1 era melhorar o desempenho. Otimizações foram realizadas na área do tempo de inicialização e dos recursos utilizados pelo demônio.
Os resultados a seguir são uma comparação do containserd 1.1 e do Docker 18.03 CE. A integração containerd 1.1 usa o plug-in CRI interno, e a integração para o Docker 18.03 CE funciona com o dockershim. Os resultados foram gerados usando o benchmark de desempenho do nó Kubernetes, que faz parte dos
testes e2e para os nós K8s . A maioria dos dados de comparação está disponível publicamente no
painel de desempenho do
nó .
Atraso no início da lareira
Os resultados do
benchmark de inicialização de lote de 105 pods mostram que a integração doerderd 1.1 tem menos atraso no início de um pod do que o Docker 18.03 CE com dockershim (quanto menor, melhor).
CPU e memória
Em um estado inativo, a integração doerderd 1.1 com 105 lareiras consome menos processador e memória do que a integração do Docker 18.03 CE com o dockershim. Os resultados podem variar dependendo do número de lareiras lançadas no nó - o número de 105 lareiras é selecionado, porque o padrão agora é o valor máximo para lareiras personalizadas no nó.
Como pode ser visto nos gráficos abaixo, a integração
doerderd 1.1 com o
Kubelet consome 30,89% menos CPU e 11,30% menos memória RSS (tamanho do conjunto residente), além de 12,78% menos memória RSS consumida pelo tempo de execução do contêiner .
Adição do tradutor
Vale a pena prestar atenção que outra solução alternativa, CRI-O , continua a se desenvolver. Em particular, em um Open Source Summit Japan 2018 hoje em dia, um funcionário da NTT apresentou um relatório com uma extensa comparação dos ambientes executáveis existentes para contêineres. E aqui está um dos slides dele comparando o desempenho deles:
crictl
A interface do console de tempo de execução do contêiner (CLI) é uma ferramenta útil para identificar problemas no sistema e no aplicativo. Ao usar o Docker como um ambiente de contêiner no Kubernetes, os administradores do sistema às vezes vão ao site do Kubernetes para executar comandos do Docker e coletar informações sobre o sistema e / ou aplicativo. Por exemplo, eles podem usar o
docker ps e o
docker inspect para verificar o status do processo, as
docker images para obter uma lista de imagens no nó, as
docker info para obter a configuração do tempo de execução dos contêineres, etc.
Para o container e outros ambientes compatíveis com CRI, como dockershim, recomendamos o uso de
crictl como uma alternativa da CLI aos comandos do console do Docker para analisar problemas em pods, contêineres e imagens de contêiner hospedados nos nós do Kubernetes.
O crictl é um utilitário que oferece recursos semelhantes à CLI do Docker e funciona igualmente bem em todos os ambientes de tempo de execução para contêineres compatíveis com o CRI. Pode ser encontrado no
repositório kubernetes-incubator / cri-tools ; a versão atual é o
cri-tools v1.11.0 (a versão foi corrigida para a versão atual 3 dias atrás, em vez da v1.0.0-beta.1 , indicada no artigo original, aproximadamente tradução ) . Embora o utilitário
crictl tenha sido projetado para ser semelhante à CLI do Docker, oferecendo uma transição simples para os usuários, não é uma cópia completa dele. Algumas diferenças importantes são descritas abaixo.
Uso limitado: crictl é uma ferramenta de solução de problemas
O crictl não substitui os
kubectl docker ou
kubectl - seu uso é limitado ao escopo de identificação e análise de problemas. A interface do console do Docker oferece um rico conjunto de comandos, tornando-o uma ferramenta de desenvolvimento muito útil. No entanto, essa não é a melhor opção para solução de problemas nos nós do Kubernetes. Alguns comandos do Docker (por exemplo,
docker network e
docker build ) são inúteis para o Kubernetes, e alguns (por exemplo,
docker rename ) podem quebrar tudo. O objetivo do
crictl é fornecer comandos suficientes para identificar problemas em nós que são seguros para uso em ambientes de produção.
Foco Kubernetes
O crictl oferece uma visão mais compreensível do contêiner no mundo Kubernetes. A interface do console do Docker não opera com conceitos básicos do Kubernetes, como under (pod) e namespace (
namespace ), o que impede a representação visual de contêineres e lareiras
(a importância desse problema é verdadeira, já no contexto de monitoramento, falamos recentemente neste relatório - note perev. ) . Um exemplo é o
docker ps mostrando nomes longos e obscuros para contêineres do Docker e uma lista de contêineres de pausa junto com os contêineres do aplicativo:
No entanto, os
contêineres de pausa fazem parte da implementação da lareira, onde um desses recipientes é usado para cada lareira; eles não devem ser exibidos ao exibir recipientes que fazem parte da lareira.
Crictl , por outro lado, foi criado para o Kubernetes. O utilitário fornece diferentes conjuntos de comandos para lareiras e contêineres. Por exemplo,
crictl pods exibe informações sobre
crictl pods e
crictl ps exibe apenas informações sobre contêineres de aplicativos. Todos os dados são formatados em uma exibição de tabela:
Outro exemplo - nos
crictl pods há um argumento
--namespace , que permite filtrar pods pelos namespaces definidos no Kubernetes:
Para mais informações sobre como usar o crictl com o container, veja aqui:
Mas e o Docker Engine?
Frequentemente ouvimos a seguinte pergunta: “A mudança para o containererd significa que não posso mais usar o Docker Engine?”, E a resposta curta é “NÃO”.
O Docker Engine é construído com base em container. A próxima versão do Docker Community Edition (Docker CE) usará a versão 1.1 da versão 1.1. Consequentemente, ele terá um plug-in CRI embutido e ativado por padrão. Isso significa que os usuários terão a oportunidade de continuar trabalhando com o Docker Engine para outros cenários típicos, bem como a capacidade de configurar o Kubernetes para usar o container subjacente que acompanha o Docker Engine e que é usado simultaneamente pelo Docker Engine no mesmo host. Dê uma olhada no diagrama arquitetural abaixo, demonstrando como o mesmo container é usado pelo Docker Engine e pelo
Kubelet :
Como o Containerd é usado pelo
Kubelet e pelo Docker Engine, os usuários que optarem por se integrar ao Containerd não apenas obterão todos os novos recursos do Kubernetes, melhorias no desempenho e estabilidade, mas também a opção de usar o Docker Engine, como antes, para outras necessidades.
O mecanismo de
espaço para
nome no containererderd garante que o
Kubelet e o Docker Engine não tenham acesso a contêineres e imagens não criados por eles. Isso significa que eles não irão interferir um com o outro, bem como:
- Os usuários que
docker ps não verão os contêineres criados no Kubernetes. Use crictl ps para isso. Por outro lado, os usuários não verão os contêineres criados na CLI do Docker no Kubernetes ou no comando crictl ps . Os crictl create e crictl run são apenas para solução de problemas. A operação manual de lareiras ou contêineres usando crictl nos nós de produção não é recomendada. - Os usuários que
docker images não verão as imagens do Kubernetes. Para fazer isso, use o comando crictl images . Por outro lado, o Kubernetes não verá as imagens criadas pelos comandos docker pull dock, load dock e builder docker build . Para fazer isso, use o comando crictl pull , bem como ctr cri load , se desejar carregar a imagem.
Sumário
- O Containerd 1.1 possui suporte nativo ao CRI. Pode ser usado diretamente pelo Kubernetes.
- O Containerd 1.1 está pronto para produção.
- O Containerd 1.1 tem bom desempenho em termos de tempo de inicialização do pod e utilização de recursos do sistema.
- crictl é um utilitário do console (CLI) para se comunicar com o containserd 1.1 e outros ambientes de tempo de execução para contêineres que estejam em conformidade com o CRI, a fim de identificar problemas no nó.
- O Containerd 1.1 será incluído na próxima versão estável do Docker CE. Os usuários terão a opção de continuar trabalhando com o Docker em casos que não sejam do Kubernetes e configurar o Kubernetes para usar o container subjacente que faz parte do Docker.
Queremos agradecer a todos do Google, IBM, Docker, ZTE, ZJU e desenvolvedores individuais que contribuíram e tornaram tudo isso possível!
Para obter uma lista detalhada de alterações no containserd 1.1, consulte
Notas da versão .
Como tentar
Instruções para configurar um cluster Kubernetes para usar o containerd como o tempo de execução padrão:
- para um cluster no GCE, gerado usando
kube-up.sh , - aqui ; - instalar um cluster de muitos nós usando Ansible e kubeadm - aqui ;
- para criar um cluster do zero no Google Cloud - consulte " Kubernetes da maneira mais difícil ";
- para instalação manual do arquivo tarball - aqui ;
- para instalação usando LinuxKit em uma máquina virtual local - aqui .
Como contribuir
Plug-in CRI do Containerd - Um projeto de código aberto no GitHub, que faz parte do containererd:
https://github.com/containerd/cri . Todas as alterações propostas são bem-vindas na forma de idéias, tickets, correções. Este
guia de introdução ao desenvolvedor é um bom ponto de partida para fazer alterações.
PS do tradutor
Leia também em nosso blog: