Istio es una service mesh abierta e independiente de la plataforma que proporciona gestión del tráfico, aplicación de políticas y recopilación de telemetría.

Abierto: Istio se está desarrollando y manteniendo como software de código abierto. Alentamos las contribuciones y los comentarios de la comunidad en general.

Independiente de la plataforma: Istio no está dirigido a ningún entorno de implementación específico. Durante las etapas iniciales de desarrollo, Istio admitirá implementaciones basadas en Kubernetes. Sin embargo, Istio se está creando para permitir una adaptación rápida y fácil a otros entornos.

service mesh: Istio está diseñado para gestionar las comunicaciones entre microservicios y aplicaciones. Sin requerir cambios en los servicios subyacentes, Istio proporciona una resistencia de tráfico de línea de base automatizada, recopilación de métricas de servicio, seguimiento distribuido, cifrado de tráfico, actualizaciones de protocolo y funcionalidad de enrutamiento avanzada para toda la comunicación de servicio a servicio.

Para obtener más detalles, consulte La service mesh de Istio

Tradicionalmente, gran parte de la lógica gestionada por Istio se ha integrado directamente en las aplicaciones. En una flota de servicios, la gestión de las actualizaciones de esta lógica de comunicaciones puede ser una gran carga. Istio proporciona una solución a nivel de infraestructura para gestionar las comunicaciones de servicio.

Desarrolladores de aplicaciones: Con Istio gestionando cómo fluye el tráfico a través de sus servicios, los desarrolladores pueden centrarse exclusivamente en la lógica empresarial e iterar rápidamente en nuevas funciones.

Operadores de servicios: Istio permite la aplicación de políticas y la supervisión de la mesh desde un único punto de control centralizado, independientemente de la evolución de la aplicación. Como resultado, los operadores pueden garantizar el cumplimiento continuo de las políticas a través de un plano de gestión simplificado.

Recomendamos seguir las instrucciones de la página de introducción, que instala una configuración de demostración junto con la principal aplicación de ejemplo de Istio, Bookinfo. Luego puede usar esta configuración para recorrer varias guías de Istio que muestran el enrutamiento inteligente, la aplicación de políticas, la seguridad, la telemetría, etc., en un estilo de tutorial.

Para comenzar a usar Istio con implementaciones de producción de Kubernetes, consulte nuestra documentación de modelos de implementación y la página de preguntas frecuentes ¿qué método de instalación de Istio debo usar?.

Istio utiliza la Licencia Apache 2.0.

El proyecto Istio fue iniciado por equipos de Google e IBM en asociación con el equipo de Envoy de Lyft. Se ha desarrollado completamente en abierto en GitHub.

Istio está diseñado para ser independiente de la plataforma, inicialmente centrado en Kubernetes. Para nuestra versión 1.27, Istio admite entornos que ejecutan Kubernetes (1.29, 1.30, 1.31, 1.32, 1.33).

Las contribuciones son muy bienvenidas. Esperamos los comentarios, los feedbacks y los bugs de la comunidad.

Los repositorios de código están alojados en GitHub. Consulte nuestras Directrices de contribución para saber cómo contribuir.

Además del código, hay otras formas de contribuir a la comunidad de Istio, incluso en nuestro foro de discusión, Slack y Stack Overflow.

Consulte la documentación aquí mismo en istio.io. Los documentos incluyen descripciones generales de conceptos, guías de tareas, ejemplos y la documentación de referencia completa.

La documentación detallada a nivel de desarrollador se mantiene en nuestra Wiki

Consulte la guía de operaciones para encontrar soluciones y nuestra página de informes de errores para presentar errores.

Consulte nuestra página de feature status y las noticias para conocer las últimas novedades.

Es la palabra griega para ‘vela’.

Si desea tener interacciones en vivo con miembros de nuestra comunidad, puede unirse a nosotros en el espacio de trabajo de Slack de Istio.

Además de la sencilla instalación de evaluación de introducción, existen varios métodos diferentes que puede utilizar para instalar Istio. Cuál debe usar depende de sus requisitos de producción. A continuación se enumeran algunas de las ventajas y desventajas de cada uno de los métodos disponibles:

1. instalación de istioctl

   La ruta de instalación y gestión más sencilla y cualificada con alta seguridad. Este es el método recomendado por la comunidad para la mayoría de los casos de uso.

   Ventajas:

   • Validación exhaustiva de la configuración y verificación del estado.
   • Utiliza la API IstioOperator, que proporciona amplias opciones de configuración/personalización.

   Desventajas:

   • Se deben gestionar varios binarios, uno por cada versión menor de Istio.
   • El comando istioctl puede establecer valores automáticamente en función de su entorno de ejecución, produciendo así instalaciones variables en diferentes entornos de Kubernetes.

2. Instalar usando Helm

   Permite una fácil integración con flujos de trabajo basados en Helm y la eliminación automática de recursos durante las actualizaciones.

   Ventajas:

   • Enfoque familiar que utiliza herramientas estándar de la industria.
   • Gestión nativa de versiones y actualizaciones de Helm.

   Desventajas:

   • Menos comprobaciones y validaciones en comparación con istioctl install.
   • Algunas tareas administrativas requieren más pasos y tienen una mayor complejidad.

3. Aplicar un manifiesto de Kubernetes generado

   • Generación de manifiestos de Kubernetes con istioctl
   • Generación de manifiestos de Kubernetes con helm

   Este método es adecuado cuando se requiere una auditoría estricta o un aumento de los manifiestos de salida, o si existen restricciones de herramientas de terceros.

   Ventajas:

   • Más fácil de integrar con herramientas que no usan helm o istioctl.
   • No se requieren herramientas de instalación que no sean kubectl.

   Desventajas:

   • No se realizan comprobaciones en tiempo de instalación, detección de entorno o validaciones compatibles con ninguno de los métodos anteriores.
   • No se admite la gestión de la instalación ni la capacidad de actualización.
   • La experiencia del usuario es menos optimizada.
   • La notificación de errores durante la instalación no es tan sólida.

Las instrucciones de instalación para todos estos métodos están disponibles en la página de instalación de Istio.

Asegúrese de que su cluster haya cumplido los requisitos previos para la inyección automática de sidecar. Si su microservicio está implementado en los namespaces kube-system, kube-public o istio-system, están exentos de la inyección automática de sidecar. Utilice un namespace diferente en su lugar.

El ztunnel de Istio no introduce un único punto de fallo (SPOF) en un cluster de Kubernetes. Los fallos de ztunnel se limitan a un único nodo, que se considera un componente falible en un cluster. Se comporta de la misma manera que otra infraestructura crítica para el nodo que se ejecuta en cada cluster, como el kernel de Linux, el tiempo de ejecución del contenedor, etc. En un sistema diseñado correctamente, las interrupciones de los nodos no provocan interrupciones del cluster. Más información.

Puede cambiar la configuración de TLS mutuo para sus servicios en cualquier momento utilizando la política de autenticación y la regla de destino. Consulte la tarea para obtener más detalles.

La política de autenticación puede ser mesh-wide (lo que afecta a todos los servicios de la mesh), namespace-wide (todos los servicios del mismo namespace) o específicamente del servicio. Puede tener una o varias políticas para configurar TLS mutuo para los servicios de un cluster de la forma que desee.

Si instaló Istio con values.global.proxy.privileged=true, puede usar tcpdump para determinar el estado del cifrado. También en Kubernetes 1.23 y versiones posteriores, como alternativa a la instalación de Istio como privilegiado, puede usar kubectl debug para ejecutar tcpdump en un contenedor efímero. Consulte Migración de TLS mutuo de Istio para obtener instrucciones.

Cuando TLS mutuo STRICT está habilitado, los workloads que no son de Istio no pueden comunicarse con los servicios de Istio, ya que no tendrán un certificado de cliente de Istio válido.

Si necesita permitir estos clientes, el modo TLS mutuo se puede configurar en PERMISSIVE, lo que permite tanto texto sin formato como TLS mutuo. Esto se puede hacer para workloads individuales o para toda la mesh.

Consulte Política de autenticación para obtener más detalles.

Si TLS mutuo está habilitado, las comprobaciones de estado HTTP y TCP del kubelet no funcionarán sin modificaciones, ya que el kubelet no tiene certificados emitidos por Istio.

Hay varias opciones:

1. Usar la reescritura de sondeo para redirigir las solicitudes de liveness y readiness a la workload directamente. Consulte Reescritura de sondeo para obtener más información. Esto está habilitado de forma predeterminada y se recomienda.

2. Usar un puerto separado para las comprobaciones de estado y habilitar TLS mutuo solo en el puerto de servicio normal. Consulte Comprobación de estado de los servicios de Istio para obtener más información.

3. Usar el modo PERMISSIVE para el workload, para que pueda aceptar tanto tráfico de texto sin formato como de TLS mutuo. Tenga en cuenta que TLS mutuo no se aplica con esta opción.

Para los workloads que se ejecutan en Kubernetes, el tiempo de vida de sus certificados de Istio es, de forma predeterminada, de 24 horas.

Esta configuración se puede anular personalizando el campo proxyMetadata de la configuración del proxy. Por ejemplo:

proxyMetadata:
  SECRET_TTL: 48h

No. Cuando se utiliza traffic.sidecar.istio.io/excludeInboundPorts en los workloads del servidor, Istio sigue configurando el Envoy del cliente para que envíe TLS mutuo de forma predeterminada. Para cambiar eso, debe configurar una regla de destino con el modo TLS mutuo establecido en DISABLE para que los clientes envíen texto sin formato a esos puertos.

Es posible que MySQL no se pueda conectar después de instalar Istio. Esto se debe a que MySQL es un protocolo primero del servidor, lo que puede interferir con la detección de protocolos de Istio. En particular, el uso del modo mTLS PERMISSIVE puede causar problemas. Es posible que vea mensajes de error como ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0.

Esto se puede solucionar asegurándose de que se utilice el modo STRICT o DISABLE, o de que todos los clientes estén configurados para enviar mTLS. Consulte protocolos primero del servidor para obtener más información.

Sí. Istio proporciona funciones de autorización tanto para servicios HTTP como para servicios TCP sin formato en la mesh. Más información.

Siguiendo las instrucciones de la tarea Asegurar el tráfico de entrada, la entrada de Istio se puede proteger para que solo acepte tráfico TLS.

Sí, puedes. Funciona tanto con TLS mutuo habilitado como deshabilitado.

Puede recopilar datos de telemetría sobre Istio utilizando Prometheus. Y luego usar la API HTTP de Prometheus para consultar esos datos.

La telemetría en el proxy (también conocida como v2) reduce el costo de los recursos y mejora el rendimiento del proxy en comparación con el enfoque de telemetría basada en Mixer (también conocida como v1), y es el mecanismo preferido para mostrar la telemetría en Istio. Sin embargo, existen algunas diferencias en la telemetría informada entre v1 y v2 que se enumeran a continuación:

• Faltan etiquetas para el tráfico fuera de la mesh La telemetría en el proxy se basa en el intercambio de metadatos entre los proxies de Envoy para recopilar información como el nombre de el workload del par, el namespace y las labels. En la telemetría basada en Mixer , esta funcionalidad la realizaba Mixer como parte de la combinación de los atributos de la solicitud con los datos de la plataforma. Este intercambio de metadatos lo realizan los proxies de Envoy agregando un encabezado HTTP específico para el protocolo HTTP o aumentando el protocolo ALPN para el protocolo TCP como se describe aquí. Esto requiere que los proxies de Envoy se inyecten tanto en los workloads del cliente como del servidor, lo que implica que a la telemetría informada cuando un par no está en la mesh le faltarán atributos del par como el nombre de el workload, el namespace y las labels. Sin embargo, si ambos pares tienen proxies inyectados, todas las labels mencionadas aquí están disponibles en las métricas generadas. Cuando el workload del servidor está fuera de la mesh, los metadatos de el workload del servidor todavía se distribuyen al sidecar del cliente, lo que hace que las métricas del lado del cliente tengan los metadatos de el workload del servidor labels completadas.

• El intercambio de metadatos TCP requiere mTLS El intercambio de metadatos TCP se basa en el protocolo ALPN de Istio que requiere que el TLS mutuo (mTLS) esté habilitado para que los proxies de Envoy intercambien metadatos con éxito. Esto implica que si mTLS no está habilitado en su cluster, la telemetría para el protocolo TCP no incluirá información del par como el nombre de el workload, el namespace y las labels.

• No hay mecanismo para configurar depósitos personalizados para métricas de histograma La telemetría basada en Mixer admitía la personalización de depósitos para métricas de tipo histograma como la duración de la solicitud y los tamaños de bytes de TCP. La telemetría en el proxy no tiene tal mecanismo disponible. Además, los depósitos disponibles para las métricas de latencia en la telemetría en el proxy están en milisegundos en comparación con los segundos en la telemetría basada en Mixer. Sin embargo, hay más depósitos disponibles de forma predeterminada en la telemetría en el proxy para las métricas de latencia en los niveles de latencia más bajos.

• No hay vencimiento de métricas para métricas de corta duración La telemetría basada en Mixer admitía el vencimiento de métricas por el cual las métricas que no se generaban durante un período de tiempo configurable se daban de baja para la recopilación por parte de Prometheus. Esto es útil en escenarios, como trabajos únicos, que generan métricas de corta duración. Dar de baja las métricas evita la notificación de métricas que ya no cambiarían en el futuro, lo que reduce el tráfico de red y el almacenamiento en Prometheus. Este mecanismo de vencimiento no está disponible en la telemetría en el proxy. La solución alternativa para esto se puede encontrar aquí.

Las métricas de corta duración pueden afectar el rendimiento de Prometheus, ya que a menudo son una gran fuente de cardinalidad de labels. La cardinalidad es una medida del número de valores únicos para una label. Para gestionar el impacto de sus métricas de corta duración en Prometheus, primero debe identificar las métricas y labels de alta cardinalidad. Prometheus proporciona información de cardinalidad en su página /status. Se puede recuperar información adicional a través de PromQL. Hay varias formas de reducir la cardinalidad de las métricas de Istio:

• Deshabilitar la reserva del encabezado del host. La label destination_service es una fuente potencial de alta cardinalidad. Los valores para destination_service se establecen de forma predeterminada en el encabezado del host si el proxy de Istio no puede determinar el servicio de destino a partir de otros metadatos de la solicitud. Si los clientes utilizan una variedad de encabezados de host, esto podría dar como resultado una gran cantidad de valores para destination_service. En este caso, siga la guía de personalización de métricas para deshabilitar la reserva del encabezado del host en toda la mesh. Para deshabilitar la reserva del encabezado del host para una workload o un namespace en particular, debe copiar la configuración de EnvoyFilter de estadísticas, actualizarla para que la reserva del encabezado del host esté deshabilitada y aplicarla con un selector más específico. Este problema tiene más detalles sobre cómo lograrlo.
• Eliminar labels innecesarias de la colección. Si no se necesita la label con alta cardinalidad, puede eliminarla de la colección de métricas a través de la personalización de métricas usando tags_to_remove.
• Normalizar los valores de las labels, ya sea a través de la federación o la clasificación. Si se desea la información proporcionada por la label, puede usar la federación de Prometheus o la clasificación de solicitudes para normalizar la label.

Mixer fue eliminado en la versión 1.8 de Istio. La migración es necesaria si todavía depende de los adaptadores integrados de Mixer o de cualquier adaptador fuera de proceso para la extensión de la mesh.

Para los adaptadores integrados, se proporcionan varias alternativas:

• Las integraciones de Prometheus y Stackdriver se implementan como extensiones de proxy. La personalización de la telemetría generada por estas dos extensiones se puede lograr a través de la clasificación de solicitudes y la personalización de métricas de Prometheus.
• La funcionalidad de limitación de velocidad global y local (adaptadores memquota y redisquota) se proporciona a través de la solución de limitación de velocidad basada en Envoy.
• El adaptador OPA se reemplaza por la solución basada en ext-authz de Envoy, que admite la integración con el agente de políticas de OPA.

Para los adaptadores personalizados fuera de proceso, se recomienda encarecidamente la migración a extensiones basadas en Wasm. Consulte las guías sobre el desarrollo de módulos Wasm y la distribución de extensiones. Como solución temporal, puede habilitar el soporte de la API de registro de acceso gRPC y ext-authz de Envoy en Mixer, lo que le permite actualizar Istio a versiones posteriores a la 1.7 sin dejar de usar Mixer 1.7 con adaptadores fuera de proceso. Esto le dará más tiempo para migrar a extensiones basadas en Wasm. Tenga en cuenta que esta solución temporal no ha sido probada en batalla y es poco probable que reciba correcciones de parches, ya que solo está disponible en la rama 1.7 de Istio, que está fuera de la ventana de soporte después de febrero de 2021.

Puede usar docker-compose para instalar Prometheus.

Puede habilitar el seguimiento para determinar el flujo de una solicitud en Istio.

Además, puede usar los siguientes comandos para saber más sobre el estado de la mesh:

• istioctl proxy-config: recupera información sobre la configuración del proxy cuando se ejecuta en Kubernetes:

  # Recuperar información sobre la configuración de arranque para la instancia de Envoy en el pod especificado.
  $ istioctl proxy-config bootstrap productpage-v1-bb8d5cbc7-k7qbm
  Recuperar información sobre la configuración del cluster para la instancia de Envoy en el pod especificado.
  $ istioctl proxy-config cluster productpage-v1-bb8d5cbc7-k7qbm
  Recuperar información sobre la configuración del listener para la instancia de Envoy en el pod especificado.
  $ istioctl proxy-config listener productpage-v1-bb8d5cbc7-k7qbm
  Recuperar información sobre la configuración de la ruta para la instancia de Envoy en el pod especificado.
  $ istioctl proxy-config route productpage-v1-bb8d5cbc7-k7qbm
  Recuperar información sobre la configuración del endpoint para la instancia de Envoy en el pod especificado.
  $ istioctl proxy-config endpoints productpage-v1-bb8d5cbc7-k7qbm
  Pruebe lo siguiente para descubrir más comandos de proxy-config
  $ istioctl proxy-config –help

• kubectl get: obtiene información sobre diferentes recursos en la mesh junto con la configuración de enrutamiento:

  # Listar todos los virtual services
  $ kubectl get virtualservices

Sí. Prometheus es un sistema de monitoreo de código abierto y una base de datos de series de tiempo. Puede usar Prometheus con Istio para registrar métricas que rastrean la salud de Istio y de las aplicaciones dentro de la service mesh. Puede visualizar métricas usando herramientas como Grafana y Kiali. Consulte Configuración para Prometheus para comprender cómo habilitar la recopilación de métricas.

Algunas notas:

• Si el pod de Prometheus se inició antes de que el pod de istiod pudiera generar los certificados requeridos y distribuirlos a Prometheus, el pod de Prometheus deberá reiniciarse para poder recopilar de los destinos protegidos con TLS mutuo.
• Si su aplicación expone las métricas de Prometheus en un puerto dedicado, ese puerto debe agregarse a las especificaciones del servicio y la implementación.

Istio se integra con sistemas de seguimiento distribuido utilizando el seguimiento basado en Envoy. Con la integración de seguimiento basada en Envoy, las aplicaciones son responsables de reenviar las cabeceras de seguimiento para las solicitudes salientes posteriores.

Puede encontrar información adicional en la descripción general del seguimiento distribuido y en los documentos de seguimiento de Envoy.

Istio permite la notificación de tramos de seguimiento para las comunicaciones de workload a workload dentro de un mesh. Sin embargo, para que los diversos tramos de seguimiento se unan para obtener una vista completa del flujo de tráfico, las aplicaciones deben propagar el contexto de seguimiento entre las solicitudes entrantes y salientes.

En particular, Istio se basa en que las aplicaciones reenvíen el ID de solicitud generado por Envoy y las cabeceras estándar. Estas cabeceras incluyen:

• x-request-id
• traceparent
• tracestate

Los usuarios de Zipkin deben asegurarse de que propagan las cabeceras de seguimiento B3.

• x-b3-traceid
• x-b3-spanid
• x-b3-parentspanid
• x-b3-sampled
• x-b3-flags
• b3

La propagación de cabeceras se puede lograr a través de bibliotecas de cliente, como OpenTelemetry. También se puede lograr manualmente, como se documenta en la tarea de seguimiento distribuido.

Para las integraciones de seguimiento basadas en Envoy, Envoy (el proxy sidecar) envía información de seguimiento directamente a los backends de seguimiento en nombre de las aplicaciones que se están representando.

Envoy:

• genera ID de solicitud y cabeceras de seguimiento (es decir, X-B3-TraceId) para las solicitudes a medida que fluyen a través del proxy
• genera tramos de seguimiento para cada solicitud en función de los metadatos de la solicitud y la respuesta (es decir, el tiempo de respuesta)
• envía los tramos de seguimiento generados a los backends de seguimiento
• reenvía las cabeceras de seguimiento a la aplicación representada

Istio admite OpenTelemetry y backends compatibles, incluidos Jaeger. Otras plataformas compatibles incluyen Zipkin y Apache SkyWalking.

La gateway de Istio o el proxy sidecar (Envoy) genera las cabeceras iniciales, si no las proporciona la solicitud.

Aunque un sidecar de Istio procesará tanto las solicitudes entrantes como las salientes para una instancia de aplicación asociada, no tiene una forma implícita de correlacionar las solicitudes salientes con la solicitud entrante que las causó. La única forma en que se puede lograr esta correlación es si la aplicación propaga información relevante (es decir, cabeceras) de la solicitud entrante a las solicitudes salientes. La propagación de cabeceras se puede lograr a través de bibliotecas de cliente o manualmente. Se proporciona una discusión adicional en ¿Qué se requiere para el seguimiento distribuido con Istio?.

La tasa de muestreo para el seguimiento se establece en el 1% en el perfil de configuración predeterminado. Esto significa que solo 1 de cada 100 instancias de seguimiento capturadas por Istio se informará al backend de seguimiento. La tasa de muestreo en el perfil demo se establece en 100%. Consulte esta sección para obtener información sobre cómo establecer la tasa de muestreo.

Si aún no ve ningún dato de seguimiento, confirme que sus puertos cumplen con las convenciones de nomenclatura de puertos de Istio y que el puerto de contenedor apropiado está expuesto (a través de la especificación del pod, por ejemplo) para permitir la captura de tráfico por el proxy sidecar (Envoy).

Si solo ve datos de seguimiento asociados con el proxy de salida, pero no con el proxy de entrada, aún puede estar relacionado con las convenciones de nomenclatura de puertos de Istio.

Istio, a través de Envoy, actualmente admite una estrategia de muestreo basada en porcentajes para la generación de trazas. Consulte esta sección para obtener más información sobre cómo establecer esta tasa de muestreo.

Actualmente, Istio no proporciona soporte para los protocolos pub/sub y de bus de eventos. Cualquier uso de esas tecnologías es en el mejor de los casos y está sujeto a roturas.

Las reglas se pueden ver usando kubectl get virtualservice -o yaml

Istio captura el tráfico entrante en todos los puertos de forma predeterminada. Puede anular este comportamiento utilizando la anotación del pod traffic.sidecar.istio.io/includeInboundPorts para especificar una lista explícita de puertos para capturar, o utilizando traffic.sidecar.istio.io/excludeOutboundPorts para especificar una lista de puertos para omitir.

Ambas configuraciones de DestinationRule enviarán tráfico TLS mutuo. Con ISTIO_MUTUAL, los certificados de Istio se utilizarán automáticamente. Para MUTUAL, se deben configurar la clave, el certificado y la CA de confianza. Esto permite iniciar TLS mutuo con aplicaciones que no son de Istio.

Sí, Istio es totalmente compatible con estas workloads a partir de Istio 1.10.

Después de aplicar la configuración de CORS, es posible que descubra que aparentemente no sucedió nada y se pregunte qué salió mal. CORS es un concepto HTTP comúnmente mal entendido que a menudo genera confusión al configurar.

Para entender esto, es útil dar un paso atrás y ver qué es CORS y cuándo debe usarse. De forma predeterminada, los navegadores tienen restricciones sobre las solicitudes de “origen cruzado” iniciadas por scripts. Esto evita, por ejemplo, que un sitio web attack.example.com realice una solicitud de JavaScript a bank.example.com y robe la información confidencial de un usuario.

Para permitir esta solicitud, bank.example.com debe permitir que attack.example.com realice solicitudes de origen cruzado. Aquí es donde entra en juego CORS. Si estuviéramos sirviendo bank.example.com en un cluster habilitado para Istio, podríamos configurar una corsPolicy para permitir esto:

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: bank
spec:
  hosts:
  - bank.example.com
  http:
  - corsPolicy:
      allowOrigins:
      - exact: https://attack.example.com
...

En este caso, permitimos explícitamente un único origen; los comodines son comunes para las páginas no confidenciales.

Una vez que hacemos esto, un error común es enviar una solicitud como curl bank.example.com -H "Origin: https://attack.example.com", y esperar que la solicitud sea rechazada. Sin embargo, curl y muchos otros clientes no verán una solicitud rechazada, porque CORS es una restricción del navegador. La configuración de CORS simplemente agrega encabezados Access-Control-* en la respuesta; depende del cliente (navegador) rechazar la solicitud si la respuesta no es satisfactoria. En los navegadores, esto se hace mediante una solicitud de verificación previa.

Las especificaciones de ingress simples, con coincidencias basadas en host, TLS y ruta exacta funcionarán de fábrica sin necesidad de reglas de ruta . Sin embargo, tenga en cuenta que la ruta utilizada en el recurso de ingress no debe tener ningún carácter ..

Por ejemplo, el siguiente recurso de ingress coincide con las solicitudes para el host example.com, con /helloworld como URL.

$ kubectl create -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: simple-ingress
  annotations:
    kubernetes.io/ingress.class: istio
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /helloworld
        pathType: Prefix
        backend:
          service:
            name: myservice
            port:
              number: 8000
EOF

Sin embargo, las siguientes reglas no funcionarán porque usan expresiones regulares en la ruta y anotaciones ingress.kubernetes.io:

$ kubectl create -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: this-will-not-work
  annotations:
    kubernetes.io/ingress.class: istio
    # Ingress annotations other than ingress class will not be honored
    ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /hello(.*?)world/
        pathType: Prefix
        backend:
          service:
            name: myservice
            port:
              number: 8000
EOF

Actualmente, Istio admite protocolos basados en TCP. Además, Istio proporciona funcionalidades como enrutamiento y métricas para otros protocolos como http y mysql.

Para obtener una lista de todos los protocolos e información sobre cómo configurar los protocolos, consulte la documentación de Selección de protocolo.