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.