Essa é a versão completa de impressão dessa seção Clique aqui para imprimir.

Retornar à visualização normal.

Kubernetes Blog

Redirecionamento do registro de imagens k8s.gcr.io para registry.k8s.io - O que você precisa saber

Autores: Bob Killen (Google), Davanum Srinivas (AWS), Chris Short (AWS), Frederico Muñoz (SAS Institute), Tim Bannister (The Scale Factory), Ricky Sadowski (AWS), Grace Nguyen (Expo), Mahamed Ali (Rackspace Technology), Mars Toktonaliev (independent), Laura Santamaria (Dell), Kat Cosgrove (Dell)

Na segunda-feira, dia 20 de março, o registro de imagens k8s.gcr.io vai ser redirecionado para o registro de imagens da comunidade, registry.k8s.io.

O que você precisa saber sobre essa mudança

  • Na segunda-feira, dia 20 de março, o tráfego do registro de imagens antigo k8s.gcr.io vai ser redirecionado para registry.k8s.io com o objetivo final de encerramento do k8s.gcr.io.
  • Se você está executando em um ambiente restrito, e aplica políticas rígidas de acesso a nomes de domínios ou endereços IPs limitado a k8s.gcr.io, o pull de imagens não vai funcionar depois que o k8s.gcr.io começar a redirecionar para o novo registro de imagens.
  • Um pequeno subconjunto de clientes que não seguem o padrão não lidam com redirecionamentos HTTP, e neste caso eles precisam ser apontados diretamente para registry.k8s.io.
  • O redirecionamento é um paliativo para ajudar os usuários a fazer essa troca. O registro obsoleto k8s.gcr.io será desativado em algum momento. Por isso, atualize seus manifestos o mais rápido possível para apontar para registry.k8s.io.
  • Se você mantém seu próprio registro de imagens, você pode copiar as imagens que você precisa para reduzir o tráfego ao registro de imagens da comunidade.

Se você acha que vai ser impactado, ou gostaria de saber mais sobre essa mudança, leia mais abaixo.

Como eu posso checar se eu vou ser afetado?

Para testar a conectividade ao registry.k8s.io (e saber se consegue baixar as imagens), pode executar o comando abaixo em um namespace da sua escolha:

kubectl run hello-world -ti --rm --image=registry.k8s.io/busybox:latest --restart=Never -- date

Quando executar o comando acima, é esperada a seguinte saída caso tudo esteja funcionando corretamente:

$ kubectl run hello-world -ti --rm --image=registry.k8s.io/busybox:latest --restart=Never -- date
Fri Feb 31 07:07:07 UTC 2023
pod "hello-world" deleted

Quais erros são esperados caso eu seja afetado?

Os erros podem depender do tipo de agente de execução de contêiner que você está usando, e para qual endpoint você está sendo direcionado, mas devem ser erros como ErrImagePull, ImagePullBackOff, ou falha na criação do container com o aviso FailedCreatePodSandBox.

Abaixo um exemplo de uma mensagem de erro mostrando uma instalação por trás de um proxy falhando devido a um certificado desconhecido:

FailedCreatePodSandBox: Failed to create pod sandbox: rpc error: code = Unknown desc = Error response from daemon: Head “https://us-west1-docker.pkg.dev/v2/k8s-artifacts-prod/images/pause/manifests/3.8”: x509: certificate signed by unknown authority

Quais imagens serão afetadas?

TODAS as imagens no k8s.gcr.io serão afetadas por essa mudança. O k8s.gcr.io hospeda muitas imagens além das releases do Kubernetes. Um grande número de subprojetos do Kubernetes hospedam seus projetos nele também. Alguns exemplos incluem as imagens dns/k8s-dns-node-cache, ingress-nginx/controller, e node-problem-detector/node-problem-detector.

Eu fui afetado, o que devo fazer?

Para usuários afetados que usam um ambiente restrito, a melhor opção é copiar as imagens necessárias para um registro privado ou configurar um cache de pull-through no seu registro de imagens.

Existem várias ferramentas para copiar imagens entre registros de imagens. Crane é uma dessas ferramentas, as imagens podem ser copiadas para um registro de imagens privado com crane copy SRC DST. Também existem ferramentas específicas de fornecedores, como o gcrane que faz uma função similar mas simplificada para a plataforma da Google.

Como eu posso encontrar quais imagens estão usando o registro de imagens antigo, e corrigir elas?

Opção 1: Veja esse comando do kubectl no blog post anterior:

kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" |\
tr -s '[[:space:]]' '\n' |\
sort |\
uniq -c

Opção 2: Um plugin do kubectl krew chamado community-images foi desenvolvido para escanear e reportar qualquer imagem usando o endpoint k8s.gcr.io.

Se você tem o krew instalado, pode instalar o plugin com:

kubectl krew install community-images

E gerar um relatório com:

kubectl community-images

Para métodos alternativos de instalação ou exemplos de saída, veja o repositório kubernetes-sigs/community-images.

Opção 3: Se você não tem acesso diretamente ao cluster, ou gerencia muitos clusters - o melhor caminho é executar uma busca sobre seus manifestos e charts por "k8s.gcr.io".

Opção 4: Se você quer prevenir a execução de imagens a partir do k8s.gcr.io no seu cluster, existem políticas para Gatekeeper e Kyverno disponíveis no repositório de melhores práticas para AWS EKS que vão bloquear o pull das imagens. Você pode usar essas políticas de terceiros com qualquer cluster Kubernetes.

Opção 5: Como a ÚLTIMA opção, você pode usar um webhook de admissão para alterar o endereço da imagem dinamicamente. Isso deve ser feito apenas como uma medida paliativa enquanto os seus manifestos são atualizados. Você pode encontrar um webhook de admissão e uma política do Kyverno (de terceiros) em k8s-gcr-quickfix.

Por que o Kubernetes mudou para um registro de imagem diferente?

O k8s.gcr.io é hospedado em um domínio customizado no Google Cloud Registry (GCR) que foi configurado exclusivamente para o projeto do Kubernetes. Isso funcionou desde o nascimento do projeto, e nós agradecemos ao Google por prover esses recursos, mas atualmente, existem outros provedores de nuvem e fornecedores que gostariam de hospedar imagens para fornecer uma melhor experiência para as pessoas nas suas plataformas. Além do Google ter renovado o compromisso de doar $3 milhões para manter a infraestrutura do projeto ano passado, a Amazon Web Services anunciou uma doação correspondente durante o seu keynote na Kubecon NA 2022 em Detroit. Isso proporcionará uma melhor experiência para os usuários (servidores mais pertos = downloads mais rápidos) e vai reduzir a largura de banda de saída e os custos do GCR ao mesmo tempo.

Para mais detalhes sobre essa mudança, leia mais em registry.k8s.io: rápido, barato e em disponibilidade geral (GA).

Por que está sendo feito um redirecionamento?

O projeto mudou para o registry.k8s.io ano passado na versão 1.25; entretanto, a maioria do tráfego de pull de imagens ainda continua sendo feito para o antigo endpoint k8s.gcr.io. Isso não foi sustentável para nós como um projeto pois não estamos usando os recursos que foram doados para o projeto por outros provedores e estamos correndo o risco de ficar sem recursos dado o custo de servir esse tráfego.

O redirecionamento vai permitir que o projeto aproveite as vantagens desses novos recursos, reduzindo significantemente os cursos da largura de banda de saída. Nós esperamos que apenas um pequeno subconjunto de usuários executando em ambientes restritos ou clientes antigos que não consigam fazer o redirecionamento apropriadamente sejam impactados.

O que vai acontecer com o k8s.gcr.io?

Para além do redirecionamento, o k8s.gcr.io vai ser congelado e não vai ser atualizado com novas imagens depois do dia 03 de abril de 2023. O k8s.gcr.io não vai receber nenhuma nova release, patch ou atualização de segurança. Ele continuará disponível para ajudar as pessoas na migração, mas SERÁ removido totalmente no futuro.

Ainda tenho perguntas, onde devo ir?

Para mais informações sobre o registry.k8s.io e porque foi desenvolvido, leia em registry.k8s.io: rápido, barato e em disponibilidade geral (GA).

Se você quer saber mais sobre o congelamento das imagens e as últimas imagens que vão ficar disponíveis lá, leia o blog post: k8s.gcr.io O registro de imagens será congelado a partir de 3 de abril de 2023.

Informações sobre a arquitetura do registry.k8s.io e sobre sua árvore de decisão de tratamento das requisições pode ser encontradas no repositório kubernetes/registry.k8s.io.

Se você encontrar um bug no novo registro de imagens ou no redirecionamento, por favor abra uma issue no repositório kubernetes/registry.k8s.io. Por favor verifique se já não existe uma issue aberta parecida antes de abrir uma nova.

Os tutoriais gratuitos do Katacoda Kubernetes estão sendo encerrados

Autor: Natali Vlatko, Co-presidente do SIG Docs do Kubernetes

Katacoda, a popular plataforma de aprendizagem da O'Reilly que tem ajudado as pessoas a aprender tudo sobre Java, Docker, Kubernetes, Python, Go, C++ e mais, foi desativada para uso público em junho de 2022. No entanto, os tutoriais específicos para Kubernetes, vinculados no website do Kubernetes para os usuários e contribuidores de nossos projetos, permaneceram disponíveis e ativos após esta mudança. Infelizmente, isso não será mais o caso, e os tutoriais do Katacoda para aprender o Kubernetes deixarão de funcionar após 31 de março de 2023.

O Projeto Kubernetes agradece à O'Reilly Media pelos muitos anos em que apoia a comunidade por meio da plataforma de aprendizado Katacoda. Você pode ler mais sobre a decisão de fechar o katacoda.com no próprio website da O'Reilly. Com essa mudança, focaremos no trabalho necessário para remover os links para seus vários tutoriais. Temos uma issue geral do GitHub para rastrear este tópico em #33936 e uma discussão no GitHub. Também estamos interessados em pesquisar quais outras plataformas de aprendizado podem ser benéficas para a comunidade do Kubernetes, substituindo o Katacoda por uma plataforma ou um serviço que tenha uma experiência de usuário semelhante. No entanto, esta pesquisa levará tempo, por isso estamos procurando ativamente por voluntários para ajudarem neste trabalho. Se uma substituição for encontrada, ela precisará ser suportada pela liderança do Kubernetes, especificamente, SIG Contributor Experience, SIG Docs, e Comitê de Gestão do Kubernetes.

O desligamento do Katacoda afeta 25 páginas de tutorial, suas localizações, bem como o repositório de cenários do Katacoda: github.com/katacoda-scenarios/kubernetes-bootcamp-scenarios. Recomendamos que quaisquer links, guias ou documentações que apontem para a plataforma de aprendizado Katacoda sejam atualizados imediatamente para refletir essa alteração. Embora ainda não tenhamos encontrado uma solução de aprendizado substituta, o website do Kubernetes contém muita documentação útil para dar suporte ao seu aprendizado e crescimento contínuos. Você pode encontrar toda a documentação dos nossos tutoriais disponível para o Kubernetes em https://k8s.io/pt-br/docs/tutorials/.

Se você tiver alguma dúvida sobre o desligamento do Katacoda ou a remoção subsequente do link das páginas de tutorial do Kubernetes, sinta-se à vontade para comentar na issue geral que acompanha o desligamento, ou visite o canal #sig-docs no Slack do Kubernetes.

k8s.gcr.io O registro de imagens será congelado a partir de 3 de abril de 2023

Autor: Mahamed Ali (Rackspace Technology)

O projeto Kubernetes executa um registro de imagens de propriedade da comunidade chamado registry.k8s.io para hospedar suas imagens de contêiner. No dia 3 de abril de 2023, o antigo registro k8s.gcr.io será congelado e nenhuma nova imagem para o Kubernetes e subprojetos relacionados será enviada para o registro antigo.

Este registro registry.k8s.io substituiu o antigo e está disponível há vários meses. Publicamos uma postagem no blog sobre seus benefícios para a comunidade e o projeto Kubernetes. Este post também anunciou que versões futuras do Kubernetes não estarão disponíveis no registro antigo. Agora chegou essa hora.

O que essa mudança significa para os colaboradores:

  • Se você é um mantenedor de um subprojeto, precisará atualizar seus manifestos e Helm charts para usar o novo registro.

O que essa mudança significa para os usuários finais:

  • A versão 1.27 do Kubernetes não será publicada no registro antigo.
  • As versões de patch para 1.24, 1.25 e 1.26 não serão mais publicadas no registro antigo a partir de abril. Leia a linha do tempo abaixo para obter detalhes sobre os lançamentos finais de patches no registro antigo.
  • A partir da versão 1.25, o registro de imagem padrão foi definido como registry.k8s.io. Este valor é substituível nos programas kubeadm e kubelet, mas defini-lo como k8s.gcr.io falhará para novas versões após abril, pois as imagens dessas novas versões não estarão disponíveis no registro antigo.
  • Se você quiser aumentar a confiabilidade do seu cluster e remover a dependência do registro de propriedade da comunidade ou se estiver executando o Kubernetes em redes onde o tráfego externo é restrito, considere hospedar uma cópia local do registro de imagens. Alguns fornecedores de nuvem podem oferecer soluções para isso.

Linha do tempo das mudanças

  • k8s.gcr.io será congelado no dia 3 de abril de 2023
  • Espera-se que a versão 1.27 seja lançada em 12 de abril de 2023
  • A última versão da 1.23 no k8s.gcr.io será 1.23.18 (a versão 1.23 deixará de ser suportada antes do congelamento do k8s.gcr.io)
  • A última versão 1.24 no k8s.gcr.io será 1.24.12
  • A última versão 1.25 no k8s.gcr.io será 1.25.8
  • A última versão 1.26 no k8s.gcr.io será 1.26.3

Próximos passos

Certifique-se de que o seu cluster não tenha dependências no registro de imagens antigo. Por exemplo, você pode executar este comando para listar as imagens usadas pelos Pods:

kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" |\
tr -s '[[:space:]]' '\n' |\
sort |\
uniq -c

Pode haver outras dependências no antigo registro de imagens. Certifique-se de revisar quaisquer dependências potenciais para manter seu cluster saudável e atualizado.

Agradecimentos

A mudança é difícil, e a evolução de nossa plataforma de serviço de imagem é necessária para garantir um futuro sustentável para o projeto. Nós nos esforçamos para melhorar as coisas para todos que utilizam o Kubernetes. Muitos colaboradores de todos os cantos da nossa comunidade têm trabalhado muito e com dedicação para garantir que estamos tomando as melhores decisões possíveis, executando planos e fazendo o nosso melhor para comunicar esses planos.

Obrigado a Aaron Crickenberger, Arnaud Meukam, Benjamin Elder, Caleb Woodbine, Davanum Srinivas, Mahamed Ali, e Tim Hockin do grupo de interesse especial (SIG) K8s Infra, Brian McQueen, e Sergey Kanzhelev do SIG Node, Lubomir Ivanov do SIG Cluster Lifecycle, Adolfo García Veytia, Jeremy Rickard, Sascha Grunert, e Stephen Augustus do SIG Release, Bob Killen and Kaslin Fields do SIG Contribex, Tim Allclair do Comitê de Resposta de Segurança. Um grande obrigado também aos nossos amigos que atuam como pontos de contato com nossos provedores de nuvem parceiros: Jay Pipes da Amazon e Jon Johnson Jr. do Google.

registry.k8s.io: rápido, barato e em disponibilidade geral (GA)

Autores: Adolfo García Veytia (Chainguard), Bob Killen (Google)

A partir do Kubernetes 1.25, o nosso repositório de imagens de contêiner mudou de k8s.gcr.io para registry.k8s.io. Este novo repositório distribui a carga por várias regiões e Provedores de Nuvem, funcionando como uma espécie de rede de entrega de conteúdo (CDN) para imagens de contêiner do Kubernetes. Essa mudança reduz a dependência do projeto em uma única entidade e fornece uma experiência mais rápida de download para um grande número de usuários.

Sumário: O que você precisa saber sobre essa mudança

  • As imagens de contêiner para versões do Kubernetes a partir de 1.25 não serão mais publicadas no k8s.gcr.io, apenas no registry.k8s.io
  • Em dezembro, nas próximas versões de patch, o novo padrão de domínio do registro será portado retroativamente para todas as branches ainda com suporte (1.22, 1.23, 1.24).
  • Em um ambiente restrito, se você aplicar políticas rígidas de acesso aos endereços de domínio/IP limitados ao k8s.gcr.io, as imagens não serão baixadas após a migração para este novo repositório. Para esses usuários, o método recomendado é espelhar o lançamento das imagens em um repositório privado.

Se você quiser saber mais sobre o motivo que fizemos essa mudança, ou alguns dos possíveis problemas que você pode encontrar, continue lendo.

Por que o Kubernetes mudou para um registro de imagens diferente?

O k8s.gcr.io está hospedado em um domínio personalizado do Google Container Registry (GCR) que foi configurado exclusivamente para o projeto Kubernetes. Isso funcionou bem desde o início do projeto, e agradecemos ao Google por fornecer esses recursos, mas hoje existem outros fornecedores e provedores de nuvem que gostariam de hospedar as imagens para fornecer uma melhor experiência para as pessoas em suas plataformas. Além do compromisso renovado do Google de doar US$ 3 milhões para apoiar a infraestrutura do projeto, a Amazon anunciou uma doação correspondente durante sua palestra na Kubecon NA 2022 em Detroit. Isso fornecerá uma melhor experiência para os usuários (servidores mais próximos = downloads mais rápidos) e reduzirá a largura de banda de saída e os custos do GCR ao mesmo tempo. O registry.k8s.io distribuirá a carga entre o Google e a Amazon, com outros provedores no futuro.

Por que não há uma lista estável de domínios/IPs? Por que não posso restringir o pull de imagens?

O registry.k8s.io é um redirecionador seguro de blob que conecta os clientes ao provedor de nuvem mais próximo. A natureza dessa mudança significa que o pull de uma imagem cliente pode ser redirecionado para qualquer um dos vários backends. Esperamos que o conjunto de backends continue mudando e aumente à medida que mais e mais provedores de nuvem e fornecedores se juntem para ajudar a espelhar as atualizações das imagens.

Os mecanismos de controle mais restritos como proxies de man-in-the-middle ou políticas de rede que restringem o acesso a uma lista específica de domínios/IPs quebrarão com essa mudança. Para esses cenários, encorajamos você a espelhar as atualizações das imagens em um repositório local sobre o qual você tenha um controle rigoroso.

Para mais informações sobre esta política, consulte a seção de estabilidade da documentação do registry.k8s.io.

Que tipo de erros eu verei? Como saberei se ainda estou usando o endereço antigo?

Os erros dependem do tipo do agente de execução de contêiner que você está usando e para qual o endpoint você está roteado, mas ele deve se apresentar como um contêiner que não pode ser criado com o aviso FailedCreatePodSandBox.

Abaixo temos um exemplo de mensagem de erro mostrando uma instalação por trás de um proxy em que não pode ser feito o pull devido a um certificado desconhecido:

FailedCreatePodSandBox: Failed to create pod sandbox: rpc error: code = Unknown desc = Error response from daemon: Head “https://us-west1-docker.pkg.dev/v2/k8s-artifacts-prod/images/pause/manifests/3.8”: x509: certificate signed by unknown authority

Fui impactado por essa mudança, como faço para reverter para o endereço de registro antigo?

Se usar o novo nome de domínio do registro não for uma opção, você pode reverter para o nome de domínio antigo para versões de cluster menores de 1.25. Tenha em mente que, eventualmente, você terá que mudar para o novo registro, pois as novas tags de imagem não serão mais enviadas para o GCR.

Revertendo o nome do registro no kubeadm

O registro usado pelo kubeadm para realizar o pull das suas imagens pode ser controlado por dois métodos:

Definindo a flag --image-repository.

kubeadm init --image-repository=k8s.gcr.io

Ou em kubeadm config ClusterConfiguration:

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
imageRepository: "k8s.gcr.io"

Revertendo o Nome do Registro no kubelet

A imagem usada pelo kubelet para o pod sandbox (pause) pode ser substituída pela flag --pod-infra-container-image. Por exemplo:

kubelet --pod-infra-container-image=k8s.gcr.io/pause:3.5

Agradecimentos

A mudança é difícil, e a evolução de nossa plataforma de serviço de imagem é necessária para garantir um futuro sustentável para o projeto. Nós nos esforçamos para melhorar as coisas para todos que utilizam o Kubernetes. Muitos colaboradores de todos os cantos da nossa comunidade têm trabalhado muito e com dedicação para garantir que estamos tomando as melhores decisões possíveis, executando planos e fazendo o nosso melhor para comunicar esses planos.

Obrigado a Aaron Crickenberger, Arnaud Meukam, Benjamin Elder, Caleb Woodbine, Davanum Srinivas, Mahamed Ali, e Tim Hockin do grupo de interesse especial (SIG) K8s Infra, Brian McQueen, e Sergey Kanzhelev do SIG Node, Lubomir Ivanov do SIG Cluster Lifecycle, Adolfo García Veytia, Jeremy Rickard, Sascha Grunert, e Stephen Augustus do SIG Release, Bob Killen and Kaslin Fields do SIG Contribex, Tim Allclair do Comitê de Resposta de Segurança. Um grande obrigado também aos nossos amigos que atuam como pontos de contato com nossos provedores de nuvem parceiros: Jay Pipes da Amazon e Jon Johnson Jr. do Google.

Atualizado: Perguntas frequentes (FAQ) sobre a remoção do Dockershim

Esta é uma atualização do artigo original FAQ sobre a depreciação do Dockershim, publicado no final de 2020.

Este documento aborda algumas perguntas frequentes sobre a descontinuação e remoção do dockershim, que foi anunciado 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.

Além disso, você pode ler verifique se a remoção do dockershim afeta você 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.

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 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. 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.

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.

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. 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 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.

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).

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.

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.

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 dos 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 pode ser utilizada como um substituto natural (veja migrando do docker cli para o 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.

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.

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

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?, uma discussão técnica mais aprofundada sobre as mudanças.

Posso ganhar um abraço?

Sim, ainda estamos dando abraços se solicitado. 🤗🤗🤗

Não entre em pânico: Kubernetes e Docker

Autores / Autoras: Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan “POP” Papandrea, Jeffrey Sica, Davanum “Dims” Srinivas

Tradução: João Brito

Kubernetes está deixando de usar Docker como seu agente de execução após a versão v1.20.

Não entre em pânico. Não é tão dramático quanto parece.

TL;DR Docker como um agente de execução primário está sendo deixado de lado em favor de agentes de execução que utilizam a Interface de Agente de Execução de Containers (Container Runtime Interface "CRI") criada para o Kubernetes. As imagens criadas com o Docker continuarão a funcionar em seu cluster com os agentes atuais, como sempre estiveram.

Se você é um usuário final de Kubernetes, quase nada mudará para você. Isso não significa a morte do Docker, e isso não significa que você não pode, ou não deva, usar ferramentas Docker em desenvolvimento mais. Docker ainda é uma ferramenta útil para a construção de containers, e as imagens resultantes de executar docker build ainda rodarão em seu cluster Kubernetes.

Se você está usando um Kubernetes gerenciado como GKE, EKS, ou AKS (que usa como padrão containerd) você precisará ter certeza que seus nós estão usando um agente de execução de container suportado antes que o suporte ao Docker seja removido nas versões futuras do Kubernetes. Se você tem mudanças em seus nós, talvez você precise atualizá-los baseado em seu ambiente e necessidades do agente de execução.

Se você está rodando seus próprios clusters, você também precisa fazer mudanças para evitar quebras em seu cluster. Na versão v1.20, você terá o aviso de alerta da perda de suporte ao Docker. Quando o suporte ao agente de execução do Docker for removido em uma versão futura (atualmente planejado para a versão 1.22 no final de 2021) do Kubernetes ele não será mais suportado e você precisará trocar para um dos outros agentes de execução de container compatível, como o containerd ou CRI-O. Mas tenha certeza que esse agente de execução escolhido tenha suporte às configurações do daemon do Docker usadas atualmente (Ex.: logs)

Então porque a confusão e toda essa turma surtando?

Estamos falando aqui de dois ambientes diferentes, e isso está criando essa confusão. Dentro do seu cluster Kubernetes, existe uma coisa chamada de agente de execução de container que é responsável por baixar e executar as imagens de seu container. Docker é a escolha popular para esse agente de execução (outras escolhas comuns incluem containerd e CRI-O), mas Docker não foi projetado para ser embutido no Kubernetes, e isso causa problemas.

Se liga, o que chamamos de "Docker" não é exatamente uma coisa - é uma stack tecnológica inteira, e uma parte disso é chamado de "containerd", que é o agente de execução de container de alto-nível por si só. Docker é legal e útil porque ele possui muitas melhorias de experiência do usuário e isso o torna realmente fácil para humanos interagirem com ele enquanto estão desenvolvendo, mas essas melhorias para o usuário não são necessárias para o Kubernetes, pois ele não é humano.

Como resultado dessa camada de abstração amigável aos humanos, seu cluster Kubernetes precisa usar outra ferramenta chamada Dockershim para ter o que ele realmente precisa, que é o containerd. Isso não é muito bom, porque adiciona outra coisa a ser mantida e que pode quebrar. O que está atualmente acontecendo aqui é que o Dockershim está sendo removido do Kubelet assim que que a versão v1.23 for lançada, que remove o suporte ao Docker como agente de execução de container como resultado. Você deve estar pensando, mas se o containerd está incluso na stack do Docker, porque o Kubernetes precisa do Dockershim?

Docker não é compatível com CRI, a Container Runtime Interface (interface do agente de execução de container). Se fosse, nós não precisaríamos do shim, e isso não seria nenhum problema. Mas isso não é o fim do mundo, e você não precisa entrar em pânico - você só precisa mudar seu agente de execução de container do Docker para um outro suportado.

Uma coisa a ser notada: Se você está contando com o socket do Docker (/var/run/docker.sock) como parte do seu fluxo de trabalho em seu cluster hoje, mover para um agente de execução diferente acaba com sua habilidade de usá-lo. Esse modelo é conhecido como Docker em Docker. Existem diversas opções por aí para esse caso específico como o kaniko, img, e buildah.

O que essa mudança representa para os desenvolvedores? Ainda escrevemos Dockerfiles? Ainda vamos fazer build com Docker?

Essa mudança aborda um ambiente diferente do que a maioria das pessoas usa para interagir com Docker. A instalação do Docker que você está usando em desenvolvimento não tem relação com o agente de execução de Docker dentro de seu cluster Kubernetes. É confuso, dá pra entender. Como desenvolvedor, Docker ainda é útil para você em todas as formas que era antes dessa mudança ser anunciada. A imagem que o Docker cria não é uma imagem específica para Docker e sim uma imagem que segue o padrão OCI (Open Container Initiative).

Qualquer imagem compatível com OCI, independente da ferramenta usada para construí-la será vista da mesma forma pelo Kubernetes. Ambos containerd e CRI-O sabem como baixar e executá-las. Esse é o porque temos um padrão para containers.

Então, essa mudança está chegando. Isso irá causar problemas para alguns, mas nada catastrófico, no geral é uma boa coisa. Dependendo de como você interage com o Kubernetes, isso tornará as coisas mais fáceis. Se isso ainda é confuso para você, tudo bem, tem muita coisa rolando aqui; Kubernetes tem um monte de partes móveis, e ninguém é 100% especialista nisso. Nós encorajamos toda e qualquer tipo de questão independente do nível de experiência ou de complexidade! Nosso objetivo é ter certeza que todos estão entendendo o máximo possível as mudanças que estão chegando. Esperamos que isso tenha respondido a maioria de suas questões e acalmado algumas ansiedades! ❤️

Procurando mais respostas? Dê uma olhada em nosso apanhado de questões quanto ao desuso do Dockershim.

Escalando a rede do Kubernetes com EndpointSlices

Autor: Rob Scott (Google)

EndpointSlices é um novo tipo de API que provê uma alternativa escalável e extensível à API de Endpoints. EndpointSlices mantém o rastreio dos endereços IP, portas, informações de topologia e prontidão de Pods que compõem um serviço.

No Kubernetes 1.19 essa funcionalidade está habilitada por padrão, com o kube-proxy lendo os EndpointSlices ao invés de Endpoints. Apesar de isso ser uma mudança praticamente transparente, resulta numa melhoria notável de escalabilidade em grandes clusters. Também permite a adição de novas funcionalidades em releases futuras do Kubernetes, como o Roteamento baseado em topologia..

Limitações de escalabilidade da API de Endpoints

Na API de Endpoints, existia apenas um recurso de Endpoint por serviço (Service). Isso significa que era necessário ser possível armazenar endereços IPs e portas para cada Pod que compunha o serviço correspondente. Isso resultava em recursos imensos de API. Para piorar, o kube-proxy rodava em cada um dos nós e observava qualquer alteração nos recursos de Endpoint. Mesmo que fosse uma simples mudança em um Endpoint, todo o objeto precisava ser enviado para cada uma das instâncias do kube-proxy.

Outra limitação da API de Endpoints era que ela limitava o número de objetos que podiam ser associados a um Service. O tamanho padrão de um objeto armazenado no etcd é 1.5MB. Em alguns casos, isso poderia limitar um Endpoint a 5,000 IPs de Pod. Isso não chega a ser um problema para a maioria dos usuários, mas torna-se um problema significativo para serviços que se aproximem desse tamanho.

Para demonstrar o quão significante se torna esse problema em grande escala, vamos usar de um simples exemplo: Imagine um Service que possua 5,000 Pods, e que possa causar o Endpoint a ter 1.5Mb . Se apenas um Endpoint nessa lista sofra uma alteração, todo o objeto de Endpoint precisará ser redistribuído para cada um dos nós do cluster. Em um cluster com 3.000 nós, essa atualização causará o envio de 4.5Gb de dados (1.5Mb de Endpoints * 3,000 nós) para todo o cluster. Isso é quase que o suficiente para encher um DVD, e acontecerá para cada mudança de Endpoint. Agora imagine uma atualização gradual em um Deployment que resulte nos 5,000 Pods serem substituídos - isso é mais que 22Tb (ou 5,000 DVDs) de dados transferidos.

Dividindo os endpoints com a API de EndpointSlice

A API de EndpointSlice foi desenhada para resolver esse problema com um modelo similar de sharding. Ao invés de rastrar todos os IPs dos Pods para um Service, com um único recurso de Endpoint, nós dividimos eles em múltiplos EndpointSlices menores.

Usemos por exemplo um serviço com 15 pods. Nós teríamos um único recurso de Endpoints referente a todos eles. Se o EndpointSlices for configurado para armazenar 5 endpoints cada, nós teríamos 3 EndpointSlices diferentes: EndpointSlices

Por padrão, o EndpointSlices armazena um máximo de 100 endpoints cada, podendo isso ser configurado com a flag --max-endpoints-per-slice no kube-controller-manager.

EndpointSlices provê uma melhoria de escalabilidade em 10x

Essa API melhora dramaticamente a escalabilidade da rede. Agora quando um Pod é adicionado ou removido, apenas 1 pequeno EndpointSlice necessita ser atualizado. Essa diferença começa a ser notada quando centenas ou milhares de Pods compõem um único Service.

Mais significativo, agora que todos os IPs de Pods para um Service não precisam ser armazenados em um único recurso, nós não precisamos nos preocupar com o limite de tamanho para objetos armazendos no etcd. EndpointSlices já foram utilizados para escalar um serviço além de 100,000 endpoints de rede.

Tudo isso é possível com uma melhoria significativa de performance feita no kube-proxy. Quando o EndpointSlices é usado em grande escala, muito menos dados serão transferidos para as atualizações de endpoints e o kube-proxy torna-se mais rápido para atualizar regras do iptables ou do ipvs. Além disso, os Services podem escalar agora para pelo menos 10x mais além dos limites anteriores.

EndpointSlices permitem novas funcionalidades

Introduzido como uma funcionalidade alpha no Kubernetes v1.16, os EndpointSlices foram construídos para permitir algumas novas funcionalidades arrebatadoras em futuras versões do Kubernetes. Isso inclui serviços dual-stack, roteamento baseado em topologia e subconjuntos de endpoints.

Serviços Dual-stack são uma nova funcionalidade que foi desenvolvida juntamente com o EndpointSlices. Eles irão utilizar simultâneamente endereços IPv4 e IPv6 para serviços, e dependem do campo addressType do Endpointslices para conter esses novos tipos de endereço por família de IP.

O roteamento baseado por topologia irá atualizar o kube-proxy para dar preferência no roteamento de requisições para a mesma região ou zona, utilizando-se de campos de topologia armazenados em cada endpoint dentro de um EndpointSlice. Como uma melhoria futura disso, estamos explorando o potencial de subconjuntos de endpoint. Isso irá permitir o kube-proxy apenas observar um subconjunto de EndpointSlices. Por exemplo, isso pode ser combinado com o roteamento baseado em topologia e assim, o kube-proxy precisará observar apenas EndpointSlices contendo endpoints na mesma zona. Isso irá permitir uma outra melhoria significativa de escalabilidade.

O que isso significa para a API de Endpoints?

Apesar da API de EndpointSlice prover uma alternativa nova e escalável à API de Endpoints, a API de Endpoints continuará a ser considerada uma funcionalidade estável. A mudança mais significativa para a API de Endpoints envolve começar a truncar Endpoints que podem causar problemas de escalabilidade.

A API de Endpoints não será removida, mas muitas novas funcionalidades irão depender da nova API EndpointSlice. Para obter vantágem da funcionalidade e escalabilidade que os EndpointSlices provém, aplicações que hoje consomem a API de Endpoints devem considerar suportar EndpointSlices no futuro.