Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Obtenir de l'aide

L'objectif principal de Google est de résoudre les incidents de production le plus rapidement possible. Pour ce faire, nous nous efforçons de comprendre votre configuration, d'analyser les journaux et les métriques et de collaborer avec nos partenaires pour résoudre rapidement les incidents.

Cloud Customer Care propose plusieurs formules d'assistance adaptées à vos besoins. Toutes les formules de Cloud Customer Care incluent la compatibilité avec GKE et Google Distributed Cloud. Si vous avez souscrit à une formule d'assistance Cloud Customer Care, vous bénéficiez déjà de la compatibilité avec GKE et Google Distributed Cloud.

Pour en savoir plus, consultez le hub Cloud Customer Care.

Exigences concernant l'assistance Google Distributed Cloud

Pour résoudre efficacement les incidents critiques, vous devez effectuer les actions suivantes :

Vérifiez que votre environnement est à jour et conforme aux délais de fin de service publiés. Pour plus d'informations, consultez la section Politique de compatibilité avec les versions.
Activez Cloud Logging et Cloud Monitoring pour les composants système. Pour en savoir plus, consultez la section Outils d'assistance suivante.

Outils d'assistance

Pour résoudre un incident Google Distributed Cloud, Cloud Customer Care s'appuie sur trois éléments d'information :

La configuration de votre environnement
Les journaux de vos clusters
Les métriques de vos clusters

La configuration de votre environnement

Lorsque vous ouvrez une demande d'assistance, fournissez des informations clés sur la configuration de votre cluster en exécutant les commandes suivantes :

Pour tous les types de clusters, capturez des informations sur Kubernetes et vos nœuds en exécutant la commande bmctl check cluster --snapshot. Joignez le fichier tar obtenu à la demande d'assistance.
Pour les clusters d'administrateur, hybrides et autonomes, vérifiez l'état de fonctionnement du cluster et des nœuds en exécutant la commande bmctl check cluster. Joignez les journaux générés à la demande d'assistance. Les journaux doivent exister dans le répertoire bmctl-workspace/[CLUSTER_NAME]/log/check-cluster-[TIMESTAMP].
Pour les clusters d'utilisateur, créez d'abord un fichier YAML de vérification de l'état avec le nom et l'espace de noms du cluster, puis appliquez-le dans le cluster d'administrateur approprié :
1. Créez un fichier YAML avec les propriétés healthcheck suivantes. Voici un exemple de contenu pour un cluster nommé user1 dans l' cluster-user1 espace de noms :
```
apiVersion: baremetal.cluster.gke.io/v1
kind: HealthCheck
metadata:
  generateName: healthcheck-
  namespace: cluster-user1
spec:
  clusterName: user1
```
2. Après avoir créé le fichier YAML, appliquez la ressource personnalisée dans le cluster d'administrateur qui gère le cluster d'utilisateur à l'aide de la commande kubectl. Voici un exemple de commande utilisant le fichier YAML créé à l'étape précédente. Dans l'exemple, la variable ADMIN_KUBECONFIG spécifie le chemin d'accès au fichier kubeconfig du cluster d'administrateur :
```
kubectl --kubeconfig ADMIN_KUBECONFIG create -f healthcheck-user1.yaml
```
  La commande renvoie la réponse suivante :
```
healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf created
```
3. Attendez que la tâche de vérification de l'état soit terminée. Pour ce faire, effectuez un test pour vérifier si la tâche de vérification de l'état est terminée. Dans l'exemple précédent, le nom de la tâche de vérification de l'état est healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf. Voici un exemple de test qui utilise la commande kubectl et qui attend 30 minutes que la tâche de vérification de l'état se termine :
```
kubectl --kubeconfig ADMIN_KUBECONFIG wait healthcheck healthcheck-7c4qf \
    -n cluster-user1 --for=condition=Reconciling=False --timeout=30m
```
  Une fois la tâche de vérification de l'état terminée, la commande kubectl précédente renvoie le résultat suivant :
```
healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf condition met
```
  Vous pouvez afficher les résultats de la vérification de l'état à l'aide de la commande suivante :
```
kubectl --kubeconfig ADMIN_KUBECONFIG get healthcheck healthcheck-7c4qf \
    -n cluster-user1
```
  La commande renvoie le résultat suivant :
```
NAME                PASS   AGE
healthcheck-7c4qf   true   17m
```
4. Rassemblez tous les journaux du pod de la tâche de vérification de l'état dans un fichier local à l'aide de la commande kubectl. Voici un exemple utilisant la tâche précédente de vérification de l'état :
```
kubectl --kubeconfig ADMIN_KUBECONFIG logs -n cluster-user1 \
    -l baremetal.cluster.gke.io/check-name=healthcheck-7c4qf --tail=-1 > \
    healthcheck-7c4qf.log
```

Journaux de cluster

Lorsque vous créez un cluster Google Distributed Cloud, les agents Cloud Logging sont activés par défaut et ne concernent que les composants au niveau du système. Cette opération permet de répliquer les journaux système dans le Google Cloud projet associé au cluster. Les journaux au niveau du système proviennent des pods Kubernetes se trouvant dans les espaces de noms suivants :

kube-system
gke-system
gke-connect
istio-system
config-management-system
gatekeeper-system
cnrm-system
knative-serving

Vous pouvez interroger les journaux à partir de l' explorateur de journaux.

Pour en savoir plus, consultez Configurer la journalisation et la surveillance.

Google Cloud CLI et accès distant au cluster

Si vous ouvrez une demande d'assistance, Cloud Customer Care peut vous demander un accès en lecture seule à distance à vos clusters, afin de diagnostiquer et de résoudre plus efficacement les problèmes. Pour que Cloud Customer Care dispose d'un accès suffisant pour résoudre à distance le problème de votre cluster, assurez-vous d'avoir installé et mis à jour la dernière version de la Google Cloud CLI. La version de Google Cloud CLI doit être la version 401.0.0 ou ultérieure pour pouvoir accorder les autorisations nécessaires à Cloud Customer Care. Nous vous recommandons de mettre à jour régulièrement Google Cloud CLI afin de bénéficier des autorisations ajoutées et d'autres améliorations.

Pour installer les derniers composants de la gcloud CLI, utilisez la gcloud components update commande. Pour en savoir plus sur l'octroi à Cloud Customer Care d'un accès en lecture seule et à distance à vos clusters, consultez la page Assistance à distance pour les clusters GKE.

Métriques de cluster

En plus des journaux, l'agent Cloud Monitoring capture également les métriques. Cette opération permet de répliquer les métriques au niveau du système dans le Google Cloud projet associé au cluster. Les métriques au niveau du système proviennent de pods Kubernetes exécutés dans les mêmes espaces de noms que ceux répertoriés dans la section Journaux de cluster.

Pour en savoir plus, consultez Configurer la journalisation et la surveillance.

Comment nous dépannons votre environnement

Voici un exemple type d'incident nécessitant une assistance :

L'administrateur du cluster ouvre une demande d'assistance dans la Google Cloud console avec Cloud Customer Care. Il sélectionne ensuite GKE et Google Distributed Cloud comme Catégorie et Composant, respectivement. Il saisit les informations requises et joint le résultat des commandes bmctl pertinentes à la demande.
La demande d'assistance est transmise à un ingénieur d'assistance technique spécialisé dans Google Distributed Cloud.
L'ingénieur de l'assistance examine le contenu de l'instantané pour connaître le contexte de l'environnement.
L'ingénieur de l'assistance examine les journaux et les métriques du Google Cloud projet. Il saisit le numéro de la demande d'assistance comme justification de l'entreprise, laquelle est consignée en interne.
L'ingénieur de l'assistance répond à la demande par une évaluation et une recommandation. L'ingénieur d'assistance et l'utilisateur continuent de tenter de résoudre le problème jusqu'à ce qu'ils trouvent une solution.

Quelles sont les fonctionnalités acceptées par Google ?

En règle générale, Cloud Customer Care accepte tous les composants logiciels fournis dans le cadre de Google Distributed Cloud, Cloud Service Mesh, Policy Controller, Config Sync et Config Controller. Le tableau suivant fournit une liste plus complète des éléments compatibles et non compatibles :

Google Cloud pris en charge	Non compatible
Kubernetes et l'environnement d'exécution des conteneurs	Choix de l'équilibreur de charge (équilibrage de charge manuel) par le client
Connexion et l'agent Connect	Code client (voir Assistance aux développeurs)
Google Cloud opérations, Monitoring, Logging et agents	Choix du système d'exploitation par le client
Équilibreur de charge groupé	Serveur physique ou virtuel, stockage et réseau
Contrôleur d'entrée	Systèmes externes de DNS, de DHCP et de gestion des identités
GKE Identity Service
Cloud Service Mesh
Policy Controller
Config Sync
Config Controller

Politique de compatibilité avec les versions

L'objectif de cette politique de support des versions est de vous donner la flexibilité nécessaire pour planifier les mises à niveau lorsqu'elles répondent aux besoins de votre entreprise, tout contrebalançant l'évolution rapide de Kubernetes et de Google Distributed Cloud.

Le logiciel Google Distributed Cloud ne suit que le schéma de gestion des versions versioning scheme et le cycle de publication de Kubernetes. Les versions mineures sont publiées environ trois fois par an. Les correctifs pour chaque version mineure compatible sont publiés environ une fois par mois. Comme Kubernetes, Google Distributed Cloud est compatible avec les trois dernières versions mineures simultanément.

Google est compatible avec chaque version mineure de Google Distributed Cloud au dernier des termes suivants :

12 mois après la publication initiale de la version mineure.
Publication de la troisième version mineure suivante.

Par exemple, la version mineure 1.33 est sortie le 2 septembre 2025. Cette version mineure et tous ses correctifs sont compatibles jusqu'au 2 septembre 2026 ou jusqu'à la date de disponibilité de la version mineure 1.36, selon la date la plus tardive.

Nous vous encourageons à mettre à jour votre environnement Google Distributed Cloud avec la dernière version mineure du produit et la version de correctif recommandée version.

Cette politique d'assistance des versions comprend les éléments suivants :

Assistance dépannage de Cloud Customer Care
Failles de sécurité CVE de Kubernetes et des composants associés
Correctifs généraux pour Kubernetes et les composants associés

Lorsque votre version arrive en fin de vie, vous pouvez continuer à ouvrir des demandes pour bénéficier d'une assistance sur les points suivants :

Aide pour les problèmes techniques
Aide pour les problèmes de facturation
Conseils sur l'utilisation du produit, y compris de l'aide pour le dépannage et les tests

L'assistance étendue peut être approuvée de manière conditionnelle en tant qu'événement ponctuel, avec des exigences de blocage de version et de calendrier de mise à niveau future. Pour en savoir plus, contactez l'ingénieur client principal de votre compte ou le responsable de compte. Vous pouvez également déposer une demande d'assistance via la console Google Cloud . Ces demandes sont transmises au groupe d'ingénieurs client de votre compte.

Durée d'assistance

Le tableau suivant présente les versions mineures compatibles avec Google Distributed Cloud et les premières dates de fin de vie (EOL) :

Version de Google Distributed Cloud	Date de disponibilité	Date de fin de vie^*
1,35	2026-04-29	2027-04-29 ou date de disponibilité la version 1.38
1,34	11/12/2025	11/12/2026 ou date de disponibilité version 1.37
1.33	2025-09-02	2026-09-02 ou date de disponibilité version 1.36
1,32	2025-05-06	2026-05-06 ou date de disponibilité version 1.35

* La date de fin de vie sera l'échéance la plus tardive.

Pour en savoir plus sur la compatibilité des versions de Google Distributed Cloud et des produits associés Google Cloud , consultez la page Compatibilité des versions et des mises à niveau support.

Schéma de gestion des versions

Google Distributed Cloud utilise la gestion sémantique des versions de Kubernetes pour référencer les versions Kubernetes compatibles, mais ajoute une version de correctif GKE. Il en résulte un numéro de version au format x.y.z-gke.N.

Version majeure de Kubernetes (x): Les versions majeures sont généralement incrémentées si des modifications incompatibles avec les versions antérieures sont introduites dans l'API publique. Une évolution de version majeure fait passer la version de Kubernetes de x.y à x+1.y.
Version mineure de Kubernetes (y): Une nouvelle version mineure de Kubernetes est publiée trois fois par an. Chaque cycle de publication dure environ 15 semaines. Les API obsolètes peuvent être supprimées dans une nouvelle version mineure. Une évolution de version mineure fait passer la version de Kubernetes de 1.y à 1.y+1 ; par exemple, Kubernetes 1. 29 est la version mineure qui suit Kubernetes 1.28.
Version de correctif Google Distributed Cloud (z-gke.N): Une version de correctif, telle que 1.28.300-gke.131, incrémente la version de correctif (z) de 100 et inclut un suffixe -gke.N, qui indique la compilation. Les versions de correctif incluent des mises à jour de sécurité et des corrections de bugs. Une version de correctif Google Distributed Cloud n'est pas corrélée à une version de correctif Kubernetes.

Modèle de responsabilité partagée

Pour exécuter une application de production stratégique sur Google Distributed Cloud, différentes responsabilités doivent être assumées par plusieurs groupes. Bien que cette liste ne soit pas exhaustive, les sections suivantes répertorient les rôles et les responsabilités des différentes parties.

Responsabilités de Google

Maintenance et distribution du package logiciel Google Distributed Cloud
Notification des utilisateurs quant aux mises à niveau disponibles pour Google Distributed Cloud et génération des scripts de mise à niveau pour la version précédente

Google Distributed Cloud n'accepte que les mises à niveau séquentielles des clusters (exemple : 1.33 → 1.34 → 1.35, mais pas 1.33 → 1.35). Lorsque vous mettez à niveau des pools de nœuds, vous pouvez parfois ignorer une version mineure. Pour en savoir plus sur la logique de mise à niveau, consultez Règles de version.
Opération des services Connect et Cloud Operations
Résolution des problèmes, solutions palliatives et correction de la cause principale des problèmes liés aux composants fournis par Google.

Responsabilités des utilisateurs

Administration globale du système pour les clusters sur site
Gestion de toute charge de travail d'application déployée sur le cluster
Exécution, maintenance et correction de l'infrastructure du centre de données, y compris les réseaux, les serveurs, le système d'exploitation, le stockage et la connectivité à Google Cloud.
Exécution, gestion et correction des équilibreurs de charge réseau si l'option d'équilibrage de charge manuel est choisie
Mise à niveau régulière des versions de Google Distributed Cloud
Surveillance du cluster et des applications et réponse aux incidents éventuels
Déploiement des agents Cloud Operations dans les clusters
Partage avec Google des informations concernant l'environnement à des fins de dépannage

Assistance aux développeurs

Google ne propose pas d'assistance spécifique pour vos charges de travail d'applications. Cependant, nous proposons une assistance aux développeurs dans la mesure du possible, afin que votre équipe puisse exécuter des applications sur Google Distributed Cloud. Une implication à un stade précoce du développement peut prévenir des incidents critiques ultérieurs au cours du déploiement.

Cette assistance aux développeurs dans la mesure du possible est disponible pour les clients bénéficiant d'une formule d'assistance payante. Elle est traitée en tant que priorité P3 pour un problème bloquant un lancement, ou P4 pour une consultation générale. Dans cette classification, les priorités de niveau 0 sont les plus élevées.