Configure nós para autenticação num registo privado

Pode configurar o cluster do Google Distributed Cloud para que os respetivos nós de trabalho possam usar registos privados, incluindo o Artifact Registry. Os registos privados ao nível do nó destinam-se a ser usados com as suas cargas de trabalho para lhe dar mais controlo sobre as obtenções de imagens e a respetiva segurança. Quando configura um cluster com os registos privados, conforme descrito neste documento, o Google Distributed Cloud atualiza a configuração do containerd em conformidade. Depois de o cluster estar configurado, todos os pods em nós qualificados podem usar os registos sem ter de especificar imagePullSecrets na especificação do pod.

Esta funcionalidade pode ser ativada ou desativada em qualquer altura no ciclo de vida do cluster.

A lista seguinte mostra a fase de lançamento desta funcionalidade por versão:

Pré-requisitos

1.30 e posteriores

Para usar esta funcionalidade de GA, o seu cluster tem de cumprir os seguintes requisitos:

  • A versão do cluster tem de ser 1.30 ou posterior.
  • A versão do conjunto de nós tem de ser 1.29 ou posterior (um cluster 1.30 pode ter conjuntos de nós na versão 1.28, mas a funcionalidade só funciona para conjuntos de nós na versão 1.29 ou posterior).

  • Esta funcionalidade destina-se a clusters de utilizadores e clusters de gestão autónoma (híbridos e autónomos) com pools de nós de trabalho, conforme mostrado na tabela seguinte:

    Modelo de implementação Tipos de clusters suportados
    Implementação de clusters de administrador e de utilizador

    Cluster de administração

    User cluster 1

    Cluster de utilizadores 2
    Implementação de clusters híbridos

    Cluster híbrido

    User cluster 1

    Cluster de utilizadores 2
    Implementação de cluster autónomo

    Cluster autónomo

1,29

Para usar esta funcionalidade de pré-visualização, o seu cluster tem de cumprir os seguintes requisitos:

  • A versão do cluster tem de ser 1.29.
  • A versão do conjunto de nós tem de ser 1.29 (nem todos os conjuntos de nós têm de estar na versão 1.29, mas a funcionalidade só funciona para conjuntos de nós na versão 1.29).
  • O cluster tem de ter a anotação da funcionalidade de preview.baremetal.cluster.gke.io/private-registry: "enable" pré-visualização.

  • Esta funcionalidade destina-se a clusters de utilizadores e clusters de gestão autónoma (híbridos e autónomos) com pools de nós de trabalho, conforme mostrado na tabela seguinte:

    Modelo de implementação Tipos de clusters suportados
    Implementação de clusters de administrador e de utilizador

    Cluster de administração

    User cluster 1

    Cluster de utilizadores 2
    Implementação de clusters híbridos

    Cluster híbrido

    User cluster 1

    Cluster de utilizadores 2
    Implementação de cluster autónomo

    Cluster autónomo

Configure um cluster de autogestão para registos privados

Para configurar um cluster autónomo ou híbrido para usar registos privados ao nível do nó:

  1. Edite o ficheiro de configuração do cluster para adicionar o bloco privateRegistries na secçã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 o seguinte:

    • REGISTRY_HOST: o nome do domínio ou o endereço IP do registo privado e a porta. Por exemplo: 10.200.0.2:5007.

    • CA_CERT_PATH: o caminho do ficheiro de certificado da CA (CA raiz do servidor). Por exemplo: /root/cert.pem. Se o seu registo privado não exigir um certificado TLS privado, pode omitir este campo.

    • CREDENTIALS_FILE_PATH: o caminho do ficheiro de configuração, config.json (por exemplo, $HOME/.docker/config.json). Para autenticar o containerd para aceder ao seu registo privado, config.json tem de conter uma versão codificada em base64 das suas credenciais na secção auths do ficheiro.

      Para o Artifact Registry, faça a autenticação através de uma chave JSON de conta de serviço com os seguintes valores:

      • username: _json_key
      • password: todo o conteúdo do ficheiro de chave JSON da conta de serviço. Inclua o conteúdo da chave JSON colado entre aspas simples (') para evitar erros de análise.

      Para mais informações sobre como gerar este ficheiro, consulte o artigo Configure a autenticação no Artifact Registry para o Docker na documentação do Artifact Registry.

      Para outros registos privados, a string auth codificada em base64 é normalmente formada a partir de USERNAME:PASSWORD, usando as credenciais específicas do seu registo. Se o seu servidor de registo privado não exigir credenciais para autenticação, pode omitir o campo pullCredentialConfigPath.

      Para proteger dados confidenciais, pode usar chown e chmod para restringir o acesso ao ficheiro de configuração.

  2. Aplique as alterações ao cluster:

    bmctl update cluster -c CLUSTER_NAME --kubeconfig=CLUSTER_KUBECONFIG

    Substitua o seguinte:

    • CLUSTER_NAME: o nome do cluster que quer atualizar.

    • CLUSTER_KUBECONFIG: caminho do ficheiro kubeconfig do cluster autogerido (híbrido ou autónomo).

Configure um cluster de utilizadores para registos privados

Com os clusters de utilizadores, a configuração do registo privado é especificada na especificação do recurso user cluster, que se encontra no cluster de administrador. Além disso, tem de armazenar as credenciais do registo privado num Secret, que também se encontra no cluster de administrador:

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

    Se quiser restringir o âmbito do segredo a um espaço de nomes específico, adicione a flag --namespace ao seguinte comando para especificar o nome do espaço de nomes. Se o segredo não estiver no mesmo espaço de nomes que o cluster, adicione a anotação baremetal.cluster.gke.io/mark-source: "true", conforme mostrado no exemplo no final deste passo.

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

    Substitua o seguinte:

    • CREDS_SECRET_NAME: o nome do seu segredo.

    • CREDENTIALS_FILE_PATH: o caminho do ficheiro de configuração, config.json (por exemplo, $HOME/.docker/config.json). Para autenticar o containerd para aceder ao seu registo privado, config.json tem de conter uma versão codificada em base64 das suas credenciais na secção auths do ficheiro.

      Para o Artifact Registry, faça a autenticação através de uma chave JSON de conta de serviço com os seguintes valores:

      • username: _json_key
      • password: todo o conteúdo do ficheiro de chave JSON da conta de serviço. Inclua o conteúdo da chave JSON colado entre aspas simples (') para evitar erros de análise.

      Para mais informações sobre como gerar este ficheiro, consulte o artigo Configure a autenticação no Artifact Registry para o Docker na documentação do Artifact Registry.

      Para outros registos privados, a string auth codificada em base64 é normalmente formada a partir de USERNAME:PASSWORD, usando as credenciais específicas do seu registo. Se o seu servidor de registo privado não exigir credenciais para autenticação, pode omitir o campo pullCredentialSecretRef.

      Para proteger dados confidenciais, pode usar chown e chmod para restringir o acesso ao ficheiro de configuração.

    O seu segredo deve ser semelhante ao seguinte exemplo:

    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

  2. Se aplicável, armazene o certificado de AC para o registo num segredo.

    O segredo tem um aspeto semelhante ao seguinte:

    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 ficheiro de configuração do cluster de utilizadores para ativar e configurar o registo privado:

    1. Apenas para clusters da versão 1.29, adicione a anotação da funcionalidade Preview preview.baremetal.cluster.gke.io/private-registry: "enable" para ativar a funcionalidade. Para clusters da versão 1.30 e posteriores, a funcionalidade de registo privado está ativada por predefiniçã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 secção nodeConfig do ficheiro de configuração do cluster de utilizadores, 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 o seguinte:

    • CA_CERT_SECRET_NAME: o nome do segredo que criou para armazenar o certificado da AC. Se não criou este segredo, remova o bloco caCertSecretRef.

    • CA_CERT_SECRET_NAMESPACE: o nome do espaço de nomes para o segredo do certificado da AC, se o tiver criado.

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

    • CREDS_SECRET_NAME: o nome do segredo do tipo kubernetes.io/dockerconfigjson para as credenciais de registo.

    • CREDS_SECRET_NAMESPACE: o nome do espaço de nomes para o segredo das credenciais do registo.

  4. Aplique as alterações ao cluster:

    bmctl update cluster -c USER_CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG

    Substitua o seguinte:

    • USER_CLUSTER_NAME: o nome do cluster que está a atualizar.

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