Gérer les services Google

Distributed Cloud connecté est compatible avec le déploiement d'un certain nombre de Google Cloud services. Ces charges de travail de service s'exécutent dans des conteneurs Kubernetes sur vos clusters Distributed Cloud connecté.

Services Google Cloud compatibles

Distributed Cloud connecté est compatible avec le déploiement des Google Cloud services suivants :

Type de service Inclus dans les coûts de GDC connecté Facturés séparément
Calcul Google Distributed Cloud (logiciel uniquement)
Environnement d'exécution des VM sur Google Distributed Cloud		 Systèmes d'exploitation invités
(vous devez obtenir vos propres licences)
Stockage Interface de stockage en conteneurs (CSI)
Stockage hybride		 Stockage défini par logiciel (SDS),
tel que Symcloud Storage
(vous devez obtenir vos propres licences)
Mise en réseau API Edge Network
Compatibilité avec les VLAN
Plug-ins GKE Custom Network Interface (CNI)
Équilibreur de charge L4 groupé GKE
 Non applicable
IA/ML Déploiement de modèles AutoML dans des conteneurs Non applicable
Base de données Aucun AlloyDB Omni (autogéré) (aperçu)
Solutions de base de données tierces, telles que MongoDB
(vous devez obtenir vos propres licences)
Observabilité Cloud Logging
Cloud Monitoring
API Cloud Logging
Journaux et métriques GDCc
Journalisation du parc
Surveillance du parc		 Prometheus pour l'observabilité déconnectée
Journaux et métriques personnalisés au niveau de l'application
Gestion de la configuration Config Sync (y compris les packages de parc) Non applicable
Gestion Tableau de bord Google Kubernetes Engine dans la Google Cloud console
Passerelle de connexion
Outil local kubectl
Mises à niveau logicielles de Distributed Cloud connecté
Gestion des équipes et des espaces de noms du parc
gcloud CLI		 Non applicable
Sécurité Intégration de Cloud Key Management Service
Lecteurs SED (Self-Encrypting Disk)
Identité de charge de travail du parc
Journalisation d'audit 		Non applicable

Prérequis

Pour pouvoir déployer Google Cloud des services sur Distributed Cloud connecté, vous devez remplir les prérequis listés dans cette section.

Obtenir les identifiants du cluster

Utilisez la commande suivante pour obtenir les identifiants permettant d'accéder au cluster cible :

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

Remplacez les éléments suivants :

  • CLUSTER_ID : nom du cluster cible.
  • PROJECT_ID : ID du projet cible. Google Cloud

Créer ou sélectionner un cluster

Si vous ne l'avez pas déjà fait, créez un cluster Distributed Cloud connecté comme décrit dans Créer un cluster. Lors de la création du cluster, spécifiez au moins huit adresses IP virtuelles (VIP). Ces VIP seront utilisées par les conteneurs Kubernetes qui exécutent vos Google Cloud charges de travail de service.

Si vous utilisez un cluster existant, exécutez la commande suivante pour vérifier qu'il dispose d'un nombre suffisant de VIP :

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

La commande renvoie un résultat semblable à celui-ci :

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

Si le cluster ne dispose pas d'un nombre suffisant de VIP provisionnées, l'erreur suivante s'affiche, où n correspond au nombre de VIP requis et m au nombre de VIP détectées sur le cluster :

Cluster has less than n external IPs, got m.

Si cette erreur s'affiche, vous devez supprimer le cluster et le recréer avec un nombre suffisant de VIP.

Configurer le Google Cloud sous-domaine du service

Avant de déployer le premier Google Cloud service dans une zone Distributed Cloud connecté, vous avez la possibilité de personnaliser le sous-domaine sur lequel tous les Google Cloud services déployés dans cette zone écouteront les connexions. Vous ne pouvez pas modifier ce sous-domaine après avoir déployé au moins un service dans cette zone Distributed Cloud.

Exécutez la commande suivante pour afficher la configuration du sous-domaine :

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

La commande renvoie un résultat semblable à celui-ci :

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

Exécutez la commande suivante pour modifier la configuration du sous-domaine :

kubectl -n dns-system edit celldns cell-dns

Déployer un Google Cloud service sur Distributed Cloud connecté

Pour déployer un Google Cloud service sur votre cluster Distributed Cloud connecté suivez les étapes de déploiement décrites dans la documentation de ce service.

Configurer le service déployé Google Cloud

Cette section décrit les étapes de configuration post-déploiement que vous pouvez choisir d'effectuer en fonction de vos besoins commerciaux.

Transférer les requêtes DNS du DNS interne vers le DNS du cluster

Lorsque vous déployez un Google Cloud service sur votre cluster Distributed Cloud connecté, un serveur DNS dédié à ce service est déployé sur le cluster. Nous vous recommandons de transférer les requêtes DNS pour le sous-domaine du service vers le serveur DNS nouvellement créé sur le cluster.

  1. Exécutez les commandes suivantes pour obtenir le sous-domaine du 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?}"

    La dernière commande renvoie un résultat semblable à celui-ci :

    my-zone.google.private.goog

  2. Exécutez la commande suivante pour obtenir la VIP du serveur DNS sur le cluster :

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

  3. Configurez votre serveur DNS interne pour transférer les requêtes DNS du service déployé Google Cloud service vers la VIP que vous avez obtenue à l'étape précédente. Exemple :

    • Pour dnsmasq, ajoutez ce qui suit à /etc/dnsmasq.conf :

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

    • Pour CoreDNS, ajoutez ce qui suit au Corefile :

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

Tester la résolution DNS

Exécutez la commande dig suivante pour tester la résolution de domaine appropriée. Portez une attention particulière à la ANSWER SECTION :

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

La commande renvoie un résultat semblable à celui-ci :

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

Récupérer le certificat autosigné du service déployé Google Cloud

Lorsque vous déployez un Google Cloud service sur votre cluster Distributed Cloud connecté, Distributed Cloud connecté émet un certificat autosigné qu'il utilise ensuite pour chiffrer le trafic réseau de ce service. Nous vous recommandons de récupérer ce certificat et de configurer votre environnement d'entreprise pour qu'il lui fasse confiance.

Pour obtenir ce certificat au format encodé PEM, exécutez la commande suivante :

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

Distributed Cloud connecté génère un certain nombre de groupes de confiance dans l'ensemble de votre cluster. Ces groupes de confiance sont stockés en tant que ConfigMaps dans chaque espace de noms du cluster. Les voici :

  • trust-store-internal-only: contient les autorités de certification (CA) pour les services internes de Distributed Cloud connecté.
  • trust-store-root-ext : contient toutes les autorités de certification dans trust-store-root-ext, ainsi que l'autorité de certification qui a signé le certificat autosigné du service cible.Google Cloud Montez ce groupe de confiance dans un pod si vous avez besoin que ce pod accède au service Google Cloud cible.
  • trust-store-user-root-ext : contient toutes les autorités de certification dans trust-store-root-ext, ainsi que toutes les autorités de certification que vous avez ajoutées manuellement. Montez ce groupe dans un pod si vous avez besoin que ce pod accède à la fois au service cible Google Cloud et à toutes les ressources internes qui utilisent des certificats signés par les autorités de certification que vous avez ajoutées manuellement.

Exécutez la commande suivante pour afficher le ConfigMap cible :

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

L'exemple de résultat suivant montre une ressource ConfigMap trust-store-user-root-ext typique :

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

Configurer un service déployé Google Cloud pour qu'il fasse confiance à vos propres certificats

Vous pouvez créer un secret TLS dans votre cluster Distributed Cloud connecté et l'annoter avec l'annotation security.private.gdc.goog/bundles=trust-store-user-root-ext dans l'espace de noms cert-manager-cluster-resources. Cela permet à votre service déployé Google Cloud de faire confiance à vos services tiers internes pour faciliter l'échange de données entre eux.

Lorsque vous appliquez ce secret à votre cluster, le service Google Cloud déployé fait confiance au certificat CA stocké dans le fichier ca.crt référencé dans le secret. Exemple :

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

Configurer un fournisseur d'authentification

Vous pouvez configurer un fournisseur d'authentification pour faciliter la connexion via l'interface utilisateur du service déployé Google Cloud . L'exemple suivant montre une configuration pour un OpenID Connect fournisseur :

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"

Pour en savoir plus, consultez Configurer GKE Identity Service pour des clusters individuels.

Utiliser un service déployé Google Cloud

Consultez la documentation du service déployé pour savoir comment le configurer afin de répondre à vos besoins commerciaux. Google Cloud

Supprimer un service déployé Google Cloud

Pour supprimer un service déployé Google Cloud de votre cluster Distributed Cloud connecté, suivez les étapes décrites dans la documentation de ce service. Si vous avez effectué l'une des étapes post-déploiement facultatives décrites sur cette page, procédez également comme suit :

  • Désactivez le transfert DNS vers le sous-domaine du service dans votre DNS interne.
  • Désactivez la confiance pour le certificat autosigné du service partout où cette confiance a été établie.