Helm-Diagramme aus Artifact Registry synchronisieren

Auf dieser Seite erfahren Sie, wie Sie Helm-Diagramme aus Artifact Registry synchronisieren, indem Sie ein Helm-Diagramm erstellen und per Push in ein Repository in Artifact Registry übertragen. Es enthält auch eine Beispielkonfiguration zur Synchronisierung eines Diagramms aus Ihrem Helm-Repository.

Sie können Config Sync für die Synchronisierung aus Helm-Repositories konfigurieren. Sie können Helm-Diagramme in Artifact Registry speichern, dem empfohlenen Helm-Repository für Google Cloud. Um diese Funktion verwenden zu können, müssen Sie die RootSync- und RepoSync APIs aktivieren. Config Sync rendert Helm-Diagramme mit helm template und unterstützt daher keine vollständige Verwaltung des Helm-Lebenszyklus.

Gebündelte Helm- und Kustomize-Versionen listet die Kustomize- und Helm-Versionen auf, die mit der entsprechenden Version von Config Sync gebündelt sind.

Hinweise

Beschränkungen

  • Sie können ein unveränderliches Feld in einer Konfiguration nicht ändern, indem Sie einfach den Wert in der "Source of Truth" ändern. Wenn Sie ein unveränderliches Feld aktualisieren müssen, nehmen Sie zuerst die Änderung in der "Source of Truth" vor und löschen Sie dann das Objekt manuell im Cluster. Config Sync kann das Objekt dann mit dem neuen Feldwert neu erstellen.

  • Die folgenden Helm-Diagramme enthalten Jobs und werden für die Bereitstellung durch Config Sync nicht empfohlen:

    Weitere Informationen dazu, warum Jobs für die Verwendung mit Config Sync nicht empfohlen werden, finden Sie unter Verwaltung von Jobs mit Config Sync vermeiden.

Artifact Registry-Repository erstellen

In diesem Abschnitt erstellen Sie ein Artifact Registry-Repository. Weitere Informationen zum Erstellen von Artifact Registry-Repositories finden Sie unter Repositories erstellen.

  1. Aktivieren Sie die Artifact Registry API:

    gcloud services enable artifactregistry.googleapis.com --project=PROJECT_ID
    
  2. Erstellen Sie ein Artifact Registry-Repository:

    gcloud artifacts repositories create AR_REPO_NAME \
       --repository-format=docker \
       --location=AR_REGION \
       --description="Config Sync Helm repo" \
       --project=PROJECT_ID
    

Ersetzen Sie Folgendes:

  • PROJECT_ID: die Projekt-ID der Organisation.
  • AR_REPO_NAME: ID des Repositorys.
  • AR_REGION: der regionale oder multiregionale Speicherort für das Repository.

In den folgenden Abschnitten verwendete Variablen:

  • FLEET_HOST_PROJECT_ID: Wenn Sie GKE Workload Identity verwenden, entspricht dies PROJECT_ID. Wenn Sie Flotten-Workload Identity verwenden, ist dies die Projekt-ID der Flotte, bei der Ihr Cluster registriert ist.
  • GSA_NAME: Name des benutzerdefinierten Google-Dienstkontos, mit dem Sie eine Verbindung zu Artifact Registry herstellen möchten.
  • KSA_NAME: das Kubernetes-Dienstkonto für den Abgleich.
    • Fügen Sie für Stamm-Repositories root-reconciler hinzu, wenn der Name RootSync root-sync ist. Fügen Sie andernfalls root-reconciler-ROOT_SYNC_NAME hinzu.
    • Für Namespace-Repositories gilt: Wenn der RepoSync-Name repo-sync lautet, fügen Sie ns-reconciler-NAMESPACE hinzu. Fügen Sie andernfalls ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH hinzu, wobei REPO_SYNC_NAME_LENGTH die Anzahl der Zeichen in REPO_SYNC_NAME ist.

Leseberechtigung erteilen

Wenn die Config Sync-Version 1.17.2 oder höher in Ihrem Cluster ist, können Sie sich mit dem Kubernetes-Dienstkonto bei Artifact Registry authentifizieren. Andernfalls verwenden Sie das Google-Dienstkonto zur Authentifizierung.

Kubernetes-Dienstkonto verwenden

Weisen Sie dem Kubernetes-Dienstkonto mit dem Workload Identity-Pool die IAM-Rolle Artifact Registry-Leser (roles/artifactregistry.reader) zu:

gcloud artifacts repositories add-iam-policy-binding AR_REPO_NAME \
    --location=AR_REGION \
    --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
    --role=roles/artifactregistry.reader \
    --project=PROJECT_ID

Google-Dienstkonto verwenden

  1. Weisen Sie dem Google-Dienstkonto die IAM-Rolle Artifact Registry-Leser (roles/artifactregistry.reader) zu:

    gcloud artifacts repositories add-iam-policy-binding AR_REPO_NAME \
       --location=AR_REGION \
       --member=serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/artifactregistry.reader \
       --project=PROJECT_ID
    
  2. Erstellen Sie eine IAM-Richtlinienbindung zwischen dem Kubernetes-Dienstkonto und dem Google-Dienstkonto:

    gcloud iam service-accounts add-iam-policy-binding \
       --role roles/iam.workloadIdentityUser \
       --member "serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
       GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
       --project=PROJECT_ID
    

Helm-Diagramm per Push in das Artifact Registry-Repository übertragen

In diesem Abschnitt laden Sie ein öffentliches Helm-Diagramm herunter und übertragen es per Push in Artifact Registry.

  1. Rufen Sie das mysql-9.3.1.tgz-Paket aus dem öffentlichen Helm-Repository ab und laden Sie es lokal herunter:

    helm pull mysql --repo https://charts.bitnami.com/bitnami --version 9.3.1
    
  2. Authentifizieren Sie sich mit einem Zugriffstoken:

    Linux/macOS

    gcloud auth print-access-token | helm registry login -u oauth2accesstoken \
    --password-stdin https://AR_REGION-docker.pkg.dev
    

    Windows

    gcloud auth print-access-token
    ya29.8QEQIfY_...
    
    helm registry login -u oauth2accesstoken -p "ya29.8QEQIfY_..." \
    https://AR_REGION-docker.pkg.dev/PROJECT_ID/AR_REPO_NAME
    

    In diesem Befehl ist oauth2accesstoken der Nutzername für die Authentifizierung mit einem Zugriffstoken und gcloud auth print-access-token der Befehl zum Abrufen des Zugriffstokens. Ihr Zugriffstoken ist das Passwort für die Authentifizierung. Die Authentifizierung mit einem Zugriffstoken ist die sicherste Authentifizierungsmethode.

  3. Übertragen Sie das Helm-Diagramm per Push in Artifact Registry:

    helm push mysql-9.3.1.tgz oci://AR_REGION-docker.pkg.dev/PROJECT_ID/AR_REPO_NAME
    

Config Sync für die Synchronisierung aus Ihrem Helm-Diagramm konfigurieren

In diesem Abschnitt erstellen Sie ein RootSync-Objekt und konfigurieren Config Sync für die Synchronisierung aus dem Helm-Diagramm.

Wenn Sie die Standardwerte des Helm-Diagramms überschreiben möchten, geben Sie entweder Werte im Feld spec.helm.values an oder fügen Sie einen Verweis zu einer ConfigMap hinzu Mithilfe des Felds spec.helm.valuesFileRefs (in Config Sync Version 1.16.0 und höher). Weitere Informationen zu den optionalen Feldern finden Sie unter Konfiguration für das Helm-Repository.

Werte

  1. Erstellen Sie ein RootSync-Objekt mit einem eindeutigen Namen:

    cat <<EOF>> ROOT_SYNC_NAME.yaml
    apiVersion: configsync.gke.io/v1beta1
    kind: RootSync
    metadata:
      name: ROOT_SYNC_NAME
      namespace: config-management-system
    spec:
      sourceFormat: unstructured
      sourceType: helm
      helm:
        repo: oci://AR_REGION-docker.pkg.dev/PROJECT_ID/AR_REPO_NAME
        chart: mysql
        version: 9.3.1
        releaseName: my-mysql
        namespace: test
        # The k8sserviceaccount auth type is available in version 1.17.2 and
        # later. Use `gcpserviceaccount` if using an older version.
        # auth: gcpserviceaccount
        # gcpServiceAccountEmail: GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
        auth: k8sserviceaccount
        # Use the optional field spec.helm.values to override default values.
        # You can use the same format as the default values file to override
        # default values.
        values:
          image:
            pullPolicy: Always
          primary:
            resources:
              limits:
                cpu: 250m
                memory: 256Mi
              requests:
                cpu: 250m
                memory: 256Mi
    EOF
    

    Ersetzen Sie dabei ROOT_SYNC_NAME durch den Namen Ihres RootSync-Objekts. Der Name darf im Cluster nur einmal vorkommen und darf nicht mehr als 26 Zeichen haben. Wenn Sie Config Sync mit der Google Cloud Console oder der Google Cloud CLI installiert haben, wählen Sie einen anderen Namen als root-sync aus.

    In diesem Beispiel wird das Helm-Diagramm im Namespace test bereitgestellt, da seine Ressourcen namespace: {{ .Release.Namespace }} in seinen Vorlagen enthalten.

    Mit helm.values können Sie die Standardwerte überschreiben. Weitere Informationen zu den optionalen Feldern finden Sie unter Konfiguration für das Helm-Repository.

  2. Wenden Sie das RootSync-Objekt an:

    kubectl apply -f ROOT_SYNC_NAME.yaml
    
  3. Prüfen Sie, ob Config Sync mit dem Image synchronisiert wird:

    nomos status --contexts=$(kubectl config current-context)
    

    Die Ausgabe sieht in etwa so aus:

    Connecting to clusters...
    
    *cluster-name
      --------------------
      <root>:root-sync   oci://AR_REGION-docker.pkg.dev/PROJECT_ID/AR_REPO_NAME/mysql:9.3.1
      SYNCED             9.3.1
      Managed resources:
          NAMESPACE  NAME                       STATUS    SOURCEHASH
          default    configmap/my-mysql         Current   9.3.1
          default    secret/my-mysql            Current   9.3.1
          default    service/my-mysql           Current   9.3.1
          default    service/my-mysql-headless  Current   9.3.1
          default    serviceaccount/my-mysql    Current   9.3.1
          default    statefulset.apps/my-mysql  Current   9.3.1
    

    Sie haben das Helm-Diagramm jetzt erfolgreich in Ihren Cluster synchronisiert.

valuesFileRefs

  1. Erstellen Sie ein RootSync-Objekt mit einem eindeutigen Namen:

    cat <<EOF>> ROOT_SYNC_NAME.yaml
    apiVersion: configsync.gke.io/v1beta1
    kind: RootSync
    metadata:
      name: ROOT_SYNC_NAME
      namespace: config-management-system
    spec:
      sourceFormat: unstructured
      sourceType: helm
      helm:
        repo: oci://AR_REGION-docker.pkg.dev/PROJECT_ID/AR_REPO_NAME
        chart: mysql
        version: 9.3.1
        releaseName: my-mysql
        # The k8sserviceaccount auth type is available in version 1.17.2 and
        # later. Use `gcpserviceaccount` if using an older version.
        # auth: gcpserviceaccount
        # gcpServiceAccountEmail: GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
        auth: k8sserviceaccount
        # use the optional field spec.helm.valuesFilesRefs to override default values
        # by referencing a ConfigMap
        valuesFileRefs:
        - name: CONFIGMAP_NAME
          dataKey: DATA_KEY
    
    EOF
    

    Ersetzen Sie Folgendes:

    • ROOT_SYNC_NAME: der Name Ihres RootSync-Objekts. Der Name darf im Cluster nur einmal vorkommen und darf nicht mehr als 26 Zeichen haben. Wenn Sie Config Sync mit der Google Cloud Console oder der Google Cloud CLI installiert haben, wählen Sie einen anderen Namen als root-sync aus.
    • CONFIGMAP_NAME: der Name Ihrer ConfigMap. Dies kann ein beliebiger gültiger ConfigMap-Name sein, der von Kubernetes akzeptiert wird und in Ihrem Cluster eindeutig ist.
    • (Optional) DATA_KEY: der Datenschlüssel in Ihrer ConfigMap, aus der Sie die Werte lesen möchten. Der Standardwert ist values.yaml.
  2. Erstellen Sie das ConfigMap-Objekt mit Ihren Werten:

    cat <<EOF>> CONFIGMAP_NAME.yaml
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: CONFIGMAP_NAME
      namespace: config-management-system
    immutable: true
    # You can use the same format as the default values file to override
    # default values.
    data:
      DATA_KEY: |-
        image:
          pullPolicy: Always
        primary:
          resources:
            limits:
              cpu: 250m
              memory: 256Mi
            requests:
              cpu: 250m
              memory: 256Mi
    
    EOF
    

    Wenn Sie in RootSync keinen Wert für DATA_KEY angegeben haben, sollte dies der Standardwert values.yaml sein.

  3. Wenden Sie das ConfigMap-Objekt an:

    kubectl apply -f CONFIGMAP_NAME.yaml
    
  4. Wenden Sie das RootSync-Objekt an:

    kubectl apply -f ROOT_SYNC_NAME.yaml
    
  5. Prüfen Sie, ob Config Sync mit dem Image synchronisiert wird:

    nomos status --contexts=$(kubectl config current-context)
    

    Die Ausgabe sieht in etwa so aus:

    Connecting to clusters...
    
    *cluster-name
      --------------------
      <root>:root-sync   oci://AR_REGION-docker.pkg.dev/PROJECT_ID/AR_REPO_NAME/mysql:9.3.1
      SYNCED             9.3.1
      Managed resources:
          NAMESPACE  NAME                       STATUS    SOURCEHASH
          default    configmap/my-mysql         Current   9.3.1
          default    secret/my-mysql            Current   9.3.1
          default    service/my-mysql           Current   9.3.1
          default    service/my-mysql-headless  Current   9.3.1
          default    serviceaccount/my-mysql    Current   9.3.1
          default    statefulset.apps/my-mysql  Current   9.3.1
    

    Sie haben das Helm-Diagramm jetzt erfolgreich in Ihren Cluster synchronisiert.

    Sie können auch imagePullPolicy in einer der synchronisierten Ressourcen im Cluster ansehen, um zu prüfen, ob die Werte aus der ConfigMap zum Rendern des Diagramms verwendet wurden:

    kubectl get statefulset -n test my-mysql -o yaml | grep imagePullPolicy
    
  6. Da die ConfigMap unveränderlich ist, müssen Sie zum Ändern der Werte eine neue ConfigMap erstellen und spec.helm.valuesFileRefs in der RootSync- oder RepoSync-Spezifikation so aktualisieren, dass sie auf die neue ConfigMap verweist. Durch die Erstellung einer neuen ConfigMap wird sichergestellt, dass Änderungen an Werten das Helm-Diagramm zum neu rendern zwingen. Dies ist nützlich, wenn mehrere ConfigMaps, auf die in spec.helm.valuesFileRefs verwiesen wird, gleichzeitig aktualisiert werden müssen, wenn das Helm-Diagramm neu rendert. “ Erstellen Sie eine neue ConfigMap mit einem anderen Namen, um die Werte zu ändern, die zum Rendern Ihres Diagramms verwendet werden:

    cat <<EOF>> CONFIGMAP_NAME-2.yaml
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: CONFIGMAP_NAME-2
      namespace: config-management-system
    immutable: true
    # You can use the same format as the default values file to override
    # default values.
    data:
      DATA_KEY: |-
        image:
          pullPolicy: Never
        primary:
          resources:
            limits:
              cpu: 100m
              memory: 256Mi
            requests:
              cpu: 250m
              memory: 200Mi
    
    EOF
    
  7. Aktualisieren Sie Ihr RootSync-Objekt, sodass es auf die neue ConfigMap verweist:

    cat <<EOF>> ROOT_SYNC_NAME.yaml
    apiVersion: configsync.gke.io/v1beta1
    kind: RootSync
    metadata:
      name: ROOT_SYNC_NAME
      namespace: config-management-system
    spec:
      sourceFormat: unstructured
      sourceType: helm
      helm:
        repo: oci://AR_REGION-docker.pkg.dev/PROJECT_ID/AR_REPO_NAME
        chart: mysql
        version: 9.3.1
        releaseName: my-mysql
        namespace: test
        # The k8sserviceaccount auth type is available in version 1.17.2 and
        # later. Use `gcpserviceaccount` if using an older version.
        # auth: gcpserviceaccount
        # gcpServiceAccountEmail: GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
        auth: k8sserviceaccount
        # use the optional field spec.helm.valuesFilesRefs to override default values
        # by referencing a ConfigMap
        valuesFileRefs:
        - name: CONFIGMAP_NAME-2
          dataKey: DATA_KEY
    
    EOF
    
  8. Wenden Sie das ConfigMap-Objekt an:

    kubectl apply -f CONFIGMAP_NAME-2.yaml
    
  9. Wenden Sie das RootSync-Objekt an:

    kubectl apply -f ROOT_SYNC_NAME.yaml
    
  10. Prüfen Sie, ob Config Sync mit dem Image synchronisiert wird:

    nomos status --contexts=$(kubectl config current-context)
    

    Sie können auch imagePullPolicy in einer der synchronisierten Ressourcen im Cluster ansehen, um zu prüfen, ob die neuen Werte aus der aktualisierten ConfigMap zum Rendern des Diagramms verwendet wurden:

    kubectl get statefulset -n test my-mysql -o yaml | grep imagePullPolicy
    

Nächste Schritte