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 Ihre eigenen Lizenzen erwerben)
Speicher Container Storage Interface (CSI)
Hybridspeicher		 Softwaredefinierter Speicher (Software Defined Storage, SDS),
wie Symcloud Storage
(Sie müssen Ihre eigenen Lizenzen erwerben)
Netzwerk Edge Network API
VLAN-Unterstützung
GKE Custom Network Interface (CNI)-Plug-ins
Gebündelter L4-Load-Balancer für GKE
 Nicht zutreffend
KI/ML AutoML-Modelle in Containern bereitstellen Nicht zutreffend
Datenbank Keine AlloyDB Omni (selbstverwaltet) (Vorschau)
Datenbanklösungen von Drittanbietern wie MongoDB
(Sie müssen Ihre eigenen Lizenzen erwerben)
Beobachtbarkeit Cloud Logging
Cloud Monitoring
Cloud Logging API
GDCc-Logs und -Messwerte
Fleet-Logging
Fleet-Monitoring		 Prometheus für die Beobachtbarkeit bei getrennter Verbindung
Benutzerdefinierte Logs und Messwerte auf Anwendungsebene
Konfigurationsverwaltung Config Sync (einschließlich Fleet-Pakete) Nicht zutreffend
Verwaltung Google Kubernetes Engine-Dashboard in der Google Cloud Console
Connect-Gateway
Das kubectl lokale Tool
Softwareupgrades für Distributed Cloud Connected
Fleet-Teamverwaltung und -Namespaces
Die gcloud CLI		 Nicht zutreffend
Sicherheit Cloud Key Management Service-Integration
SED-Laufwerke (Self-Encrypting Disk)
Fleet Workload Identity
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: gibt den Namen des Zielclusters an.
  • 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 nicht genügend VIPs im Cluster 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.

Subdomain des Google Cloud Dienstes 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

Dienst in Distributed Cloud Connected bereitstellen Google Cloud

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.

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 zum 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
...

Selbst signiertes 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 vertrauenswürdig ist.

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 in Ihrem Cluster eine Reihe von Trust-Bundles. Diese Trust-Bundles 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 Ziel Google Cloud dienstes signiert hat. Binden Sie dieses Trust-Bundle in einem 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 Bundle in einem 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 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 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. So kann Ihr bereitgestellter Google Cloud Dienst Ihren internen Drittanbieterdiensten vertrauen, um den Datenaustausch zwischen ihnen zu erleichtern.

Wenn Sie dieses Secret auf Ihren Cluster anwenden, vertraut der bereitgestellte Google Cloud Dienst dem CA-Zertifikat, 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.

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.

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 so vor:

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