Configurer les nœuds pour s'authentifier auprès d'un registre privé

Vous pouvez configurer votre cluster Google Distributed Cloud de sorte que ses nœuds de calcul puissent utiliser des registres privés. Les registres privés au niveau du nœud sont conçus pour être utilisés avec vos charges de travail. Ils vous permettent de mieux contrôler les extractions d'images et leur sécurité associée. Lorsque vous configurez un cluster avec des registres privés comme décrit dans ce document, Google Distributed Cloud met à jour la configuration containerd en conséquence. Une fois votre cluster configuré, tous les pods des nœuds qualifiés peuvent utiliser les registres sans avoir à spécifier imagePullSecrets dans la spécification des pods.

Cette fonctionnalité peut être activée ou désactivée à tout moment du cycle de vie du cluster.

Prérequis

Pour que vous puissiez utiliser cette fonctionnalité en version preview, votre cluster doit répondre aux exigences suivantes:

  • Cette fonctionnalité est destinée aux clusters d'utilisateur et aux clusters autogérés (hybrides et autonomes) avec des pools de nœuds de calcul.
  • La version du cluster doit être 1.29.
  • La version du pool de nœuds doit être 1.29 (tous les pools de nœuds ne doivent pas nécessairement avoir la version 1.29, mais cette fonctionnalité ne fonctionne que pour les pools de nœuds version 1.29).
  • Le cluster doit comporter l'annotation de fonctionnalité d'aperçu preview.baremetal.cluster.gke.io/private-registry: "enable".

Configurer un cluster auto-géré pour les registres privés

Pour configurer un cluster autonome ou hybride afin d'utiliser des registres privés au niveau du nœud:

  1. Modifiez le fichier de configuration du cluster pour ajouter le bloc privateRegistries dans la section des identifiants:

    ---
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
  ...

    Remplacez les éléments suivants :

    • REGISTRY_HOST: nom de domaine ou adresse IP du registre privé et du port. Exemple : 10.200.0.2:5007.

    • CA_CERT_PATH: chemin d'accès au fichier de certificat CA (autorité de certification racine du serveur). Exemple : /root/cert.pem. Si votre registre privé ne nécessite pas de certificat TLS privé, vous pouvez omettre ce champ.

    • CREDENTIALS_FILE_PATH: chemin du fichier contenant les identifiants permettant d'accéder à votre registre privé. Exemple : /root/.docker/config.json. Si votre serveur de registre privé ne nécessite pas d'identifiants pour l'authentification, vous pouvez omettre ce champ.

  2. Appliquez les modifications à votre cluster:

    bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster que vous souhaitez mettre à jour.

    • ADMIN_KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster d'administrateur.

Configurer un cluster d'utilisateur pour des registres privés

Avec les clusters d'utilisateur, la configuration du registre privé est spécifiée dans les spécifications de ressources de cluster. De plus, pour les clusters d'utilisateur, vous devez stocker les identifiants du registre privé dans un secret:

  1. Créez un secret Kubernetes de type kubernetes.io/dockerconfigjson pour les identifiants du registre:

    Si vous souhaitez étendre le champ d'application du secret à un espace de noms spécifique, ajoutez l'option --namespace à la commande suivante pour spécifier le nom de l'espace de noms.

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

    Remplacez les éléments suivants :

    • CREDS_SECRET_NAME : nom de votre secret.

    • CREDENTIALS_FILE_PATH: chemin d'accès au fichier de configuration Docker. Exemple :/root/.docker/config.json

    Votre secret doit ressembler à l'exemple suivant:

    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

    Si le secret ne se trouve pas dans le même espace de noms que le cluster, ajoutez l'annotation baremetal.cluster.gke.io/mark-source: "true", comme indiqué dans l'exemple précédent.

  2. Le cas échéant, stockez le certificat CA pour le registre dans un secret.

    Le secret se présente comme suit:

    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. Modifiez le fichier de configuration du cluster d'utilisateur pour activer et configurer le registre privé:

    1. Ajoutez l'annotation preview.baremetal.cluster.gke.io/private-registry: "enable" pour activer le registre privé lorsqu'il est en Preview.

      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. Dans la section nodeConfig du fichier de configuration du cluster d'utilisateur, ajoutez le bloc 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

    Remplacez les éléments suivants :

    • CA_CERT_SECRET_NAME: nom du secret que vous avez créé pour stocker le certificat CA. Si vous n'avez pas créé ce secret, supprimez le bloc caCertSecretRef.

    • CA_CERT_SECRET_NAMESPACE: nom de l'espace de noms pour le secret du certificat CA, si vous l'avez créé.

    • REGISTRY_HOST: nom de domaine ou adresse IP du registre privé et du port. Exemple : 10.200.0.2:5007.

    • CREDS_SECRET_NAME: nom du secret de type kubernetes.io/dockerconfigjson pour les identifiants du registre.

    • CREDS_SECRET_NAMESPACE: nom de l'espace de noms du secret pour les identifiants de registre.

  4. Appliquez les modifications à votre cluster:

    bmctl update cluster -c USER_CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG

    Remplacez les éléments suivants :

    • USER_CLUSTER_NAME: nom du cluster que vous mettez à jour.

    • ADMIN_KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster d'administrateur.