26. Bootstrap multizona

Tempo stimato per il completamento: 3 ore

Proprietario del componente utilizzabile: MZ

Profilo delle competenze: ingegnere del deployment

26.1. Panoramica

Il bootstrapping multizona prevede la configurazione del control plane globale root. La prima zona di un universo stabilisce il control plane globale. Altre zone si uniscono al control plane globale. L'unione a un control plane globale è un processo più complesso rispetto alla creazione del control plane, perché è necessario stabilire l'attendibilità tra il control plane globale dell'universo e la nuova zona. Quando si esegue il join di un control plane globale, sono coinvolte due zone:

  • Zona di ancoraggio: una zona che fa già parte del control plane globale. Deve essere la zona la cui istanza GitLab viene utilizzata per applicare le modifiche dell'infrastruttura come codice (IaC) all'API globale dell'universo.
  • Zona di unione: la zona che si unisce al control plane globale.

Hai eseguito il bootstrap della prima zona dell'universo in Inizializza multizona. Questa zona funge da zona di ancoraggio quando altre zone si uniscono all'universo.

Se nell'universo esiste già un'API globale e stai eseguendo il bootstrapping di una zona che si unisce all'universo, completa i seguenti passaggi.

26.2. Bootstrap multizona nelle zone che si uniscono a un universo

Prima di procedere, verifica di aver eseguito il bootstrap di più zone nella zona di ancoraggio.

26.2.1. Avvia il container dello strumento IO

Per motivi di sicurezza e controllabilità, la procedura di bootstrapping multizona deve essere eseguita utilizzando le credenziali personali per accedere a Kubernetes (non una configurazione di Kubernetes amministratore) e IaC per l'approvazione da più parti delle richieste di autorizzazione per eseguire azioni sensibili. Tutti gli strumenti necessari per eseguire le azioni di bootstrapping sono inclusi nel container dello strumento IO. Consulta la procedura di configurazione del container dello strumento IO OOPS-P0065 per scoprire come avviare il container nell'ambiente OIC. Una zona che si unisce al control plane globale prevede interazioni con due zone, una delle quali (la zona di ancoraggio) non opera in condizioni di giorno 0, pertanto devono essere impiegate misure di autenticazione e autorizzazione a livello di produzione per garantire che la sicurezza della zona di ancoraggio non venga compromessa.

26.2.2. Inizializza il repository GitLab

Utilizza le credenziali del provider di identità (IdP) configurato in Configurazione dell'infrastruttura come codice e segui la procedura OOPS-P0066 per gestire l'accesso degli utenti GitLab.

Clona il repository IaC della zona di ancoraggio:

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

Sostituisci GLOBAL_DNS_DOMAIN con il dominio DNS per l'universo.

Fornisci il nome utente e la password quando richiesti.

26.2.3. Aggiungi i ruoli richiesti

Segui le istruzioni nel runbook Procedura di accesso e aumento dei privilegi IAM-R0005 per creare i binding di ruolo e cluster-role necessari:

  • Aggiungi un'associazione di ruolo del cluster con il ruolo del cluster mz-bootstrap-joining-editor nel cluster root-admin della zona di unione.
  • Aggiungi un'associazione di ruolo del cluster con il ruolo del cluster mz-bootstrap-anchor-reader nel cluster root-admin della zona di ancoraggio.
  • Aggiungi un'associazione di ruolo con il ruolo mz-bootstrap-viewer nello spazio dei nomi mz-system nell'API globale della zona di ancoraggio.

26.2.4. Crea richiesta di token

Quando si unisce a un control plane globale, il contatto viene stabilito tra la zona di unione e la zona di ancoraggio utilizzando un token di bootstrap API globale. Una richiesta di token viene utilizzata per richiedere un token dall'API globale nella zona di ancoraggio.

  1. Crea un nuovo ramo per una richiesta di unione:

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

    Sostituisci JOINING_ZONE_NAME con il nome della zona derivato dal questionario di acquisizione del cliente, come descritto nella nota alla fine della sezione.

  2. Accedi alla zona di unione. Per maggiori dettagli, consulta l'interfaccia a riga di comando gcloud. Questo è necessario perché il comando gdcloud nel passaggio successivo interagisce con il cluster di amministrazione principale nella zona di unione per ottenere una coppia di chiave di crittografia della chiave pubblica per trasferire in modo sicuro il token di bootstrap dalla zona di ancoraggio alla zona di unione.

  3. Genera il file YAML della richiesta di token:

    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. Crea o aggiorna il file kustomization.yaml.

    1. Apri il file:

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

    2. Se il file esisteva già, aggiungi un elemento mz-token-request.yaml all'elenco resources. Altrimenti, aggiungi il file YAML della risorsa completa:

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

    3. Salva il file ed esci da vim.

  5. Esegui il commit delle modifiche al ramo:

    git add infrastructure
git commit

  6. Esegui il push del ramo su GitLab:

    git push

  7. Unisci le modifiche al ramo main. Per maggiori dettagli, consulta il runbook IAC-R0004.

26.2.5. Crea token

Per creare il token di bootstrap nella zona di unione:

  1. Crea un nuovo ramo per una richiesta di unione:

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

  2. Accedi alla zona di ancoraggio. Per maggiori dettagli, consulta l'interfaccia a riga di comando gcloud. Questo è necessario perché il comando gdcloud nel passaggio successivo interagisce con l'API globale nella zona di ancoraggio per creare e criptare un token di bootstrap.

  3. Genera il file YAML del token:

    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. Crea o aggiorna il file kustomization.yaml.

    1. Apri il file:

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

    2. Se il file esisteva già, aggiungi un elemento mz-token.yaml all'elenco resources. Altrimenti, aggiungi il file YAML della risorsa completo:

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

    3. Salva il file ed esci da vim.

  5. Esegui il commit delle modifiche al ramo:

    git add infrastructure
git commit

  6. Esegui il push del ramo su GitLab:

    git push

  7. Unisci le modifiche al ramo main. Per maggiori dettagli, consulta il runbook IAC-R0004.

26.2.6. Crea la risorsa di bootstrap

Per creare la risorsa di bootstrap nel cluster di amministrazione radice della zona di unione:

  1. Crea un nuovo ramo per una richiesta di unione:

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

  2. Accedi alla zona di ancoraggio. Per maggiori dettagli, consulta l'interfaccia a riga di comando gcloud. Questo è necessario perché durante un'operazione di unione il comando gdcloud nel passaggio successivo interagisce con il cluster di amministrazione principale nella zona di ancoraggio per recuperare le informazioni di connettività per interagire con l'API globale nella zona di ancoraggio.

  3. Genera il file YAML di bootstrap:

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

  4. Crea o aggiorna il file kustomization.yaml:

    1. Apri il file:

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

    2. Se il file esisteva già, aggiungi un elemento mz-token.yaml all'elenco resources. Altrimenti, aggiungi il file YAML della risorsa completo:

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

    3. Salva il file ed esci da vim.

  5. Esegui il commit delle modifiche al ramo:

    git add infrastructure
git commit

  6. Esegui il push del ramo su GitLab:

    git push

  7. Unisci le modifiche al ramo main. Per maggiori dettagli, consulta il runbook IAC-R0004.

Una volta unite le modifiche, IaC propaga la risorsa Bootstrap al nuovo cluster di amministrazione principale della zona in cui viene riconciliata. Si tratta di un'operazione asincrona, quindi l'API globale non sarà disponibile immediatamente dopo l'unione.

26.2.7. Convalida il deployment riuscito dell'API globale

Per convalidare il deployment dell'API globale, segui questi passaggi:

  1. Accedi alla zona di unione. Per maggiori dettagli, consulta l'interfaccia a riga di comando gcloud.

  2. Ottieni una configurazione Kubernetes per l'API globale principale (global-api). Per i dettagli, consulta il runbook IAM-R0004.

  3. Verifica la connettività con l'API globale nella zona di unione:

    kubectl version

26.2.8. Pulisci coppia di chiavi

Per eliminare la coppia di chiavi utilizzata per trasferire il token di bootstrap dalla zona di ancoraggio alla zona di unione:

  1. Accedi alla zona di unione. Per maggiori dettagli, consulta l'interfaccia a riga di comando gcloud.

  2. Ottieni una configurazione Kubernetes per il cluster di amministrazione principale (root-admin). Per maggiori dettagli, consulta il runbook IAM-R0004.

  3. Esegui questo comando per eliminare la coppia di chiavi:

    kubectl delete keypair -n global-kube-system kp

26.2.9. Pulizia della richiesta di token

Per eliminare il file YAML della richiesta di token:

  1. Crea un nuovo ramo per una richiesta di unione:

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

  2. Elimina il file YAML della richiesta di token:

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

  3. Aggiorna il file kustomization.yaml.

    1. Apri il file:

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

    2. Rimuovi l'elemento mz-token-request.yaml dall'elenco resources, salva il file e chiudi vim.

  4. Esegui il commit delle modifiche al ramo:

    git add infrastructure
git commit

  5. Esegui il push del ramo su GitLab:

    git push

  6. Unisci le modifiche al ramo main. Per maggiori dettagli, consulta il runbook IAC-R0004.

26.2.10. Pulisci token

Una volta che l'API globale è disponibile nella zona di unione, elimina il token perché non è più necessario:

  1. Crea un nuovo ramo per una richiesta di unione:

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

  2. Elimina il file YAML del token:

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

  3. Aggiorna il file kustomization.yaml se esiste già.

    1. Apri il file:

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

    2. Rimuovi l'elemento mz-token.yaml dall'elenco resources, salva il file e chiudi vim.

  4. Esegui il commit delle modifiche al ramo:

    git add infrastructure
git commit

  5. Esegui il push del ramo su GitLab:

    git push

  6. Unisci le modifiche al ramo main. Per maggiori dettagli, consulta il runbook IAC-R0004.

26.2.11. Sincronizzare l'ora con altri fusi orari

  1. Segui NTP P0007 - Configure Multizone SyncServers per sincronizzare l'ora in questa zona con le altre zone.

26.2.12. Verifica che l'API globale sia integra

Al termine della procedura di bootstrap dell'API globale, esegui controlli di integrità per verificare che l'API sia integra:

  1. Ottieni il nome della zona dal server API del cluster di amministrazione principale:

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

  2. Controlla il timestamp dell'ultimo heartbeat dell'API globale:

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

    Il timestamp del battito cardiaco viene compilato in status.lastHeartbeat. Il timestamp viene aggiornato ogni 30 secondi. Un'API globale integra un timestamp dell'ultimo heartbeat non più vecchio di 30 secondi.

26.2.13. Estendere la data di scadenza della CA etcd globale

L'autorità di certificazione (CA) di etcd globale ha una data di scadenza di 90 giorni. etcd globale è un cluster etcd con istanze di cui è stato eseguito il deployment in più zone GDC. Non esiste un'automazione per la rotazione della CA.

Queste istruzioni devono essere applicate alle zone esistenti che hanno già aderito all'universo multizona. Dopo l'aggiornamento delle zone esistenti, la zona successiva che entrerà a far parte di questo universo può saltare questa sezione.

26.2.13.1. Controlla la data di scadenza

Utilizza la configurazione Kubernetes dell'amministratore per il cluster di amministrazione principale in qualsiasi zona esistente. Controlla la data di scadenza della CA:

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 -

Se la data di scadenza è già impostata su circa un anno, non sono necessarie ulteriori azioni. Se è inferiore a un anno, consulta Esegui la rotazione della CA con una durata più lunga.

26.2.13.2. Ruota la CA con una durata più lunga

Segui MZ-T0001 per ruotare la CA. Assicurati che la specifica del certificato della nuova CA contenga un valore di duration: 8760h.