La mise en réseau ambiante GKE fournit un modèle de déploiement simplifié et sans sidecar pour un maillage de services avec des fonctionnalités de couche 4. En transférant la fonctionnalité de proxy vers des composants au niveau des nœuds intégrés à GKE Dataplane V2 (DPv2), la mise en réseau ambiante réduit la surcharge de ressources, élimine les redémarrages de charge de travail pour les mises à jour de proxy et simplifie la gestion du cycle de vie du maillage.
Capacités
La version preview de la mise en réseau ambiante GKE est compatible avec la fonctionnalité de maillage de couche 4 à un seul cluster :
- TLS mutuel (mTLS) : applique le chiffrement en transit et l'authentification de l'identité.
- Découverte des services : découvre les services et achemine automatiquement les connexions entre les charges de travail.
- Gestion du trafic de couche 4 : équilibre la charge et achemine le trafic TCP.
- Télémétrie de couche 4 : émet des métriques sur le trafic réseau, les connexions et les erreurs vers Cloud Observability. Pour savoir comment visualiser et analyser ces métriques, consultez la présentation de la surveillance des services réseau.
Avantages de la mise en réseau ambiante
Par rapport aux architectures de maillage de services basées sur des sidecars, la mise en réseau ambiante offre plusieurs avantages opérationnels et de ressources clés :
Gestion simplifiée du cycle de vie : élimine le modèle de destin partagé entre les proxys side-car et les conteneurs d'application. Vous pouvez appliquer des mises à jour de proxy, des correctifs de sécurité et des mises à niveau au niveau du nœud sans redémarrer les pods de charge de travail ni provoquer de temps d'arrêt des applications.
Consommation de ressources réduite : la mise en proxy est consolidée dans des instances partagées au niveau des nœuds, ce qui réduit la surcharge de processeur et de mémoire jusqu'à 90% par rapport aux modèles side-car.
Élimination des risques liés aux sidecars : résout les problèmes courants liés aux sidecars, tels que les failles de contournement du proxy de conteneur, les interruptions de connexion persistantes et la propagation non fiable de la fin de la connexion.
Intégration native à la plate-forme Google Cloud : s'intègre de manière native à GKE Dataplane V2 (DPv2), Managed Workload Identity, Certificate Authority Service (CAS) et Google Cloud Observability.
Interopérabilité et portée
Pendant cette version bêta de la mise en réseau ambiante, tenez compte des contraintes de portée et d'interopérabilité suivantes :
- Exigence de l'API Gateway : la mise en réseau ambiante nécessite l'API Gateway. Les API Istio ne sont pas compatibles.
- Interopérabilité des charges de travail : les charges de travail enregistrées dans la mise en réseau ambiante ne peuvent pas interagir avec les charges de travail injectées dans un side-car (sur GKE, Compute Engine ou Cloud Run) ni avec les charges de travail gRPC sans proxy.
Architecture et composants
La mise en réseau ambiante s'intègre directement à GKE Dataplane V2 (DPv2) sur chaque nœud au lieu d'injecter des sidecars Envoy dans les pods de charge de travail.
Composants du plan de contrôle existants
La mise en réseau ambiante repose sur des composants du plan de contrôle pour distribuer les règles, traduire la configuration et émettre des certificats :
- Traffic Director : fournit le plan de contrôle xDS pour la distribution des règles et la configuration du routage.
- Le contrôleur GKE Gateway traduit les ressources personnalisées Kubernetes en configuration Traffic Director.
- Certificate Authority Service (CAS) : émet des certificats d'identité X.509 pour les charges de travail à l'aide de Managed Workload Identity.
- Plan de contrôle du cluster GKE : approuve les demandes de signature de certificat (CSR) et les achemine vers CAS.
Composants de nœud
La mise en réseau ambiante installe les composants par nœud suivants pour intercepter et transférer le trafic de charge de travail directement sur chaque nœud de cluster :
Plug-in NRI ambiant GKE : plug-in Node Resource Interface (NRI) qui configure la mise en réseau de bas niveau pour intercepter et rediriger le trafic des pods vers le proxy.
Proxy ambiant GKE : proxy au niveau du nœud qui gère les sockets d'écoute, reçoit les règles xDS de Traffic Director, récupère les certificats d'identité X.509 à la demande à partir du plan de contrôle GKE et sert de proxy pour le trafic de couche 4.
Les composants du dataplane ambiant au niveau des nœuds s'exécutent en tant que DaemonSets dans l'espace de noms gke-managed-ambient et sont automatiquement versionnés, corrigés et mis à niveau en même temps que le plan de contrôle GKE.
Échelle et limites cibles
En version bêta, la mise en réseau ambiante présente les limites de portée et d'interopérabilité suivantes :
| Métrique de ressource | GKE DPv2 (avec ambient) | GKE Standard DPv2 (sans ambient) |
|---|---|---|
| Nœuds par cluster | 500 | 7 500 |
| Services par cluster | 300 | 10 000 |
| Pods par cluster | 5 000 | 200 000 |
| Nombre maximal de pods par nœud | 256 | 256 |
Pour connaître les quotas généraux des clusters GKE, consultez les limites des clusters et les spécifications de GKE Dataplane V2.
Tarifs
Consultez les informations suivantes concernant les tarifs et les frais liés aux ressources opérationnelles pour la mise en réseau ambiante :
- Tous les pods de n'importe quel espace de noms portant le libellé ambiant
networking.gke.io/dataplane-mode=ambientseront facturés 0,004 $ par heure (0,00006667 $ par minute, soit environ 2,90 $ par mois). La facturation ne sera pas appliquée pendant la preview. - Les frais d'utilisation standards pour Cloud Observability (Cloud Monitoring / Cloud Logging) et Certificate Authority Service'appliquent.
Comprendre les ressources de l'API Gateway
Lorsque vous utilisez la mise en réseau ambiante, les ressources personnalisées de l'API Kubernetes Gateway que vous gérez sur votre cluster sont automatiquement traduites en un ensemble de ressources d'APIGoogle Cloud gérées.
| Fonctionnalité | Ressource d'API Google Cloud gérée | Champ d'application | Cardinalité |
|---|---|---|---|
| Routage des services | TCPRoute |
Régional | Un par service Kubernetes avec mTLS activé |
| Représentation du service | BackendService |
Régional | 2 par cluster |
| Authentification | ClientTlsPolicy, ServerTlsPolicy |
Régional | 1 par règle Kubernetes correspondante |
| Autorisation | EndpointPolicy, TcpFilter |
Régional | 1 par règle Kubernetes correspondante |
Étapes suivantes
- Préparer la mise en réseau ambiante GKE
- À propos de l'API Gateway
- Présentation de la surveillance des services réseau