Fonctionnalités compatibles à l'aide des API Istio (plan de contrôle géré)

Cette page décrit les fonctionnalités et les limites compatibles avec 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 fonctionnalités Cloud Service Mesh compatibles avec une instance intégrée à un cluster, sur le plan de contrôle, consultez Utiliser les API Istio (plan de contrôle istiod dans le cluster) Si vous ne savez pas quel plan de contrôle Cloud Service Mesh 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.
  • Il n'est pas possible de modifier les canaux de publication.
  • Migrations depuis Cloud Service Mesh géré avec asmcli à Cloud Service Mesh avec l'API de parc ne sont pas acceptés. 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 et mises à niveau ne sont compatibles qu'à partir des versions 1.9 et ultérieures de Cloud Service Mesh installées avec Mesh CA. Les installations utilisant Istio CA (anciennement Citadel) doivent d'abord migrer vers Mesh CA.
  • Le scaling est limité à 1 000 services et 5 000 charges de travail par cluster.
  • 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:

    • EnvoyFilter API

    • WasmPlugin API

    • IstioOperator API

    • Kubernetes Ingress API

  • 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 les fonctionnalités disponibles aux abonnés et aux non-abonnés, consultez Différences entre l'interface utilisateur de GKE Enterprise et de 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.

  • Le service géré Cloud Service Mesh n'est compatible qu'avec le domaine DNS par défaut .cluster.local.

  • Depuis le 14 novembre 2023, les nouvelles installations de Cloud Service Mesh géré sur le canal de publication rapide ne récupèrent les clés JWKS qu'à l'aide d'envoys. Cela équivaut à l'option Istio PILOT_JWT_ENABLE_REMOTE_JWKS=envoy. Par rapport aux installations sur les canaux de publication standard et stable, ou sur le canal de publication rapide avant le 14 novembre 2023, vous devrez peut-être configurer des ServiceEntry et DestinationRule supplémentaires. Pour voir un exemple, consultez la requestauthn-with-se.yaml.tmpl

Différences entre les plans 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 la section 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 peuvent avoir des différences entre les différentes 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é est compatible avec la liste d'autorisation. Les anciens utilisateurs d'Anthos Service Mesh géré automatiquement ajouté à la liste d'autorisation au niveau de l'organisation. Contactez l'assistance Google Cloud pour demander l'accès. ou pour vérifier l'état de votre liste d'autorisation.
  •  : 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.

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éterminer quelle implémentation du plan de contrôle utiliser. La même implémentation est utilisé pour tous les clusters qui provisionnent le maillage Cloud Service Mesh géré de ce parc.

Les nouveaux parcs qui intègrent le maillage de services Cloud Service géré reçoivent le 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é, jusqu'au 30 juin 2024 au moins. Si vous faites partie de ces utilisateurs, vous pouvez contacter l'assistance pour ajuster ce comportement. Utilisateurs dont l'utilisation existante n'est pas compatible avec TRAFFIC_DIRECTOR mise en œuvre sans modification continuera de recevoir le ISTIOD est mise en œuvre jusqu'au 8 septembre 2024. (Ces utilisateurs ont reçu une annonce de service.)
  • Si un cluster de votre parc utilise le service d'autorité de certification lorsque vous provisionnez Cloud Service Mesh géré, vous recevez l'implémentation du plan de contrôle ISTIOD.
  • Si un cluster de votre parc contient un plan de contrôle Cloud Service Mesh au sein du 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 le bac à sable GKE, 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

Caractéristique Géré (TD) Géré (istiod)
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 à partir de versions de Cloud Service Mesh antérieures à la version 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

Caractéristique Géré (TD) Géré (istiod)
GKE 1.25 à 1.27 dans l'une des régions compatibles
Clusters GKE 1.25 à 1.27 avec Autopilot
Environnements en dehors de Google Cloud (GKE Enterprise sur site, sur d'autres clouds publics, Amazon EKS, Microsoft AKS ou d'autres clusters Kubernetes)

Échelle

Caractéristique Géré (TD) Géré (istiod)
1 000 services et 5 000 charges de travail par cluster
50 ports de service sans adresse IP de cluster par maillage et 36 pods par port de service sans adresse IP de cluster

Environnement de plate-forme

Caractéristique Géré (TD) Géré (istiod)
Réseau unique
Plusieurs réseaux
Projet unique
Multiprojets avec VPC partagé

Déploiement multicluster

Caractéristique Géré (TD) Géré (istiod)
Plusieurs serveurs principaux
Serveurs principaux à distance
Détection de points de terminaison multiclusters avec l'API déclarative
Détection de points de terminaison multicluster avec des secrets distants

Remarques sur la terminologie

  • Une configuration avec plusieurs déploiements principaux signifie que la configuration doit être répliquée dans tous les clusters.
  • Une configuration de déploiement principal à distance signifie qu'un cluster unique contient la configuration et qu'elle est considérée comme source fiable.
  • 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.

Images de base

Caractéristique Géré (TD) Géré (istiod)
Image de proxy Distroless †

† Cloud Service Mesh avec un plan de contrôle géré (TD) ne prend en charge que le type d'image "distroless". Vous ne pouvez pas le modifier.

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

Sécurité

VPC Service Controls

Caractéristique Géré (TD) Géré (istiod)
Version preview de VPC Service Controls
VPC Service Controls DG

Mécanismes de distribution et de rotation des certificats

Caractéristique Géré (TD) Géré (istiod)
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)

Caractéristique Géré (TD) Géré (istiod)
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 proposer des fonctionnalités de sécurité Istio, Cloud Service Mesh offre encore plus de fonctionnalités pour vous aider à sécuriser vos applications.

Caractéristique Géré (TD) Géré (istiod)
Intégration IAP
Authentification de l'utilisateur final
Mode de simulation
Journalisation de refus
Règles d'audit (non compatibles)

Règle d'autorisation

Caractéristique Géré (TD) Géré (istiod)
Règle d'autorisation v1beta1 †
Règle d'autorisation PERSONNALISÉE §

† L'implémentation du plan de contrôle TRAFFIC_DIRECTOR n'est pas compatible avec les champs rules.from.source.RemoteIp et rules.from.source.NotRemoteIp.

Authentification des pairs

Caractéristique Géré (TD) Géré (istiod)
mTLS automatique
mTLS en mode PERMISSIVE
mTLS en mode STRICT * *
Mode DÉSACTIVÉ mTLS

Authentification des requêtes

Caractéristique Géré (TD) Géré (istiod)
Authentification JWT(Remarque 1)
Routage basé sur les revendications JWT
Revendication de copie 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 à extraire le JWKS lorsque vous spécifiez un URI JWKS.

Télémétrie

Métriques

Caractéristique Géré (TD) Géré (istiod)
Cloud Monitoring (métriques HTTP dans le proxy)
Cloud Monitoring (métriques TCP dans le proxy)
Exportation de 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 Telemetry Istio †
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 d'Istio. utilisées pour configurer les journaux d'accès et trace.

Journalisation des requêtes de proxy

Caractéristique Géré (TD) Géré (istiod)
Journaux de trafic
Journaux d'accès * *

Trace

Caractéristique Géré (TD) Géré (istiod)
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

Caractéristique Géré (TD) Géré (istiod)
Utilisation classique de iptables à l'aide de conteneurs init avec CAP_NET_ADMIN
CNI (Container Network Interface) Istio
Side-car de type "boîte blanche"

Compatibilité avec le protocole

Caractéristique Géré (TD) Géré (istiod)
IPv4
HTTP/1.1
HTTP/2
Flux d'octets TCP (Remarque 1)
gRPC
IPv6

Remarques :

  1. Bien que TCP soit un protocole pris en charge pour la mise en réseau et TCP de métriques sont collectées, elles ne sont pas incluses dans les rapports. 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, 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.

Déploiements Envoy

Caractéristique Géré (TD) Géré (istiod)
Side-cars
Passerelle d'entrée
Sortie directe à partir des side-cars
Sortie à l'aide de passerelles de sortie * *

Compatibilité des CRD

Caractéristique Géré (TD) Géré (istiod)
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 "EnvoyFilter" §
API WasmPlugin
Opérateur Istio

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

Caractéristique Géré (TD) Géré (istiod)
Équilibreur de charge externe tiers
Équilibreur de charge interne Google Cloud * *

Passerelle cloud du maillage de services

Caractéristique Géré (TD) Géré (istiod)
Passerelle cloud de service mesh

API Gateway Kubernetes

Caractéristique Géré (TD) Géré (istiod)
API Gateway Kubernetes

Règles d'équilibrage de charge

Caractéristique Géré (TD) Géré (istiod)
Round robin (à tour de rôle)
connexions minimales
Aléatoire
Passthrough
Hachage cohérent
Localité

Entrée de service

Caractéristique Géré (TD) Géré (istiod)
ServiceEntry v1beta1 †

† L'implémentation du plan de contrôle TRAFFIC_DIRECTOR n'est pas compatible avec les champs et valeurs suivants :

  • Champ workloadSelector
  • Champ endpoints[].network
  • Champ endpoints[].locality
  • Champ endpoints[].weight
  • Champ endpoints[].serviceAccount
  • Valeur DNS_ROUND_ROBIN dans le champ resolution
  • Valeur MESH_INTERNAL dans le champ location
  • Adresse du socket de domaine Unix dans le champ endpoints[].address
  • Champ subjectAltNames

Règle de destination

Caractéristique Géré (TD) Géré (istiod)
DestinationRule v1beta1 †

† L'implémentation du plan de contrôle TRAFFIC_DIRECTOR n'est pas compatible Champ trafficPolicy.loadBalancer.localityLbSetting et trafficPolicy.tunnel . De plus, l'implémentation du plan de contrôle TRAFFIC_DIRECTOR nécessite que le règle de destination définissant des sous-ensembles se trouve dans le même espace de noms et le même cluster avec le service Kubernetes ou l'entrée ServiceEntry.

Sidecar

Caractéristique Géré (TD) Géré (istiod)
Sidecar v1beta1 †

† L'implémentation du plan de contrôle TRAFFIC_DIRECTOR n'est pas compatible avec les champs et valeurs suivants :

  • Champ ingress
  • Champ egress.port
  • Champ egress.bind
  • Champ egress.captureMode
  • Champ inboundConnectionPool

MeshConfig

Caractéristique Géré (TD) Géré (istiod)
LocalityLB §
ExtensionProviders §
CACert
ImageType – distroless §
OutboundTrafficPolicy §
defaultProviders.accessLogging
defaultProviders.tracing
defaultConfig.tracing.stackdriver §
accessLogFile §

ProxyConfig

Caractéristique Géré (TD) Géré (istiod)
Proxy DNS (ISTIO_META_DNS_CAPTURE, ISTIO_META_DNS_AUTO_ALLOCATE)
Compatibilité avec HTTP/1.0 (ISTIO_META_NETWORK)
Sélection d'images (distroles ou image de base) †

† L'image Distroless est utilisée pour l'injection.

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
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-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
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

Caractéristique Géré (TD) Géré (istiod)
Tableaux de bord Cloud Service Mesh dans la console Google Cloud
Cloud Monitoring
Cloud Logging

Outils

Caractéristique Géré (TD) Géré (istiod)
Outil gcloud beta container fleet mesh debug