|
| 1 | +--- |
| 2 | +layout: blog |
| 3 | +title: "registry.k8s.io: rápido, barato e sempre disponível (GA)" |
| 4 | +date: 2022-11-28 |
| 5 | +slug: registry-k8s-io-faster-cheaper-ga |
| 6 | +--- |
| 7 | + |
| 8 | +**Autores**: Adolfo García Veytia (Chainguard), Bob Killen (Google) |
| 9 | + |
| 10 | +A partir do Kubernetes 1.25, o nosso repositório de imagens de contêiner mudou de k8s.gcr.io para [registry.k8s.io](https://registry.k8s.io). |
| 11 | +Este novo registro 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. |
| 12 | +Essa mudança reduz a dependência do projeto de uma única entidade e fornece uma experiência mais rápida de download para um grande número de usuários. |
| 13 | + |
| 14 | +## TL;DR: O que você precisa saber sobre essa mudança |
| 15 | + |
| 16 | +* 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 |
| 17 | +* Em dezembro, nas próximas versões de patch, o novo padrão de domínio do registro será backported para todas as branches com suporte ainda (1.22, 1.23, 1.24). |
| 18 | +* Se você executar em um ambiente restrito e aplicar as políticas de acesso aos endereços de domínio/IP limitados ao k8s.gcr.io, os _pulls de imagem não funcionarão_ 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. |
| 19 | + |
| 20 | +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. |
| 21 | + |
| 22 | +## Por que o Kubernetes mudou para um registro de imagens diferente? |
| 23 | + |
| 24 | +O K8s.gcr.io está hospedado em um domínio personalizado do [Google Container Registry](https://cloud.google.com/container-registry) (GCR) que foi configurado exclusivamente para o projeto Kubernetes. |
| 25 | +Isso funcionou bem desde o início do projeto, e agradecemos ao Google por fornecer esses recursos, mas hoje existem outros provedores de nuvem e fornecedores que gostariam de hospedar as imagens para fornecer uma melhor experiência para as pessoas em suas plataformas. |
| 26 | +Além do compromisso renovado do Google de [doar US$ 3 milhões para apoiar](https://www.cncf.io/google-cloud-recommits-3m-to-kubernetes/) a infraestrutura do projeto, a Amazon anunciou uma doação correspondente durante sua palestra na Kubecon NA 2022 em Detroit. |
| 27 | +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 espalhará a carga entre o Google e a Amazon, e com outros provedores no futuro. |
| 28 | + |
| 29 | +## Por que não há uma lista estável de domínios/IPs? Por que não posso restringir o pull de imagens? |
| 30 | + |
| 31 | +O registry.k8s.io é um [redirecionador seguro de blob](https://github.com/kubernetes/registry.k8s.io/blob/main/cmd/archeio/docs/request-handling.md) que conecta os clientes ao provedor de nuvem mais próximo. |
| 32 | +A natureza dessa mudança significa que o pull de uma imagem cliente pode ser redirecionado para qualquer um dos vários backends. |
| 33 | +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. |
| 34 | + |
| 35 | +O restrito mecanismos de controle, tais como man-in-the-middle proxies ou as políticas de rede que restringem o acesso a uma lista específica de domínios/IPs, quebrarão com essa mudança. |
| 36 | +Para esses cenários, encorajamos você a espelhar as atualizações das imagens em um repositório local sobre o qual você tem um rigoroso controle. |
| 37 | + |
| 38 | +Para mais informações sobre esta política, consulte a seção [estabilidade registry.k8s.io](https://github.com/kubernetes/registry.k8s.io#stability) na documentação. |
| 39 | + |
| 40 | +## Que tipo de erros eu verei? Como saberei se ainda estou usando o endereço antigo? |
| 41 | + |
| 42 | +Os erros dependem do tipo de tempo de execução do 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`. |
| 43 | + |
| 44 | +Abaixo temos um exemplo da mensagem de erro mostrando uma falha na implantação do proxy que não pode ser feito o pull devido a um certificado desconhecido: |
| 45 | + |
| 46 | +``` |
| 47 | +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 |
| 48 | +``` |
| 49 | + |
| 50 | +## Estou impressionado com essa mudança, como faço para reverter para o endereço de registro antigo? |
| 51 | + |
| 52 | +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. |
| 53 | + |
| 54 | +### Revertendo o nome do registro em kubeadm |
| 55 | + |
| 56 | +O registro usado pelo kubeadm para realizar o pull das suas imagens pode ser controlado por dois métodos: |
| 57 | + |
| 58 | +Definindo a flag `--image-repository`. |
| 59 | + |
| 60 | +``` |
| 61 | +kubeadm init --image-repository=k8s.gcr.io |
| 62 | +``` |
| 63 | + |
| 64 | +Ou em [kubeadm config](https://kubernetes.io/docs/reference/config-api/kubeadm-config.v1beta3/) `ClusterConfiguration`: |
| 65 | + |
| 66 | +```yaml |
| 67 | +apiVersion: kubeadm.k8s.io/v1beta3 |
| 68 | +kind: ClusterConfiguration |
| 69 | +imageRepository: "k8s.gcr.io" |
| 70 | +``` |
| 71 | +
|
| 72 | +### Revertendo o Nome do Registro em kubelet |
| 73 | +
|
| 74 | +A imagem usada pelo kubelet para o pod sandbox (`pausa`) pode ser substituída pela flag `--pod-infra-container-image`. |
| 75 | +Por exemplo: |
| 76 | + |
| 77 | +``` |
| 78 | +kubelet --pod-infra-container-image=k8s.gcr.io/pause:3.5 |
| 79 | +``` |
| 80 | + |
| 81 | +## Agradecimentos |
| 82 | + |
| 83 | +_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. |
| 84 | +Nós nos esforçamos para melhorar as coisas para todos que utilizam o Kubernetes. |
| 85 | +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. |
| 86 | + |
| 87 | +Obrigado a Aaron Crickenberger, Arnaud Meukam, Benjamin Elder, Caleb Woodbine, Davanum Srinivas, Mahamed Ali, and Tim Hockin from SIG K8s Infra, Brian McQueen, and Sergey Kanzhelev from SIG Node, Lubomir Ivanov from SIG Cluster Lifecycle, Adolfo García Veytia, Jeremy Rickard, Sascha Grunert, and Stephen Augustus from SIG Release, Bob Killen and Kaslin Fields from SIG Contribex, Tim Allclair from the Security Response Committee. |
| 88 | +Um grande obrigado também aos nossos amigos que atuam como ligação com nossos provedores de nuvem parceiros: Jay Pipes da Amazon e Jon Johnson Jr. do Google. |
0 commit comments