Verbindung aus Google Kubernetes Engine herstellen

Auf dieser Seite wird beschrieben, wie Sie eine Verbindung von einer in Google Kubernetes Engine ausgeführten Anwendung zu einer Cloud SQL-Instanz einrichten.

Einführung

Für den Zugriff auf eine Cloud SQL-Instanz von einer Anwendung aus, die in Google Kubernetes Engine ausgeführt wird, können Sie entweder den Cloud SQL Auth-Proxy (mit öffentlicher oder privater IP-Adresse) verwenden oder direkt eine Verbindung über eine private IP-Adresse herstellen.

Wir empfehlen, den Cloud SQL Auth-Proxy zum Herstellen einer Verbindung zu Cloud SQL zu nutzen, auch wenn eine private IP-Adresse verwendet wird. Dies liegt daran, dass der Cloud SQL Auth-Proxy eine starke Verschlüsselung und Authentifizierung mit IAM bietet, wodurch die Sicherheit Ihrer Datenbank gewährleistet werden kann.

Datenbankverbindungen nutzen Ressourcen des Servers und der Anwendung, von der die Verbindung ausgeht. Daher sollten Sie sich bei der Verbindungsverwaltung immer an Best Practices orientieren. So können Sie die Kosten für die Anwendung minimieren und die Wahrscheinlichkeit senken, dass die Verbindungslimits für Cloud SQL überschritten werden. Weitere Informationen finden Sie unter Datenbankverbindungen verwalten.

Hinweis

Zum Herstellen einer Verbindung mit Cloud SQL benötigen Sie Folgendes:

  • Einen GKE-Cluster, in dem das kubectl-Befehlszeilentool installiert und für die Kommunikation mit dem Cluster konfiguriert ist.

    Eine Anleitung für die ersten Schritte mit GKE finden Sie im Schnellstart.

    Um eine Verbindung über eine private IP-Adresse herzustellen, muss der GKE-Cluster VPC-nativ sein und sich im selben VPC-Netzwerk wie die Cloud SQL-Instanz befinden.

  • Eine erstellte Instanz.

    Informationen zum Erstellen einer Cloud SQL-Instanz finden Sie unter Instanzen erstellen.

  • Ein SQL Server-Nutzerkonto, das für die Instanz konfiguriert ist.

    Ihre Anwendung stellt mit diesem Konto eine Verbindung zur Datenbank her. Hilfe beim Erstellen von Nutzerkonten finden Sie unter Nutzer erstellen.

Informationen zu Secrets

In Kubernetes sind Secrets eine sichere Möglichkeit, Konfigurationsdetails an Ihre Anwendung zu übergeben. Sie können ein Secret mit Details wie dem Datenbanknamen, dem Nutzer und dem Passwort erstellen. Diese Details können als Umgebungsvariablen in Ihre Anwendung eingefügt werden.

Je nach Verbindungstyp können Secrets auf unterschiedliche Weise verwendet werden:

  • Ein Secret für Datenbankanmeldedaten enthält den Namen des Datenbanknutzers, mit dem Sie eine Verbindung herstellen, und das Datenbankpasswort des Nutzers.
  • Wenn Sie eine Verbindung über den Cloud SQL Auth-Proxy herstellen, kann ein Secret verwendet werden, um die Anmeldedatendatei Ihres Dienstkontos zu speichern.
  • Wenn Sie eine Verbindung mit einer privaten IP-Adresse herstellen, kann ein Secret verwendet werden, um die private IP-Adresse Ihrer Cloud SQL-Instanz anzugeben.

Vollständige Beispiele zur Verwendung von Secrets finden Sie in den GitHub-Repositories weiter unten auf dieser Seite.

Secret-Objekt erstellen

  1. Sie erstellen die Secret-Objekte mit dem Befehl kubectl create secret.

    So erstellen Sie ein Secret für Datenbankanmeldedaten:

    kubectl create secret generic <YOUR-DB-SECRET> \
      --from-literal=username=<YOUR-DATABASE-USER> \
      --from-literal=password=<YOUR-DATABASE-PASSWORD> \
      --from-literal=database=<YOUR-DATABASE-NAME>
    
  2. Nach der Erstellung können Sie die Objekte im Bereich Konfiguration auf der Google Kubernetes Engine-Seite in der Cloud Console ansehen.

Über den Cloud SQL Auth-Proxy verbinden

Wenn Sie eine Verbindung über den Cloud SQL Auth-Proxy herstellen, wird der Cloud SQL Auth-Proxy mithilfe des Containermusters sidecar zu Ihrem Pod hinzugefügt. Der Cloud SQL Auth-Proxy-Container befindet sich im selben Pod wie Ihre Anwendung, sodass die Anwendung mithilfe von localhost eine Verbindung zum Cloud SQL Auth-Proxy herstellen kann, wodurch Sicherheit und Leistung erhöht werden. Weitere Informationen

Weitere Informationen zum Cloud SQL Auth-Proxy finden Sie unter Informationen zum Cloud SQL Auth-Proxy. Weitere Informationen zum Arbeiten mit Pods finden Sie unter Pod-Übersicht in der Kubernetes-Dokumentation.

Zum Herstellen einer Verbindung mit dem Cloud SQL Auth-Proxy benötigen Sie Folgendes:

  1. Den Namen der Instanzverbindung Ihrer Cloud SQL-Instanz.

    Der Name der Instanzverbindung kann auf der Seite Cloud SQL-Instanzdetails der Cloud Console oder über den Befehl gcloud sql instances describe INSTANCE_ID abgerufen werden.

  2. Den Speicherort der Schlüsseldatei, die einem Dienstkonto mit den erforderlichen Berechtigungen für Ihre Cloud SQL-Instanz zugeordnet ist.

    Weitere Informationen finden Sie unter Dienstkonto erstellen.

  3. Die Cloud SQL Admin API ist aktiviert.

    Aktivieren Sie die API

Dienstkonto für den Cloud SQL Auth-Proxy bereitstellen

Der erste Schritt zum Ausführen des Cloud SQL Auth-Proxys in Google Kubernetes Engine besteht darin, ein Google-Dienstkonto (Google Service Account, GSA) für Ihre Anwendung zu erstellen. Es empfiehlt sich, für jede Anwendung ein eigenes Dienstkonto zu erstellen, anstatt überall dasselbe Dienstkonto zu verwenden. Dieses Modell ist sicherer, da Sie damit Berechtigungen auf Anwendungsbasis beschränken können.

Das Dienstkonto für Ihre Anwendung muss die folgenden Kriterien erfüllen:

  • Es muss zu einem Projekt mit aktivierter Cloud SQL Admin API gehören.
  • Ihm muss die IAM-Rolle "Cloud SQL-Client" oder eine gleichwertige Rolle für das Projekt mit der Instanz zugewiesen sein, zu der Sie eine Verbindung herstellen möchten.
  • Wenn Sie eine Verbindung mithilfe einer privaten IP-Adresse herstellen, muss ein VPC-nativer GKE-Cluster in derselben VPC wie Ihre Cloud SQL-Instanz verwendet werden.

Sie müssen GKE so konfigurieren, dass das Dienstkonto für den Cloud SQL Auth-Proxy bereitgestellt wird. Dafür gibt es zwei Möglichkeiten: über Workload Identity oder eine Schlüsseldatei des Dienstkontos.

Workload Identity

Wenn Sie Google Kubernetes Engine verwenden, wird das GKE-Feature Workload Identity als bevorzugte Methode empfohlen. Mit dieser Methode können Sie ein Kubernetes-Dienstkonto (Kubernetes Service Account, KSA) an ein Google-Dienstkonto (Google Service Account, GSA) binden. Das GSA ist dann für Anwendungen zugänglich, die das entsprechende KSA verwenden.

Ein Google-Dienstkonto (Google Service Account, GSA) ist eine IAM-Identität, die Ihre Anwendung in Google Cloud darstellt. Entsprechend ist ein Kubernetes-Dienstkonto (Kubernetes Service Account, KSA) eine Identität, die Ihre Anwendung in einem Google Kubernetes Engine-Cluster darstellt.

Workload Identity bindet ein KSA an ein GSA. Dadurch werden alle Deployments mit diesem KSA als GSA bei Interaktionen mit Google Cloud authentifiziert.

  1. Workload Identity für den Cluster aktivieren
  2. Normalerweise hat jede Anwendung eine eigene Identität, die durch ein KSA- und GSA-Paar dargestellt wird. Führen Sie kubectl apply -f service-account.yaml aus, um ein KSA für Ihre Anwendung zu erstellen:

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: <YOUR-KSA-NAME> # TODO(developer): replace these values
  3. Aktivieren Sie die IAM-Bindung zwischen YOUR-GSA-NAME und YOUR-KSA-NAME:

    gcloud iam service-accounts add-iam-policy-binding \
      --role roles/iam.workloadIdentityUser \
      --member "serviceAccount:<YOUR-GCP-PROJECT>.svc.id.goog[<YOUR-K8S-NAMESPACE>/<YOUR-KSA-NAME>]" \
      <YOUR-GSA-NAME>@<YOUR-GCP-PROJECT>.iam.gserviceaccount.com
    
  4. Fügen Sie YOUR-KSA-NAME eine Anmerkung hinzu, um die Bindung fertigzustellen:

    kubectl annotate serviceaccount \
       <YOUR-KSA-NAME> \
       iam.gke.io/gcp-service-account=<YOUR-GSA-NAME>@<YOUR-GCP-PROJECT>.iam.gserviceaccount.com
    
  5. Geben Sie schließlich das Dienstkonto für das k8s-Objekt an.

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: <YOUR-DEPLOYMENT-NAME>
    spec:
      selector:
        matchLabels:
          app: <YOUR-APPLICATION-NAME>
      template:
        metadata:
          labels:
            app: <YOUR-APPLICATION-NAME>
        spec:
          serviceAccountName: <YOUR-KSA-NAME>

Dienstkontoschlüsseldatei

Wenn Sie Workload Identity nicht verwenden können, wird empfohlen, eine Dienstkonto-Schlüsseldatei im Pod des Cloud SQL Auth-Proxys bereitzustellen und das Flag -credential_file zu verwenden.

  1. Erstellen Sie eine Anmeldedatendatei für Ihren Dienstkontoschlüssel:

    gcloud iam service-accounts keys create ~/key.json \
      --iam-account <YOUR-SA-NAME>@project-id.iam.gserviceaccount.com
    
  2. Machen Sie aus Ihrem Dienstkontoschlüssel ein k8s-Secret:

    kubectl create secret generic <YOUR-SA-SECRET> \
    --from-file=service_account.json=~/key.json
    
  3. Stellen Sie das Secret als Volume unter spec: für Ihr k8s-Objekt bereit:

    volumes:
    - name: <YOUR-SA-SECRET-VOLUME>
      secret:
        secretName: <YOUR-SA-SECRET>
  4. Folgen Sie der Anleitung im nächsten Abschnitt, um auf das Volume aus dem Pod des Cloud SQL Auth-Proxys zuzugreifen.

Cloud SQL Auth-Proxy als Sidecar ausführen

Wir empfehlen, den Cloud SQL Auth-Proxy in einem sidecar-Muster auszuführen (als zusätzlichen Container, der einen Pod für Ihre Anwendung freigibt). Diese Vorgehensweise wird aus verschiedenen Gründen gegenüber der Ausführung eines separaten Dienstes empfohlen:

  • Verhindert, dass SQL-Traffic lokal verfügbar gemacht wird. Der Cloud SQL Auth-Proxy bietet die Möglichkeit, ausgehende Verbindungen zu verschlüsseln, aber Sie sollten die Sichtbarkeit für eingehende Verbindungen einschränken.
  • Verhindert einen Single Point of Failure. Der Zugriff jeder Anwendung auf Ihre Datenbank ist unabhängig von den anderen, was die Ausfallsicherheit erhöht.
  • Beschränkt den Zugriff auf den Cloud SQL Auth-Proxy, sodass Sie IAM-Berechtigungen pro Anwendung verwenden können, anstatt die Datenbank für den gesamten Cluster freizugeben.
  • Ermöglicht eine genauere Bestimmung von Ressourcenanfragen. Da der Cloud SQL Auth-Proxy Ressourcen linear zur Nutzung verbraucht, können Sie mit diesem Muster Ressourcen genauer bestimmen und entsprechend der Skalierung Ihrer Anwendungen anfordern.

  • Fügen Sie den Cloud SQL Auth-Proxy der Pod-Konfiguration unter containers hinzu:

    - name: cloud-sql-proxy
      # It is recommended to use the latest version of the Cloud SQL proxy
      # Make sure to update on a regular schedule!
      image: gcr.io/cloudsql-docker/gce-proxy:1.17
      command:
        - "/cloud_sql_proxy"
    
        # If connecting from a VPC-native GKE cluster, you can use the
        # following flag to have the proxy connect over private IP
        # - "-ip_address_types=PRIVATE"
    
        # Replace DB_PORT with the port the proxy should listen on
        # Defaults: MySQL: 3306, Postgres: 5432, SQLServer: 1433
        - "-instances=<INSTANCE_CONNECTION_NAME>=tcp:<DB_PORT>"
      securityContext:
        # The default Cloud SQL proxy image runs as the
        # "nonroot" user and group (uid: 65532) by default.
        runAsNonRoot: true
      # Resource configuration depends on an application's requirements. You
      # should adjust the following values based on what your application
      # needs. For details, see https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
      resources:
        requests:
          # The proxy's memory use scales linearly with the number of active
          # connections. Fewer open connections will use less memory. Adjust
          # this value based on your application's requirements.
          memory: "2Gi"
          # The proxy's CPU use scales linearly with the amount of IO between
          # the database and the application. Adjust this value based on your
          # application's requirements.
          cpu:    "1"

    Wenn Sie einen Dienstkontoschlüssel verwenden, geben Sie Ihr Secret-Volume an und fügen Sie dem Befehl das Flag -credential_file hinzu:

      # This flag specifies where the service account key can be found
      - "-credential_file=/secrets/service_account.json"
    securityContext:
      # The default Cloud SQL proxy image runs as the
      # "nonroot" user and group (uid: 65532) by default.
      runAsNonRoot: true
    volumeMounts:
    - name: <YOUR-SA-SECRET-VOLUME>
      mountPath: /secrets/
      readOnly: true
  • Abschließend konfigurieren Sie Ihre Anwendung so, dass eine Verbindung über 127.0.0.1 auf dem DB_PORT hergestellt wird, den Sie im Befehlsbereich angegeben haben.

Vollständige Beispielkonfigurationsdateien:

Cloud SQL Auth-Proxy mit Workload Identity

apiVersion: apps/v1
kind: Deployment
metadata:
  name: <YOUR-DEPLOYMENT-NAME>
spec:
  selector:
    matchLabels:
      app: <YOUR-APPLICATION-NAME>
  template:
    metadata:
      labels:
        app: <YOUR-APPLICATION-NAME>
    spec:
      serviceAccountName: <YOUR-KSA-NAME>
      containers:
      - name: <YOUR-APPLICATION-NAME>
        # ... other container configuration
        env:
        - name: DB_USER
          valueFrom:
            secretKeyRef:
              name: <YOUR-DB-SECRET>
              key: username
        - name: DB_PASS
          valueFrom:
            secretKeyRef:
              name: <YOUR-DB-SECRET>
              key: password
        - name: DB_NAME
          valueFrom:
            secretKeyRef:
              name: <YOUR-DB-SECRET>
              key: database
      - name: cloud-sql-proxy
        # It is recommended to use the latest version of the Cloud SQL proxy
        # Make sure to update on a regular schedule!
        image: gcr.io/cloudsql-docker/gce-proxy:1.17
        command:
          - "/cloud_sql_proxy"

          # If connecting from a VPC-native GKE cluster, you can use the
          # following flag to have the proxy connect over private IP
          # - "-ip_address_types=PRIVATE"

          # Replace DB_PORT with the port the proxy should listen on
          # Defaults: MySQL: 3306, Postgres: 5432, SQLServer: 1433
          - "-instances=<INSTANCE_CONNECTION_NAME>=tcp:<DB_PORT>"
        securityContext:
          # The default Cloud SQL proxy image runs as the
          # "nonroot" user and group (uid: 65532) by default.
          runAsNonRoot: true
        # Resource configuration depends on an application's requirements. You
        # should adjust the following values based on what your application
        # needs. For details, see https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
        resources:
          requests:
            # The proxy's memory use scales linearly with the number of active
            # connections. Fewer open connections will use less memory. Adjust
            # this value based on your application's requirements.
            memory: "2Gi"
            # The proxy's CPU use scales linearly with the amount of IO between
            # the database and the application. Adjust this value based on your
            # application's requirements.
            cpu:    "1"

Cloud SQL Auth-Proxy mit Dienstkontoschlüssel

apiVersion: apps/v1
kind: Deployment
metadata:
  name: <YOUR-DEPLOYMENT-NAME>
spec:
  selector:
    matchLabels:
      app: <YOUR-APPLICATION-NAME>
  template:
    metadata:
      labels:
        app: <YOUR-APPLICATION-NAME>
    spec:
      containers:
      - name: <YOUR-APPLICATION-NAME>
        # ... other container configuration
        env:
        - name: DB_USER
          valueFrom:
            secretKeyRef:
              name: <YOUR-DB-SECRET>
              key: username
        - name: DB_PASS
          valueFrom:
            secretKeyRef:
              name: <YOUR-DB-SECRET>
              key: password
        - name: DB_NAME
          valueFrom:
            secretKeyRef:
              name: <YOUR-DB-SECRET>
              key: database
      - name: cloud-sql-proxy
        # It is recommended to use the latest version of the Cloud SQL proxy
        # Make sure to update on a regular schedule!
        image: gcr.io/cloudsql-docker/gce-proxy:1.17
        command:
          - "/cloud_sql_proxy"

          # If connecting from a VPC-native GKE cluster, you can use the
          # following flag to have the proxy connect over private IP
          # - "-ip_address_types=PRIVATE"

          # Replace DB_PORT with the port the proxy should listen on
          # Defaults: MySQL: 3306, Postgres: 5432, SQLServer: 1433
          - "-instances=<INSTANCE_CONNECTION_NAME>=tcp:<DB_PORT>"

          # This flag specifies where the service account key can be found
          - "-credential_file=/secrets/service_account.json"
        securityContext:
          # The default Cloud SQL proxy image runs as the
          # "nonroot" user and group (uid: 65532) by default.
          runAsNonRoot: true
        volumeMounts:
        - name: <YOUR-SA-SECRET-VOLUME>
          mountPath: /secrets/
          readOnly: true
        # Resource configuration depends on an application's requirements. You
        # should adjust the following values based on what your application
        # needs. For details, see https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
        resources:
          requests:
            # The proxy's memory use scales linearly with the number of active
            # connections. Fewer open connections will use less memory. Adjust
            # this value based on your application's requirements.
            memory: "2Gi"
            # The proxy's CPU use scales linearly with the amount of IO between
            # the database and the application. Adjust this value based on your
            # application's requirements.
            cpu:    "1"
      volumes:
      - name: <YOUR-SA-SECRET-VOLUME>
        secret:
          secretName: <YOUR-SA-SECRET>

Verbindung ohne Cloud SQL Auth-Proxy herstellen

Sie können auch eine Verbindung von einem VPC-nativen GKE-Cluster zu einer Cloud SQL-Instanz in derselben VPC mit privater IP-Adresse ohne den Cloud SQL Auth-Proxy herstellen. Diese Vorgehensweise ist jedoch weniger sicher.

  1. Erstellen Sie ein Secret mit der privaten IP-Adresse Ihrer Instanz:

    kubectl create secret generic <YOUR-PRIVATE-IP-SECRET> \
        --from-literal=db_host=<YOUR-PRIVATE-IP-ADDRESS>
    
  2. Als Nächstes fügen Sie das Secret dem Container Ihrer Anwendung hinzu:

    - name: DB_HOST
      valueFrom:
        secretKeyRef:
          name: <YOUR-PRIVATE-IP-SECRET>
          key: db_host
  3. Abschließend konfigurieren Sie Ihre Anwendung so, dass eine Verbindung mit der IP-Adresse aus der Umgebungsvariable DB_HOST hergestellt wird. Sie müssen den richtigen Port für SQL Server verwenden: 1433

Vollständige Beispielkonfigurationsdatei:

Kein Cloud SQL Auth-Proxy – Private IP-Adresse

apiVersion: apps/v1
kind: Deployment
metadata:
  name: <YOUR-DEPLOYMENT-NAME>
spec:
  selector:
    matchLabels:
      app: <YOUR-APPLICATION-NAME>
  template:
    metadata:
      labels:
        app: <YOUR-APPLICATION-NAME>
    spec:
      containers:
      - name: <YOUR-APPLICATION-NAME>
        # ... other container configuration
        env:
        - name: DB_USER
          valueFrom:
            secretKeyRef:
              name: <YOUR-DB-SECRET>
              key: username
        - name: DB_PASS
          valueFrom:
            secretKeyRef:
              name: <YOUR-DB-SECRET>
              key: password
        - name: DB_NAME
          valueFrom:
            secretKeyRef:
              name: <YOUR-DB-SECRET>
              key: database
        - name: DB_HOST
          valueFrom:
            secretKeyRef:
              name: <YOUR-PRIVATE-IP-SECRET>
              key: db_host

Benötigen Sie Hilfe? Informationen zur Fehlerbehebung für den Proxy finden Sie unter Fehlerbehebung bei Cloud SQL Auth-Proxyverbindungen. Weitere Informationen erhalten Sie auf der Cloud SQL-Supportseite.

Weitere Informationen