diff --git a/content/pt-br/blog/_posts/2022-02-17-updated-dockershim-faq.md b/content/pt-br/blog/_posts/2022-02-17-updated-dockershim-faq.md new file mode 100644 index 0000000000..1fdc271cf6 --- /dev/null +++ b/content/pt-br/blog/_posts/2022-02-17-updated-dockershim-faq.md @@ -0,0 +1,208 @@ +--- +layout: blog +title: "Atualizado: Perguntas frequentes (FAQ) sobre a remoção do Dockershim" +date: 2022-02-17 +slug: dockershim-faq +aliases: [ '/dockershim' ] +--- + +**Esta é uma atualização do artigo original [FAQ sobre a depreciação do Dockershim](/blog/2020/12/02/dockershim-faq/), +publicado no final de 2020.** + +Este documento aborda algumas perguntas frequentes sobre a +descontinuação e remoção do _dockershim_, que foi +[anunciado](/blog/2020/12/08/kubernetes-1-20-release-announcement/) +como parte do lançamento do Kubernetes v1.20. Para obter mais detalhes sobre +o que isso significa, confira a postagem do blog +[Não entre em pânico: Kubernetes e Docker](/pt-br/blog/2020/12/02/dont-panic-kubernetes-and-docker/). + +Além disso, você pode ler [verifique se a remoção do dockershim afeta você](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/) +para determinar qual impacto a remoção do _dockershim_ teria para você +ou para sua organização. + +Como o lançamento do Kubernetes 1.24 se tornou iminente, estamos trabalhando bastante para tentar fazer uma transição suave. + +- Escrevemos uma postagem no blog detalhando nosso [compromisso e os próximos passos](/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/). +- Acreditamos que não há grandes obstáculos para a migração para [outros agentes de execução de contêiner](/docs/setup/production-environment/container-runtimes/#container-runtimes). +- Há também um guia [Migrando do dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/) disponível. +- Também criamos uma página para listar + [artigos sobre a remoção do dockershim e sobre o uso de agentes de execução compatíveis com CRI](/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes/). Essa lista inclui alguns dos documentos já mencionados e também + abrange fontes externas selecionadas (incluindo guias de fornecedores). + +### Por que o _dockershim_ está sendo removido do Kubernetes? + +As primeiras versões do Kubernetes funcionavam apenas com um ambiente de execução de contêiner específico: +Docker Engine. Mais tarde, o Kubernetes adicionou suporte para trabalhar com outros agentes de execução de contêiner. +O padrão CRI (_Container Runtime Interface_ ou Interface de Agente de Execução de Containers) foi [criado](/blog/2016/12/container-runtime-interface-cri-in-kubernetes/) para +habilitar a interoperabilidade entre orquestradores (como Kubernetes) e diferentes agentes +de execução de contêiner. +O Docker Engine não implementa essa interface (CRI), então o projeto Kubernetes criou um +código especial para ajudar na transição, e tornou esse código _dockershim_ parte do projeto +Kubernetes. + +O código _dockershim_ sempre foi destinado a ser uma solução temporária (daí o nome: _shim_). +Você pode ler mais sobre a discussão e o planejamento da comunidade na +[Proposta de remoção do Dockershim para aprimoramento do Kubernetes][drkep]. +Na verdade, manter o _dockershim_ se tornou um fardo pesado para os mantenedores do Kubernetes. + +Além disso, recursos que são amplamente incompatíveis com o _dockershim_, como +_cgroups v2_ e _namespaces_ de usuário estão sendo implementados nos agentes de execução de CRI +mais recentes. A remoção do suporte para o _dockershim_ permitirá um maior +desenvolvimento nessas áreas. + +[drkep]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2221-remove-dockershim + +### Ainda posso usar o Docker Engine no Kubernetes 1.23? + +Sim, a única coisa que mudou na versão 1.20 é a presença de um aviso no log de inicialização +do [kubelet] se estiver usando o Docker Engine como agente de execução de contêiner. +Você verá este aviso em todas as versões até 1.23. A remoção do _dockershim_ ocorre no Kubernetes 1.24. + +[kubelet]: /docs/reference/command-line-tools-reference/kubelet/ + +### Quando o _dockershim_ será removido? + +Dado o impacto dessa mudança, estamos definindo um cronograma de depreciação mais longo. +A remoção do _dockershim_ está agendada para o Kubernetes v1.24, consulte a +[Proposta de remoção do Dockershim para aprimoramento do Kubernetes][drkep]. +O projeto Kubernetes trabalhará em estreita colaboração com fornecedores e outros ecossistemas para garantir +uma transição suave e avaliará os acontecimentos à medida que a situação for evoluindo. + +### Ainda posso usar o Docker Engine como meu agente de execução do contêiner? + +Primeiro, se você usa o Docker em seu próprio PC para desenvolver ou testar contêineres: nada muda. +Você ainda pode usar o Docker localmente, independentemente dos agentes de execução de contêiner que +você usa em seus Clusters Kubernetes. Os contêineres tornam esse tipo de interoperabilidade possível. + +Mirantis e Docker [comprometeram-se][mirantis] a manter um adaptador substituto para o +Docker Engine, e a manter este adaptador mesmo após o _dockershim_ ser removido +do Kubernetes. O adaptador substituto é chamado [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd). + +[mirantis]: https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/ + +### Minhas imagens de contêiner existentes ainda funcionarão? + +Sim, as imagens produzidas a partir do `docker build` funcionarão com todas as implementações do CRI. +Todas as suas imagens existentes ainda funcionarão exatamente da mesma forma. + +#### E as imagens privadas? + +Sim. Todos os agentes de execução de CRI são compatíveis com as mesmas configurações de segredos usadas no +Kubernetes, seja por meio do PodSpec ou ServiceAccount. + +### Docker e contêineres são a mesma coisa? + +Docker popularizou o padrão de contêineres Linux e tem sido fundamental no +desenvolvimento desta tecnologia. No entanto, os contêineres já existiam +no Linux há muito tempo. O ecossistema de contêineres cresceu para ser muito +mais abrangente do que apenas Docker. Padrões como o OCI e o CRI ajudaram muitas +ferramentas a crescer e prosperar no nosso ecossistema, alguns substituindo +aspectos do Docker, enquanto outros aprimoram funcionalidades já existentes. + +### Existem exemplos de pessoas que usam outros agentes de execução de contêineres em produção hoje? + +Todos os artefatos produzidos pelo projeto Kubernetes (binários Kubernetes) são validados +a cada lançamento de versão. + +Além disso, o projeto [kind] vem usando containerd há algum tempo e tem +visto uma melhoria na estabilidade para seu caso de uso. Kind e containerd são executados +várias vezes todos os dias para validar quaisquer alterações na base de código do Kubernetes. +Outros projetos relacionados seguem um padrão semelhante, demonstrando a estabilidade e +usabilidade de outros agentes de execução de contêiner. Como exemplo, o OpenShift 4.x utiliza +o agente de execução [CRI-O] em produção desde junho de 2019. + +Para outros exemplos e referências, dê uma olhada em projetos adeptos do containerd e +CRI-O, dois agentes de execução de contêineres sob o controle da _Cloud Native Computing Foundation_ +([CNCF]). + +- [containerd](https://github.com/containerd/containerd/blob/master/ADOPTERS.md) +- [CRI-O](https://github.com/cri-o/cri-o/blob/master/ADOPTERS.md) + +[CRI-O]: https://cri-o.io/ +[kind]: https://kind.sigs.k8s.io/ +[CNCF]: https://cncf.io + +### As pessoas continuam referenciando OCI, o que é isso? + +OCI significa _[Open Container Initiative]_ (ou Iniciativa Open Source de Contêineres), que padronizou muitas das +interfaces entre ferramentas e tecnologias de contêiner. Eles mantêm uma +especificação padrão para imagens de contêiner (OCI image-spec) e para +contêineres em execução (OCI runtime-spec). Eles também mantêm uma implementação real +da especificação do agente de execução na forma de [runc], que é o agente de execução padrão +para ambos [containerd] e [CRI-O]. O CRI baseia-se nessas especificações de baixo nível para +fornecer um padrão de ponta a ponta para gerenciar contêineres. + +[Open Container Initiative]: https://opencontainers.org/about/overview/ +[runc]: https://github.com/opencontainers/runc +[containerd]: https://containerd.io/ + +### Qual implementação de CRI devo usar? + +Essa é uma pergunta complexa e depende de muitos fatores. Se você estiver +trabalhando com Docker, mudar para containerd deve ser uma troca relativamente fácil e +terá um desempenho estritamente melhor e menos sobrecarga. No entanto, nós encorajamos você a +explorar todas as opções do [cenário CNCF], pois outro agente de execução de contêiner +pode funcionar ainda melhor para o seu ambiente. + +[cenário CNCF]: https://landscape.cncf.io/card-mode?category=container-runtime&grouping=category + +### O que devo ficar atento ao mudar a minha implementação de CRI utilizada? + +Embora o código de conteinerização base seja o mesmo entre o Docker e a maioria +CRIs (incluindo containerd), existem algumas poucas diferenças. Alguns +pontos a se considerar ao migrar são: + +- Configuração de _log_ +- Limitações de recursos de agentes de execução +- Scripts de provisionamento que chamam o docker ou usam o docker por meio de seu soquete de controle +- Plugins kubectl que exigem CLI do docker ou o soquete de controle +- Ferramentas do projeto Kubernetes que requerem acesso direto ao Docker Engine + (por exemplo: a ferramenta depreciada `kube-imagepuller`) +- Configuração de funcionalidades como `registry-mirrors` e _registries_ inseguros +- Outros scripts de suporte ou _daemons_ que esperam que o Docker Engine esteja disponível e seja executado + fora do Kubernetes (por exemplo, agentes de monitoramento ou segurança) +- GPUs ou hardware especial e como eles se integram ao seu agente de execução e ao Kubernetes + +Se você usa solicitações ou limites de recursos do Kubernetes ou usa DaemonSets para coleta de logs +em arquivos, eles continuarão a funcionar da mesma forma. Mas se você personalizou +sua configuração `dockerd`, você precisará adaptá-la para seu novo agente de execução de +contêiner assim que possível. + +Outro aspecto a ser observado é que ferramentas para manutenção do sistema ou execuções dentro de um +contêiner no momento da criação de imagens podem não funcionar mais. Para o primeiro, a ferramenta +[`crictl`][cr] pode ser utilizada como um substituto natural (veja +[migrando do docker cli para o crictl](https://kubernetes.io/docs/tasks/debug-application-cluster/crictl/#mapping-from-docker-cli-to-crictl)) +e para o último, você pode usar novas opções de construções de contêiner, como [img], [buildah], +[kaniko], ou [buildkit-cli-for-kubectl] que não requerem Docker. + +[cr]: https://github.com/kubernetes-sigs/cri-tools +[img]: https://github.com/genuinetools/img +[buildah]: https://github.com/containers/buildah +[kaniko]: https://github.com/GoogleContainerTools/kaniko +[buildkit-cli-for-kubectl]: https://github.com/vmware-tanzu/buildkit-cli-for-kubectl + +Para containerd, você pode começar com sua [documentação] para ver quais opções de configuração +estão disponíveis à medida que você vá realizando a migração. + +[documentação]: https://github.com/containerd/cri/blob/master/docs/registry.md + +Para obter instruções sobre como usar containerd e CRI-O com Kubernetes, consulte o +documentação do Kubernetes em [Agentes de execução de contêineres] + +[Agentes de execução de contêineres]: /docs/setup/production-environment/container-runtimes/ + +### E se eu tiver mais perguntas? + +Se você usa uma distribuição do Kubernetes com suporte do fornecedor, pode perguntar a eles sobre +planos de atualização para seus produtos. Para perguntas de usuário final, poste-as +no nosso fórum da comunidade de usuários: https://discuss.kubernetes.io/. + +Você também pode conferir a excelente postagem do blog +[Espere, o Docker está depreciado no Kubernetes agora?][dep], uma discussão técnica mais aprofundada +sobre as mudanças. + +[dep]: https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m + +### Posso ganhar um abraço? + +Sim, ainda estamos dando abraços se solicitado. 🤗🤗🤗