Gérer les services Google

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

Services Google Cloud compatibles

Distributed Cloud Connected est compatible avec le déploiement des servicesGoogle Cloud suivants :

Type de service Inclus dans les coûts de GDC connecté Facturé 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 Stockage brut (volume persistant)
Container Storage Interface (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 CNI (Container Network Interface) personnalisés GKE
Équilibreur de charge de couche 4 groupé GKE
 Non applicable
AI/ML Déployer des modèles AutoML dans des conteneurs Non applicable
Database (Base de données) Aucun AlloyDB Omni (preview)
Solutions de bases 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		 Prometheus pour l'observabilité déconnectée
Journaux et métriques personnalisés au niveau de l'application
Gestion de la configuration Config Sync
Packages de parc (aperçu)		 Non applicable
Gestion Tableau de bord Google Kubernetes Engine dans la Google Cloud console
Connect Gateway
L'outil local kubectl
Mises à niveau logicielles connectées Distributed Cloud		 Non applicable
Sécurité Intégration de Cloud Key Management Service
Disques à chiffrement automatique (SED)
Identité de charge de travail de parc
Journaux d'audit 		Non applicable

Prérequis

Avant de pouvoir déployer des services sur Distributed Cloud Connected, vous devez remplir les conditions préalables listées dans cette section. Google Cloud

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 Google Cloud cible.

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. Lorsque vous créez le cluster, spécifiez au moins huit adresses IP virtuelles (VIP). Ces adresses IP virtuelles seront utilisées par les conteneurs Kubernetes qui exécutent vos charges de travail de service Google Cloud .

Si vous utilisez un cluster existant, exécutez la commande suivante pour vérifier que suffisamment d'adresses IP virtuelles sont disponibles sur ce cluster :

 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 nombre d'adresses IP virtuelles provisionnées sur le cluster est insuffisant, l'erreur suivante s'affiche, où n correspond au nombre d'adresses IP virtuelles requises et m au nombre d'adresses IP virtuelles 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 d'adresses IP virtuelles.

Configurer le sous-domaine du service Google Cloud

Avant de déployer le premier service Google Cloud dans une zone Distributed Cloud connectée, vous pouvez personnaliser le sous-domaine sur lequel tous les services Google Cloud déployés dans cette zone écouteront les connexions. Vous ne pourrez pas modifier ce sous-domaine une fois que vous aurez déployé au moins un service sur cette zone Distributed Cloud.

Utilisez 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 service Google Cloud sur Distributed Cloud connecté

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

Configurer le service Google Cloud déployé

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

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

Lorsque vous déployez un service Google Cloud 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. Utilisez 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 l'adresse IP virtuelle du serveur DNS du cluster :

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

  3. Configurez votre serveur DNS interne pour qu'il transfère les requêtes DNS pour le service Google Cloud déployé vers l'adresse IP virtuelle que vous avez obtenue à l'étape précédente. Exemple :

    • Pour dnsmasq, ajoutez le code suivant à /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

Utilisez la commande dig suivante pour tester la résolution correcte du domaine. Portez une attention particulière à 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é pour le service Google Cloud déployé

Lorsque vous déployez un service Google Cloud sur votre cluster connecté Distributed Cloud, Distributed Cloud connecté émet un certificat auto-signé 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 professionnel pour qu'il lui fasse confiance.

Pour obtenir ce certificat au format PEM, utilisez la commande suivante :

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

Le Cloud distribué connecté génère un certain nombre de groupes de confiance dans votre cluster. Ces faisceaux 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 pour les services internes de Distributed Cloud connected.
  • 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 serviceGoogle Cloud cible. Montez ce bundle de confiance dans un pod si vous avez besoin que ce pod accède au service Google Cloud cible.
  • trust-store-user-ext : contient toutes les autorités de certification dans trust-store-root-ext, ainsi que toutes celles que vous avez ajoutées manuellement. Montez ce bundle dans un pod si vous avez besoin que ce pod accède à la fois au service Google Cloud cible et à toutes les ressources internes qui utilisent des certificats signés par les autorités de certification que vous avez ajoutées manuellement.

Utilisez la commande suivante pour afficher le ConfigMap cible :

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

L'exemple de sortie 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 Google Cloud déployé pour qu'il fasse confiance à vos propres certificats

Vous pouvez créer un secret TLS dans votre cluster connecté Distributed Cloud 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 Google Clouddéployé 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 de l'autorité de certification 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 serviceGoogle Cloud déployé. L'exemple suivant montre une configuration pour un fournisseur OpenID Connect :

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 Google Cloud déployé

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

Supprimer un service Google Cloud déployé

Pour supprimer un service Google Cloud déployé de votre cluster connecté Distributed Cloud, 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 l'approbation du certificat autosigné du service partout où elle a été établie.