La red de Ambient de GKE proporciona un modelo de implementación simplificado y sin sidecar para una malla de servicios con capacidades de capa 4. Cuando se traslada la funcionalidad de proxy a los componentes a nivel del nodo integrados en GKE Dataplane V2 (DPv2), Ambient Networking reduce la sobrecarga de recursos, elimina los reinicios de las cargas de trabajo para las actualizaciones del proxy y simplifica la administración del ciclo de vida de la malla.
Funciones
La versión preliminar de Ambient Networking de GKE admite la funcionalidad de malla de capa 4 de un solo clúster:
- TLS mutua (mTLS): Aplica el tránsito encriptado y la autenticación de identidad.
- Descubrimiento de servicios: Descubre servicios y enruta conexiones automáticamente en las 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 Ambient Networking
En comparación con las arquitecturas de malla de servicios basadas en sidecars, Ambient Networking ofrece varias ventajas operativas y de recursos clave:
Administración simplificada del ciclo de vida: Elimina el modelo de destino compartido entre los proxies sidecar y los contenedores de aplicaciones. Puedes aplicar actualizaciones de proxy, parches de seguridad y actualizaciones a nivel de nodo sin reiniciar los Pods de carga de trabajo ni causar tiempo de inactividad de la aplicación.
Menor consumo de recursos: Consolida el proxy en instancias compartidas a nivel de nodo, lo que reduce la sobrecarga de CPU y memoria hasta un 90% en comparación con los modelos sidecar.
Eliminación de riesgos de sidecar: Resuelve problemas comunes de sidecar, como vulnerabilidades de omisión de proxy de contenedor, interrupción de conexión fija y propagación de finalización de conexión no confiable.
Integración nativa en la plataforma de Google Cloud : Se integra de forma nativa en GKE Dataplane V2 (DPv2), Workload Identity administrada, Certificate Authority Service (CAS) y Google Cloud Observability.
Interoperabilidad y alcance
Durante esta versión preliminar de Ambient Networking, ten en cuenta las siguientes restricciones de alcance e interoperabilidad:
- Requisito de la API de Gateway: Ambient Networking requiere la API de Gateway. No se admiten las APIs de Istio.
- Interoperabilidad de las cargas de trabajo: Las cargas de trabajo inscritas en Ambient Networking no pueden interoperar con cargas de trabajo con inyección de sidecar (en GKE, Compute Engine o Cloud Run) ni con cargas de trabajo de gRPC sin proxy.
Arquitectura y componentes
Ambient Networking se integra directamente en GKE Dataplane V2 (DPv2) en cada nodo, en lugar de insertar sidecars de Envoy en los Pods de carga de trabajo.
Componentes del plano de control existentes
Las redes de Ambient 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 con Workload Identity administrada.
- Plano de control del clúster de GKE: Aprueba las solicitudes de firma de certificados (CSR) y las enruta a CAS.
Componentes de nodo
Ambient Networking instala los siguientes componentes por nodo para interceptar y enrutar el tráfico de las cargas 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 las redes de bajo nivel para interceptar y redireccionar el tráfico de Pods al proxy.
Proxy de GKE Ambient: Es un proxy a nivel de nodo que administra sockets de escucha, recibe reglas de xDS de Traffic Director, recupera certificados de identidad X.509 on demand del plano de control de GKE y envía tráfico de capa 4 a través de un proxy.
Los componentes del plano de datos de Ambient a nivel del nodo se ejecutan como DaemonSets en el
espacio de nombres gke-managed-ambient y se les asignan versiones, se parchan y se actualizan automáticamente
junto con el plano de control de GKE.
Escala y límites de destino
Durante la versión preliminar, Ambient Networking tiene los siguientes límites de alcance e interoperabilidad:
| Métrica de recursos | GKE DPv2 (con ambient) | DPv2 de GKE 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 de GKE.
Precios
Revisa los siguientes detalles sobre los precios y los cargos por recursos operativos para Ambient Networking:
- Todos los Pods de cualquier espacio de nombres con la etiqueta de ambient
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 y Cloud Logging) y de Certificate Authority Service.
Comprende los recursos de la API de Gateway
Cuando usas Ambient Networking, 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 de Google Cloud administrados.
| Funcionalidad | Recurso de API de Google Cloud administrado | Alcance | Cardinalidad |
|---|---|---|---|
| Mesh | Mesh |
Regional | 1 por clúster |
| Enrutamiento de servicios | TCPRoute |
Regional | 1 por clúster, más 1 por Service al que se orienta un GCPClientTLSPolicy |
| Representación del servicio | BackendService |
Regional | 1 por clúster |
| Autenticación de clientes | ClientTlsPolicy |
Regional | 1 por clúster |
| Autenticación del servidor | ServerTlsPolicy |
Regional | 3 por clúster |
| Autenticación del servidor | EndpointPolicy |
Regional | 1 por GCPServerTLSPolicy, más 1 por cada modo de mTLS distinto en su portOverrides |
| Autorización | AuthzPolicy |
Regional | 1 por Pod targetRef en cada GCPAuthzPolicy con enforcementLevel: L4 |
| Enrutamiento de salida | EgressRouting |
Regional | 1 por espacio de nombres que tenga un GCPEgressPolicy |
¿Qué sigue?
- Prepara Ambient Networking de GKE
- Acerca de la API de Gateway
- Descripción general de la supervisión de servicios de red