Configurar nós para autenticação em um registro particular

É possível configurar o cluster do Google Distributed Cloud para que os nós de worker possam usar registros particulares. Os registros particulares no nível do nó são destinados ao uso com suas cargas de trabalho para dar mais controle sobre envios de imagem e a segurança relacionada. Quando você configura um cluster com os registros particulares, conforme descrito neste documento, o Google Distributed Cloud faz as atualizações necessárias na configuração do containerd. Depois que o cluster é configurado, todos os pods em nós qualificados podem usar os registros sem precisar especificar imagePullSecrets na especificação.

Esse recurso pode ser ativado ou desativado a qualquer momento no ciclo de vida do cluster.

A lista a seguir mostra o estágio de lançamento desse recurso por versão:

• 1.30: GA
• 1.29: pré-lançamento
• 1.28: não disponível

Pré-requisitos

1.30

Para usar esse recurso GA, seu cluster precisa atender aos seguintes requisitos:

• A versão do cluster precisa ser 1.30.
• A versão do pool de nós precisa ser 1.29 ou mais recente. Um cluster 1.30 pode ter pools de nós na versão 1.28, mas o recurso só funciona para pools de nós na versão 1.29 ou mais recente.

• Esse recurso é para clusters de usuário e autogerenciados (híbridos e autônomos) com pools de nós de trabalho, conforme mostrado na tabela a seguir:

  Modelo de implantação	Tipos de cluster compatíveis
  Implantação de clusters de administrador e usuário	Cluster de administrador Cluster de usuário 1 Cluster de usuário 2
  Implantação de clusters híbridos	Cluster híbrido Cluster de usuário 1 Cluster de usuário 2
  Implantação de clusters autônomos	Cluster autônomo

1.29

Visualização

Este produto ou recurso está sujeito aos "Termos das ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos do serviço. Os produtos e recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Para usar esse recurso de pré-lançamento, seu cluster precisa atender aos seguintes requisitos:

• A versão do cluster precisa ser 1.29.
• A versão do pool de nós precisa ser 1.29. Nem todos os pools de nós precisam estar na versão 1.29, mas o recurso só funciona para pools de nós na versão 1.29.
• O cluster precisa ter a anotação do recurso de visualização preview.baremetal.cluster.gke.io/private-registry: "enable".

• Esse recurso é para clusters de usuário e autogerenciados (híbridos e autônomos) com pools de nós de trabalho, conforme mostrado na tabela a seguir:

  Modelo de implantação	Tipos de cluster compatíveis
  Implantação de clusters de administrador e usuário	Cluster de administrador Cluster de usuário 1 Cluster de usuário 2
  Implantação de clusters híbridos	Cluster híbrido Cluster de usuário 1 Cluster de usuário 2
  Implantação de clusters autônomos	Cluster autônomo

Configurar um cluster autogerenciado para registros particulares

Para configurar um cluster autônomo ou híbrido para usar registros particulares no nível do nó:

1. Edite o arquivo de configuração do cluster para adicionar o bloco privateRegistries na seção de credenciais:

   ---
   gcrKeyPath: baremetal/gcr.json
   sshPrivateKeyPath: .ssh/id_rsa
   ...
   privateRegistries:
     - host: REGISTRY_HOST
       caCertPath: CA_CERT_PATH
       pullCredentialConfigPath: CREDENTIALS_FILE_PATH
   ...
   ---
   apiVersion: v1
   kind: Namespace
   metadata:
     name: cluster-hybrid-basic
   ---
   apiVersion: baremetal.cluster.gke.io/v1
   kind: Cluster
   metadata:
     name: hybrid-basic
     namespace: cluster-hybrid-basic
     annotations:
       preview.baremetal.cluster.gke.io/private-registry: "enable" # Version 1.29 clusters only
       ...
   spec:
     type: hybrid
     ...
   

   Substitua:

   • REGISTRY_HOST: o nome de domínio ou endereço IP do registro particular e da porta. Por exemplo, 10.200.0.2:5007.

   • CA_CERT_PATH: o caminho do arquivo de certificado da AC (AC raiz do servidor). Por exemplo, /root/cert.pem. Se o registro particular não exigir um certificado TLS particular, omita esse campo.

   • CREDENTIALS_FILE_PATH: o caminho do arquivo que contém as credenciais para acessar o registro privado. Por exemplo, /root/.docker/config.json. Se o servidor de registro particular não exigir credenciais para autenticação, omita esse campo.

2. Aplique as mudanças ao cluster:

   bmctl update cluster -c CLUSTER_NAME --kubeconfig=CLUSTER_KUBECONFIG
   

   Substitua:

   • CLUSTER_NAME: o nome do cluster que você quer atualizar.

   • CLUSTER_KUBECONFIG: caminho do arquivo kubeconfig do cluster autogerenciado (híbrido ou autônomo).

Configurar um cluster de usuários para registros particulares

Com clusters de usuários, a configuração do registro particular é especificada na especificação de recurso do cluster. Além disso, para clusters de usuários, é necessário armazenar as credenciais do registro particular em um secret:

1. Crie um secret do Kubernetes do tipo kubernetes.io/dockerconfigjson para as credenciais do registro:

   Se você quiser definir o escopo do secret para um namespace específico, adicione a flag --namespace ao comando abaixo para especificar o nome do namespace.

   kubectl create secret docker-registry CREDS_SECRET_NAME \
       --from-file=.dockerconfigjson=CREDENTIALS_FILE_PATH \
       --kubeconfig=ADMIN_KUBECONFIG
   

   Substitua:

   • CREDS_SECRET_NAME: o nome do secret.

   • CREDENTIALS_FILE_PATH: o caminho do arquivo de configuração do Docker. Por exemplo, /root/.docker/config.json.

   O secret vai ser semelhante ao exemplo abaixo:

   apiVersion: v1
   data:
     .dockerconfigjson: ewoJImF1dGhzIjogewoJ...clpYSXdNak14IgoJCX0KCX0KfQ==
   kind: Secret
   metadata:
     creationTimestamp: "2024-04-28T22:06:06Z"
     name: private-registry-secret
     namespace: default
     resourceVersion: "5055821"
     ...
     annotations:
       ...
       baremetal.cluster.gke.io/mark-source: "true"
   type: kubernetes.io/dockerconfigjson
   

   Se o secret não estiver no mesmo namespace do cluster, adicione a anotação baremetal.cluster.gke.io/mark-source: "true", conforme mostrado no exemplo anterior.

2. Se aplicável, armazene o certificado de CA do registro em um secret.

   A resposta será semelhante a:

   apiVersion: v1
   kind: Secret
   metadata:
     annotations:
       baremetal.cluster.gke.io/mark-source: "true"
     name: ca-9dd74fd308bac6df562c7a7b220590b5
     namespace: some-namespace
   type: Opaque
   data:
     ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUR2RENDQXFTZ0F3SUJBZ0lVQi
     3UGxjUzVFVk8vS0xuYjZiMHRhRFVleXJvd0RRWUpLb1pJaHZjTkFRRUwKQlFBd2ZqRUxNQWtHQ
     ...
     QnpPTkxTRFZJVk5LMm9YV1JvNEpJY0ZoNFZ4MWRMRHpqMldEaHhrUEljWEhLdGR3dk5iS2tocU
     LUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
     ```
   

3. Edite o arquivo de configuração do cluster de usuário para ativar e configurar o registro privado:

   1. Para clusters da versão 1.29, adicione a anotação Preview preview.baremetal.cluster.gke.io/private-registry: "enable" para ativar o recurso. Para clusters da versão 1.30 e mais recentes, o recurso de registro particular é ativado por padrão.

      apiVersion: baremetal.cluster.gke.io/v1
      kind: Cluster
      metadata:
        name: user-basic
        namespace: cluster-user-basic
        resourceVersion: "766027"
        annotations:
          ...
          preview.baremetal.cluster.gke.io/private-registry: "enable"
      ...
      

   2. Na seção nodeConfig do arquivo de configuração do cluster de usuário, adicione o bloco privateRegistries:

      apiVersion: baremetal.cluster.gke.io/v1
      kind: Cluster
      metadata:
        name: user-basic
      ...
      spec:
        bypassPreflightCheck: false
      ...
        nodeConfig:
          containerRuntime: containerd
          podDensity:
            maxPodsPerNode: 250
          privateRegistries:
          - caCertSecretRef:
              name: CA_CERT_SECRET_NAME
              namespace: CA_CERT_SECRET_NAMESPACE
            host: REGISTRY_HOST
            pullCredentialSecretRef:
              name: CREDS_SECRET_NAME
              namespace: CREDS_SECRET_NAMESPACE
      

   Substitua:

   • CA_CERT_SECRET_NAME: o nome do secret que você criou para armazenar o certificado da AC. Se você não criou esse secret, remova o bloco caCertSecretRef.

   • CA_CERT_SECRET_NAMESPACE: o nome do namespace do secret do certificado de AC, se você o criou.

   • REGISTRY_HOST: o nome de domínio ou endereço IP do registro particular e a porta. Por exemplo, 10.200.0.2:5007.

   • CREDS_SECRET_NAME: o nome do secreto do tipo kubernetes.io/dockerconfigjson para as credenciais do registro.

   • CREDS_SECRET_NAMESPACE: o nome do namespace do secret para as credenciais do registro.

4. Aplique as mudanças ao cluster:

   bmctl update cluster -c USER_CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
   

   Substitua:

   • USER_CLUSTER_NAME: o nome do cluster que você está atualizando.

   • ADMIN_KUBECONFIG: caminho do arquivo kubeconfig do cluster de administrador.