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

É possível configurar seu cluster do Google Distributed Cloud para que os nós de trabalho dele possam usar registros particulares. Registros privados no nível do nó destinam-se ao uso com suas cargas de trabalho para oferecer mais controle sobre extrações de imagens e a segurança relacionada. Quando você configura um cluster com os registros particulares conforme descrito neste documento, o Google Distributed Cloud atualiza a configuração do containerd adequadamente. Após a configuração do cluster, todos os pods em nós qualificados poderão usar os registros sem precisar especificar imagePullSecrets na especificação do pod.

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

Pré-requisitos

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

  • Esse recurso é destinado a clusters de usuários e clusters autogerenciados (híbridos e independentes) com pools de nós de trabalho.
  • A versão do cluster precisa ser 1.29.
  • A versão do pool de nós precisa ser a 1.29. Nem todos os pools de nós precisam estar na versão 1.29, mas o recurso só funciona com a versão 1.29.
  • O cluster precisa ter a anotação de recurso de visualização preview.baremetal.cluster.gke.io/private-registry: "enable".

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"
        ...
    spec:
      type: hybrid
      ...
    

    Substitua:

    • REGISTRY_HOST: o nome de domínio ou endereço IP do registro particular e a 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, será possível omitir esse campo.

    • CREDENTIALS_FILE_PATH: o caminho do arquivo que contém as credenciais para acessar o registro particular. 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 alterações 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ário para registros particulares

Com clusters de usuário, a configuração do registro particular é definida na especificação do recurso do cluster. Além disso, para clusters de usuário, você precisa armazenar as credenciais de 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.

    Seu secret será semelhante ao exemplo a seguir:

    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 que o 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 chave secreta é semelhante a esta:

    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 particular:

    1. Adicione a anotação preview.baremetal.cluster.gke.io/private-registry: "enable" para ativar o registro particular enquanto ele estiver em Visualizaçã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 de 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 secret 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 alterações 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.