Usar um espelho de registro para instalar clusters do Anthos em bare metal

Nesta página, mostramos como instalar clusters do Anthos em bare metal usando um espelho de registro em vez de usar gcr.io. Para usar um espelho de registro, defina o ambiente de execução do contêiner como containerd.

Os espelhos do registro são projetados para espelhar todo o gcr.io. não apenas gcr.io/anthos-baremetal-release/, que é onde os clusters do Anthos em imagens bare metal são normalmente armazenados.

Por exemplo, se você tentar extrair uma imagem gcr.io/kubernetes-e2e-test-images/nautilus:1.0, isso só funcionará se o serviço de registro tiver essa imagem no mesmo caminho, como 172.18.0.20:5000/kubernetes-e2e-test-images/nautilus:1.0. Todas as imagens que não são gcr.io ainda funcionam normalmente. Por exemplo, ainda é possível extrair k8s.gcr.io/pause:3.1.

Usar um espelho de registro ajuda você a economizar no tráfego e oferece uma alternativa ao uso do gcr.io, caso precise isolar seus clusters de interrupções do gcr.io. Ele também permite que você realize sua própria verificação de vulnerabilidades.

Antes de começar

É preciso ter um servidor do Container Registry configurado na rede.
Se o servidor de registro executar um certificado TLS particular, você precisará ter o arquivo de autoridade de certificação (CA, na sigla em inglês).
Se o servidor de registros precisar de autenticação, você precisará ter as credenciais de login adequadas ou o arquivo de configuração do Docker.

Faça o download de todas as imagens necessárias para clusters do Anthos em Bare Metal

Faça o download da versão mais recente da ferramenta bmctl e do pacote de imagens na página Download.

Fazer upload de imagens de contêiner para seu servidor de registro

Faça upload das imagens do pacote de imagens para seu servidor de registro executando:

[HTTPS_PROXY=http://PROXY_IP:PORT] ./bmctl push images \
    --source=./bmpackages_1.8.0.tar.xz \
    --private-registry=REGISTRY_IP:PORT \
    [--cacert=CERT_PATH] \
    [--need-credential=false]

Substitua:

PROXY_IP:PORT pelo endereço IP e pela porta do proxy se você precisar de um proxy para fazer upload das imagens da estação de trabalho para o servidor de registro.
REGISTRY_IP:PORT pelo endereço IP e pela porta do servidor de registro particular.
CERT_PATH pelo caminho do arquivo de certificado de CA se o servidor de registros usar um certificado TLS particular.

Digite seu nome de usuário e senha quando solicitado ou selecione um arquivo de configuração do Docker. Se o servidor de registro não exigir credenciais, especifique --need-credential=false.

Para mais informações sobre o comando bmctl push images, consulte:

bmctl push images --help

Como usar seu próprio namespace

Se você quiser usar seu próprio namespace no servidor de registros em vez do namespace raiz, containerd poderá extrair desse subnamespace se você fornecer o endpoint da API para seu registro particular em registryMirrors.endpoint. O endpoint geralmente está no formato <REGISTRY_IP:PORT>/v2/<NAMESPACE>. Consulte o guia do usuário do seu registro particular para ver detalhes específicos.

Por exemplo, se você só tiver acesso a 172.18.0.20:5000/test-namespace/, poderá usar o seguinte comando para fazer upload de todas as imagens no namespace test-namespace:

./bmctl push images \
    --source=./bmpackages_1.8.0.tar.xz \
    --private-registry=172.18.0.20:5000/test-namespace
    --username=<USERNAME>
    --password=<PASSWORD>
    --cacert <path/to/cert.crt>

Em seguida, no arquivo YAML do cluster, é possível inserir o seguinte para fazer o pull de containerd do subnamespace:

registryMirrors:
  - endpoint: https://172.18.0.20:5000/v2/test-namespace

Criar clusters a partir do espelho de registro

Veja abaixo um exemplo de arquivo de configuração de cluster que usa seu próprio servidor de espelho de registro em vez de gcr.io.

Se o registro não exigir um certificado TLS particular, deixe o campo caCertPath em branco.

Se o servidor de registro não exigir um arquivo de configuração do Docker de autenticação, deixe o campo pullCredentialConfigPath em branco.

Para informações detalhadas sobre a criação de clusters, consulte Como criar clusters.

# Sample cluster config with registry mirror:
---
gcrKeyPath: /bmctl/bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-gcr.json
sshPrivateKeyPath: /root/ssh-key/id_rsa
registryMirrors:
  - endpoint: https://172.18.0.20:5000
    caCertPath: /root/ca.crt
    pullCredentialConfigPath: /root/.docker/config.json
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: admin1
  namespace: cluster-admin1
spec:
  nodeConfig:
    containerRuntime: containerd
...

Todos os nós neste cluster usarão este espelho de registro 172.18.0.20:5000 em vez de gcr.io.

Failover para `gcr.io`

Se o cluster não conseguir extrair do espelho de registro, ele fará o failover automaticamente para gcr.io. É por isso que recomendamos fornecer um valor para gcrKeyPath no arquivo de configuração do cluster. Se um valor não for fornecido, o cluster não poderá extrair de gcr.io caso o espelho de registro falhe.

Se você não precisa do recurso de failover de pull, não precisa adicionar um gcrKeyPath ou adicionar gcr.io à sua lista de permissões de proxy.

Atualizar endpoints de espelho de registro, certificados e credenciais de pull

Para atualizar endpoints de espelho do registro, certificados ou credenciais de pull:

No arquivo de configuração do cluster, atualize o endpoint, o arquivo de certificado de CA e o caminho do arquivo de configuração de credencial.
Aplique as alterações executando:
```
bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
```
Substitua:
- CLUSTER_NAME pelo nome do cluster que você quer atualizar.
- ADMIN_KUBECONFIG pelo caminho do arquivo de configuração do cluster de administrador.