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

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

Para ver la lista de funciones compatibles con Cloud Service Mesh para un plano de control en el clúster, consulta Usar APIs de Istio (plano de control istiod en el clúster). Si no sabes qué plano de control de Cloud Service Mesh estás usando, puedes comprobar tu implementación siguiendo las instrucciones de Identificar la implementación del plano de control.

Limitaciones

Se aplican las siguientes limitaciones:

  • 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 indican en Entornos.
  • No se admite cambiar los canales de lanzamiento.
  • No se admiten migraciones de Cloud Service Mesh gestionado con asmclia Cloud Service Mesh con la API de flota. Del mismo modo, no se admite el aprovisionamiento de Cloud Service Mesh gestionado con la API Fleet de --management manual a --management automatic.
  • Las migraciones y las actualizaciones solo se admiten desde versiones 1.9 o posteriores de Cloud Service Mesh en el clúster instaladas con Mesh CA. Las instalaciones con Istio CA (anteriormente conocido como Citadel) deben migrar a Mesh CA primero.
  • La escala está limitada a 1000 servicios y 5000 cargas de trabajo por clúster.
  • Solo se admite la opción de implementación multiprimaria para multiclústeres. No se admite la opción de implementación primaria-remota para multiclústeres.
  • No se admite istioctl ps. En su lugar, puedes usar los comandos de gcloud beta container fleet mesh debug tal como se describe en Solucionar problemas.
  • APIs no compatibles:

    • EnvoyFilter API

    • WasmPlugin API

    • IstioOperator API

    • Kubernetes Ingress API

    .
  • Puedes usar el plano de control gestionado sin una suscripción a GKE Enterprise, pero algunos elementos de la interfaz de usuario y funciones de la consola Google Cloud solo están disponibles para los suscriptores de GKE Enterprise. Para obtener información sobre lo que está disponible para suscriptores y no suscriptores, consulta Diferencias entre la interfaz de GKE Enterprise y la de Cloud Service Mesh.

  • Durante el proceso de aprovisionamiento de un plano de control gestionado, se instalan en el clúster especificado los CRDs de Istio correspondientes al canal seleccionado. Si hay CRDs de Istio en el clúster, se sobrescribirán.

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

  • Las nuevas instalaciones de Cloud Service Mesh gestionado solo obtienen JWKS mediante Envoys, a menos que la flota contenga otros clústeres en los que no esté habilitado ese comportamiento. Es equivalente 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 la información que se muestra más abajo), es posible que necesites una configuración adicional para las configuraciones ServiceEntry y DestinationRule. Para ver un ejemplo, consulta requestauthn-with-se.yaml.tmpl. Puedes determinar si el modo de funcionamiento actual es equivalente a PILOT_JWT_ENABLE_REMOTE_JWKS=envoy comprobando si Controles de Servicio de VPC se admite en el plano de control (es decir, si se muestra la condición VPCSC_GA_SUPPORTED).

Diferencias en el plano de control

Hay diferencias en las funciones admitidas entre las implementaciones del plano de control de ISTIOD y TRAFFIC_DIRECTOR. Para comprobar qué implementación estás usando, consulta 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, tal como se describe en la sección Habilitar funciones opcionales o en la guía de la función vinculada en la tabla de funciones.
  • §: indica que la función se admite en la lista de permitidos. Los usuarios anteriores de Anthos Service Mesh gestionado se añaden automáticamente a la lista de permitidos a nivel de organización. Ponte en contacto con el Google Cloud equipo de Asistencia para solicitar acceso o consultar el estado de tu lista de permitidos.
  • : indica que la función no está disponible o que no es compatible.

El equipo de Asistencia de Google Cloud ofrece asistencia completa para las funciones predeterminadas y opcionales. Las funciones que no se indican explícitamente en las tablas reciben asistencia de la mejor manera posible.

Qué determina la implementación del plano de control

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

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

  • Si ya usas Cloud Service Mesh gestionado, recibirás la implementación del plano de control ISTIOD cuando incorpores una nueva flota a Cloud Service Mesh gestionado en la misma organización Google Cloud , al menos hasta el 30 de junio del 2024. Si eres uno de estos usuarios, puedes ponerte en contacto con el equipo de Asistencia para ajustar este comportamiento. Los usuarios cuyo uso actual no sea compatible con la implementación TRAFFIC_DIRECTOR sin cambios seguirán recibiendo la implementación ISTIOD hasta el 8 de septiembre del 2024. (Estos usuarios han recibido un anuncio de servicio).
  • Si algún clúster de tu flota usa el servicio de autoridad de certificación al aprovisionar Cloud Service Mesh gestionado, recibirás la implementación del plano de control ISTIOD.
  • Si algún clúster de GKE en tu flota contiene un plano de control de Cloud Service Mesh en el clúster cuando aprovisiones Cloud Service Mesh gestionado, recibirás la implementación del plano de control de ISTIOD. Google Cloud
  • Si algún clúster de tu flota usa GKE Sandbox, cuando aprovisiones Cloud Service Mesh gestionado, recibirás la implementación del plano de control ISTIOD.

Funciones admitidas del plano de control gestionado

Instalar, actualizar y restaurar

Función Gestionado (TD) Gestionado (istiod)
Instalación en clústeres de GKE mediante la API de la función flota
Actualizaciones desde versiones de ASM 1.9 que usan Mesh CA
Actualizaciones directas (con salto de versión) desde versiones de Cloud Service Mesh anteriores a la 1.9 (consulta las notas sobre las actualizaciones indirectas)
Actualizaciones directas (con salto de versión) desde Istio OSS (consulta las notas sobre las actualizaciones indirectas)
Actualizaciones directas (con salto de versión) desde el complemento Istio on GKE (consulta las notas sobre las actualizaciones indirectas)
Habilitar funciones opcionales

Entornos

Función Gestionado (TD) Gestionado (istiod)
Versiones de GKE disponibles en los canales de lanzamiento, en una de las regiones admitidas
Versiones de GKE disponibles en los canales de lanzamiento, en una de las regiones admitidas, clústeres de Autopilot de GKE
Entornos que no sean Google Cloud (GKE Enterprise on-premise, GKE Enterprise en otras nubes públicas, Amazon EKS, Microsoft AKS u otros clústeres de Kubernetes)

Escalar

Función Gestionado (TD) Gestionado (istiod)
1000 servicios y 5000 cargas de trabajo por clúster
50 puertos de servicio sin encabezado por malla y 36 pods por puerto de servicio sin encabezado

Entorno de la plataforma

Función Gestionado (TD) Gestionado (istiod)
Una sola red
Multired
Un solo proyecto
Multi-proyecto con VPC compartida

Despliegue de varios clústeres

Función Gestionado (TD) Gestionado (istiod)
Modo con varios servidores principales
Principal-remoto
Detección de endpoints multiclúster con la API declarativa
Descubrimiento de endpoints entre clústeres con secretos remotos

Notas sobre la terminología

  • Una configuración con varios primarios significa que la configuración debe replicarse en todos los clústeres.
  • Una configuración principal-remota significa que un único clúster contiene la configuración y se considera la fuente de información veraz.
  • Cloud Service Mesh usa una definición simplificada de la red basada en la conectividad general. Las instancias de carga de trabajo están en la misma red si pueden comunicarse directamente, sin una pasarela.

Imágenes base

Función Gestionado (TD) Gestionado (istiod)
Imagen de proxy sin distribución

† Cloud Service Mesh con un plano de control gestionado (TD) solo admite el tipo de imagen sin distribución. No puedes cambiarlo.

Ten en cuenta que las imágenes sin distribución tienen archivos 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, de esta forma, inspeccionarlo y ejecutar comandos personalizados. Por ejemplo, consulta el artículo Recoger registros de Cloud Service Mesh.

Seguridad

Controles de Servicio de VPC

Función Gestionado (TD) Gestionado (istiod)
Controles de Servicio de VPC

Mecanismos de distribución y rotación de certificados

Función Gestionado (TD) Gestionado (istiod)
Gestión de certificados de carga de trabajo
Gestión de certificados externos en las pasarelas de entrada y salida.

Compatibilidad con autoridades de certificación (AC)

Función Gestionado (TD) Gestionado (istiod)
Autoridad de certificación de Cloud Service Mesh
Servicio de Autoridades de Certificación
CA de Istio
Integración con CAs personalizadas

Funciones de seguridad

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

Función Gestionado (TD) Gestionado (istiod)
Integración de IAP
Autenticación de usuarios finales
Modo de prueba
Registro de denegaciones
Políticas de auditoría (no admitidas)

Política de autorización

Función Gestionado (TD) Gestionado (istiod)
Política de autorización v1beta1
Política de autorización PERSONALIZADA §

† La implementación del plano de control de TRAFFIC_DIRECTOR no admite los campos rules.from.source.RemoteIp y rules.from.source.NotRemoteIp.

Autenticación de entidad par

Función Gestionado (TD) Gestionado (istiod)
mTLS automático
Modo PERMISIVO de mTLS
Modo ESTRICTO de mTLS * *
Modo INHABILITAR de mTLS

Solicitar autenticación

Función Gestionado (TD) Gestionado (istiod)
Autenticación JWT(Nota 1)
Enrutamiento basado en reclamaciones de JWT
Copiar la reclamación de JWT en los encabezados

Notas:

  1. Los JWTs de terceros están habilitados de forma predeterminada.
  2. Añade el nombre de dominio completo en JWKSURI al definir la API RequestAuthentication.
  3. El plano de control gestionado obliga a Envoy a obtener JWKS al especificar el URI de JWKS.

Telemetría

Métricas

Función Gestionado (TD) Gestionado (istiod)
Cloud Monitoring (métricas de proxy HTTP)
Cloud Monitoring (métricas de proxy 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 control de Cloud Service Mesh * *
API Telemetry de Istio
Adaptadores o back-ends personalizados, dentro o fuera del proceso
Back-ends de telemetría y registro arbitrarios

† El plano de control de TRAFFIC_DIRECTOR admite un subconjunto de la API de telemetría de Istio que se usa para configurar registros de acceso y trazas. El TRAFFIC_DIRECTOR plano de control no admite la configuración de la frecuencia de muestreo de trazas.

Registro de solicitudes de proxy

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

Trace

Función Gestionado (TD) Gestionado (istiod)
Cloud Trace * *
Trazas de Jaeger (permite usar Jaeger gestionado por el cliente) Compatible
Trazas de Zipkin (permite usar Zipkin gestionado por el cliente) Compatible

Redes

Mecanismos de intercepción y redirección del tráfico

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

† Recomendamos usar la interfaz de red de contenedores (CNI) en lugar de contenedores init.

Compatibilidad con protocolos

Función Gestionado (TD) Gestionado (istiod)
IPv4
HTTP/1.1
HTTP/2
Secuencias de bytes TCP (nota 1)
gRPC
IPv6

Notas:

  1. Aunque TCP es un protocolo compatible con las redes y se recogen métricas de TCP, no se registran. 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 capa 7 para los siguientes protocolos: WebSocket, MongoDB, Redis, Kafka, Cassandra, RabbitMQ y Cloud SQL. Es posible que puedas hacer que el protocolo funcione usando la compatibilidad con el flujo de bytes TCP. Si el flujo de bytes TCP no admite el protocolo (por ejemplo, Kafka envía una dirección de redirección en una respuesta específica del protocolo y esta redirección no es compatible con la lógica de enrutamiento de Cloud Service Mesh), el protocolo no se admite.
  3. † IPv6 está disponible como función de red de pila dual en versión preliminar. En gRPC sin proxy, las funciones de pila dual solo se admiten en gRPC 1.66.1 o versiones posteriores en C++ y Python o gRPC Node.js v1.12. Si intentas configurar funciones de pila dual con una versión de gRPC que no admita la pila dual, los clientes solo usarán la primera dirección enviada por Traffic Director.

Despliegues de Envoy

Función Gestionado (TD) Gestionado (istiod)
Sidecars
Pasarela de entrada
Salida directamente desde los sidecars
Salida mediante pasarelas de salida * *

Compatibilidad con CRD

Función Gestionado (TD) Gestionado (istiod)
Recurso de sidecar
Recurso de entrada de servicio
Porcentaje, inyección de fallos, coincidencia de rutas, redirecciones, reintentos, reescritura, tiempo de espera, reintento, creación de reflejos, manipulación de encabezados y reglas de enrutamiento de CORS
API `EnvoyFilter` §
API `WasmPlugin`
Operador de Istio

Balanceador de carga de la pasarela de entrada de Istio

Función Gestionado (TD) Gestionado (istiod)
Balanceador de carga externo de terceros
Google Cloud Balanceador de carga interno * *

Puerta de enlace de nube de malla de servicios

Función Gestionado (TD) Gestionado (istiod)
Puerta de enlace de nube de malla de servicios

API Gateway de Kubernetes

Función Gestionado (TD) Gestionado (istiod)
API Gateway de Kubernetes

Políticas de balanceo de carga

Función Gestionado (TD) Gestionado (istiod)
Orden aleatorio
Menos conexiones
Aleatoria
Transparente
Hash coherente
Localidad
GCPTrafficDistributionPolicy
GCPBackendPolicy

Entrada de servicio

Función Gestionado (TD) Gestionado (istiod)
ServiceEntry v1beta1

† La implementación del plano de control de TRAFFIC_DIRECTOR no admite los siguientes campos ni valores de 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 de socket de dominio de Unix en el campo endpoints[].address
  • Campo subjectAltNames

Regla de destino

Función Gestionado (TD) Gestionado (istiod)
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 servicio de Kubernetes o ServiceEntry.

Sidecar

Función Gestionado (TD) Gestionado (istiod)
Sidecar v1beta1

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

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

MeshConfig

Función Gestionado (TD) Gestionado (istiod)
LocalityLB §
ExtensionProviders §
CACert
ImageType - distroless §
OutboundTrafficPolicy §
defaultProviders.accessLogging
defaultProviders.tracing
defaultConfig.tracing.stackdriver §
accessLogFile §

ProxyConfig

Función Gestionado (TD) Gestionado (istiod)
Proxy de DNS (ISTIO_META_DNS_CAPTURE e ISTIO_META_DNS_AUTO_ALLOCATE)
Compatibilidad con HTTP/1.0 (ISTIO_META_NETWORK)
Selección de imagen (sin distribución o imagen base)

† Se usa una imagen sin distribución para la inyección.

Regiones

Los clústeres de GKE deben estar en una de las siguientes regiones o en cualquier zona de estas 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-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 Saudí)
me-west1 Tel Aviv
northamerica-northeast1 Montreal (Canadá)
northamerica-northeast2 Toronto (Canadá)
southamerica-east1 Brasil
southamerica-west1 Chile
us-central1 Iowa
us-east1 Carolina del Sur
us-east4 Norte de Virginia
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 Gestionado (TD) Gestionado (istiod)
Paneles de control de Cloud Service Mesh en la Google Cloud consola
Cloud Monitoring
Cloud Logging

Herramientas

Función Gestionado (TD) Gestionado (istiod)
Herramienta gcloud beta container fleet mesh debug