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

Cette page décrit les fonctionnalités et les limites compatibles avec Cloud Service Mesh utilisant Cloud Service Mesh 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 de Cloud Service Mesh.

Pour obtenir la liste des fonctionnalités compatibles avec Cloud Service Mesh pour un plan de contrôle de cluster, consultez la section 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 la mise en œuvre de votre plan de contrôle en suivant les instructions de la section Identifier la mise en œuvre 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 changer de version disponible.
  • Les migrations de Cloud Service Mesh géré avec asmcli vers Cloud Service Mesh avec l'API de parc ne sont pas acceptées. De même, il n'est pas possible de provisionner le maillage de services Cloud Service géré avec l'API de parc de --management manual vers --management automatic.
  • Les migrations et les mises à niveau ne sont possibles qu'à partir des versions 1.9 et ultérieures de Cloud Service Mesh installées dans le cluster 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. À la place, 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

    • Kubernetes Gateway API

  • Vous pouvez utiliser le plan de contrôle géré sans abonnement GKE Enterprise, mais certains éléments d'interface utilisateur 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 le cluster contient des CRD Istio existantes, elles seront écrasées.

  • Le maillage de services Cloud géré n'est compatible qu'avec le domaine DNS par défaut .cluster.local.

  • Depuis le 14 novembre 2023, les nouvelles installations de maillage de services Cloud géré sur le version disponible rapid extraient JWKS uniquement à l'aide d'Envoys. Cela équivaut à l'option Istio PILOT_JWT_ENABLE_REMOTE_JWKS=envoy. Par rapport aux installations sur les versions disponibles standard et stable, ou à celles en version disponible rapide avant le 14 novembre 2023, vous pourriez avoir besoin de configurations ServiceEntry et DestinationRule supplémentaires. Pour obtenir un exemple, consultez requestauthn-with-se.yaml.tmpl.

Différences du plan de contrôle

Il existe des différences de fonctionnalités compatibles entre les implémentations du plan de contrôle istiod et Cloud Service Mesh. Pour vérifier l'implémentation que vous utilisez, consultez la section Identifier la mise en œuvre du plan de contrôle.

  •  : indique que la fonctionnalité est disponible et activée par défaut.
  • † : indique que les API de fonctionnalité peuvent présenter des différences entre différentes plates-formes.
  • * : indique que la fonctionnalité est compatible avec la plate-forme et peut être activée, comme décrit dans la section Activer les fonctionnalités facultatives ou dans le guide des fonctionnalités disponible dans le tableau des fonctionnalités.
  • § : indique que la fonctionnalité est compatible avec la liste d'autorisation. Contactez l'assistance Google Cloud pour demander l'accè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.

Ce qui détermine l'implémentation du plan de contrôle

Lorsque vous provisionnez le maillage de services Cloud Service 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 le maillage de services Cloud géré dans ce parc.

Les nouveaux parcs qui s'intègrent au maillage de services Cloud 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 recevez l'implémentation du plan de contrôle ISTIOD lorsque vous intégrez un nouveau parc dans la même organisation Google Cloud vers le maillage de services Cloud géré, jusqu'au 24 juin 2024 au moins. Si vous faites partie de ces utilisateurs, vous pouvez contacter l'assistance pour ajuster ce comportement.
  • Si un cluster de votre parc utilise Certificate Authority Service lorsque vous provisionnez le maillage de services Cloud Service géré, vous recevez l'implémentation du plan de contrôle ISTIOD.
  • Si l'un des clusters de votre parc contient un plan de contrôle Cloud Service Mesh dans le cluster lorsque vous provisionnez le maillage de services Cloud géré, vous recevez l'implémentation du plan de contrôle ISTIOD.
  • Si l'un des clusters de votre parc utilise GKE Sandbox, vous recevez la mise en œuvre du plan de contrôle ISTIOD lorsque vous provisionnez le maillage de services Cloud géré.

Identifier l'implémentation du plan de contrôle

Exécutez la commande suivante pour identifier la mise en œuvre de votre plan de contrôle:

  gcloud container fleet mesh describe --project FLEET_PROJECT_ID

Notez que si vous utilisez Cloud Service Mesh avec les API Google Cloud (consultez la section À propos de Cloud Service Mesh), cette commande ne fonctionnera pas.

Le résultat ressemble à ce qui suit :

  ...
  membershipSpecs:
    projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
      mesh:
        management: MANAGEMENT_AUTOMATIC
  membershipStates:
    projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
      servicemesh:
        controlPlaneManagement:
          details:
          - code: REVISION_READY
            details: 'Ready: asm-managed'
          state: ACTIVE
          implementation: TRAFFIC_DIRECTOR
  ...

Les valeurs possibles implementation sont les suivantes:

  • TRAFFIC_DIRECTOR: l'infrastructure principale de Google Cloud sert de plan de contrôle pour Cloud Service Mesh.
  • ISTIOD: l'instance gérée de istiod sert de plan de contrôle Cloud Service Mesh.
  • UPDATING: le cluster est en cours de migration entre les implémentations. L'implémentation de TRAFFIC_DIRECTOR sera bientôt disponible.

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

Installer, mettre à niveau et effectuer un rollback

Sélection 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 (de niveau ignorant) à 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

Sélection 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, GKE Enterprise sur d'autres clouds publics, Amazon EKS, Microsoft AKS ou d'autres clusters Kubernetes)

Échelle

Sélection Géré (TD) Géré (Istiod)
1 000 services et 5 000 charges de travail par cluster
50 ServicePorts par maillage et 36 pods par ServicePort

Environnement de plate-forme

Sélection Géré (TD) Géré (Istiod)
Réseau unique
Plusieurs réseaux
Projet unique
Multiprojet avec VPC partagé

Déploiement multicluster

Sélection Géré (TD) Géré (Istiod)
Plusieurs serveurs principaux
Serveurs principaux à distance
Détection de points de terminaison multicluster avec une API déclarative
Détection de points de terminaison multicluster avec des secrets distants

Remarques sur la terminologie

  • Une configuration multi-principale signifie que la configuration doit être répliquée dans tous les clusters.
  • Une configuration primaire à distance signifie qu'un cluster unique contient la configuration et est considéré comme source de référence.
  • 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

Sélection Géré (TD) Géré (Istiod)
Image de proxy Distroless †

† Cloud Service Mesh avec un plan de contrôle géré (TD) n'est compatible qu'avec le type d'image "distroless". Vous ne pouvez pas le modifier.

Notez que les images distroles ont peu 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 à associer à un pod de charge de travail en cours d'exécution pour pouvoir l'inspecter et exécuter des commandes personnalisées. Par exemple, consultez la section Collecter des journaux Cloud Service Mesh.

Sécurité

VPC Service Controls

Sélection Géré (TD) Géré (Istiod)
Aperçu de VPC Service Controls
VPC Service Controls accessible à tous

Mécanismes de distribution et de rotation des certificats

Sélection 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)

Sélection 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 d'être compatible avec les fonctionnalités de sécurité d'Istio, Cloud Service Mesh offre des fonctionnalités supplémentaires pour vous aider à sécuriser vos applications.

Sélection 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

Sélection Géré (TD) Géré (Istiod)
Règle d'autorisation v1beta1 †
Règles d'autorisation PERSONNALISÉES §

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

Authentification des pairs

Sélection Géré (TD) Géré (Istiod)
mTLS automatique
mTLS en mode PERMISSIVE
mTLS en mode STRICT * *
Mode DÉSACTIVÉ de mTLS

Authentification des requêtes

Sélection Géré (TD) Géré (Istiod)
Authentification JWT(Remarque 1)
Routage basé sur une revendication JWT
Copie de 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 tout en définissant l'API RequestAuthentication.
  3. Le plan de contrôle géré impose à Envoy d'extraire JWKS lors de la spécification de l'URI JWKS.

Télémétrie

Métriques

Sélection Géré (TD) Géré (Istiod)
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 Telemetry d'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 Cloud Service Mesh accepte un sous-ensemble de l'API de télémétrie d'Istio utilisée pour configurer les journaux d'accès et la trace.

Journalisation des requêtes proxy

Sélection Géré (TD) Géré (Istiod)
Journaux de trafic
Journaux d'accès * *

Trace

Sélection 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

Sélection 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

Sélection 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 compatible pour la mise en réseau et que des métriques TCP soient collectées, elles ne sont pas consigné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, 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 être compatible avec le protocole (par exemple, Kafka envoie une adresse de redirection dans une réponse spécifique au protocole et cette redirection est incompatible avec la logique de routage de Cloud Service Mesh), le protocole n'est pas compatible.

Déploiements Envoy

Sélection 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

Sélection 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

Sélection Géré (TD) Géré (Istiod)
Équilibreur de charge externe tiers
Équilibreur de charge interne Google Cloud * *

Passerelle cloud du maillage de services

Sélection Géré (TD) Géré (Istiod)
Passerelle cloud du maillage de services

API Kubernetes Gateway

Sélection Géré (TD) Géré (Istiod)
API Kubernetes Gateway

Règles d'équilibrage de charge

Sélection 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

Sélection Géré (TD) Géré (Istiod)
ServiceEntry v1beta1 †

† L'implémentation du plan de contrôle Cloud Service Mesh n'accepte pas 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 de socket de domaine Unix dans le champ endpoints[].address

Règle de destination

Sélection Géré (TD) Géré (Istiod)
DestinationRule v1beta1 †

† L'implémentation du plan de contrôle Cloud Service Mesh n'est pas compatible avec les champs trafficPolicy.loadBalancer.localityLbSetting et trafficPolicy.tunnel. En outre, l'implémentation du plan de contrôle Cloud Service Mesh nécessite que la règle de destination définissant des sous-ensembles se trouve dans le même espace de noms et le même cluster que le service Kubernetes ou ServiceEntry.

Sidecar

Sélection Géré (TD) Géré (Istiod)
Sidecar v1beta1 †

† L'implémentation du plan de contrôle Cloud Service Mesh n'accepte pas les champs et valeurs suivants:

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

MeshConfig

Sélection Géré (TD) Géré (Istiod)
LocalityLB §
ExtensionProviders §
CACert
ImageType – distroless §
OutboundTrafficPolicy §
defaultProviders.accessLogging
defaultProviders.tracing
defaultConfig.tracing.stackdriver §
accessLogFile §

ProxyConfig

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

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

Sélection Géré (TD) Géré (Istiod)
Tableaux de bord Cloud Service Mesh dans la console Google Cloud
Cloud Monitoring
Cloud Logging

Outils

Sélection Géré (TD) Géré (Istiod)
Outil gcloud beta container fleet mesh debug