Google-Dienste verwalten

Distributed Cloud Connected unterstützt die Bereitstellung einer Reihe von Google Cloud Diensten. Diese Dienstarbeitslasten werden in Kubernetes-Containern in Ihren Distributed Cloud Connected-Clustern ausgeführt.

Unterstützte Google Cloud Dienste

Distributed Cloud Connected unterstützt die Bereitstellung der folgenden Google Cloud Dienste:

Diensttyp In den Kosten für GDC Connected enthalten Separat abgerechnet
Computing Google Distributed Cloud (nur Software)
VM Runtime on Google Distributed Cloud		 Gastbetriebssysteme
(Sie müssen eigene Lizenzen erwerben)
Speicher Container Storage Interface (CSI)
Hybridspeicher		 Softwaredefinierter Speicher (Software Defined Storage, SDS),
z. B. Symcloud Storage
(Sie müssen eigene Lizenzen erwerben)
Netzwerk Edge Network API
VLAN-Unterstützung
GKE Custom Network Interface (CNI)-Plug-ins
Gebündelter L4-Load-Balancer von GKE
 Nicht zutreffend
KI/ML AutoML-Modelle in Containern bereitstellen Nicht zutreffend
Datenbank Keine AlloyDB Omni (Vorschau)
Datenbanklösungen von Drittanbietern, z. B. MongoDB
(Sie müssen eigene Lizenzen erwerben)
Beobachtbarkeit Cloud Logging
Cloud Monitoring
Cloud Logging API Logs und ‑Messwerte für GDCc		 Prometheus für die Beobachtbarkeit bei getrennter Verbindung
Benutzerdefinierte Logs und Messwerte auf Anwendungsebene
Konfigurationsverwaltung Config Sync
Flottenpakete in Distributed Cloud Connected verwenden
Flottenpakete (Vorschau)		 Nicht zutreffend
Verwaltung Google Kubernetes Engine-Dashboard in der Google Cloud Console
Connect-Gateway
Das kubectl lokale Tool
Softwareupgrades für Distributed Cloud Connected		 Nicht zutreffend
Sicherheit Cloud Key Management Service-Integration
SED-Laufwerke (Self-Encrypting Disk)
Flotten-Workload-Identität
Audit-Logging 		Nicht zutreffend

Vorbereitung

Bevor Sie Dienste in Distributed Cloud Connected bereitstellen können, müssen Sie die in diesem Abschnitt aufgeführten Voraussetzungen erfüllen. Google Cloud

Clusteranmeldedaten abrufen

Verwenden Sie den folgenden Befehl, um die Anmeldedaten für den Zugriff auf den Zielcluster abzurufen:

 gcloud container hub memberships get-credentials CLUSTER_ID \
       --project="PROJECT_ID"

Ersetzen Sie Folgendes:

  • CLUSTER_ID: der Name des Zielclusters
  • PROJECT_ID: die ID des Ziel Google Cloud projekts

Cluster erstellen oder auswählen

Erstellen Sie einen Distributed Cloud Connected Cluster, falls noch nicht geschehen. Eine Anleitung finden Sie unter Cluster erstellen. Geben Sie beim Erstellen des Clusters mindestens acht virtuelle IP-Adressen (VIPs) an. Diese VIPs werden von den Kubernetes-Containern verwendet, in denen Ihre Google Cloud Dienstarbeitslasten ausgeführt werden.

Wenn Sie einen vorhandenen Cluster verwenden, prüfen Sie mit dem folgenden Befehl, ob genügend VIPs in diesem Cluster verfügbar sind:

 kubectl get cluster --all-namespaces -o jsonpath="{.items[0].spec.loadBalancer.addressPools}"

Die Ausgabe des Befehls sieht in etwa so aus:

[
  {
    "addresses": [
      "10.200.11.188-10.200.11.196"
    ],
    "name": "loadBalancerAddressPool-1"
  }
]

Wenn im Cluster nicht genügend VIPs bereitgestellt wurden, wird der folgende Fehler angezeigt, wobei n die erforderliche Anzahl von VIPs und m die Anzahl der im Cluster gefundenen VIPs ist:

Cluster has less than n external IPs, got m.

Wenn dieser Fehler auftritt, müssen Sie den Cluster löschen und mit einer ausreichenden Anzahl von VIPs neu erstellen.

Die Google Cloud Subdomain desDienstes konfigurieren

Bevor Sie den ersten Google Cloud Dienst in einer Distributed Cloud Connected-Zone bereitstellen, können Sie die Subdomain anpassen, auf der alle Google Cloud in dieser Zone bereitgestellten Dienste auf Verbindungen warten. Sie können diese Subdomain nicht mehr ändern, nachdem Sie mindestens einen Dienst in dieser Distributed Cloud-Zone bereitgestellt haben.

Verwenden Sie den folgenden Befehl, um die Subdomainkonfiguration aufzurufen:

kubectl -n dns-system get celldns cell-dns -o yaml

Die Ausgabe des Befehls sieht in etwa so aus:

apiVersion: system.private.gdc.goog/v1alpha1
kind: CellDNS
metadata:
  name: cell-dns
  namespace: dns-system
spec:
  delegatedSubdomain: private.goog

Verwenden Sie den folgenden Befehl, um die Subdomainkonfiguration zu ändern:

kubectl -n dns-system edit celldns cell-dns

Einen Google Cloud Dienst in Distributed Cloud Connected bereitstellen

Wenn Sie einen Google Cloud Dienst in Ihrem Distributed Cloud Connected Cluster bereitstellen möchten, folgen Sie der Anleitung in der Dokumentation des jeweiligen Dienstes.

Den bereitgestellten Google Cloud Dienst konfigurieren

In diesem Abschnitt werden Konfigurationsschritte nach der Bereitstellung beschrieben, die Sie je nach Ihren geschäftlichen Anforderungen ausführen können.

DNS-Abfragen vom internen DNS an das DNS des Clusters weiterleiten

Wenn Sie einen Google Cloud Dienst in Ihrem Distributed Cloud Connected Cluster bereitstellen, wird ein dedizierter DNS-Server für diesen Dienst im Cluster bereitgestellt. Wir empfehlen, DNS-Abfragen für die Subdomain des Dienstes an den neu erstellten DNS-Server im Cluster weiterzuleiten.

  1. Verwenden Sie die folgenden Befehle, um die Cluster-Subdomain abzurufen:

    CLUSTER_SUBDOMAIN=$(kubectl get configmap -n \
    $(kubectl get clusters -A -o jsonpath="{.items[0].metadata.namespace}") \
    dns-prefix -o jsonpath="{.data.dnsPrefix}")
DELEGATED_SUBDOMAIN=$(kubectl get celldns -n dns-system cell-dns -o \
  jsonpath="{.spec.delegatedSubdomain}")
CLUSTER_FQDN="${CLUSTER_SUBDOMAIN?}.${DELEGATED_SUBDOMAIN?}"
echo "${CLUSTER_FQDN?}"

    Die Ausgabe des letzten Befehls sieht in etwa so aus:

    my-zone.google.private.goog

  2. Verwenden Sie den folgenden Befehl, um die VIP des DNS-Servers im Cluster abzurufen:

    DNS_EXT_IP=$(kubectl -n dns-system get service gpc-coredns-external-tcp -o "jsonpath={.status.loadBalancer.ingress[0].ip}")

  3. Konfigurieren Sie Ihren internen DNS-Server so, dass DNS-Abfragen für den bereitgestellten Google Cloud Dienst an die VIP weitergeleitet werden, die Sie im vorherigen Schritt abgerufen haben. Beispiel:

    • Fügen Sie für dnsmasq Folgendes zu /etc/dnsmasq.conf hinzu:

      server=/${CLUSTER_FQDN?}/${DNS_EXT_IP?}

    • Fügen Sie für CoreDNS Folgendes zur Corefile hinzu:

      ${CLUSTER_FQDN?}:53 {
  errors
  cache 30
  forward . ${DNS_EXT_IP?} {
    max_concurrent 1000
  }
}

DNS-Auflösung testen

Verwenden Sie den folgenden dig-Befehl, um die korrekte Domainauflösung zu testen. Achten Sie besonders auf den Abschnitt ANSWER SECTION:

 dig "ais-core.${CLUSTER_FQDN?}"

Die Ausgabe des Befehls sieht in etwa so aus:

...
;; ANSWER SECTION:
ais-core.my-zone.google.private.goog. 300 IN A 10.200.0.0
...

Das selbst signierte Zertifikat für den bereitgestellten Google Cloud Dienst abrufen

Wenn Sie einen Google Cloud Dienst in Ihrem Distributed Cloud Connected-Cluster bereitstellen, gibt Distributed Cloud Connected ein selbst signiertes Zertifikat aus, mit dem der Netzwerkverkehr für diesen Dienst verschlüsselt wird. Wir empfehlen, dieses Zertifikat abzurufen und Ihre Geschäftsumgebung so zu konfigurieren, dass es als vertrauenswürdig eingestuft wird.

Verwenden Sie den folgenden Befehl, um dieses Zertifikat im PEM-codierten Format abzurufen:

 kubectl get secret -n cert-manager-cluster-resources web-ca-cert -o jsonpath="{.data.ca\.crt}" | base64 -d

Distributed Cloud Connected generiert eine Reihe von Vertrauensbündeln im gesamten Cluster. Diese Vertrauensbündel werden als ConfigMaps in jedem Namespace im Cluster gespeichert. Diese sind:

  • trust-store-internal-only. Enthält Zertifizierungsstellen (Certificate Authorities, CAs) für interne Distributed Cloud Connected-Dienste.
  • trust-store-root-ext. Enthält alle CAs in trust-store-root-ext sowie die CA, die das selbst signierte Zertifikat des Zieldienstes signiert hat.Google Cloud Binden Sie dieses Vertrauensbündel in einen Pod ein, wenn dieser Pod auf den Ziel Google Cloud dienst zugreifen muss.
  • trust-store-user-root-ext. Enthält alle CAs in trust-store-root-ext sowie alle CAs, die Sie manuell hinzugefügt haben. Binden Sie dieses Bündel in einen Pod ein, wenn dieser Pod sowohl auf den Ziel Google Cloud dienst als auch auf interne Ressourcen zugreifen muss, die Zertifikate verwenden, die von den manuell hinzugefügten CAs signiert wurden.

Verwenden Sie den folgenden Befehl, um die Ziel-ConfigMap aufzurufen:

 kubectl -n default get configmap trust-store-user-root-ext -o yaml

Die folgende Beispielausgabe zeigt eine typische trust-store-user-root-ext-ConfigMap-Ressource:

apiVersion: v1
binaryData:
  ca.jks: WW91IGFyZSBhd2Vzb21lIQo=
data:
  ca.crt: |-
    -----BEGIN CERTIFICATE-----
    WW91IGFyZSBncmVhdCEK
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    WW91IGFyZSBmYW50YXN0aWMhCg==
    -----END CERTIFICATE-----
kind: ConfigMap
metadata:
  labels:
    trust.cert-manager.io/bundle: trust-store-user-root-ext
  name: trust-store-user-root-ext
  namespace: default

Einen bereitgestellten Google Cloud Dienst so konfigurieren, dass er Ihre eigenen Zertifikate als vertrauenswürdig einstuft

Sie können ein TLS-Secret in Ihrem Distributed Cloud Connected-Cluster erstellen und es im Namespace cert-manager-cluster-resources mit der Annotation security.private.gdc.goog/bundles=trust-store-user-root-ext versehen. Dadurch kann Ihr bereitgestellter Google Cloud Dienst Ihre internen Drittanbieterdienste als vertrauenswürdig einstufen, um den Datenaustausch zwischen ihnen zu erleichtern.

Wenn Sie dieses Secret auf Ihren Cluster anwenden, stuft der bereitgestellte Google Cloud Dienst das CA-Zertifikat als vertrauenswürdig ein, das in der ca.crt Datei gespeichert ist, auf die im Secret verwiesen wird. Beispiel:

apiVersion: v1
data:
  ca.crt: base64EncodedCaCert
  tls.crt: base64EncodedCert
  tls.key: base64EncodedKey
kind: Secret
metadata:
  annotations:
    security.private.gdc.goog/bundles: trust-store-user-root-ext
  name: my-corporate-cert
  namespace: cert-manager-cluster-resources
type: kubernetes.io/tls

Authentifizierungsanbieter konfigurieren

Sie können einen Authentifizierungsanbieter konfigurieren, um die Anmeldung über die Benutzeroberfläche des bereitgestellten Google Cloud Dienstes zu erleichtern. Das folgende Beispiel zeigt eine Konfiguration für einen OpenID Connect Anbieter:

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  authentication:
  - name: "google-oidc"
    oidc:
      clientID: "my-supersecret-client-id.apps.googleusercontent.com"
      clientSecret: "my-supersecret-secret"
      issuerURI: "https://accounts.google.com"
      scopes: "email"
      userClaim: "email"
  name: "default"

Weitere Informationen finden Sie unter GKE Identity Service für einzelne Cluster einrichten.

Einen bereitgestellten Google Cloud Dienst verwenden

Informationen zum Konfigurieren des bereitgestellten Google Cloud Dienstes gemäß Ihren geschäftlichen Anforderungen finden Sie in der Dokumentation des jeweiligen Dienstes.

Einen bereitgestellten Google Cloud Dienst entfernen

Wenn Sie einen bereitgestellten Google Cloud Dienst aus Ihrem Distributed Cloud Connected-Cluster entfernen möchten, folgen Sie der Anleitung in der Dokumentation des jeweiligen Dienstes. Wenn Sie einen der optionalen Schritte nach der Bereitstellung auf dieser Seite ausgeführt haben, gehen Sie außerdem so vor:

  • Deaktivieren Sie die DNS-Weiterleitung zur Subdomain des Dienstes in Ihrem internen DNS.
  • Deaktivieren Sie die Vertrauensstellung für das selbst signierte Zertifikat des Dienstes überall dort, wo diese Vertrauensstellung eingerichtet wurde.