Gestisci i servizi Google

Distributed Cloud connesso supporta il deployment di una serie di Google Cloud servizi. Questi carichi di lavoro dei servizi vengono eseguiti nei container Kubernetes sui cluster Distributed Cloud connessi.

Servizi supportati Google Cloud

Distributed Cloud connesso supporta il deployment dei seguenti Google Cloud servizi:

Tipo di servizio Incluso nei costi di GDC connesso Fatturato separatamente
Computing Google Distributed Cloud solo software
VM Runtime su Google Distributed Cloud
Sistemi operativi guest
(devi ottenere le tue licenze)
Spazio di archiviazione Container Storage Interface (CSI)
Spazio di archiviazione ibrido
Software Defined Storage (SDS),
come Symcloud Storage
(devi ottenere le tue licenze)
Networking API Edge Network
Supporto VLAN
Plug-in GKE Custom Network Interface (CNI)
Bilanciamento del carico L4 in bundle GKE
Non applicabile
AI/ML Deployment di modelli AutoML nei container Non applicabile
Database Nessuno AlloyDB Omni (autogestito) (anteprima)
Soluzioni di database di terze parti, come MongoDB
(devi ottenere le tue licenze)
Osservabilità Cloud Logging
Cloud Monitoring
API Cloud Logging
Log e metriche GDCc
Logging del parco risorse
Monitoraggio del parco risorse
Prometheus per l'osservabilità disconnessa
Log e metriche personalizzate a livello di applicazione
Gestione della configurazione Config Sync (inclusi i pacchetti del parco risorse) Non applicabile
Gestione Dashboard di Google Kubernetes Engine nella Google Cloud console
Gateway di connessione
Lo strumento locale kubectl
Aggiornamenti software di Distributed Cloud connesso
Gestione dei team e degli spazi dei nomi del parco risorse
La gcloud CLI
Non applicabile
Sicurezza Integrazione di Cloud Key Management Service
Unità SED (Self-Encrypting Disk)
Workload Identity del parco risorse
Log di audit
Non applicabile

Prerequisiti

Prima di poter eseguire il deployment dei servizi su Distributed Cloud connesso, devi completare i prerequisiti elencati in questa sezione. Google Cloud

Ottieni le credenziali del cluster

Utilizza il seguente comando per ottenere le credenziali di accesso al cluster di destinazione:

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

Sostituisci quanto segue:

  • CLUSTER_ID: il nome del cluster di destinazione.
  • PROJECT_ID: l'ID del progetto di destinazione. Google Cloud

Crea o seleziona un cluster

Se non l'hai ancora fatto, crea un cluster Distributed Cloud connesso come descritto in Creare un cluster. Quando crei il cluster, specifica almeno 8 indirizzi IP virtuali (VIP). Questi VIP verranno utilizzati dai container Kubernetes che eseguono i carichi di lavoro dei Google Cloud servizi.

Se utilizzi un cluster esistente, utilizza il seguente comando per verificare che siano disponibili VIP sufficienti sul cluster:

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

Il comando restituisce un output simile al seguente:

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

Se non sono stati sottoposti a provisioning VIP sufficienti sul cluster, viene visualizzato il seguente errore, dove n è il numero di VIP richiesto e m è il numero di VIP rilevati su il cluster:

Cluster has less than n external IPs, got m.

Se ricevi questo errore, devi eliminare e ricreare il cluster con un numero sufficiente di VIP.

Configura il sottodominio del Google Cloud servizio

Prima di eseguire il deployment del primo Google Cloud servizio in una zona Distributed Cloud connessa, hai la possibilità di personalizzare il sottodominio su cui tutti i Google Cloud servizi di cui è stato eseguito il deployment in quella zona ascolteranno le connessioni. Non puoi modificare questo sottodominio dopo aver eseguito il deployment di almeno un servizio nella zona Distributed Cloud.

Utilizza il seguente comando per visualizzare la configurazione del sottodominio:

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

Il comando restituisce un output simile al seguente:

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

Utilizza il seguente comando per modificare la configurazione del sottodominio:

kubectl -n dns-system edit celldns cell-dns

Esegui il deployment di un Google Cloud servizio su Distributed Cloud connesso

Per eseguire il deployment di un Google Cloud servizio sul cluster Distributed Cloud connesso, segui i passaggi di deployment descritti nella documentazione del servizio.

Configura il servizio di cui è stato eseguito il deployment Google Cloud

Questa sezione descrive i passaggi di configurazione post-deployment che puoi scegliere di completare in base ai requisiti aziendali.

Inoltra le query DNS dal DNS interno al DNS del cluster

Quando esegui il deployment di un Google Cloud servizio sul cluster Distributed Cloud connesso, sul cluster viene eseguito il deployment di un server DNS dedicato per quel servizio. Ti consigliamo di inoltrare le query DNS per il sottodominio del servizio al server DNS appena creato sul cluster.

  1. Utilizza i seguenti comandi per ottenere il sottodominio del cluster:

    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?}"
    

    L'ultimo comando restituisce un output simile al seguente:

    my-zone.google.private.goog
    
  2. Utilizza il seguente comando per ottenere il VIP del server DNS sul cluster:

    DNS_EXT_IP=$(kubectl -n dns-system get service gpc-coredns-external-tcp -o "jsonpath={.status.loadBalancer.ingress[0].ip}")
    
  3. Configura il server DNS interno in modo che inoltri le query DNS per il servizio di cui è stato eseguito il deployment Google Cloud al VIP ottenuto nel passaggio precedente. Ad esempio:

    • Per dnsmasq, aggiungi quanto segue a /etc/dnsmasq.conf:

      server=/${CLUSTER_FQDN?}/${DNS_EXT_IP?}
      
    • Per CoreDNS, aggiungi quanto segue al Corefile:

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

Verifica la risoluzione DNS

Utilizza il seguente comando dig per verificare la corretta risoluzione del dominio. Presta particolare attenzione alla ANSWER SECTION:

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

Il comando restituisce un output simile al seguente:

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

Recupera il certificato autofirmato per il servizio di cui è stato eseguito il deployment Google Cloud

Quando esegui il deployment di un Google Cloud servizio sul cluster Distributed Cloud connesso, Distributed Cloud connesso emette un certificato autofirmato che utilizza per criptare il traffico di rete per quel servizio. Ti consigliamo di recuperare questo certificato e configurare il tuo ambiente aziendale in modo che lo consideri attendibile.

Per ottenere questo certificato in formato con codifica PEM, utilizza il seguente comando:

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

Distributed Cloud connesso genera una serie di bundle di attendibilità in tutto il cluster. Questi bundle di attendibilità vengono archiviati come ConfigMap in ogni spazio dei nomi del cluster. Sono:

  • trust-store-internal-only. Contiene le autorità di certificazione (CA) per i servizi interni di Distributed Cloud connesso.
  • trust-store-root-ext. Contiene tutte le CA in trust-store-root-ext, oltre alla CA che ha firmato il certificato autofirmato del servizio di destinazione Google Cloud . Monta questo bundle di attendibilità in un pod se hai bisogno che il pod acceda al servizio Google Cloud di destinazione.
  • trust-store-user-root-ext. Contiene tutte le CA in trust-store-root-ext, oltre a tutte le CA che hai aggiunto manualmente. Monta questo bundle in un pod se hai bisogno che il pod acceda sia al servizio di destinazione sia a tutte le risorse interne che utilizzano certificati firmati dalle CA che hai aggiunto manualmente. Google Cloud

Utilizza il seguente comando per visualizzare il ConfigMap di destinazione:

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

L'output di esempio seguente mostra una risorsa ConfigMap trust-store-user-root-ext tipica:

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

Configura un servizio di cui è stato eseguito il deployment Google Cloud in modo che consideri attendibili i tuoi certificati

Puoi creare un secret TLS nel cluster Distributed Cloud connesso e annotarlo con l'annotazione security.private.gdc.goog/bundles=trust-store-user-root-ext nello spazio dei nomi cert-manager-cluster-resources. In questo modo, il servizio di cui è stato eseguito il deployment Google Cloud considera attendibili i servizi interni di terze parti per facilitare lo scambio di dati tra loro.

Quando applichi questo secret al cluster, il servizio di cui è stato eseguito il deployment considera attendibile il certificato CA archiviato nel file ca.crt a cui fa riferimento il secret. Google Cloud Ad esempio:

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

Configura un provider di autenticazione

Puoi configurare un provider di autenticazione per facilitare l'accesso tramite l'interfaccia utente del servizio di cui è stato eseguito il deployment Google Cloud . L'esempio seguente mostra una configurazione per un OpenID Connect provider:

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"

Per saperne di più, consulta Configurare GKE Identity Service per i singoli cluster.

Utilizza un servizio di cui è stato eseguito il deployment Google Cloud

Consulta la documentazione del servizio di cui è stato eseguito il deployment Google Cloud per informazioni su come configurarlo in modo che soddisfi i requisiti aziendali.

Rimuovi un servizio di cui è stato eseguito il deployment Google Cloud

Per rimuovere un servizio di cui è stato eseguito il deployment Google Cloud dal cluster Distributed Cloud connesso, segui i passaggi descritti nella documentazione del servizio. Se hai completato uno dei passaggi post-deployment facoltativi descritti in questa pagina, esegui anche le seguenti operazioni:

  • Disattiva l'inoltro DNS al sottodominio del servizio nel DNS interno.
  • Disattiva l'attendibilità per il certificato autofirmato del servizio ovunque sia stata stabilita.