Créer des règles pour un cluster mutualisé

Ce tutoriel explique comment utiliser Config Sync et Kustomize pour configurer des règles pour les espaces de noms dans un cluster mutualisé.

Dans Kubernetes, un locataire peut être une équipe ou une charge de travail. Pour les clusters mutualisés, il est recommandé de créer un espace de noms pour chaque locataire. Ensuite, chaque espace de noms peut avoir des règles adaptées à ses différents besoins. Vous pouvez utiliser Config Sync pour appliquer ces règles de manière cohérente à chacun de vos différents locataires.

Architecture du dépôt

Dans ce tutoriel, vous allez configurer Config Sync pour qu'il se synchronise avec les configurations du répertoire namespace-specific-policy/ du dépôt d'exemples Anthos Config Management. Le répertoire contient les répertoires et fichiers suivants :

├── configsync
│   ├── tenant-a
│   │   ├── ~g_v1_namespace_default.yaml
│   │   ├── networking.k8s.io_v1_networkpolicy_deny-all.yaml
│   │   ├── rbac.authorization.k8s.io_v1_rolebinding_tenant-admin-rolebinding.yaml
│   │   └── rbac.authorization.k8s.io_v1_role_tenant-admin.yaml
│   ├── tenant-b
│   │   ├── ~g_v1_namespace_default.yaml
│   │   ├── networking.k8s.io_v1_networkpolicy_deny-all.yaml
│   │   ├── rbac.authorization.k8s.io_v1_rolebinding_tenant-admin-rolebinding.yaml
│   │   └── rbac.authorization.k8s.io_v1_role_tenant-admin.yaml
│   └── tenant-c
│       ├── ~g_v1_namespace_default.yaml
│       ├── networking.k8s.io_v1_networkpolicy_deny-all.yaml
│       ├── rbac.authorization.k8s.io_v1_rolebinding_tenant-admin-rolebinding.yaml
│       └── rbac.authorization.k8s.io_v1_role_tenant-admin.yaml
├── configsync-src
│   ├── base
│   │   ├── kustomization.yaml
│   │   ├── namespace.yaml
│   │   ├── networkpolicy.yaml
│   │   ├── rolebinding.yaml
│   │   └── role.yaml
│   ├── tenant-a
│   │   └── kustomization.yaml
│   ├── tenant-b
│   │   └── kustomization.yaml
│   └── tenant-c
│       └── kustomization.yaml
├── README.md
└── scripts
    └── render.sh

Ce dépôt est un dépôt non structuré. Cela vous donne la possibilité d'organiser vos configurations comme vous le souhaitez, ce qui est particulièrement utile lorsque vous travaillez avec Kustomize.

Ce dépôt contient trois espaces de noms pour trois locataires différents : tenant-a, tenant-b et tenant-c. Chacun des répertoires d'espaces de noms contient des configurations pour les objets Role, RoleBinding et NetworkPolicy. Le répertoire configsync- src contient la configuration au format kustomize. Le répertoire configconfig-src contient la configuration au format Kustomize. Il y a une base et trois superpositions tenant-a, tenant-b et tenant-c.

Objectifs

  • Mettre à jour une superposition Kustomize

  • Créer un cluster que vous pouvez utiliser avec Config Sync

  • Synchroniser les stratégies de votre dépôt Git avec un cluster

  • Vérifier que le cluster se synchronise avec les configurations de votre dépôt

Coûts

Ce tutoriel utilise les composants facturables suivants de Google Cloud :

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Une fois que vous avez terminé ce tutoriel, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées. Consultez la page Effectuer un nettoyage pour en savoir plus.

Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Avant de commencer

Avant de commencer ce tutoriel, effectuez les tâches suivantes :

  1. Dans Google Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud.

    Accéder au sélecteur de projet

  2. Assurez-vous que la facturation est activée pour votre projet Cloud. Découvrez comment vérifier que la facturation est activée pour votre projet.

  3. Créer un compte GitHub ou y avoir accès
  4. Installer Kustomize en exécutant la commande suivante :

    gcloud components install kustomize
    

Il est également utile de se familiariser avec Git et Kustomize.

Mettre à jour un fichier Kustomize

Dans la section suivante, vous allez mettre à jour un fichier Kustomize dans votre dépôt pour mettre à jour les stratégies appliquées à tenant-a.

Préparer votre environnement

Pour préparer votre environnement, procédez comme suit :

  1. Dupliquez le dépôt :

    1. Accédez au répertoire d'exemples Anthos Config Management dans GitHub.
    2. Cliquez sur Fork (Dupliquer).
  2. Clonez le dépôt dupliqué :

    git clone https://github.com/GITHUB_USERNAME/anthos-config-management-samples
    

    Remplacez GITHUB_USERNAME par votre nom d'utilisateur GitHub.

  3. Accédez au répertoire qui contient les exemples utilisés dans ce tutoriel :

    cd anthos-config-management-samples/namespace-specific-policy
    

Mettre à jour une superposition

Dans cette section, vous allez mettre à jour une superposition. Une superposition est un kustomization qui dépend d'un autre kustomization.

Les étapes suivantes vous montrent comment attribuer un nouveau rôle à tenant-a en mettant à jour sa superposition : acm-samples/namespace-specific-policy/configsync-src/tenant-a. Étant donné que vous ne mettez à jour qu'une seule configuration, il vous suffit de mettre à jour une seule superposition.

Pour attribuer ce nouveau rôle à tenant-a, procédez comme suit :

  1. Créez un fichier en accédant à la page suivante dans GitHub :

    github.com/GITHUB_USERNAME/anthos-config-management-samples/new/main/namespace-specific-policy/configsync-src/tenant-a
    
  2. Nommez votre fichier another-role.yaml.

  3. Dans la fenêtre Modifier le fichier, collez le fichier manifeste suivant pour le nouveau rôle :

    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: pod-reader
    rules:
    - apiGroups: [""]
      resources: ["pods"]
      verbs: ["get", "watch", "list"]
    
  4. Cliquez sur Effectuer un commit du nouveau fichier.

    Vous pouvez maintenant inclure la configuration du nouveau rôle dans le fichier kustomization.yaml.

  5. Dans le dossier /namespace-specific-policy/configsync-src/tenant-a, ouvrez kustomization.yaml et cliquez sur l'icône de modification (icône en forme de crayon).

  6. Dans la section Ressources de kustomization.yaml, ajoutez - another-role.yaml :

    namespace: tenant-a
    
    resources:
    - ../base
    - another-role.yaml
    # The rest of the file is omitted
    
  7. Cliquez sur Valider les modifications.

  8. Après la mise à jour, recompilez le résultat Kustomize pour chaque espace de noms en exécutant le script render.sh :

    ./scripts/render.sh
    
  9. Validez et transférez le commit de la mise à jour :

    git add .
    git commit -m 'update configuration'
    git push
    

Créer et enregistrer un cluster GKE

Dans cette section, vous allez créer et configurer un cluster que vous pouvez utiliser avec Config Sync.

Créer un cluster

Console

Pour créer un cluster à l'aide de Google Cloud Console, procédez comme suit :

  1. Accédez au menu Google Kubernetes Engine de Cloud Console.

    Accéder à Google Kubernetes Engine

  2. Cliquez sur Créer.

  3. Dans la section Standard, cliquez sur Configurer.

  4. Dans la section Paramètres de base du cluster, procédez comme suit :

    1. Saisissez mt-cluster comme nom du cluster.
    2. Dans la liste déroulante Zone, sélectionnez us-central1-c.
    3. Conservez les valeurs par défaut recommandées dans tous les autres champs.
  5. Dans le menu de gauche, cliquez sur default-pool, puis sur Nœuds dans la liste déroulante qui s'affiche.

  6. Dans la section Nœuds, procédez comme suit :

    1. Dans la liste déroulante Type de machine, sélectionnez e2-standard-4.
    2. Laissez les valeurs par défaut de tous les autres champs.
  7. Dans le menu de gauche, sélectionnez Sécurité.

  8. Dans la section Sécurité, cochez la case Activer Workload Identity.

  9. Cliquez sur Create (Créer). La création du cluster peut prendre plusieurs minutes.

gcloud

Pour créer un cluster avec l'outil de ligne de commande gcloud, procédez comme suit :

gcloud container clusters create mt-cluster \
    --project PROJECT_ID \
    --zone us-central1-c \
    --release-channel regular \
    --machine-type "e2-standard-4" \
    --workload-pool=PROJECT_ID.svc.id.goog

Remplacez PROJECT_ID par l'ID du projet.

Obtenir des informations d'authentification pour le cluster

Après avoir créé votre cluster, vous devez obtenir des informations d'authentification pour interagir avec lui :

gcloud container clusters get-credentials mt-cluster --zone us-central1-c

Obtenir les autorisations d'administrateur

Une fois votre cluster créé, accordez-vous le rôle d'administrateur GKE Hub dont vous avez besoin pour Config Sync.

Console

Pour vous accorder des autorisations d'administrateur avec Google Cloud Console, procédez comme suit :

  1. Dans Cloud Console, accédez à la page IAM.

    Accédez à la page IAM.

  2. Cliquez sur Ajouter.

  3. Dans le champ Nouveaux membres, saisissez une adresse e-mail. Vous pouvez ajouter des personnes, des comptes de service ou des groupes Google en tant que membres.

  4. Dans la liste déroulante Sélectionner un rôle, recherchez et sélectionnez Administrateur de hub GKE.

  5. Cliquez sur Enregistrer.

gcloud

Pour vous accorder des autorisations d'administrateur avec l'outil de ligne de commande gcloud, procédez comme suit :

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=roles/gkehub.admin

Remplacez l'élément suivant :

  • PROJECT_ID : ID de votre projet.
  • MEMBER : identifiant du membre, généralement au format suivant : member-type :id, par exemple user:my-user@example.com. Pour obtenir la liste complète des valeurs possibles pour member, consultez la documentation de référence sur les liaisons de stratégie.

Enregistrer votre cluster

Une fois le cluster créé, vous pouvez l'enregistrer dans un parc.

Console

Pour enregistrer votre cluster dans Google Cloud Console, procédez comme suit :

  1. Dans Google Cloud Console, accédez à la page Clusters Anthos.

    Accéder à la page "Clusters Anthos"

  2. Cliquez sur Enregistrer un cluster existant.

  3. À côté de mt-cluster, cliquez sur Enregistrer. Si vous ne voyez pas ce cluster dans la liste, assurez-vous qu'il a bien été créé.

    Exemple de résultat :

    Cluster mt-cluster registered successfully as mt-cluster in project PROJECT_NAME.
    

gcloud

Pour enregistrer votre cluster à l'aide de l'outil de ligne de commande gcloud, procédez comme suit :

gcloud beta container hub memberships register MEMBERSHIP_NAME \
 --gke-cluster=us-central1-c/mt-cluster \
 --enable-workload-identity

Remplacez l'élément suivant :

  • MEMBERSHIP_NAME : nom d'appartenance que vous choisissez pour représenter de manière unique le cluster enregistré dans une Fleet.

Configurer Config Sync

Dans cette section, vous allez configurer Config Sync afin qu'il se synchronise avec les règles du répertoire namespace-specific-policy/.

Pour configurer Config Sync, procédez comme suit :

Console

Pour configurer Config Sync avec Google Cloud Console, procédez comme suit :

  1. Dans Cloud Console, accédez à la page Anthos Config Management.

    Accéder à la page "Anthos Config Management"

  2. Sélectionnez mt-cluster, puis cliquez sur Configurer.

  3. Dans la section Authentification auprès du dépôt Git pour ACM, sélectionnez Aucune, puis cliquez sur Continuer.

  4. Dans la section Paramètres ACM pour vos clusters, procédez comme suit :

    1. Dans le champ Version, sélectionnez la version 1.7 ou ultérieure.
    2. Cochez la case Activer Config Sync et renseignez les champs suivants :
      1. Dans le champ URL, saisissez https://github.com/GITHUB_USERNAME/anthos-config-management-samples.
      2. Dans le champ Branche, saisissez main.
      3. Dans le champ Tag/Commit, saisissez HEAD.
      4. Dans le champ Répertoire des règles, saisissez namespace-specific-policy/configsync.
      5. Laissez le champ Délai entre les synchronisations vide.
      6. Laissez le champ Proxy Git vide.
      7. Dans la liste déroulante Format source, sélectionnez non structuré.
  5. Cliquez sur OK. Vous êtes redirigé vers la page Anthos Config Management. Après quelques minutes, Synced devrait apparaître dans la colonne d'état à côté du cluster que vous avez configuré.

gcloud

Pour configurer Config Sync avec l'outil de ligne de commande gcloud, procédez comme suit :

  1. Créez un fichier nommé apply-spec.yaml et copiez-y le fichier YAML ci-dessous :

    # apply-spec.yaml
    
    applySpecVersion: 1
    spec:
      configSync:
        # Set to true to install and enable Config Sync
        enabled: true
        sourceFormat: unstructured
        syncRepo: https://github.com/GITHUB_USERNAME/anthos-config-management-samples
        syncBranch: main
        secretType: none
        policyDir: namespace-specific-policy/configsync
    

    Remplacez GITHUB_USERNAME par votre nom d'utilisateur GitHub.

  2. Appliquez le fichier apply-spec.yaml :

     gcloud beta container hub config-management apply \
         --membership=MEMBERSHIP_NAME \
         --config=CONFIG_YAML_PATH \
         --project=PROJECT_ID
    

    Remplacez l'élément suivant :

    • MEMBERSHIP_NAME : nom de l'appartenance que vous avez choisi lors de l'enregistrement de votre cluster, vous pouvez trouver le nom avec gcloud container hub memberships list.
    • CONFIG_YAML_PATH : chemin d'accès à votre fichier apply-spec.yaml
    • PROJECT_ID : ID de votre projet.

Vérifier la synchronisation des règles spécifiques à l'espace de noms

Maintenant que vous avez installé Config Sync, vous pouvez vérifier que les règles spécifiques à l'espace de noms sont synchronisées avec votre cluster à l'aide de la commande nomos status :

nomos status

Un résultat semblable aux lignes suivantes doit s'afficher :

gke_PROJECT_ID_us-central1-c_mt-cluster
  --------------------
  <root>   https:/github.com/GITHUB_USERNAME/anthos-config-management-samples/namespace-specific-policy/configsync@main
  SYNCED   bf8655aa
  Managed resources:
     NAMESPACE   NAME                                                             STATUS
                 namespace/foo                                                    Current
                 namespace/istio-system                                           Current
                 namespace/tenant-a                                               Current
                 namespace/tenant-b                                               Current
                 namespace/tenant-c                                               Current
     tenant-a    networkpolicy.networking.k8s.io/deny-all                         Current
     tenant-a    role.rbac.authorization.k8s.io/tenant-admin                      Current
     tenant-a    rolebinding.rbac.authorization.k8s.io/tenant-admin-rolebinding   Current
     tenant-b    networkpolicy.networking.k8s.io/deny-all                         Current
     tenant-b    role.rbac.authorization.k8s.io/tenant-admin                      Current
     tenant-b    rolebinding.rbac.authorization.k8s.io/tenant-admin-rolebinding   Current
     tenant-c    networkpolicy.networking.k8s.io/deny-all                         Current
     tenant-c    role.rbac.authorization.k8s.io/tenant-admin                      Current
     tenant-c    rolebinding.rbac.authorization.k8s.io/tenant-admin-rolebinding   Current

Ensuite, vérifiez que les ressources existent bien sur le cluster. Les exemples suivants vous montrent comment vérifier certaines des ressources pour tenant-a.

  1. Vérifiez que l'objet RoleBinding pour tenant-a existe :

    kubectl get RoleBinding/tenant-admin-rolebinding -n tenant-a
    

    Exemple de résultat :

    NAME                       ROLE                AGE
    tenant-admin-rolebinding   Role/tenant-admin   23h
    
  2. Vérifiez que le rôle pour tenant-a existe :

    kubectl get Role/tenant-admin -n tenant-a
    

    Exemple de résultat :

    NAME           CREATED AT
    tenant-admin   2021-05-24T21:49:06Z
    
  3. Vérifiez que la règle NetworkPolicy pour tenant-a existe :

    kubectl get NetworkPolicy/deny-all -n tenant-a
    

    Exemple de résultat :

    NAME       POD-SELECTOR   AGE
    deny-all   <none>         23h
    

En utilisant ces commandes, vous pouvez voir que chaque espace de noms dispose de son propre ensemble de règles, conformément aux bonnes pratiques concernant les clusters mutualisés.

Nettoyer

Pour éviter que les ressources utilisées lors de ce tutoriel soient facturées sur votre compte Google Cloud, supprimez le projet contenant les ressources, ou conservez le projet et les ressources individuelles.

Supprimer le projet

  1. Dans Cloud Console, accédez à la page Gérer les ressources.

    Accéder à la page Gérer les ressources

  2. Dans la liste des projets, sélectionnez le projet que vous souhaitez supprimer, puis cliquez sur Supprimer.
  3. Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez sur Arrêter pour supprimer le projet.

Supprimer le répertoire

Pour nettoyer les espaces de noms et les règles des locataires, nous vous recommandons de supprimer les répertoires contenant leur configuration de votre dépôt Git :

rm -r acm-samples/namespace-specific-policy/configsync/tenant-*/*
git add .
git commit -m 'clean up'
git push

Lorsque le dernier commit du dépôt racine est synchronisé, les trois espaces de noms tenant-a, tenant-b et tenant-c sont supprimés du cluster.

Étape suivante