Fonctionnalités compatibles avec le plan de contrôle au sein du cluster

Cette page décrit les fonctionnalités compatibles dans Cloud Service Mesh1.21.5 avec un plan de contrôle au sein du cluster. Pour consulter les fonctionnalités acceptées dans Cloud Service Mesh 1.21.5 avec un plan de contrôle géré, consultez la page Plan de contrôle géré.

Versions compatibles

La compatibilité de Cloud Service Mesh est conforme à la politique de compatibilité avec les versions de GKE Enterprise.

Pour Cloud Service Mesh géré avec une implémentation de plan de contrôle TRAFFIC_DIRECTOR, Google prend toujours en charge ce plan de contrôle.

Pour Cloud Service Mesh géré avec une implémentation de plan de contrôle ISTIOD, Google prend en charge les versions actuelles de Cloud Service Mesh disponibles dans chaque canal de publication.

Pour le Cloud Service Mesh intégré au cluster auto-installé, Google est compatible avec les deux versions mineures (n-2) actuelles et précédentes de Cloud Service Mesh.

Le tableau suivant présente les versions compatibles de Cloud Service Mesh auto-installé dans le cluster et la date de fin de vie minimale pour chaque version.

Si vous utilisez une version de Cloud Service Mesh non compatible, vous devez passer à Cloud Service Mesh 1.19 ou une version ultérieure. Pour en savoir plus sur la mise à niveau, consultez la page Mettre à niveau Cloud Service Mesh.

Le tableau suivant présente les versions non compatibles de Cloud Service Mesh et leur date de fin de vie.

Pour en savoir plus sur nos règles d'assistance, consultez la page Assistance.

Différences entre plates-formes

Les fonctionnalités compatibles entre les plates-formes compatibles diffèrent.

Les colonnes Autres clusters GKE Enterprise font référence à des clusters situés en dehors de Google Cloud, par exemple:

• Google Distributed Cloud:

  • Cloud distribué de Google
  • Google Distributed Cloud (logiciel uniquement) pour solution Bare Metal

  Cette page utilise Google Distributed Cloud, qui bénéficie de la même assistance que Google Distributed Cloud (logiciel uniquement) pour VMware et Google Distributed Cloud (logiciel uniquement) pour Bare Metal, et la plate-forme spécifique en cas de différences entre les plates-formes.

• GKE Enterprise sur d'autres clouds publics:

  • GKE sur AWS
  • GKE sur Azure

• Clusters GKE associés : clusters Kubernetes tiers qui ont été enregistrés dans un parc. Cloud Service Mesh est compatible avec les types de clusters suivants:

  • Clusters Amazon EKS
  • Clusters Microsoft AKS

Dans les tableaux suivants :

•  : indique que la fonctionnalité est activée par défaut.
• * : indique que la fonctionnalité est compatible avec la plate-forme et qu'elle peut être activée, comme décrit dans la section Activer les fonctionnalités facultatives ou dans le guide de fonctionnalités dont le lien se trouve dans le tableau des fonctionnalités.
• Compatible : indique que la fonctionnalité ou l'outil tiers s'intègre ou fonctionne avec Cloud Service Mesh, mais n'est pas entièrement compatible avec l'assistance Google Cloud et aucun guide de fonctionnalités n'est disponible.
•  : indique que la fonctionnalité n'est pas disponible ou qu'elle n'est pas compatible avec Cloud Service Mesh 1.21.5.

Les fonctionnalités par défaut et facultatives sont entièrement prises en charge par l'assistance Google Cloud. Les fonctionnalités qui ne sont pas explicitement répertoriées dans les tableaux bénéficient d'une assistance selon le principe du meilleur effort.

Images de base

Sécurité

Mécanismes de distribution/rotation des certificats

Compatibilité avec l'autorité de certification (CA)

Fonctionnalités de sécurité de Cloud Service Mesh

En plus de proposer des fonctionnalités de sécurité Istio, Cloud Service Mesh offre encore plus de fonctionnalités pour vous aider à sécuriser vos applications.

Règle d'autorisation

Stratégie d'authentification

Authentification des pairs

Pour en savoir plus sur l'activation du mode mTLS STRICT, consultez la section Configurer la sécurité du transport.

Authentification des requêtes

Remarques :

1. Le JWT tiers est activé par défaut.

Télémétrie

Métriques

Journalisation des requêtes de proxy

Trace

Mise en réseau

Mécanisme de direction/redirection du trafic

Compatibilité avec le protocole

Les services configurés avec des fonctionnalités de couche 7 pour les protocoles suivants ne sont pas compatibles : WebSocket, MongoDB, Redis, Kafka, Cassandra, RabbitMQ, Cloud SQL. Vous pourrez peut-être rendre le protocole opérationnel grâce à la prise en charge du flux d'octets TCP. Si le flux d'octets TCP ne peut pas prendre en charge le protocole (par exemple, Kafka envoie une adresse de redirection dans une réponse spécifique au protocole, et cette redirection n'est pas compatible avec la logique de routage de Cloud Service Mesh), le protocole n'est pas compatible.

Remarques :

1. Bien que TCP soit un protocole compatible pour la mise en réseau, les métriques TCP ne sont ni collectées, ni signalées. Les métriques ne sont affichées que pour les services HTTP dans la console Google Cloud.

Déploiements Envoy

Compatibilité des CRD

Équilibreur de charge pour la passerelle d'entrée Istio

Pour en savoir plus sur la configuration des équilibreurs de charge, consultez les pages suivantes :

• Configurer votre équilibreur de charge pour Google Distributed Cloud (logiciel uniquement) pour VMware
• GKE sur AWS : Créer un équilibreur de charge
• Exposer une passerelle d'entrée à l'aide d'un équilibreur de charge externe

API Kubernetes Gateway (preview)

Dans Cloud Service Mesh v1.20, l'API Kubernetes Gateway est disponible en version preview publique.

Si vous utilisez des clusters associés Microsoft AKS ou GKE sur des clusters Azure, vous devez définir l'annotation suivante pour la ressource de passerelle afin de configurer les vérifications d'état via TCP:

  service.beta.kubernetes.io/port_80_health-probe_protocol: tcp

Sinon, le trafic HTTP ne sera pas accepté.

Exigences de la version preview de l'API Kubernetes Gateway

La version preview de l'API Kubernetes Gateway présente les exigences suivantes:

• Utilisez le comportement par défaut des déploiements automatisés pour les passerelles.

• Utilisez le CRD HttpRoute pour les configurations de routage. HttpRoute doit comporter un parentRef pointant vers une passerelle.

• N'utilisez pas de CRD Istio Gateway et de CRD API Kubernetes Gateway sur le même cluster.

Règles d'équilibrage de charge

Pour en savoir plus sur les règles d'équilibrage de charge, consultez la page Règles de destination.

Plan de données

Compatibilité multicluster

Dans le cas de plusieurs déploiements principaux de clusters GKE dans différents projets, tous les clusters doivent se trouver dans un cloud privé virtuel partagé (VPC).

Réseau

Remarques :

• Pour les clusters associés, seuls les réseaux maillés multi-clusters couvrant une seule plate-forme (Microsoft AKS, Amazon EKS) sont acceptés pour le moment.

Modèle de déploiement

Remarques sur la terminologie:

• Un cluster principal est un cluster avec un plan de contrôle. Un seul maillage peut disposer de plusieurs clusters principaux pour assurer une haute disponibilité ou réduire la latence. Dans la documentation d'Istio 1.7, plusieurs déploiements principaux sont appelés "plan de contrôle répliqué".

• Un cluster distant est un cluster qui se connecte à un plan de contrôle situé en dehors du cluster. Un cluster distant peut se connecter à un plan de contrôle exécuté dans un cluster principal ou à un plan de contrôle externe.

• Cloud Service Mesh utilise une définition simplifiée du réseau basée sur la connectivité générale. Les instances de charge de travail se trouvent sur le même réseau si elles peuvent communiquer directement, sans passerelle.

Interface utilisateur

Remarque:Les clusters sur site nécessitent GKE Enterprise version 1.11 ou ultérieure. Pour en savoir plus sur la mise à niveau, consultez Mettre à niveau Google Distributed Cloud (logiciel uniquement) pour VMware ou Mettre à niveau Google Distributed Cloud (logiciel uniquement) pour bare metal.