La mise en réseau ambiante GKE fournit un modèle de déploiement simplifié sans side-car pour un maillage de services avec des fonctionnalités de couche 4. En déplaçant la fonctionnalité de proxy vers des composants au niveau du nœud intégrés à GKE Dataplane V2 (DPv2), la mise en réseau ambiante réduit la surcharge de ressources, élimine les redémarrages de charges 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 à cluster unique :
- TLS mutuel (mTLS) : applique le chiffrement du transit et l'authentification de l'identité.
- Découverte des services : découvre automatiquement les services et achemine les connexions entre les charges de travail.
- 10. 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 de trafic réseau, de connexion et d'erreur vers Cloud Observability. Pour en savoir plus sur la visualisation et l'analyse de 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 side-cars, la mise en réseau ambiante offre plusieurs avantages clés en termes d'exploitation et de ressources :
Gestion simplifiée du cycle de vie : élimine le modèle dit 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 de l'application.
Réduction de la consommation de ressources : consolide le proxying dans des instances partagées au niveau du nœud, 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 side-cars : résout les problèmes courants liés aux side-cars, tels que les failles de contournement du proxy de conteneur, l'interruption de la connexion persistante et la propagation non fiable de l'arrêt de la connexion.
Intégration de la plate-forme native Google Cloud : s'intègre de manière native à GKE Dataplane V2 (DPv2), à Workload Identity géré, à Certificate Authority Service (CAS) et à Google Cloud Observability.
Interopérabilité et champ d'application
Pendant cette version preview de la mise en réseau ambiante, tenez compte des contraintes de champ d'application 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 par 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 plutôt que d'injecter des side-cars Envoy dans les pods de charge de travail.
Composants du plan de contrôle existants
La mise en réseau ambiante s'appuie sur les 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.
- GKE Gateway Controller : 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 Workload Identity gérée.
- 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 suivants par nœud pour intercepter et proxyser le trafic des charges de travail directement sur chaque nœud du 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 gère le trafic de couche 4.
Les composants du plan de données ambiant au niveau du nœud s'exécutent en tant que DaemonSets dans l'espace de noms gke-managed-ambient. Ils sont automatiquement gérés par version, corrigés et mis à niveau avec le plan de contrôle GKE.
Échelle et limites de la cible
En version preview, la mise en réseau ambiante présente les limites de champ d'application et d'interopérabilité suivantes :
| Métrique de ressource | GKE DPv2 (avec Ambient) | GKE DPv2 standard (sans mode ambiant) |
|---|---|---|
| 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 de ressources opérationnelles pour la mise en réseau ambiante :
- Tous les pods de n'importe quel espace de noms portant l'étiquette ambiante
networking.gke.io/dataplane-mode=ambientseront facturés 0,004 $ par heure (0,00006667 $ par minute ou environ 2,90 $ par mois). La facturation ne sera pas appliquée pendant la preview. - Les frais d'utilisation standards de Cloud Observability (Cloud Monitoring/Cloud Logging) et de Certificate Authority Service s'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é |
|---|---|---|---|
| Maillé | Mesh |
Régional | 1 par cluster |
| Routage des services | TCPRoute |
Régional | 1 par cluster, plus 1 par service ciblé par un GCPClientTLSPolicy |
| Représentation du service | BackendService |
Régional | 1 par cluster |
| Authentification client | ClientTlsPolicy |
Régional | 1 par cluster |
| Authentification du serveur | ServerTlsPolicy |
Régional | 3 par cluster |
| Authentification du serveur | EndpointPolicy |
Régional | 1 par GCPServerTLSPolicy, plus 1 par mode mTLS distinct dans son portOverrides |
| Autorisation | AuthzPolicy |
Régional | 1 par pod targetRef dans chaque GCPAuthzPolicy avec enforcementLevel: L4 |
| Routage de sortie | EgressRouting |
Régional | 1 par espace de noms disposant d'un GCPEgressPolicy |
É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