Preguntas frecuentes sobre la gestión del tráfico

¿Cómo puedo ver las reglas de ruta actuales que he configurado con Istio?

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

¿En qué puertos captura un proxy sidecar el tráfico entrante?

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.

¿Cuál es la diferencia entre los modos TLS MUTUAL e ISTIO_MUTUAL?

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.

¿Se puede usar Istio con StatefulSets y servicios headless?

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

¿Por qué no funciona mi configuración de CORS?

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.

¿Puedo usar la especificación de Ingress estándar sin ninguna regla de ruta?

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
¿Qué protocolos admite Istio?

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.