Fonctionnalités compatibles avec les API Istio (plan de contrôle géré)

Cette page décrit les fonctionnalités et les limites de Cloud Service Mesh utilisant TRAFFIC_DIRECTOR ou ISTIOD comme plan de contrôle, ainsi que les différences entre chaque implémentation. Notez que vous ne pouvez pas choisir ces options. L'implémentation de ISTIOD n'est disponible que pour les utilisateurs existants. Les nouvelles installations utilisent l'implémentation TRAFFIC_DIRECTOR lorsque cela est possible.

Pour obtenir la liste des API Istio et Google Cloud compatibles avec Managed Cloud Service Mesh avec TRAFFIC_DIRECTOR, consultez Compatibilité des API dans Managed Cloud Service Mesh.

Pour obtenir la liste des fonctionnalités de Cloud Service Mesh compatibles avec un plan de contrôle au sein du cluster, consultez Utiliser les API Istio (plan de contrôle istiod au sein du cluster).

Si vous n'êtes pas sûr du plan de contrôle Cloud Service Mesh que vous utilisez, vous pouvez vérifier son implémentation en suivant les instructions de la section Identifier l'implémentation du plan de contrôle.

Limites

Les limites suivantes s'appliquent :

  • Les clusters GKE doivent se trouver dans l'une des régions disponibles.
  • La version de GKE doit être une version compatible.
  • Seules les plates-formes répertoriées dans la section Environnements sont compatibles.
  • Les pods exécutés avec hostNetwork: true ne sont pas acceptés.
  • Vous ne devez pas déployer Managed Cloud Service Mesh dans un cluster qui comporte également un déploiement dans le cluster d'OSS Istio ou un plan de contrôle Cloud Service Mesh dans le cluster.
  • Il n'est pas possible de changer de canal de publication.
  • Les migrations d'Anthos Service Mesh géré avec asmcli vers Cloud Service Mesh avec l'API Fleet ne sont pas possibles. De même, le provisionnement de Cloud Service Mesh géré avec l'API Fleet de --management manual à --management automatic n'est pas possible.
  • Les migrations depuis Cloud Service Mesh intégré au cluster ne sont compatibles qu'avec la stratégie de migration vers un cluster Canary.
  • Les migrations et les mises à niveau ne sont compatibles qu'avec les versions de Cloud Service Mesh dans le cluster qui figurent dans le tableau des versions compatibles et qui utilisent Mesh CA ou Certificate Authority Service. Les installations utilisant Istio CA (anciennement Citadel) doivent d'abord migrer vers Mesh CA.
  • Les limites de l'échelle sont décrites dans ce guide.
  • Seule l'option de déploiement multi-niveau pour les clusters multiples est compatible : l'option de déploiement principal à distance n'est pas acceptée.
  • istioctl ps n'est pas compatible. Vous pouvez utiliser les commandes gcloud beta container fleet mesh debug, comme décrit dans la section Dépannage.

  • API non compatibles :

    • WasmPlugin API

    • IstioOperator API

    • Kubernetes Ingress API

  • Pour obtenir des informations détaillées sur la compatibilité et les limites au niveau des champs pour toutes les API Istio, consultez Compatibilité avec l'API Cloud Service Mesh.

  • Vous pouvez utiliser le plan de contrôle géré sans abonnement GKE Enterprise, mais certains éléments d'UI et certaines fonctionnalités de la console Google Cloud ne sont disponibles que pour les abonnés GKE Enterprise. Pour en savoir plus sur ce qui est disponible pour les abonnés et les non-abonnés, consultez la section Différences entre les interfaces utilisateur GKE Enterprise et Cloud Service Mesh.

  • Au cours du processus de provisionnement d'un plan de contrôle géré, les CRD d'Istio correspondant au canal sélectionné sont installées dans le cluster spécifié. Si des CRD d'Istio sont présentes dans le cluster, elles seront écrasées.

  • Cloud Service Mesh géré n'accepte que le domaine DNS par défaut .cluster.local.

  • Les nouvelles installations de Cloud Service Mesh géré n'extraient les JWKS qu'à l'aide d'Envoys, sauf si le parc contient d'autres clusters pour lesquels ce comportement n'est pas activé. Cela équivaut à l'option Istio PILOT_JWT_ENABLE_REMOTE_JWKS=envoy. Par rapport aux installations qui ne comportent pas la condition VPCSC_GA_SUPPORTED (voir ci-dessous), vous devrez peut-être effectuer une configuration supplémentaire pour les configurations ServiceEntry et DestinationRule. Pour obtenir un exemple, consultez requestauthn-with-se.yaml.tmpl. Pour déterminer si le mode de fonctionnement actuel est équivalent à PILOT_JWT_ENABLE_REMOTE_JWKS=envoy, vérifiez si VPC Service Controls est compatible avec le plan de contrôle (c'est-à-dire si la condition VPCSC_GA_SUPPORTED s'affiche).

  • Le plan de données géré n'est compatible qu'avec les charges de travail sans side-cars supplémentaires (autres que le side-car Cloud Service Mesh).

Différences au niveau du plan de contrôle

Les fonctionnalités compatibles diffèrent entre les implémentations du plan de contrôle ISTIOD et TRAFFIC_DIRECTOR. Pour vérifier l'implémentation que vous utilisez, consultez Identifier l'implémentation du plan de contrôle.

  •  : indique que la fonctionnalité est disponible et activée par défaut.
  • † – indique que les API de fonctionnalités peuvent présenter des différences entre les plates-formes.
  • * : 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.
  •  : indique que la fonctionnalité n'est pas disponible ou qu'elle n'est pas compatible.

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.

Qu'est-ce qui détermine l'implémentation du plan de contrôle ?

Lorsque vous provisionnez Cloud Service Mesh géré pour la première fois dans un parc, nous déterminons l'implémentation du plan de contrôle à utiliser. La même implémentation est utilisée pour tous les clusters qui provisionnent Cloud Service Mesh géré dans ce parc.

Les nouvelles flottes intégrées à Cloud Service Mesh géré reçoivent l'implémentation du plan de contrôle TRAFFIC_DIRECTOR, à quelques exceptions près :

  • Si vous êtes déjà un utilisateur de Cloud Service Mesh géré, vous recevrez l'implémentation du plan de contrôle ISTIOD lorsque vous intégrerez un nouveau parc dans la même organisation Google Cloudà Cloud Service Mesh géré, au moins jusqu'au 30 juin 2024. Si vous faites partie de ces utilisateurs, vous pouvez contacter l'assistance pour affiner ce comportement. Les utilisateurs dont l'utilisation existante n'est pas compatible avec l'implémentation TRAFFIC_DIRECTOR sans modification continueront de recevoir l'implémentation ISTIOD jusqu'au 8 septembre 2024. (Ces utilisateurs ont reçu une annonce de service.)
  • Si un cluster GKE sur Google Cloud de votre parc contient un plan de contrôle Cloud Service Mesh dans le cluster lorsque vous provisionnez Cloud Service Mesh géré, vous recevrez l'implémentation du plan de contrôle ISTIOD.
  • Si un cluster de votre parc utilise GKE Sandbox, vous recevez l'implémentation du plan de contrôle ISTIOD lorsque vous provisionnez Cloud Service Mesh géré.

Fonctionnalités du plan de contrôle géré

Installer, mettre à niveau et effectuer un rollback

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
Installation sur les clusters GKE à l'aide de l'API de la fonctionnalité PARC
Mises à niveau à partir de versions ASM 1.9 utilisant l'autorité de certification Mesh
Mises à niveau directes (avec saut de version) depuis les versions de Cloud Service Mesh antérieures à 1.9 (voir les notes pour les mises à niveau indirectes)
Mises à niveau directes d'Istio OSS (voir les notes pour les mises à niveau indirectes)
Mises à niveau directes du module complémentaire Istio-on-GKE (voir les notes pour les mises à niveau indirectes)
Activer les fonctionnalités facultatives

Environnements

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
Versions de GKE actuellement disponibles dans les canaux de publication, dans l'une des régions compatibles
Versions GKE actuellement disponibles dans les canaux de publication, dans l'une des régions compatibles, clusters Autopilot GKE
Environnements en dehors de Google Cloud (GKE Enterprise sur site, GKE Enterprise sur d'autres clouds publics, Amazon EKS, Microsoft AKS ou d'autres clusters Kubernetes)

Échelle

Consultez la page Limites d'évolutivité.

Environnement de plate-forme

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
Réseau unique
Plusieurs réseaux
Projet unique
Multiprojets avec un VPC partagé

Déploiement multicluster

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
Plusieurs serveurs principaux
Serveurs principaux à distance
Découverte de points de terminaison multicluster avec l'API déclarative
Découverte de points de terminaison multiclusters avec des secrets à distance
Découverte de points de terminaison multiclusters avec l'API déclarative et une topologie simple

Remarques sur la terminologie

  • Une configuration multi-primaire signifie que la configuration doit être répliquée dans tous les clusters.
  • Une configuration primaire-à-distance signifie qu'un seul cluster contient la configuration et est considéré comme la source de vérité.
  • 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.
  • Une topologie simple pour la découverte des points de terminaison multicluster signifie que chaque cluster du parc participe ou non à la découverte des points de terminaison. Les topologies complexes non compatibles incluent (a) la découverte de points de terminaison unidirectionnelle (par exemple, le cluster A peut découvrir les points de terminaison du cluster B, mais pas l'inverse) et (b) les réseaux de découverte de points de terminaison disjoints (par exemple, les clusters A et B peuvent découvrir les points de terminaison de l'autre, les clusters C et D peuvent découvrir les points de terminaison de l'autre, mais A/B et C/D ne peuvent pas découvrir les points de terminaison de l'autre).

Images de base

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
Image de proxy Distroless †

† Istio publie les images de proxy default, debug et distroless. Pour Cloud Service Mesh avec un plan de contrôle géré (TRAFFIC_DIRECTOR) : les clusters directement intégrés utilisent distroless par défaut et ne peuvent pas être modifiés. Les clusters migrés utilisent les images default par défaut et peuvent activer distroless à l'aide de MeshConfig ou d'une annotation de pod. Les remplacements d'autres types d'images (debug) ne sont pas acceptés.

Notez que les images distroless contiennent un minimum de binaires. Vous ne pouvez donc pas exécuter les commandes habituelles telles que bash ou curl, car elles ne sont pas présentes dans l'image distroless. Toutefois, vous pouvez utiliser des conteneurs éphémères pour vous attacher à un pod de charge de travail en cours d'exécution afin de pouvoir l'inspecter et exécuter des commandes personnalisées. Par exemple, consultez Collecter les journaux Cloud Service Mesh.

Sécurité

VPC Service Controls

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
VPC Service Controls

Mécanismes de distribution et de rotation des certificats

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
Gestion des certificats de charge de travail
Gestion des certificats externes sur les passerelles d'entrée et de sortie

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

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
Autorité de certification Cloud Service Mesh
Certificate Authority Service
Istio CA
Intégration aux autorités de certification personnalisées

Fonctionnalités de sécurité

En plus de prendre en charge les fonctionnalités de sécurité d'Istio, Cloud Service Mesh offre encore plus de fonctionnalités pour vous aider à sécuriser vos applications.

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
Intégration IAP
Authentification de l'utilisateur final
Mode de simulation
Journalisation de refus
Règles d'audit (non disponible)

Règle d'autorisation

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
Règle d'autorisation v1beta1
Règle d'autorisation CUSTOM

Authentification des pairs

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
mTLS automatique
mTLS en mode PERMISSIVE
mTLS en mode STRICT * *
mTLS en mode DISABLE

Remarque : Bien que l'API PeerAuthentication ne soit pas compatible avec le mode DISABLE pour l'implémentation du plan de contrôle TRAFFIC_DIRECTOR, vous pouvez désactiver mTLS pour des charges de travail spécifiques en utilisant l'API DestinationRule comme solution de contournement. Pour en savoir plus, consultez Désactiver mTLS pour Managed CSM.

Authentification des requêtes

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
Authentification JWT(Remarque 1)
Routage basé sur les revendications JWT
Copier la revendication JWT dans les en-têtes

Remarques :

  1. Le JWT tiers est activé par défaut.
  2. Ajoutez le nom d'hôte/FQDN complet dans JWKSURI lorsque vous définissez l'API RequestAuthentication.
  3. Le plan de contrôle géré oblige Envoy à récupérer les JWKS lorsque l'URI JWKS est spécifié.
  4. Les algorithmes AES-CBC A128CBC-HS256, A192CBC-HS384 et A256CBC-HS512 ne sont pas autorisés dans les JWKS intégrés lorsque vous utilisez l'implémentation du plan de contrôle TRAFFIC_DIRECTOR.

Télémétrie

Métriques

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
Cloud Monitoring (métriques HTTP dans le proxy)
Cloud Monitoring (métriques TCP dans le proxy)
Exportation des métriques Prometheus vers Grafana (métriques Envoy uniquement) * *
Exportation des métriques Prometheus vers Kiali
Google Cloud Managed Service pour Prometheus, à l'exclusion du tableau de bord Cloud Service Mesh * *
API Istio Telemetry  †
Adaptateurs/Backends personnalisés, via un processus ou hors processus
Backends de télémétrie et de journalisation arbitraires

† Le plan de contrôle TRAFFIC_DIRECTOR est compatible avec un sous-ensemble de l'API de télémétrie Istio utilisée pour configurer les journaux d'accès et le traçage.

Journalisation des requêtes de proxy

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
Journaux de trafic
Journaux d'accès * *

Trace

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
Cloud Trace * *
Traçage Jaeger (permet l'utilisation de Jaeger géré par le client) Compatible
Traçage Zipkin (permet d'utiliser Zipkin géré par le client) Compatible

Mise en réseau

Mécanismes d'interception et de redirection du trafic

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
Utilisation de iptables à l'aide de conteneurs init avec CAP_NET_ADMIN †
CNI (Container Network Interface) Istio
Side-car de type "boîte blanche"

† Nous vous recommandons vivement d'utiliser l'interface réseau de conteneur (CNI) au lieu des conteneurs init.

Compatibilité avec le protocole

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
IPv4
HTTP/1.1
HTTP/2
Flux d'octets TCP (Remarque 1)
gRPC
IPv6 †

Remarques :

  1. Bien que TCP soit un protocole compatible pour la mise en réseau et que les métriques TCP soient collectées, elles ne sont pas signalées. Les métriques ne sont affichées que pour les services HTTP dans la console Google Cloud .
  2. Les services configurés avec des fonctionnalités de couche 7 pour les protocoles suivants ne sont pas compatibles : WebSocket, MongoDB, Redis, MySQL, 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. Bien que des ports de passerelle puissent être créés avec les protocoles Mongo, MySQL et Redis, le maillage traite le trafic résultant comme du trafic TCP standard, sans gestion spécifique au protocole.
  3. † Dans gRPC sans proxy, les fonctionnalités IPv6 à double pile ne sont compatibles qu'avec gRPC 1.66.1 ou version ultérieure dans C++ et Python, gRPC Go v1.71 et/ou gRPC Node.js v1.12. Si vous essayez de configurer des fonctionnalités double pile avec une version de gRPC qui ne prend pas en charge la double pile, les clients n'utiliseront que la première adresse envoyée par Traffic Director.

Déploiements Envoy

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
Side-cars
Passerelle d'entrée
Sortie directe à partir des side-cars
Sortie à l'aide de passerelles de sortie * *

Compatibilité des CRD

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
Ressource side-car
Ressource d'entrée de service
Pourcentage, injection de pannes, mise en correspondance des chemins d'accès, redirections, nouvelles tentatives, réécriture, délai avant expiration, nouvelle tentative, mise en miroir, manipulation des en-têtes et règles de routage CORS
API`WasmPlugin`
Opérateur Istio

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

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
Équilibreur de charge externe tiers
Google Cloud Équilibreur de charge interne * *

Passerelle cloud de maillage de services

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
Passerelle cloud de maillage de services

API Gateway Kubernetes

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
API Gateway Kubernetes

Règles d'équilibrage de charge

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
Round robin (à tour de rôle)
connexions minimales
Aléatoire
Passthrough
Hachage cohérent
Localité
GCPTrafficDistributionPolicy
GCPBackendPolicy

Modes d'équilibrage de charge

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
TAUX
UTILISATION
CUSTOM_METRICS
EN COURS

Pour en savoir plus sur les modes d'équilibrage, consultez la Présentation des services de backend.

Entrée de service

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
ServiceEntry v1beta1 †

† L'implémentation du plan de contrôle TRAFFIC_DIRECTOR est compatible avec un sous-ensemble de champs ServiceEntry. Pour obtenir la liste complète des champs compatibles, des champs non compatibles et des limites de configuration, consultez Compatibilité de l'API : ServiceEntry.

Règle de destination

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
DestinationRule v1beta1 †

† L'implémentation du plan de contrôle TRAFFIC_DIRECTOR exige que la règle de destination définissant les sous-ensembles se trouve dans le même espace de noms et le même cluster que le service Kubernetes ou ServiceEntry. Pour obtenir la liste complète des champs compatibles, des champs non compatibles et des limites de configuration, consultez Compatibilité de l'API : DestinationRule.

Sidecar

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
Sidecar v1beta1 †

† L'implémentation du plan de contrôle TRAFFIC_DIRECTOR est compatible avec un sous-ensemble de champs Sidecar. Pour obtenir la liste complète des champs compatibles et non compatibles, ainsi que les limites de configuration, consultez Compatibilité de l'API : Sidecar.

Proxy DNS

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
Résolution de noms de Service entre les clusters †
Résolution de noms de ServiceEntry dans un cluster †
Résolution de nom de Service sans adresse IP de cluster
Attribution automatique d'adresses †

† La version 1.21.5-asm.39 ou ultérieure du side-car est requise.

EnvoyFilter

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
EnvoyFilter v1alpha3 †

† Consultez la page Extensibilité du plan de données pour connaître les champs compatibles et les extensions configurables.

MeshConfig

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
DiscoverySelectors
clusterLocal
LocalityLB †
ExtensionProviders
CACert
ImageType : distroless †
OutboundTrafficPolicy
defaultProviders.accessLogging
defaultProviders.tracing
defaultConfig.tracing.stackdriver
accessLogFile †
accessLogFormat †
accessLogEncoding †

† Pour en savoir plus sur le comportement de configuration, consultez Image de proxy sans distribution.
† Consultez Configurer l'équilibrage de charge de localité pour en savoir plus sur le comportement et les limites de configuration.
† Pour en savoir plus sur le comportement et les limites de configuration, consultez Personnaliser le format et l'encodage du journal d'accès Envoy.

ProxyConfig

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
Compatibilité HTTP/1.0 (ISTIO_META_NETWORK)
Sélection d'image (image minimale ou de base)
Side-car natif Kubernetes (ENABLE_NATIVE_SIDECARS)

Régions

Les clusters GKE doivent se trouver dans l'une des régions suivantes ou dans n'importe quelle zone des régions suivantes.

Région Emplacement
africa-south1 Johannesburg
asia-east1 Taïwan
asia-east2 Hong Kong
asia-northeast1 Tokyo, Japon
asia-northeast2 Osaka, Japon
asia-northeast3 Corée du Sud
asia-south1 Mumbai, Inde
asia-south2 Delhi, Inde
asia-southeast1 Singapour
asia-southeast2 Jakarta
australia-southeast1 Sydney, Australie
australia-southeast2 Melbourne, Australie
europe-central2 Pologne
europe-north1 Finlande
europe-north2 Stockholm
europe-southwest1 Espagne
europe-west1 Belgique
europe-west2 Angleterre
europe-west3 Francfort, Allemagne
europe-west4 Pays-Bas
europe-west6 Suisse
europe-west8 Milan, Italie
europe-west9 France
europe-west10 Berlin, Allemagne
europe-west12 Turin, Italie
me-central1 Doha
me-central2 Dammam, Arabie saoudite
me-west1 Tel-Aviv
northamerica-northeast1 Montréal, Canada
northamerica-northeast2 Toronto, Canada
northamerica-south1 Mexique
southamerica-east1 Brésil
southamerica-west1 Chili
us-central1 Iowa
us-east1 Caroline du Sud
us-east4 Virginie du Nord
us-east5 Ohio
us-south1 Dallas
us-west1 Oregon
us-west2 Los Angeles
us-west3 Salt Lake City
us-west4 Las Vegas

Interface utilisateur

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
Tableaux de bord Cloud Service Mesh dans la console Google Cloud
Cloud Monitoring
Cloud Logging

Outils

Fonctionnalité Plan de contrôle géré (TD) Plan de contrôle géré (istiod) obsolète
Outil gcloud beta container fleet mesh debug