Este artigo foi publicado há mais de um ano. Artigos mais antigos podem conter conteúdo desatualizado. Certifique-se de que a informação desta página não se tornou incorreta desde a sua publicação.
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.
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.
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.
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.
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
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.
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"
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
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.