23. Einrichtung von Infrastruktur als Code

Geschätzte Dauer: 60 Minuten

Eigentümer der betriebsbereiten Komponente: IAC

Kompetenzprofil: Bereitstellungsingenieur

Infrastruktur als Code (IaC) in Google Distributed Cloud (GDC) mit Air Gap besteht aus zwei Systemen:

• Config Sync ist eine Komponente, die in Distributed Cloud Infrastructure as Code (IaC) zum Verwalten von Ressourcen auf Clusterebene und freigegebenen Diensten verwendet wird.

• GitLab hostet ein Git-Repository, das als „Source of Truth“ (SoT) für Config Sync dient. Ein Zielcluster ist ein Cluster, der von Config Sync über die SoT im Repository verwaltet wird.

  • GitLab enthält ein System zur Codeüberprüfung, mit dem die Genehmigung durch mehrere Parteien (Multi-Party Approval, MPA) für Richtlinien- und Konfigurationsänderungen implementiert werden kann.

Bei einer Bereitstellung sind die folgenden beiden Zonentypen beteiligt:

• Ankerzone: Die Zone, die bereits Teil der globalen Steuerungsebene ist. Die erste Zone ist die Ankerzone einer Bereitstellung.
• Beitrittszone: Die Zone, die der globalen Steuerungsebene beitritt.

Config Sync verwaltet Kubernetes-Objekte in den Clustern root-admin und „organization-admin“. Es ist so konfiguriert, dass es aus dem Distributed Cloud IaC-Repository liest, das von GitLab im primären root-admin-Cluster bereitgestellt wird.

Distributed Cloud installiert IaC während des Bootstrapping. Führen Sie die folgenden manuellen Schritte aus, um die IaC-Einrichtung abzuschließen.

Wichtig :Um auf die auf dieser Seite aufgeführten URLs zuzugreifen, müssen Sie mit dem Internet verbunden sein. Die URLs werden für den Zugriff außerhalb Ihrer Air-Gap-Umgebung bereitgestellt.

23.1. Erste Zone für IaC einrichten

Dieser Abschnitt enthält Schritte zum Einrichten von IaC in der ersten Bereitstellungszone.

23.2. Vorbereitung

• Der Stammadministratorcluster wurde gebootstrapped.
• Erstellen Sie einen SAML-Client in der Active Directory Federation Services-Instanz (ADFS) von OC IT als Identitätsföderationsclient in GitLab.

23.3. Tag 0: Zugriff auf GitLab

1. Öffnen Sie die GitLab-Webkonsole unter https://iac.GDC_URL. GDC_URL ist die Domain, die im CIQ angegeben wurde.

   # Use the root kubeconfig of the root admin cluster.
   export ANCHOR_KUBECONFIG=ANCHOR_ZONE_KUBECONFIG
   echo https://$(kubectl --kubeconfig $ANCHOR_KUBECONFIG get dnsregistrations \
        -n gitlab-system iac -o jsonpath='{.status.fqdn}')
   

2. Verwenden Sie den Nutzernamen für Tag 0: ioadmin.

3. Führen Sie den folgenden Befehl aus, um das Passwort abzurufen:

   export IO_ADMIN_PWD=$(kubectl --kubeconfig $ANCHOR_KUBECONFIG \
     get secret gitlab-basic-users -n gitlab-system  \
     -o jsonpath='{.data.admin}' | base64 -d)
   

4. Melden Sie sich an und rufen Sie Menü > Projekte > Projekte durchsuchen gdch / iac auf, um zu prüfen, ob das iac-Git-Repository erstellt wurde.

23.4. Administratoren erstellen

1. Erstellen Sie dedizierte Administratorkonten in ADFS. Sie dürfen nicht für nicht administrative Zwecke verwendet werden und müssen die Erweiterung „-ga“ haben. Die ersten Administratornutzer MÜSSEN hier dieselbe email verwenden, die sie in Active Directory Federation Services (ADFS) verwenden.

2. Führen Sie den folgenden Befehl aus, um einen neuen Nutzer zu erstellen:

   export NEW_USER_NAME=NEW_USER_NAME
   export NEW_USER_USERNAME=NEW_USERNAME
   export NEW_USER_PWD=NEW_USER_PWD
   export NEW_USER_EMAIL=NEW_USER_EMAIL
   export GDC_URL=GDC_URL
   export TOKEN=$(curl -X POST https://iac.$GDC_URL/oauth/token \
       -d "grant_type=password&username=ioadmin&password=${IO_ADMIN_PWD}" \
       | jq -r '.access_token')
   USERID=$(curl -X GET https://iac.$GDC_URL/api/v4/users \
       -d access_token=${TOKEN} -d username=ioadmin |\
       sed -E 's/.*"id":"?([^,"]*)"?.*/\1/')
   curl -X POST https://iac.$GDC_URL/api/v4/users \
       -d username=${NEW_USER_USERNAME} -d password=${NEW_USER_PWD} -d name=${NEW_USER_NAME} \
       -d email=${NEW_USER_EMAIL} -d admin=true -d access_token=${TOKEN} 
   curl -X POST https://iac.$GDC_URL/oauth/revoke \
       -d client_id=${USERID} -d "token=${TOKEN}"
   

Hinweis :Wenn Sie den Zugriff eines vorhandenen Nutzers auf Administrator eskalieren möchten, wählen Sie den Nutzer im Bereich Nutzer aus und klicken Sie auf Bearbeiten. Rufen Sie den Bereich Zugriff auf, wählen Sie Administrator aus und klicken Sie auf Speichern.

23.5. GitLab-Lizenz aktualisieren

Für viele Funktionen von GitLab ist eine „Ultimate“-Lizenz erforderlich. In diesem Schritt ersetzen Sie die mit GDC gelieferte temporäre Lizenz durch die eigene Lizenz der Website. GitLab EE mit einer Lizenzdatei oder einem Schlüssel aktivieren enthält alle Details.

Der Lizenzschlüssel für die Website, den Sie erhalten haben, ist eine base64-codierte ASCII-Textdatei mit der Erweiterung .gitlab-license. Mit diesem Schlüssel aktivieren Sie GitLab.

1. Melden Sie sich in der GitLab-Webkonsole als ioadmin an.
2. Wählen Sie in der Navigationsleiste Menü und dann Administrator aus.
3. Wählen Sie im Navigationsmenü Einstellungen und dann Allgemein aus.
4. Fügen Sie im Bereich „Lizenz hinzufügen“ eine Lizenz hinzu, indem Sie entweder die Datei hochladen oder den Schlüssel eingeben.
5. Klicken Sie das Kästchen für die Nutzungsbedingungen an.
6. Wählen Sie „Lizenz hinzufügen“ aus.

23.6. GitLab-Repository einrichten

ConfigSync verwaltet Kubernetes-Objekte im Root-Administratorcluster und in Organisationsadministratorclustern und ist so konfiguriert, dass Daten aus dem von GitLab bereitgestellten Distributed Cloud IaC-Repository im Root-Administratorcluster gelesen werden.

Wir müssen die ersten GitLab-Ordner für Configsync einrichten, damit Konfigurationen verwendet und auf den erforderlichen Kubernetes-Cluster angewendet werden können.

infrastructure
│   └── zonal
│     └── zones
│         ├── ${anchor_zone_name}
│           ├── root-admin
│             ├── kustomization.yaml
│   └── global
│     └── orgs
│         ├── root
│           ├── kustomization.yaml

So erstellen Sie die erste Dateistruktur:

1. Öffnen Sie das iac-Repository über „Menü –> Projekte ansehen“.

2. Öffnen Sie die Web-IDE.

3. Erstellen Sie eine Datei in /infrastructure/zonal/zones/${anchor_zone_name}/root-admin/kustomization.yaml mit folgendem Inhalt:

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

4. Klicken Sie auf die Schaltfläche „Commit“.

5. Wählen Sie „Commit in den Hauptzweig übernehmen“ aus und bestätigen Sie die Auswahl.

23.7. Genehmigung durch mehrere Parteien einrichten

In diesem Abschnitt können Sie das System so konfigurieren, dass für jede Merge-Anfrage für das iac-Repository eine Genehmigung erforderlich ist. Außerdem können Sie direkte Commits (ohne Erstellen einer Merge-Anfrage) für den main-Branch verhindern, um die Genehmigung durch mehrere Parteien (Multi-Party Approval, MPA) zu erzwingen.

23.7.1. Genehmigung von Merge-Anfragen in GitLab aktivieren

1. Rufen Sie das Repository iac auf.

2. Erstellen Sie mit der Web-IDE im Stammordner eine Datei namens CODEOWNERS und fügen Sie die Distributed Cloud-Gruppe als Repository-Inhaber hinzu:

   [Repository Owners]
   * @gdch
   

   Nur Nutzer, die der Datei CODEOWNERS hinzugefügt wurden, können Merge-Anfragen im Repository iac genehmigen. Diese generische Datei dient nur zu Einrichtungszwecken. Eine detailliertere Anleitung zu Berechtigungen für die detaillierte Genehmigung finden Sie unter IAC-R0007.

3. Klicken Sie auf die Schaltfläche Commit.

4. Wählen Sie Commit to the main branch (Im Hauptzweig committen) aus und bestätigen Sie den Vorgang.

5. Wenn Sie der Datei CODEOWNERS weitere Nutzer hinzufügen möchten, erstellen Sie eine Merge-Anfrage, die von vorhandenen Nutzern in CODEOWNERS genehmigt werden muss.

Hinweis: GDC deaktiviert Identitätsübernahmetokens in GitLab, um die Autorisierung durch mehrere Parteien zu erzwingen. Weitere Informationen zu Identitätswechsel-Tokens finden Sie in der GitLab-Dokumentation unter https://docs.gitlab.com/ee/api/rest/index.html#impersonation-tokens.

23.8. Active Directory Federation Services (ADFS) mit GitLab verbinden

Warnung :Wenn Sie einen Identitätsanbieter mit GitLab verbinden, wird die Standardanmeldemethode mit Nutzername und Passwort aus der GitLab-Benutzeroberfläche entfernt. Da der Nutzer ioadmin nicht verfügbar ist, erstellen Sie einen ersten Administrator.

Sie können ADFS mit einem SAML-Client über das Auth-Framework von GitLab mit GitLab verbinden.

Wenn Sie eine private Zertifizierungsstelle für Ihren Identitätsanbieter verwenden, müssen Sie sie der GitLab-Instanz hinzufügen. Rufen Sie die Base64-Version des ADFS-CA-Zertifikats ab und speichern Sie sie in einem Secret.

cat <<EOF > adfs-ca-cert-secret.yaml
apiVersion: v1
data:
  tls.crt: ADFS_CA_CERTIFICATE_BASE64
kind: Secret
metadata:
  name: adfs-ca-cert-secret
  namespace: gitlab-system
type: Opaque
EOF

kubectl apply -f adfs-ca-cert-secret.yaml

23.8.1. ADFS für die SAML-Authentifizierung konfigurieren

Bevor Sie GitLab über die Helm-Konfiguration mit ADFS verbinden, muss ADFS einen SAML-Client erstellen. Gehen Sie in Ihrer Windows-Instanz so vor:

1. Führen Sie die App AD FS Management als Administrator aus.

   

2. Klicken Sie im Verzeichnis AD FS auf den Ordner Vertrauensstellung der vertrauenden Seite. Klicken Sie im Bereich Aktionen auf Vertrauensstellung der vertrauenden Seite hinzufügen.

   

3. Der Assistent zum Hinzufügen einer Vertrauensstellung der vertrauenden Seite wird geöffnet. Wählen Sie im ersten Schritt Claims aware aus und klicken Sie auf Start.

   

4. Wählen Sie Daten über die vertrauende Seite manuell eingeben aus und klicken Sie auf Weiter.

   

5. Geben Sie im Feld Anzeigename und Hinweise einige erkennbare Informationen zur ADFS-Instanz ein. Klicken Sie auf Weiter.

   

6. Überspringen Sie den Schritt Zertifikat konfigurieren, indem Sie auf Weiter klicken.

7. Klicken Sie das Kästchen Unterstützung für das SAML 2.0-WebSSO-Protokoll aktivieren an. Geben Sie im Feld URL des SAML 2.0-Diensts für einmaliges Anmelden der vertrauenden Seite Folgendes ein: https://iac.GDC_URL/users/auth/saml/callback.

   Ersetzen Sie GDC_URL durch die URL der Organisation in GDC.

   

8. Geben Sie einen Namen für IaC ein und fügen Sie Folgendes hinzu:

   https://iac.GDC_URL.sesame.street https://iac.GDC_URL.sesame.street/users/auth/saml/callback
   

9. Klicken Sie bei den Schritten Configure Identifiers (Kennungen konfigurieren), Choose Access Control Policy (Zugriffssteuerungsrichtlinie auswählen) und Ready to Add Trust (Vertrauensstellung hinzufügen) auf Next (Weiter), um den Assistenten abzuschließen.

   Hinweis :Wenn Sie Schritte auf der Seite IDs konfigurieren überspringen möchten, fügen Sie die folgenden IDs der vertrauenden Seite hinzu:

     # Replace GDC_URL with the cells URL, for example, bert.sesame.street
     https://iac.GDC_URL
     https://iac.GDC_URL/users/auth/saml/callback
   

10. Die Anzeige wird mit der neu erstellten Vertrauensstellung der vertrauenden Seite aktualisiert. Klicken Sie mit der rechten Maustaste auf das Element und wählen Sie Richtlinie für Anspruchsausstellung bearbeiten aus.

    

11. Klicken Sie auf die Schaltfläche Regel hinzufügen und wählen Sie im Schritt Regeltyp auswählen die Anspruchsregelvorlage LDAP-Attribute als Ansprüche senden aus. Klicken Sie auf Weiter.

12. Füllen Sie im Schritt Anspruchsregel konfigurieren die folgenden Parameter aus:

    1. Geben Sie im Feld Claim rule name den Wert Email ein.
    2. Wählen Sie in der Liste Attributspeicher die Option Active Directory aus.
    3. Wählen Sie in der Tabelle Zuordnung von LDAP-Attributen zu ausgehenden Anforderungstypen in der Spalte LDAP-Attribut die Option E-Mail-Addresses aus oder geben Sie sie ein.

    4. Wählen Sie in der Spalte Typ des ausgehenden Anspruchs der Tabelle E-Mail Address aus oder geben Sie E-Mail Address ein.

       

    5. Beenden Sie den Assistenten.

13. Klicken Sie auf die Schaltfläche Regel hinzufügen.

14. Klicken Sie mit der rechten Maustaste auf das Element und dann noch einmal auf Richtlinie für die Ausstellung von Ansprüchen bearbeiten.

15. Wählen Sie im Schritt Regeltyp auswählen die Anspruchsregelvorlage Eingehenden Anspruch transformieren aus. Klicken Sie auf Weiter.

16. Füllen Sie im Schritt Anspruchsregel konfigurieren die folgenden Parameter aus:

    1. Geben Sie im Feld Claim rule name den Wert Transform email to nameid ein.
    2. Wählen Sie im Feld Eingehender Anspruchstyp die Option E-Mail Address aus oder geben Sie sie ein.
    3. Wählen Sie im Feld Typ des ausgehenden Anspruchs die Option Name ID aus oder geben Sie sie ein.
    4. Wählen Sie im Feld Format der ausgehenden Namens-ID die Option Persistent Identifier aus oder geben Sie sie ein.

    5. Wählen Sie die Option Alle Anspruchswerte übergeben aus.

       

    6. Beenden Sie den Assistenten.

23.8.2. SAML-Konfiguration zu GitLab hinzufügen

In diesem Abschnitt wird beschrieben, wie Sie die SAML-Konfiguration zu GitLab hinzufügen.

23.8.2.1. GitLab beim Identitätsanbieter registrieren

Öffnen Sie die SAML-Clientkonfiguration in ADFS. Für die Einbindung in Ihren IdP sind in GitLab die folgenden Werte erforderlich:

• assertion_customer_service_url: Der IdP leitet den Nutzer nach der Authentifizierung an diese URL weiter. Stell die Temperatur auf https://iac.GDC_URL/users/auth/saml/callback.

  Ersetzen Sie GDC_URL durch die URL der Organisation in GDC.

• idp_cert_fingerprint: GitLab verwendet diesen Fingerabdruck, um das Zertifikat einer eingehenden SAML-Nachricht zu überprüfen. So finden Sie die idp_cert_fingerprint in ADFS:

  1. Führen Sie die App AD FS Management als Administrator aus.

  2. Klicken Sie in der Verzeichnisstruktur AD FS > Dienst > Zertifikate auf den Ordner Zertifikate. Im Bereich Tokensignatur wird ein Zertifikat angezeigt. Klicken Sie mit der rechten Maustaste auf das Zertifikat und wählen Sie Zertifikat anzeigen aus.

     

  3. Rufen Sie im Fenster Zertifikat den Tab Details auf. Scrolle durch die Liste, bis du den Eintrag Thumbprint siehst. Klicken Sie auf das Element und kopieren Sie den Inhalt, der in der Konsole angezeigt wird.

     

• idp_sso_target_url – GitLab verwendet diesen Endpunkt für die Authentifizierung per SAML. So finden Sie die idp_sso_target_url in ADFS:

  1. Führen Sie die App AD FS Management als Administrator aus.

  2. Klicken Sie in der Verzeichnisstruktur AD FS > Dienst auf den Ordner Endpoints.

     Endpunkte

     

  3. Suchen Sie auf dem mittleren Bildschirm nach einer Zeile mit dem Typ SAML 2.0/WS-Federation. Der Zielendpunkt ist Ihre ADFS-URL und der Zielendpunkt. Wenn der Domainname Ihrer Instanz beispielsweise https://ocit.gdch.test/ und der Zielendpunkt /adfs/ls ist, lautet idp_sso_target_url https://ocit.gdch.test/adfs/ls.

• issuer: Die URL, die GitLab zur Identifizierung verwendet. Verwenden Sie https://iac.GDC_URL.

  Bereiten Sie die oben genannten IdP-Werte vor und schreiben Sie sie in eine benutzerdefinierte Konfiguration mit dem Namen custom_saml.yaml. Bearbeiten Sie diese YAML-Datei, um die für Ihren SAML-Client erforderliche Konfiguration zu erhalten.

  cat <<EOF > custom_saml.yaml
  name: saml
  label: "ADFS SAML" # This is the label the login button will use.
  args:
    assertion_consumer_service_url: "https://iac.GDC_URL/users/auth/saml/callback"
    idp_cert_fingerprint: "ADFS_IDP_CERT_FINGERPRINT"
    idp_sso_target_url: "ADFS_IDP_SSO_TARGET_URL"
    issuer: "https://iac.GDC_URL"
  
    # These parameters are necessary for ADFS to connect to GitLab. Do not change unless you are sure of what you're doing.
    name_identifier_format: "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
    attribute_statements: { email: ['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress'] }
  EOF
  

  Wenn Sie bereit sind, wenden Sie die Konfiguration als Secret mit dem Namen custom-gitlab-saml-provider an.

  cat <<EOF > custom-gitlab-saml-provider.yaml
  apiVersion: v1
  data:
    provider: |
    $(cat custom_saml.yaml | base64 -w 0)
  kind: Secret
  metadata:
    name: custom-gitlab-saml-provider
    namespace: gitlab-system
    annotations:
      "helm.sh/hook": post-install,post-upgrade
      "helm.sh/hook-weight": "-5"
  EOF
  kubectl apply -f custom-gitlab-saml-provider.yaml
  

  Sie können das Secret beim Erstellen von subcomponentoverride.yaml verwenden. Weitere Informationen zu Variablen finden Sie in der GitLab-Dokumentation.

  cat <<EOF > subcomponentoverride.yaml
  apiVersion: lcm.private.gdc.goog/v1
  kind: SubcomponentOverride
  metadata:
    name: iac-gitlab
    namespace: root
  spec:
    subComponentRef: "iac-gitlab"
    backend:
      operableParameters:
        omniauth:
          enabled: true
          providers:
          - secret: custom-gitlab-saml-provider
        certificates:
          customCAs:
          - secret: adfs-ca-cert-secret
          - configMap: trust-store-root-ext
  EOF
  kubectl apply -f subcomponentoverride.yaml
  

Dadurch wird die Überschreibung der untergeordneten Komponente erstellt. Führen Sie folgenden Befehl aus, um zu prüfen, ob die Konfiguration erstellt wurde: sh kubectl get subcomponentoverride -n root

Die Ausgabe sieht etwa so aus:

NAME            AGE
iac-gitlab   1s

23.8.2.2. Ersten angemeldeten SAML-Nutzer initialisieren

Wenn Sie SAML aktivieren, wird die lokale Anmeldung entfernt. Nutzer müssen die Verfahren für den Notfallzugriff durchlaufen, um die lokale Anmeldung wieder zu aktivieren und wieder Zugriff auf ioadmin zu erhalten.

Die ersten initialisierten Administratoren, die in Administratornutzer erstellen erstellt wurden, funktionieren ohne weitere Änderungen als Administratoren. Sie sollten keinen Zugriff auf das Projekt haben. Wenn Sie dem Distributed Cloud-Projekt Nutzer hinzufügen möchten, folgen Sie der Anleitung unter Neuen Nutzer über ADFS einbinden.

23.8.3. ADFS-Verbindung prüfen

1. Prüfen Sie den Status der GitLab-webservice-Pods:

   kubectl --kubeconfig $KUBECONFIG get pod -l app=webservice,release=gitlab -n gitlab-system
   

   NAME	BEREIT	STATUS	NEUSTARTS	AGE
   gitlab-webservice-default-5d99b4d7c7-9fmln	2/2	Wird ausgeführt	0	4m6s
   gitlab-webservice-default-5d99b4d7c7-w99p4	2/2	Wird ausgeführt	0	96 s
   gitlab-webservice-default-7884d4c8b9-qjhtv	2/2	Wird beendet	0	18 Std.

2. Rufen Sie https://iac.GDC_URL auf und prüfen Sie, ob dieser Bildschirm angezeigt wird. Er enthält die Schaltfläche ADFS SAML für die SSO-Anmeldung und keine Felder für die direkte Anmeldung mit Nutzername und Passwort.

3. Klicken Sie auf ADFS SAML. Prüfen Sie, ob Sie zur Anmeldung bei ADFS aufgefordert werden.

4. Prüfen Sie nach der Anmeldung bei ADFS, ob Sie bei GitLab angemeldet sind und jetzt mit der Anwendung interagieren können.

23.9. Administratorkonto für Tag 0 sperren

Nachdem SAML aktiviert wurde, deaktivieren Sie die Passwortauthentifizierung für die Weboberfläche und setzen Sie dann das Passwort für ioadmin zurück, da der API-Zugriff bestehen bleibt.

1. Führen Sie das folgende Skript aus.

   Hinweis :Fügen Sie in Testumgebungen den curl-Befehlen - k hinzu.

     export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig
     export PWD=$(kubectl get secret gitlab-basic-users -n gitlab-system -o yaml \
         | grep admin | head -n1 | awk '{print $2}' | xargs echo | base64 -d)
     export TOKEN=$(curl -X POST https://iac.GDC_URL/oauth/token \
         -d "grant_type=password&username=ioadmin&password=${PWD}" \
         | jq -r '.access_token')
     curl -X PUT  https://iac.GDC_URL/api/v4/application/settings \
         -d access_token=${TOKEN} \
         -d password_authentication_enabled_for_web=false
     NEWPASS=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1)
     USERID=$(curl -X GET https://iac.GDC_URL/api/v4/users \
         -d access_token=${TOKEN} -d username=ioadmin |\
         jq -r '.[] | .id')
     curl -X PUT  https://iac.GDC_URL/api/v4/users/${USERID} \
         -d access_token=${TOKEN} -d username=ioadmin \
         -d "password=${NEWPASS}" \
         -d user_id=${USERID}
     curl -X POST https://iac.GDC_URL/oauth/revoke \
         -d client_id=${USERID} -d "token=${TOKEN}"
   

2. Speichern Sie das neue Passwort im Secret gitlab-basic-users.

     kubectl patch secret gitlab-basic-users -n gitlab-system --type=json -p'[{"op": "replace", "path": "/data/admin", "value": '"$(echo $NEWPASS | base64 -w0)"'}]'
   

Verwenden Sie Konten im OI ADFS, um sich anzumelden.

23.10. IaC für die Beitrittszone einrichten

In diesem Abschnitt werden die Schritte zum Einrichten von IaC in der Joining-Zone der Bereitstellung beschrieben.

23.11. Vorbereitung

Bevor Sie die Join-Zone einrichten, müssen Sie den Root-Administratorcluster booten.

23.12. Config Sync-Anmeldedaten konfigurieren

So konfigurieren Sie Config Sync-Anmeldedaten:

1. Stellen Sie eine Verbindung zum Root-Administratorcluster der Ankerzone her.

2. Rufen Sie die Config Sync-Anmeldedaten ab:

   kubectl --kubeconfig $ANCHOR_KUBECONFIG get secret -n config-management-system iac-creds-replica -o json |\
       jq 'del(.metadata.creationTimestamp, .metadata.resourceVersion, .metadata.uid)' > iac-creds-replica.json
   

3. Kopieren Sie die Datei iac-creds-replica.json.

4. Stellen Sie eine Verbindung zum Stammadministratorcluster der Beitrittszone her.

5. Fügen Sie die Datei iac-creds-replica.json ein.

6. Wenden Sie die Config Sync-Anmeldedaten auf den Root-Administratorcluster an:

   # Use the root kubeconfig of the root admin cluster.
   export JOINING_KUBECONFIG=JOINING_ZONE_KUBECONFIG
   kubectl --kubeconfig $JOINING_KUBECONFIG apply -f iac-creds-replica.json
   

7. Prüfen Sie, ob die Config Sync-Anmeldedaten konfiguriert sind:

   kubectl --kubeconfig $JOINING_KUBECONFIG get secret -n config-management-system \
       iac-creds-replica -o yaml
   

23.13. Config Sync-„Source of Truth“ konfigurieren

So konfigurieren Sie die Config Sync-Source of Truth:

1. Stellen Sie eine Verbindung zum Root-Administratorcluster der Ankerzone her.

2. Rufen Sie den FQDN von GitLab ab:

   export primaryDnsFQDN=$(kubectl --kubeconfig $ANCHOR_KUBECONFIG get DNSRegistration \
       -n gitlab-system iac -o jsonpath='{.status.fqdn}')
   

3. Stellen Sie eine Verbindung zum Stammadministratorcluster der Beitrittszone her.

4. Erstellen Sie die IaC-Datei SubcomponentOverride:

   echo "apiVersion: lcm.private.gdc.goog/v1
   kind: SubcomponentOverride
   metadata:
       name: iac
       namespace: root
   spec:
       subComponentRef: "iac-configsync"
       backend:
           operableParameters:
               primaryDnsFQDN: ${primaryDnsFQDN}" > iac-subcomponentoverride.yaml
   

5. Konfigurieren Sie das Config Sync-Ziel:

   kubectl --kubeconfig $JOINING_KUBECONFIG apply -f iac-subcomponentoverride.yaml
   

6. Prüfen Sie, ob das Config Sync-Git-Repository konfiguriert ist:

   kubectl --kubeconfig $JOINING_KUBECONFIG get RootSync -n config-management-system \
       root-sync -o jsonpath='{.spec.git.repo}'
   

7. Achten Sie darauf, dass Config Sync in beiden Zonen (Anker- und Joining-Zone) keine Fehler aufweist.

   kubectl --kubeconfig $JOINING_KUBECONFIG get RootSync \
       -n config-management-system root-sync \
       -o jsonpath='{.status.source.errors[0].errorMessage}'
   

   1. Wenn root-sync den Fehler KNV2004 enthält, ist der Verzeichnispfad, der von der Anker- oder Verbindungszone verwendet wird, nicht im iac-Repository vorhanden. Führen Sie Folgendes aus, um das erforderliche Verzeichnis zu finden:

      kubectl --kubeconfig $JOINING_KUBECONFIG get RootSync \
          -n config-management-system root-sync
          -o jsonpath='{.spec.git.dir}'
      

   2. Erstellen Sie den Pfad, der vom vorherigen Befehl ausgegeben wurde, im Repository iac und fügen Sie eine generische Datei kustomization.yaml hinzu. Führen Sie die Änderungen dann mit dem main-Zweig zusammen.

   3. Führen Sie den ursprünglichen get RootSync-Befehl noch einmal aus, um sicherzustellen, dass Config Sync keine Fehler aufweist.