Google-Dienste verwalten

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

Unterstützte Google Cloud Dienste

Distributed Cloud Connected unterstützt die Bereitstellung der folgendenGoogle Cloud -Dienste:

Diensttyp	In GDC-Verbindungskosten enthalten	Separat abgerechnet
Computing	Google Distributed Cloud (nur Software) VM Runtime on Google Distributed Cloud	Gastbetriebssysteme (Sie müssen Ihre eigenen Lizenzen erwerben)
Speicher	Rohspeicher (nichtflüchtiges Volume) Container Storage Interface (CSI) Hybridspeicher	Software Defined Storage (SDS), z. B. Symcloud Storage (Sie müssen Ihre eigenen Lizenzen erwerben)
Netzwerk	Edge Network API VLAN-Unterstützung GKE Custom Network Interface (CNI)-Plug-ins GKE-gebündelter L4-Load Balancer	Nicht zutreffend
AI/ML	AutoML-Modelle in Containern bereitstellen	Nicht zutreffend
Datenbank	Keine	AlloyDB Omni (Vorabversion) Datenbanklösungen von Drittanbietern wie MongoDB (Sie müssen eigene Lizenzen erwerben)
Beobachtbarkeit	Cloud Logging Cloud Monitoring Cloud Logging API GDCc-Logs und -Messwerte	Prometheus für die Offline-Beobachtbarkeit Benutzerdefinierte Logs und Messwerte auf Anwendungsebene
Konfigurationsverwaltung	Config Sync Flottenpakete (Vorabversion)	Nicht zutreffend
Verwaltung	Google Kubernetes Engine-Dashboard in der Google Cloud Console Connect Gateway Das kubectllokale Tool Software-Upgrades für Distributed Cloud-Verbindungen	Nicht zutreffend
Sicherheit	Cloud Key Management Service-Integration SED-Laufwerke (Self-Encrypting Disk) Fleet Workload Identity Audit-Logging	Nicht zutreffend

Vorbereitung

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

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 gibt den Namen des Zielclusters an.
• PROJECT_ID: die ID des Zielprojekts Google Cloud .

Cluster erstellen oder auswählen

Falls noch nicht geschehen, erstellen Sie einen Distributed Cloud Connected-Cluster, wie unter Cluster erstellen beschrieben. 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 in diesem Cluster genügend VIPs 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 nicht genügend VIPs für den Cluster bereitgestellt wurden, wird der folgende Fehler angezeigt. Dabei ist n die erforderliche Anzahl von VIPs und m die Anzahl der im Cluster gefundenen VIPs:

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.

Google Cloud -Dienst-Subdomain konfigurieren

Bevor Sie den ersten Google Cloud -Dienst in einer mit Distributed Cloud verbundenen Zone bereitstellen, können Sie die Subdomain anpassen, auf der alle Google Cloud -Dienste, die in dieser Zone bereitgestellt werden, 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 Subdomain-Konfiguration 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 Konfiguration der Subdomain zu ändern:

kubectl -n dns-system edit celldns cell-dns

Google Cloud -Dienst in Distributed Cloud Connected bereitstellen

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

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 mit Distributed Cloud verbundenen Cluster bereitstellen, wird ein dedizierter DNS-Server für diesen Dienst im Cluster bereitgestellt. Wir empfehlen, DNS-Anfragen 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?}"
   

   Der letzte Befehl gibt eine Ausgabe ähnlich der folgenden zurück:

   my-zone.google.private.goog
   

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

   DNS_EXT_IP=$(k -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-Anfragen für den bereitgestellten Google Cloud -Dienst an die VIP weitergeleitet werden, die Sie im vorherigen Schritt erhalten haben. Beispiel:

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

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

   • Fügen Sie für CoreDNS Folgendes in die Corefile ein:

     ${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 Folgendes: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
...

Selbst signiertes Zertifikat für den bereitgestellten Google Cloud -Dienst abrufen

Wenn Sie einen Google Cloud -Dienst in Ihrem mit Distributed Cloud verbundenen Cluster bereitstellen, stellt Distributed Cloud Connected ein selbstsigniertes Zertifikat aus, mit dem der Netzwerkverkehr für diesen Dienst verschlüsselt wird. Wir empfehlen Ihnen, dieses Zertifikat abzurufen und Ihre Geschäftsumgebung so zu konfigurieren, dass sie ihm vertraut.

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 Trust-Bundles werden als ConfigMaps in jedem Namespace im Cluster gespeichert. Diese sind:

• trust-store-internal-only: Enthält Zertifizierungsstellen für die internen Dienste von Distributed Cloud Connect.
• trust-store-root-ext: Enthält alle Zertifizierungsstellen in trust-store-root-ext sowie die Zertifizierungsstelle, die das selbst signierte Zertifikat des Ziel-Google Cloud -Dienstes signiert hat. Hängen Sie dieses Trust-Bundle in einem Pod ein, wenn dieser Pod auf den Google Cloud -Zieldienst zugreifen muss.
• trust-store-user-ext: Enthält alle Zertifizierungsstellen in trust-store-root-ext sowie alle Zertifizierungsstellen, die Sie manuell hinzugefügt haben. Stellen Sie dieses Bundle in einem Pod bereit, wenn dieser Pod sowohl auf den Ziel Google Cloud -Dienst als auch auf interne Ressourcen zugreifen muss, die Zertifikate verwenden, die von den CAs signiert wurden, die Sie manuell hinzugefügt haben.

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

Bereitgestellten Google Cloud Dienst so konfigurieren, dass er Ihren eigenen Zertifikaten vertraut

Sie können ein TLS-Secret in Ihrem verbundenen Distributed Cloud-Cluster erstellen und es mit der Annotation security.private.gdc.goog/bundles=trust-store-user-root-ext im Namespace cert-manager-cluster-resources annotieren. So kann Ihr bereitgestellter Google CloudDienst Ihren internen Drittanbieterdiensten vertrauen, um den Datenaustausch zwischen ihnen zu ermöglichen.

Wenn Sie dieses Secret auf Ihren Cluster anwenden, vertraut der bereitgestellte Google Cloud -Dienst dem CA-Zertifikat, das in der im Secret referenzierten ca.crt-Datei gespeichert ist. 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 bereitgestelltenGoogle Cloud -Dienstes zu ermöglichen. 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.

Bereitgestellten Google Cloud Dienst verwenden

Informationen zum Konfigurieren des bereitgestellten Google Cloud -Dienstes, damit er Ihren Geschäftsanforderungen entspricht, finden Sie in der Dokumentation des Dienstes.

Bereitgestellten Google Cloud Dienst entfernen

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

• Deaktivieren Sie die DNS-Weiterleitung zur Subdomain des Dienstes in Ihrem internen DNS.
• Deaktivieren Sie das Vertrauen in das selbstsignierte Zertifikat des Dienstes überall dort, wo es eingerichtet wurde.