26. Amorcer une configuration multizone

Durée estimée : 3 heures

Propriétaire du composant exploitable : MZ

Profil de compétences : ingénieur de déploiement

26.1. Présentation

L'amorçage multizone implique la configuration du plan de contrôle global racine. La première zone d'un univers établit le plan de contrôle global. D'autres zones rejoignent le plan de contrôle mondial. Rejoindre un plan de contrôle mondial est plus complexe que d'établir le plan de contrôle, car une relation de confiance doit être établie entre le plan de contrôle mondial de l'univers et la nouvelle zone. Lorsque vous rejoignez un plan de contrôle mondial, deux zones sont impliquées :

• Zone d'ancrage : zone qui fait déjà partie du plan de contrôle mondial. Il doit s'agir de la zone dont l'instance GitLab est utilisée pour appliquer les modifications d'infrastructure en tant que code (IaC) à l'API globale de l'univers.
• Zone de connexion : zone qui se connecte au plan de contrôle mondial.

Vous avez amorcé la première zone de l'univers dans Initialize multi-zone. Cette zone sert de zone d'ancrage lorsque d'autres zones rejoignent l'univers.

Si une API globale existe déjà dans l'univers et que vous amorcez une zone qui rejoint l'univers, procédez comme suit.

26.2. Amorcer plusieurs zones dans des zones rejoignant un univers

Avant de continuer, vérifiez que vous avez amorcé le multizone dans la zone d'ancrage.

26.2.1. Démarrer le conteneur d'outil d'E/S

Pour des raisons de sécurité et d'auditabilité, le processus d'amorçage multizone doit être effectué à l'aide d'identifiants personnels pour accéder à Kubernetes (et non à une configuration Kubernetes d'administrateur) et à l'IaC pour l'approbation multipartite des demandes d'autorisation d'effectuer des actions sensibles. Tous les outils nécessaires pour effectuer les actions d'amorçage sont inclus dans le conteneur d'outils d'E/S. Consultez la procédure de configuration du conteneur d'outil d'E/S OOPS-P0065 pour savoir comment démarrer le conteneur dans l'environnement OIC. Lorsqu'une zone rejoint le plan de contrôle mondial, elle interagit avec deux zones. L'une d'elles (la zone d'ancrage) ne fonctionne pas dans des conditions de jour 0. Des mesures d'authentification et d'autorisation de niveau production doivent donc être utilisées pour s'assurer que la sécurité de la zone d'ancrage n'est pas compromise.

26.2.2. Initialiser le dépôt GitLab

Utilisez les identifiants du fournisseur d'identité (IdP) configuré dans la configuration de l'infrastructure en tant que code et suivez la procédure OOPS-P0066 pour gérer l'accès des utilisateurs GitLab.

Clonez le dépôt IaC de la zone d'ancrage :

git clone https://iac.GLOBAL_DNS_DOMAIN/gdch/iac.git /tmp/iac

Remplacez GLOBAL_DNS_DOMAIN par le domaine DNS de l'univers.

Indiquez le nom d'utilisateur et le mot de passe lorsque vous y êtes invité.

26.2.3. Ajouter les rôles requis

Suivez les instructions du runbook Processus d'accès et d'élévation des privilèges IAM-R0005 pour créer les liaisons de rôle et de cluster-rôle nécessaires :

• Ajoutez une liaison de rôle de cluster avec le rôle de cluster mz-bootstrap-joining-editor dans le cluster root-admin de la zone de jonction.
• Ajoutez une liaison de rôle de cluster avec le rôle de cluster mz-bootstrap-anchor-reader dans le cluster root-admin de la zone d'ancrage.
• Ajoutez une liaison de rôle avec le rôle mz-bootstrap-viewer dans l'espace de noms mz-system de l'API globale de la zone d'ancrage.

26.2.4. Créer une demande de jeton

Lorsqu'une zone rejoint un plan de contrôle mondial, une communication est établie entre la zone qui rejoint le plan et la zone d'ancrage à l'aide d'un jeton d'amorçage de l'API globale. Une demande de jeton est utilisée pour demander un jeton à l'API mondiale dans la zone d'ancrage.

1. Créez une branche pour une demande de fusion :

   cd /tmp/iac
   git checkout -b JOINING_ZONE_NAME-mz-token-request
   

   Remplacez JOINING_ZONE_NAME par le nom de la zone tel qu'il est indiqué dans le questionnaire d'accueil des clients, comme décrit dans la note à la fin de la section.

2. Connectez-vous à la zone de ralliement. Pour en savoir plus, consultez Interface de ligne de commande gdcloud. Cela est nécessaire, car la commande gdcloud de l'étape suivante interagit avec le cluster d'administrateur racine dans la zone de rattachement pour obtenir une paire de clé de chiffrement de clé publique permettant de transférer de manière sécurisée le jeton d'amorçage de la zone d'ancrage vers la zone de rattachement.

3. Générez le fichier YAML de demande de jeton :

   gdcloud system multi-zone create-token-request --cluster root --zone JOINING_ZONE_NAME --client-type api-join --namespace global-kube-system --output-file /tmp/iac/infrastructure/global/orgs/root/mz-token-request.yaml
   

4. Créez ou mettez à jour le fichier kustomization.yaml.

   1. Ouvrez le fichier :

      vim infrastructure/global/orgs/root/kustomization.yaml
      

   2. Si le fichier existait déjà, ajoutez un élément mz-token-request.yaml à la liste resources. Sinon, ajoutez le fichier YAML complet de la ressource :

      Remarque : Utilisez :set paste pour empêcher vim de mettre en forme automatiquement le texte préformaté que vous collez.

      apiVersion: kustomize.config.k8s.io/v1beta1
      kind: Kustomization
      metadata:
        name: global-root-kustomization
      resources:
      - mz-token-request.yaml
      

   3. Enregistrez le fichier et quittez vim.

5. Validez les modifications dans la branche :

   Remarque : Vous devez configurer Git avec votre nom et votre adresse e-mail avant de pouvoir valider les modifications.

   git add infrastructure
   git commit
   

6. Transférez la branche vers GitLab :

   git push
   

7. Faites fusionner les modifications dans la branche main. Pour en savoir plus, consultez le runbook IAC-R0004.

26.2.5. Créer un jeton

Pour créer le jeton d'amorçage dans la zone de connexion, procédez comme suit :

1. Créez une branche pour une demande de fusion :

   cd /tmp/iac
   git checkout main
   git pull --ff-only
   git checkout -b JOINING_ZONE_NAME-mz-token
   

2. Connectez-vous à la zone d'ancrage. Pour en savoir plus, consultez Interface de ligne de commande gdcloud. Cela est nécessaire, car la commande gdcloud de l'étape suivante interagit avec l'API globale dans la zone d'ancrage pour créer et chiffrer un jeton d'amorçage.

3. Générez le fichier YAML du jeton :

   gdcloud system multi-zone create-token --zone JOINING_ZONE_NAME --namespace global-kube-system --output-file /tmp/iac/infrastructure/zonal/zones/JOINING_ZONE_NAME/root-admin/mz-token.yaml
   

4. Créez ou mettez à jour le fichier kustomization.yaml.

   1. Ouvrez le fichier :

      vim infrastructure/zonal/zones/JOINING_ZONE_NAME/root-admin/kustomization.yaml
      

   2. Si le fichier existait déjà, ajoutez un élément mz-token.yaml à la liste resources. Sinon, ajoutez le fichier YAML complet de la ressource :

      Remarque : Utilisez :set paste pour empêcher vim de mettre en forme automatiquement le texte préformaté que vous collez.

      apiVersion: kustomize.config.k8s.io/v1beta1
      kind: Kustomization
      metadata:
        name: root-admin-kustomization
      resources:
      - mz-token.yaml
      

   3. Enregistrez le fichier et quittez vim.

5. Validez les modifications dans la branche :

   Remarque : Vous devez configurer Git avec votre nom et votre adresse e-mail avant de pouvoir valider les modifications.

   git add infrastructure
   git commit
   

6. Transférez la branche vers GitLab :

   git push
   

7. Faites fusionner les modifications dans la branche main. Pour en savoir plus, consultez le runbook IAC-R0004.

26.2.6. Créer la ressource d'amorçage

Pour créer la ressource d'amorçage dans le cluster d'administrateur racine de la zone à joindre, procédez comme suit :

1. Créez une branche pour une demande de fusion :

   cd /tmp/iac
   git checkout main
   git pull --ff-only
   git checkout -b JOINING_ZONE_NAME-mz-bootstrap
   

2. Connectez-vous à la zone d'ancrage. Pour en savoir plus, consultez Interface de ligne de commande gdcloud. Cette étape est nécessaire, car lors d'une opération d'association, la commande gdcloud de l'étape suivante interagit avec le cluster d'administrateur racine dans la zone d'ancrage pour récupérer les informations de connectivité permettant d'interagir avec l'API globale dans la zone d'ancrage.

3. Générez le fichier YAML d'amorçage :

   gdcloud system multi-zone create-bootstrap --type join --output-file /tmp/iac/infrastructure/zonal/zones/JOINING_ZONE_NAME/root-admin/mz-bootstrap.yaml
   

4. Créez ou mettez à jour le fichier kustomization.yaml :

   1. Ouvrez le fichier :

      vim infrastructure/zonal/zones/JOINING_ZONE_NAME/root-admin/kustomization.yaml
      

   2. Si le fichier existait déjà, ajoutez un élément mz-token.yaml à la liste resources. Sinon, ajoutez le fichier YAML complet de la ressource :

      Remarque : Utilisez :set paste pour empêcher vim de mettre en forme automatiquement le texte préformaté que vous collez.

      apiVersion: kustomize.config.k8s.io/v1beta1
      kind: Kustomization
      metadata:
        name: root-admin-kustomization
      resources:
      - mz-bootstrap.yaml
      

   3. Enregistrez le fichier et quittez vim.

5. Validez les modifications dans la branche :

   Remarque : Vous devez configurer Git avec votre nom et votre adresse e-mail avant de pouvoir valider les modifications.

   git add infrastructure
   git commit
   

6. Transférez la branche vers GitLab :

   git push
   

7. Faites fusionner les modifications dans la branche main. Pour en savoir plus, consultez le runbook IAC-R0004.

Une fois les modifications fusionnées, l'IaC propage la ressource Bootstrap au cluster d'administrateur racine de la nouvelle zone, où elle est réconciliée. Il s'agit d'une opération asynchrone. L'API globale ne sera donc pas disponible immédiatement après la fusion.

26.2.7. Valider le déploiement réussi de l'API globale

Pour valider le déploiement de l'API globale, procédez comme suit :

1. Connectez-vous à la zone de ralliement. Pour en savoir plus, consultez Interface de ligne de commande gdcloud.

2. Obtenez une configuration Kubernetes pour l'API globale racine (global-api). Pour en savoir plus, consultez le runbook IAM-R0004.

3. Vérifiez la connectivité avec l'API globale dans la zone de connexion :

   kubectl version
   

26.2.8. Supprimer la paire de clés

Pour supprimer la paire de clés utilisée pour transférer le jeton d'amorçage de la zone d'ancrage vers la zone de jonction, procédez comme suit :

1. Connectez-vous à la zone de ralliement. Pour en savoir plus, consultez Interface de ligne de commande gdcloud.

2. Obtenez une configuration Kubernetes pour le cluster d'administrateur racine (root-admin). Pour en savoir plus, consultez le runbook IAM-R0004.

3. Exécutez la commande suivante pour supprimer la paire de clés :

   kubectl delete keypair -n global-kube-system kp
   

26.2.9. Nettoyer la demande de jeton

Pour supprimer le fichier YAML de demande de jeton, procédez comme suit :

1. Créez une branche pour une demande de fusion :

   cd /tmp/iac
   git checkout main
   git pull --ff-only
   git checkout -b JOINING_ZONE_NAME-mz-token-request-delete
   

2. Supprimez le fichier YAML de demande de jeton :

   rm /tmp/iac/infrastructure/global/orgs/root/mz-token-request.yaml
   

3. Mettez à jour le fichier kustomization.yaml.

   1. Ouvrez le fichier :

      vim infrastructure/global/orgs/root/kustomization.yaml
      

   2. Supprimez l'élément mz-token-request.yaml de la liste resources, enregistrez le fichier et quittez vim.

4. Validez les modifications dans la branche :

   Remarque : Vous devez configurer Git avec votre nom et votre adresse e-mail avant de pouvoir valider les modifications.

   git add infrastructure
   git commit
   

5. Transférez la branche vers GitLab :

   git push
   

6. Faites fusionner les modifications dans la branche main. Pour en savoir plus, consultez le runbook IAC-R0004.

26.2.10. Nettoyer le jeton

Une fois l'API globale disponible dans la zone de connexion, supprimez le jeton, car il n'est plus nécessaire :

1. Créez une branche pour une demande de fusion :

   cd /tmp/iac
   git checkout main
   git pull --ff-only
   git checkout -b JOINING_ZONE_NAME-mz-token-delete
   

2. Supprimez le fichier YAML du jeton :

   rm /tmp/iac/infrastructure/zonal/zones/JOINING_ZONE_NAME/root-admin/mz-token.yaml
   

3. Mettez à jour le fichier kustomization.yaml s'il existe déjà.

   1. Ouvrez le fichier :

      vim infrastructure/zonal/zones/JOINING_ZONE_NAME/root-admin/kustomization.yaml
      

   2. Supprimez l'élément mz-token.yaml de la liste resources, enregistrez le fichier et quittez vim.

4. Validez les modifications dans la branche :

   Remarque : Vous devez configurer Git avec votre nom et votre adresse e-mail avant de pouvoir valider les modifications.

   git add infrastructure
   git commit
   

5. Transférez la branche vers GitLab :

   git push
   

6. Faites fusionner les modifications dans la branche main. Pour en savoir plus, consultez le runbook IAC-R0004.

26.2.11. Synchroniser l'heure avec d'autres zones

1. Suivez NTP P0007 – Configurer des SyncServers multizones pour synchroniser l'heure de cette zone avec celle des autres zones.

26.2.12. Vérifier que l'API globale est en bon état

Une fois le processus d'amorçage de l'API globale terminé, effectuez des vérifications de l'état pour confirmer que l'API est en bon état :

1. Obtenez le nom de la zone à partir du serveur d'API du cluster d'administrateur racine :

   export ZONE_NAME=$(kubectl get controlplane -n mz-system cp -o jsonpath='{.spec.zone}')
   

2. Vérifiez le code temporel de la dernière pulsation de l'API globale :

   kubectl get globalapizone -n mz-system ${ZONE_NAME} -o yaml
   

   Le code temporel du battement cardiaque est renseigné dans status.lastHeartbeat. L'horodatage est mis à jour toutes les 30 secondes. Une API globale saine présente un code temporel de dernier signal de présence qui ne date pas de plus de 30 secondes.

26.2.13. Prolonger la date d'expiration de l'autorité de certification etcd globale

L'autorité de certification (CA) de l'etcd mondial a une date d'expiration de 90 jours. L'etcd global est un cluster etcd dont les instances sont déployées dans plusieurs zones GDC. Il n'existe aucune automatisation pour faire tourner l'AC.

Ces instructions doivent être appliquées aux zones existantes qui ont déjà rejoint l'univers multizone. Une fois les zones existantes mises à jour, la zone suivante qui rejoindra cet univers peut ignorer cette section.

26.2.13.1. Vérifier la date d'expiration

Utilisez la configuration Kubernetes de l'administrateur pour le cluster d'administrateur racine dans n'importe quelle zone existante. Vérifiez la date d'expiration de l'autorité de certification :

export CA_NAME=$(kubectl get etcdca etcd -n global-kube-system -o jsonpath="{.spec.rootCA.name}")

kubectl get secret $CA_NAME -n global-kube-system -o jsonpath="{.data.tls\.crt}" | base64 -d | openssl x509 -enddate -noout -in -

Si la date d'expiration est déjà définie sur environ un an, aucune autre action n'est requise. Si elle est inférieure à un an, consultez Faire pivoter l'autorité de certification avec une durée plus longue.

26.2.13.2. Faire tourner l'AC avec une durée plus longue

Suivez MZ-T0001 pour effectuer la rotation de l'autorité de certification. Assurez-vous que la spécification du certificat de la nouvelle CA contient une valeur duration: 8760h.