Funciones compatibles con las APIs de Istio (plano de control administrado)

En esta página, se describen las funciones y limitaciones admitidas para Cloud Service Mesh con TRAFFIC_DIRECTOR o ISTIOD como plano de control y las diferencias entre cada implementación. Ten en cuenta que estas no son opciones que puedas elegir. La implementación de ISTIOD solo está disponible para los usuarios existentes. Las instalaciones nuevas usan la implementación de TRAFFIC_DIRECTOR cuando es posible.

Para obtener una lista de las funciones compatibles de Cloud Service Mesh para un plano de control en el clúster, consulta Usa las APIs de Istio (plano de control de istiod en el clúster). Si no estás seguro de qué plano de control de Cloud Service Mesh usas, puedes verificar la implementación del plano de control con las instrucciones que se indican en Identifica la implementación del plano de control.

Limitaciones

Se aplica la siguiente limitación:

  • Los clústeres de GKE deben estar en una de las regiones admitidas.
  • La versión de GKE debe ser una versión compatible.
  • Solo se admiten las plataformas que se mencionan en Entornos.
  • No se admiten los Pods que se ejecutan con hostNetwork: true.
  • Cloud Service Mesh administrado no se debe implementar en un clúster que también tenga una implementación en el clúster de Istio de OSS o un plano de control de Cloud Service Mesh en el clúster.
  • No se admite cambiar los canales de versiones.
  • No se admiten las migraciones de Cloud Service Mesh administrado con asmcli a Cloud Service Mesh con la API de Fleet. Del mismo modo, no se admite el aprovisionamiento de Cloud Service Mesh administrado con la API de Fleet de --management manual a --management automatic.
  • Las migraciones desde Cloud Service Mesh en el clúster solo se admiten con la estrategia de migración de clústeres de versiones canary.
  • Las migraciones y actualizaciones solo son compatibles con las versiones de Cloud Service Mesh en el clúster que se encuentran en la tabla de versiones compatibles y que usan la CA de Mesh o Certificate Authority Service. Las instalaciones con la CA de Istio (antes conocida como Citadel) primero se deben migrar a la CA de Mesh.
  • Los límites de escala se describen en esta guía.
  • Solo se admite la opción de implementación de varias instancias para varios clústeres; no se admite la opción de implementación principal remota para varios clústeres.
  • istioctl ps no es compatible. En su lugar, puedes usar los comandos gcloud beta container fleet mesh debug como se describe en Solución de problemas.

  • APIs no compatibles:

    • API WasmPlugin

    • API IstioOperator

    • API Kubernetes Ingress

  • Para obtener una lista de los campos de la API no compatibles, consulta APIs de Istio no compatibles en Cloud Service Mesh administrado.

  • Puedes usar el plano de control administrado sin una suscripción a GKE Enterprise, pero ciertos elementos de la IU y las funciones de la consola de Google Cloud solo están disponibles para los suscriptores de GKE Enterprise. Si quieres obtener información sobre lo que está disponible para suscriptores y no suscriptores, consulta las diferencias en la IU de GKE Enterprise y Cloud Service Mesh.

  • Durante el proceso de aprovisionamiento de un plano de control administrado, las CRD de Istio correspondientes al canal seleccionado se instalan en el clúster especificado. Si hay CRD de Istio existentes en el clúster, se reemplazarán.

  • Cloud Service Mesh administrado solo admite el dominio de DNS predeterminado .cluster.local.

  • Las instalaciones nuevas de Cloud Service Mesh administrado recuperan JWKS solo con Envoys, a menos que la flota contenga otros clústeres para los que ese comportamiento no esté habilitado. Esto equivale a la opción PILOT_JWT_ENABLE_REMOTE_JWKS=envoy de Istio. En comparación con las instalaciones que no tienen la condición VPCSC_GA_SUPPORTED (consulta a continuación), es posible que necesites una configuración adicional para las configuraciones de ServiceEntry y DestinationRule. Para ver un ejemplo, consulta requestauthn-with-se.yaml.tmpl. Puedes determinar si el modo de operación actual es equivalente a PILOT_JWT_ENABLE_REMOTE_JWKS=envoy determinando si los Controles del servicio de VPC son compatibles con el plano de control (es decir, se muestra la condición VPCSC_GA_SUPPORTED).

  • El plano de datos administrado solo es compatible con cargas de trabajo sin sidecars adicionales (que no sean el sidecar de Cloud Service Mesh).

Diferencias entre planos de control

Existen diferencias en las funciones compatibles entre las implementaciones del plano de control de ISTIOD y TRAFFIC_DIRECTOR. Para verificar qué implementación usas, consulta Cómo identificar la implementación del plano de control.

  • : Indica que la función está disponible y habilitada de forma predeterminada.
  • †: Indica que las APIs de funciones pueden tener diferencias entre las distintas plataformas.
  • *: Indica que la función es compatible con la plataforma y se puede habilitar, como se describe en Habilita funciones opcionales o la guía de función vinculada en la tabla de funciones.
  • §: Indica que la función es compatible con la lista de entidades permitidas. Los usuarios anteriores de Anthos Service Mesh administrado se agregan automáticamente a la lista de entidades permitidas a nivel de la organización. Comunícate con el Google Cloud equipo de asistencia para solicitar acceso o verificar el estado de tu lista de entidades permitidas.
  • : Indica que la función no está disponible o no se admite.

Las funciones predeterminadas y opcionales tienen una compatibilidad total con la asistencia de Google Cloud. Las funciones que no aparecen en las tablas de manera explícita reciben la mejor asistencia posible.

Qué determina la implementación del plano de control

Cuando aprovisionas Cloud Service Mesh administrado por primera vez en una flota, determinamos qué implementación del plano de control se debe usar. Se usa la misma implementación para todos los clústeres que aprovisionan Cloud Service Mesh administrado en esa flota.

Las flotas nuevas que se incorporan a Cloud Service Mesh administrado reciben la implementación del plano de control de TRAFFIC_DIRECTOR, con ciertas excepciones:

  • Si ya eres usuario de Cloud Service Mesh administrado, recibirás la implementación del plano de control de ISTIOD cuando incorpores una flota nueva en la misma organización de Google Cloud Cloud Service Mesh administrado, hasta al menos el 30 de junio de 2024. Si eres uno de estos usuarios, puedes comunicarte con el equipo de asistencia al cliente para ajustar este comportamiento. Los usuarios cuyo uso existente no sea compatible con la implementación de TRAFFIC_DIRECTOR sin cambios seguirán recibiendo la implementación de ISTIOD hasta el 8 de septiembre de 2024. (Estos usuarios recibieron un Anuncio de Servicio).
  • Si algún clúster de GKE en Google Cloud de tu flota contiene un plano de control de Cloud Service Mesh en el clúster cuando aprovisionas Cloud Service Mesh administrado, recibirás la implementación del plano de control de ISTIOD.
  • Si algún clúster de tu flota usa GKE Sandbox, cuando aprovisiones Cloud Service Mesh administrado, recibirás la implementación del plano de control de ISTIOD.

Funciones compatibles del plano de control administrado

Instala, actualiza y revierte

Función Administrado (TD) Se dejó de usar Managed (istiod)
Instalación en clústeres de GKE mediante la API de la función de flota
Actualizaciones de las versiones de ASM 1.9 que usan CA de Mesh
Actualizaciones directas (con omisión de nivel) desde versiones de Cloud Service Mesh anteriores a la 1.9 (consulta las notas para las actualizaciones indirectas)
Actualizaciones directas (nivel de omisión) de Istio OSS (consulta las notas para las actualizaciones indirectas)
Actualizaciones directas (nivel de omisión) del complemento Istio-on-GKE (consulta las notas para las actualizaciones indirectas)
Habilita funciones opcionales

Entornos

Función Administrado (TD) Se dejó de usar Managed (istiod)
Versiones de GKE disponibles actualmente en los canales de versiones, en una de las regiones admitidas
Versiones de GKE disponibles actualmente en los canales de versiones, en una de las regiones admitidas, clústeres de GKE Autopilot
Entornos fuera de Google Cloud (GKE Enterprise local, GKE Enterprise en otras nubes públicas, Amazon EKS, Microsoft AKS o cualquier otro clúster de Kubernetes)

Escala

Consulta la página Límites de escalabilidad.

Entorno de plataforma

Función Administrado (TD) Administrado (istiod) obsoleto
Una sola red
Varias redes
Un solo proyecto
Varios proyectos con VPC compartida

Implementación de varios clústeres

Función Administrado (TD) Administrado (istiod) obsoleto
Principales múltiples
Control principal
Detección de extremos de varios clústeres con la API declarativa
Descubrimiento de extremos de varios clústeres con secretos remotos
Descubrimiento de extremos de varios clústeres con la API declarativa y una topología simple

Notas sobre la terminología

  • Una configuración de varios elementos principales significa que la configuración debe replicarse en todos los clústeres.
  • Una configuración principal-remota significa que un solo clúster contiene la configuración y se considera la fuente de información.
  • Cloud Service Mesh usa una definición simplificada de red basada en la conectividad general. Las instancias de carga de trabajo están en la misma red si pueden comunicarse directamente, sin una puerta de enlace.
  • La topología simple para el descubrimiento de extremos de varios clústeres significa que cada clúster de la flota participa o no en el descubrimiento de extremos. Las topologías complejas que no se admiten incluyen (a) el descubrimiento de extremos unidireccional (p.ej., el clúster A puede descubrir extremos en el clúster B, pero no al revés) y (b) las redes de descubrimiento de extremos no conjuntas (p.ej., los clústeres A y B pueden descubrir los extremos del otro, los clústeres C y D pueden descubrir los extremos del otro, pero A/B y C/D no pueden descubrir los extremos del otro).

Imágenes base

Función Administrado (TD) Administrado (istiod) obsoleto
Imagen de proxy distroless †

† Istio publica imágenes de proxy default, debug y distroless. Para Cloud Service Mesh con un plano de control administrado (TRAFFIC_DIRECTOR), los clústeres incorporados directamente usan distroless de forma predeterminada y no se pueden cambiar. Los clústeres migrados usan imágenes de default de forma predeterminada y pueden habilitar distroless con MeshConfig o la anotación de Pod. No se admiten las anulaciones de otros tipos de imágenes (debug).

Ten en cuenta que las imágenes sin distribución tienen objetos binarios mínimos, por lo que no puedes ejecutar los comandos habituales, como bash o curl, porque no están presentes en la imagen sin distribución. Sin embargo, puedes usar contenedores efímeros para conectarte a un Pod de carga de trabajo en ejecución y, así, poder inspeccionarlo y ejecutar comandos personalizados. Por ejemplo, consulta Cómo recopilar registros de Cloud Service Mesh.

Seguridad

Controles del servicio de VPC

Función Administrado (TD) Se dejó de usar Managed (istiod)
Controles del servicio de VPC

Mecanismos de distribución y rotación de certificados

Función Administrado (TD) Se dejó de usar Managed (istiod)
Administración de certificados de cargas de trabajo
Administración de certificados externos en puertas de enlace de entrada y salida.

Compatibilidad con autoridad certificada (CA)

Función Administrado (TD) Se dejó de usar Managed (istiod)
Autoridad certificadora de Cloud Service Mesh
Certificate Authority Service
CA de Istio
Integración con CA personalizadas

Funciones de seguridad

Además de admitir las funciones de seguridad de Istio, Cloud Service Mesh proporciona aún más capacidades para ayudarte a proteger tus aplicaciones.

Función Administrado (TD) Se dejó de usar Managed (istiod)
Integración de IAP
Autenticación del usuario final
Modo de ejecución de prueba
Registro de denegación
Políticas de auditoría (no admitidas)

Política de autorización

Función Administrado (TD) Se dejó de usar Managed (istiod)
Política de autorización de v1beta1
Política de autorización PERSONALIZADA

Autenticación entre pares

Función Administrado (TD) Se dejó de usar Managed (istiod)
Auto-mTLS
Modo PERMISSIVE de mTLS
Modo STRICT de mTLS * *
Modo DISABLE de mTLS

Nota: Si bien la API de PeerAuthentication no admite el modo DISABLE para la implementación del plano de control de TRAFFIC_DIRECTOR, puedes inhabilitar mTLS para cargas de trabajo específicas con la API de DestinationRule como solución alternativa. Para obtener más información, consulta Cómo inhabilitar mTLS para el CSM administrado.

Autenticación de solicitudes

Función Administrado (TD) Administrado (istiod) obsoleto
Autenticación de JWT (Nota 1)
Enrutamiento basado en reclamaciones de JWT
JWT Copy Claim to Headers

Notas:

  1. JWT de terceros está habilitado de forma predeterminada.
  2. Agrega el FQDN o nombre de host completo en JWKSURI mientras defines la API de RequestAuthentication.
  3. El plano de control administrado exige que Envoy recupere JWKS cuando se especifica el URI de JWKS.
  4. Los algoritmos AES CBC A128CBC-HS256, A192CBC-HS384 y A256CBC-HS512 no se permiten en JWKS intercalados cuando se usa la implementación del plano de control de TRAFFIC_DIRECTOR.

Telemetría

Métricas

Función Administrado (TD) Administrado (istiod) obsoleto
Cloud Monitoring (métricas en el proxy de HTTP)
Cloud Monitoring (métricas en el proxy de TCP)
Exportación de métricas de Prometheus a Grafana (solo métricas de Envoy) * *
Exportación de métricas de Prometheus a Kiali
Google Cloud Managed Service para Prometheus, sin incluir el panel de Cloud Service Mesh * *
API de telemetría de Istio †
Adaptadores y backends personalizados, dentro o fuera del proceso
Telemetría arbitraria y backends de registro

† El plano de control de TRAFFIC_DIRECTOR admite un subconjunto de la API de telemetría de Istio que se usa para configurar los registros de acceso y el registro de seguimiento.

Registro de solicitudes de proxy

Función Administrado (TD) Administrado (istiod) obsoleto
Registros de tráfico
Registros de acceso * *

Trace

Función Administrado (TD) Se dejó de usar Managed (istiod)
Cloud Trace * *
Seguimiento de Jaeger (permite el uso de Jaeger administrado por el cliente) Compatible
Seguimiento de Zipkin (permite el uso de Zipkin administrado por el cliente) Compatible

Redes

Mecanismos de intercepción y redireccionamiento del tráfico

Función Administrado (TD) Administrado (istiod) obsoleto
Uso de iptables con contenedores init con CAP_NET_ADMIN †
Interfaz de red de contenedor (CNI) de Istio
Sidecar de caja blanca

† Te recomendamos que uses la interfaz de red de contenedor (CNI) en lugar de los contenedores de init.

Compatibilidad con protocolos

Función Administrado (TD) Administrado (istiod) obsoleto
IPv4
HTTP/1.1
HTTP/2
Transmisiones de bytes de TCP (Nota 1)
gRPC
IPv6 †

Notas:

  1. A pesar de que TCP es un protocolo que se admite para las redes y se recopilan las métricas de TCP, estas no se informan. Las métricas solo se muestran para los servicios HTTP en la consola de Google Cloud .
  2. No se admiten los servicios configurados con funciones de la capa 7 para los siguientes protocolos: WebSocket, MongoDB, Redis, MySQL, Kafka, Cassandra, RabbitMQ y Cloud SQL. Es posible que puedas hacer que el protocolo funcione mediante la compatibilidad con la transmisión de bytes de TCP. Si la transmisión de bytes de TCP no admite el protocolo (por ejemplo, Kafka envía una dirección de redireccionamiento en una respuesta específica del protocolo, y este redireccionamiento no es compatible con la lógica de enrutamiento de Cloud Service Mesh), el protocolo no es compatible. Si bien los puertos de la puerta de enlace se pueden crear con los protocolos de Mongo, MySQL y Redis, la malla trata el tráfico resultante como TCP estándar, sin un control específico del protocolo.
  3. † En gRPC sin proxy, las funciones de pila doble de IPv6 solo se admiten en gRPC 1.66.1 o versiones posteriores en C++ y Python, gRPC Go v1.71 y gRPC Node.js v1.12. Si intentas configurar funciones de doble pila con una versión de gRPC que no admite doble pila, los clientes usarán solo la primera dirección que envíe Traffic Director.

Implementaciones de Envoy

Función Administrado (TD) Se dejó de usar Managed (istiod)
Sidecars
Puerta de enlace de entrada
Salida directa desde sidecars
Salida mediante puertas de enlace de salida * *

Compatibilidad con CRD

Función Administrado (TD) Administrado (istiod) obsoleto
Recurso de sidecar
Recurso de entrada del servicio
Porcentajes, inserción de errores, coincidencias de rutas de acceso, redireccionamientos, reintentos, reescrituras, tiempo de espera, reintentos, duplicaciones, manipulación de encabezados y reglas de enrutamiento de CORS
API de`WasmPlugin`
Operador de Istio

Balanceador de cargas para la puerta de enlace de entrada de Istio

Función Administrado (TD) Se dejó de usar Managed (istiod)
Balanceador de cargas externo de terceros
Google Cloud Balanceador de cargas interno * *

Puerta de enlace de malla de servicio en la nube

Función Administrado (TD) Se dejó de usar Managed (istiod)
Puerta de enlace de Cloud de malla de servicios

API de Kubernetes Gateway

Función Administrado (TD) Administrado (istiod) obsoleto
API de Kubernetes Gateway

Políticas de balanceo de cargas

Función Administrado (TD) Administrado (istiod) obsoleto
Round robin
Conexiones mínimas
Aleatorio
Transferencia
Hash coherente
Localidad
GCPTrafficDistributionPolicy
GCPBackendPolicy

Modos de balanceo de cargas

Función Administrado (TD) Administrado (istiod) obsoleto
TARIFA
UTILIZACIÓN
CUSTOM_METRICS
EN VUELO

Para obtener más información sobre los modos de balanceo, consulta la Descripción general de los servicios de backend.

Entrada de servicio

Función Administrado (TD) Se dejó de usar Managed (istiod)
ServiceEntry v1beta1 †

† La implementación del plano de control de TRAFFIC_DIRECTOR no admite los siguientes campos ni valores en los campos:

  • Campo workloadSelector
  • Campo endpoints[].network
  • Campo endpoints[].locality
  • Campo endpoints[].weight
  • Campo endpoints[].serviceAccount
  • Valor de DNS_ROUND_ROBIN en el campo resolution
  • Valor de MESH_INTERNAL en el campo location
  • Dirección del socket de dominio Unix en el campo endpoints[].address
  • Campo subjectAltNames
  • Dos o más entradas endpoints[] si el campo resolution tiene el valor DNS

Regla de destino

Función Administrado (TD) Administrado (istiod) obsoleto
DestinationRule v1beta1 †

† La implementación del plano de control de TRAFFIC_DIRECTOR no admite los siguientes campos.

  • Campo trafficPolicy.loadBalancer.localityLbSetting
  • Campo trafficPolicy.tunnel
  • Campo trafficPolicy.tls.credentialName
  • Campo trafficPolicy.portLevelSettings[].tls.credentialName

Además, la implementación del plano de control de TRAFFIC_DIRECTOR requiere que la regla de destino que define los subconjuntos esté en el mismo espacio de nombres y clúster que el Service o ServiceEntry de Kubernetes.

Sidecar

Función Administrado (TD) Administrado (istiod) obsoleto
Sidecar v1beta1 †

† La implementación del plano de control de TRAFFIC_DIRECTOR no admite los siguientes campos ni valores en los campos:

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

Proxy de DNS

Función Administrado (TD) Administrado (istiod) obsoleto
Resolución de nombres de Service en todos los clústeres †
Resolución de nombres de ServiceEntry en un clúster †
Resolución de nombres de Headless Service
Asignación automática de direcciones †

† Se requiere la versión 1.21.5-asm.39 o una posterior del archivo adicional.

EnvoyFilter

Función Administrado (TD) Administrado (istiod) obsoleto
EnvoyFilter v1alpha3 †

† Consulta la página de extensibilidad del plano de datos para conocer los campos admitidos y las extensiones configurables.

MeshConfig

Función Administrado (TD) Administrado (istiod) obsoleto
DiscoverySelectors
clusterLocal
LocalityLB §
ExtensionProviders
CACert
ImageType: distroless †
OutboundTrafficPolicy
defaultProviders.accessLogging
defaultProviders.tracing
defaultConfig.tracing.stackdriver
accessLogFile

† Consulta Imagen de proxy sin distribución para conocer el comportamiento de configuración detallado.

ProxyConfig

Función Administrado (TD) Administrado (istiod) obsoleto
Compatibilidad con HTTP/1.0 (ISTIO_META_NETWORK)
Selección de imagen (imagen distroless o base)
Sidecar nativo de Kubernetes (ENABLE_NATIVE_SIDECARS)

Regiones

Los clústeres de GKE deben estar en una de las siguientes regiones o en cualquier zona de las siguientes regiones.

Región Ubicación
africa-south1 Johannesburgo
asia-east1 Taiwán
asia-east2 Hong Kong
asia-northeast1 Tokio, Japón
asia-northeast2 Osaka, Japón
asia-northeast3 Corea del Sur
asia-south1 Bombay, India
asia-south2 Delhi, India
asia-southeast1 Singapur
asia-southeast2 Yakarta
australia-southeast1 Sídney, Australia
australia-southeast2 Melbourne, Australia
europe-central2 Polonia
europe-north1 Finlandia
europe-north2 Estocolmo
europe-southwest1 España
europe-west1 Bélgica
europe-west2 Inglaterra
europe-west3 Fráncfort, Alemania
europe-west4 Países Bajos
europe-west6 Suiza
europe-west8 Milán, Italia
europe-west9 Francia
europe-west10 Berlín, Alemania
europe-west12 Turín, Italia
me-central1 Doha
me-central2 Dammam, Arabia Saudita
me-west1 Tel Aviv
northamerica-northeast1 Montreal, Canadá
northamerica-northeast2 Toronto, Canadá
northamerica-south1 México
southamerica-east1 Brasil
southamerica-west1 Chile
us-central1 Iowa
us-east1 Carolina del Sur
us-east4 Virginia del Norte
us-east5 Ohio
us-south1 Dallas
us-west1 Oregón
us-west2 Los Ángeles
us-west3 Salt Lake City
us-west4 Las Vegas

Interfaz de usuario

Función Administrado (TD) Administrado (istiod) obsoleto
Paneles de Cloud Service Mesh en la consola de Google Cloud
Cloud Monitoring
Cloud Logging

Herramientas

Función Administrado (TD) Se dejó de usar Managed (istiod)
Herramienta de gcloud beta container fleet mesh debug