La red ambiental de GKE proporciona un modelo de implementación simplificado y sin sidecar para una malla de servicios con capacidades de capa 4. Al trasladar la funcionalidad del proxy a componentes a nivel del nodo integrados en GKE Dataplane V2 (DPv2), las redes ambientales reducen la sobrecarga de recursos, eliminan los reinicios de cargas de trabajo para las actualizaciones de proxy y simplifican la administración del ciclo de vida de la malla.
Funciones
La versión preliminar de las redes ambientales de GKE admite la funcionalidad de malla de capa 4 de un solo clúster:
- TLS mutua (mTLS): Aplica la encriptación en tránsito y la autenticación de identidad.
- Descubrimiento de servicios: Descubre servicios y enruta conexiones automáticamente entre cargas de trabajo.
- Administración de tráfico de capa 4: Balancea las cargas y enruta el tráfico de TCP.
- Telemetría de capa 4: Emite métricas de tráfico de red, conexión y errores a Cloud Observability. Para obtener detalles sobre cómo visualizar y analizar estas métricas, consulta la descripción general de la supervisión de servicios de red.
Beneficios de las redes ambientales
En comparación con las arquitecturas de malla de servicios basadas en sidecar, las redes de transferencia ofrecen varias ventajas operativas y de recursos clave:
Administración del ciclo de vida simplificada: Elimina el modelo de destino compartido entre los proxies de sidecar y los contenedores de aplicaciones. Puedes aplicar actualizaciones de proxy, parches de seguridad y actualizaciones a nivel del nodo sin reiniciar los Pods de carga de trabajo ni causar tiempo de inactividad de la aplicación.
Consumo de recursos reducido: Consolida el proxy en instancias compartidas a nivel del nodo, lo que reduce la sobrecarga de CPU y memoria hasta en un 90% en comparación con los modelos de sidecar.
Eliminación de riesgos de sidecar: Resuelve problemas comunes de sidecar, como vulnerabilidades de omisión de proxy de contenedores, interrupciones de conexión persistentes y propagación poco confiable de la finalización de la conexión.
Integración nativa Google Cloud en la plataforma: Se integra de forma nativa en GKE Dataplane V2 (DPv2), Managed Workload Identity, Certificate Authority Service (CAS) y Google Cloud Observability.
Interoperabilidad y alcance
Durante esta versión preliminar de las redes ambientales, ten en cuenta las siguientes restricciones de alcance e interoperabilidad:
- Requisito de la API de Gateway: Las redes ambientales requieren la API de Gateway. No se admiten las APIs de Istio.
- Interoperabilidad de cargas de trabajo: Las cargas de trabajo inscritas en redes ambientales no pueden interoperar con cargas de trabajo insertadas en sidecar (en GKE, Compute Engine o Cloud Run) ni con cargas de trabajo de gRPC sin proxy.
Arquitectura y componentes
Las redes perimetrales se integran directamente en GKE Dataplane V2 (DPv2) en cada nodo, en lugar de insertar sidecars de Envoy en los Pods de carga de trabajo.
Componentes existentes del plano de control
Las redes ambientales dependen de los componentes del plano de control para distribuir políticas, traducir la configuración y emitir certificados:
- Traffic Director: Proporciona el plano de control de xDS para la distribución de políticas y la configuración de enrutamiento.
- GKE Gateway Controller: Traduce los recursos personalizados de Kubernetes en la configuración de Traffic Director.
- Certificate Authority Service (CAS): emite certificados de identidad X.509 para cargas de trabajo mediante Workload Identity administrada.
- Plano de control del clúster de GKE: Aprueba las solicitudes de firma de certificados (CSR) y las enruta a la CA.
Componentes de nodos
Las redes ambientales instalan los siguientes componentes por nodo para interceptar y redireccionar el tráfico de la carga de trabajo directamente en cada nodo del clúster:
Complemento de NRI de GKE ambient: Complemento de interfaz de recursos de nodo (NRI) que configura redes de bajo nivel para interceptar y redireccionar el tráfico de Pods al proxy.
Proxy ambiental de GKE: Proxy a nivel del nodo que administra los sockets de escucha, recibe reglas de xDS de Traffic Director, recupera certificados de identidad X.509 a pedido del plano de control de GKE y actúa como proxy del tráfico de capa 4.
Los componentes del plano de datos ambient a nivel del nodo se ejecutan como DaemonSets en el espacio de nombres gke-managed-ambient y se les aplica automáticamente el control de versiones, los parches y las actualizaciones junto con el plano de control de GKE.
Escala y límites de destino
Durante la versión preliminar, las redes ambientales tienen los siguientes límites de alcance e interoperabilidad:
| Métrica de recursos | GKE DPv2 (con ambient) | GKE DPv2 estándar (sin ambient) |
|---|---|---|
| Nodos por clúster | 500 | 7,500 |
| Services por clúster | 300 | 10,000 |
| Pods por clúster | 5,000 | 200,000 |
| Cantidad máxima de Pods por nodo | 256 | 256 |
Para conocer las cuotas generales de clúster de GKE, consulta los límites de los clústeres y las especificaciones de GKE Dataplane V2.
Precios
Revisa los siguientes detalles sobre los precios y los cargos por recursos operativos de las redes ambientales:
- Todos los Pods en cualquier espacio de nombres con la etiqueta ambiental
networking.gke.io/dataplane-mode=ambientse facturarán a USD 0.004 por hora (USD 0.00006667 por minuto o aproximadamente USD 2.90 por mes). No se aplicará la facturación durante la versión preliminar. - Se aplican los cargos de uso estándar de Cloud Observability (Cloud Monitoring / Cloud Logging) y de Certificate Authority Service.
Información sobre los recursos de la API de Gateway
Cuando usas redes ambientales, los recursos personalizados de la API de Kubernetes Gateway que administras en tu clúster se traducen automáticamente en un conjunto de recursos de la API deGoogle Cloud administrados.
| Funcionalidad | Recurso de la API Google Cloud administrado | Alcance | Cardinalidad |
|---|---|---|---|
| Planificación de ruta de servicios | TCPRoute |
Regional | 1 por cada servicio de Kubernetes con mTLS habilitado |
| Representación del servicio | BackendService |
Regional | 2 por clúster |
| Authentication | ClientTlsPolicy, ServerTlsPolicy |
Regional | 1 por cada política de Kubernetes correspondiente |
| Autorización | EndpointPolicy, TcpFilter |
Regional | 1 por cada política de Kubernetes correspondiente |
¿Qué sigue?
- Prepara las redes ambientales de GKE
- Acerca de la API de Gateway
- Descripción general de la supervisión de servicios de red