Configurar proxies de waypoint

Un proxy de waypoint es un despliegue opcional del proxy basado en Envoy para agregar procesamiento de capa 7 (L7) a un conjunto definido de cargas de trabajo.

Los proxies de waypoint se instalan, actualizan y escalan independientemente de las aplicaciones; el propietario de una aplicación no debería ser consciente de su existencia. En comparación con el modo de data plane de sidecar, que ejecuta una instancia del proxy de Envoy junto con cada carga de trabajo, el número de proxies necesarios se puede reducir sustancialmente.

Un waypoint, o un conjunto de waypoints, se puede compartir entre aplicaciones con un límite de seguridad similar. Esto podría ser todas las instancias de una carga de trabajo en particular, o todas las cargas de trabajo en un namespace.

A diferencia del modo sidecar, en el modo ambient las políticas son aplicadas por el waypoint de destino. En muchos sentidos, el waypoint actúa como una gateway a un recurso (un namespace, servicio o pod). Istio garantiza que todo el tráfico que ingresa al recurso pase a través del waypoint, que luego aplica todas las políticas para ese recurso.

¿Necesitas un proxy de waypoint?

El enfoque por capas de ambient permite a los usuarios adoptar Istio de una manera más incremental, pasando sin problemas de ninguna malla, a la superposición segura L4, al procesamiento L7 completo.

La mayoría de las características del modo ambient son proporcionadas por el proxy de nodo ztunnel. Ztunnel está diseñado para procesar solo el tráfico en la capa 4 (L4), de modo que pueda operar de forma segura como un componente compartido.

Cuando configuras la redirección a un waypoint, el tráfico será reenviado por ztunnel a ese waypoint. Si tus aplicaciones requieren alguna de las siguientes funciones de mesh L7, deberás usar un proxy de waypoint:

• Gestión del tráfico: enrutamiento y balanceo de carga HTTP, interrupción de circuito, limitación de velocidad, inyección de fallas, reintentos, tiempos de espera
• Seguridad: políticas de autorización enriquecidas basadas en primitivas L7 como el tipo de solicitud o el encabezado HTTP
• Observabilidad: métricas HTTP, registro de acceso, trazado

Desplegar un proxy de waypoint

Los proxies de waypoint se despliegan usando los recursos de la API de Gateway de Kubernetes.

Ten en cuenta que las CRD de la API de Gateway de Kubernetes no vienen instaladas por defecto en la mayoría de los clusteres de Kubernetes, así que asegúrate de que estén instaladas antes de usar la API de Gateway:

$ kubectl get crd gateways.gateway.networking.k8s.io &> /dev/null || \
  kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.6.0/standard-install.yaml

Puedes usar los subcomandos de istioctl waypoint para generar, aplicar o listar estos recursos.

Después de que se despliegue el waypoint, todo el namespace (o los servicios o pods que elijas) deben estar inscritos para usarlo.

Antes de desplegar un proxy de waypoint para un namespace específico, confirma que el namespace esté etiquetado con istio.io/data plane-mode: ambient:

$ kubectl get ns -L istio.io/data plane-mode
NAME              STATUS   AGE   data plane-MODE
istio-system      Active   24h
default           Active   24h   ambient

istioctl puede generar un recurso de Gateway de Kubernetes para un proxy de waypoint. Por ejemplo, para generar un proxy de waypoint llamado waypoint para el namespace default que pueda procesar el tráfico para los servicios en el namespace:

$ istioctl waypoint generate --for service -n default
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  labels:
    istio.io/waypoint-for: service
  name: waypoint
  namespace: default
spec:
  gatewayClassName: istio-waypoint
  listeners:
  - name: mesh
    port: 15008
    protocol: HBONE

Observa que el recurso de Gateway tiene un gatewayClassName de istio-waypoint, que instancia un waypoint gestionado por Istio. El recurso de Gateway está etiquetado con istio.io/waypoint-for: service, lo que indica que el waypoint puede procesar el tráfico para los servicios, que es el valor predeterminado.

Para desplegar un proxy de waypoint directamente, usa apply en lugar de generate:

$ istioctl waypoint apply -n default
waypoint default/waypoint applied

O bien, puedes desplegar el recurso de Gateway generado:

$ kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  labels:
    istio.io/waypoint-for: service
  name: waypoint
  namespace: default
spec:
  gatewayClassName: istio-waypoint
  listeners:
  - name: mesh
    port: 15008
    protocol: HBONE
EOF

Después de que se aplique el recurso de Gateway, Istiod monitoreará el recurso, desplegará y gestionará el despliegue y el servicio del waypoint correspondiente para los usuarios automáticamente.

Tipos de tráfico de waypoint

Por defecto, un waypoint solo manejará el tráfico destinado a los servicios en sus namespaces. Esta elección se hizo porque el tráfico dirigido solo a un pod es raro y, a menudo, se usa para fines internos, como el raspado de Prometheus, y es posible que no se desee la sobrecarga adicional del procesamiento L7.

También es posible que el waypoint maneje todo el tráfico, solo maneje el tráfico enviado directamente a las cargas de trabajo (pods o VM) en el cluster, o ningún tráfico en absoluto. Los tipos de tráfico que se redirigirán al waypoint se determinan mediante la etiqueta istio.io/waypoint-for en el objeto Gateway.

Usa el argumento --for para istioctl waypoint apply para cambiar los tipos de tráfico que se pueden redirigir al waypoint:

La selección del waypoint se produce en función del tipo de destino, service o workload, al que se dirigió originalmente el tráfico. Si el tráfico se dirige a un servicio que no tiene un waypoint, no se transitará un waypoint: incluso si la carga de trabajo final a la que llega sí tiene un waypoint adjunto.

Usar un proxy de waypoint

Cuando se despliega un proxy de waypoint, no lo utiliza ningún recurso hasta que configures explícitamente esos recursos para que lo usen.

Para habilitar un namespace, servicio o Pod para que use un waypoint, agrega la etiqueta istio.io/use-waypoint con un valor del nombre del waypoint.

Si usas istioctl para desplegar tu waypoint de namespace, puedes usar el parámetro --enroll-namespace para etiquetar automáticamente un namespace:

$ istioctl waypoint apply -n default --enroll-namespace
waypoint default/waypoint applied
namespace default labeled with "istio.io/use-waypoint: waypoint"

Alternativamente, puedes agregar la etiqueta istio.io/use-waypoint: waypoint al namespace default usando kubectl:

$ kubectl label ns default istio.io/use-waypoint=waypoint
namespace/default labeled

Después de que un namespace se inscriba para usar un waypoint, cualquier solicitud de cualquier pod que use el modo de data plane ambient, a cualquier servicio que se ejecute en ese namespace, se enrutará a través del waypoint para el procesamiento L7 y la aplicación de políticas.

Si prefieres más granularidad que usar un waypoint para todo un namespace, puedes inscribir solo un servicio o pod específico para que use un waypoint. Esto puede ser útil si solo necesitas características L7 para algunos servicios en un namespace, si solo quieres que una extensión como un WasmPlugin se aplique a un servicio específico, o si estás llamando a un servicio headless de Kubernetes por su dirección IP de pod.

Gateways de entrada y waypoints

La etiqueta istio.io/use-waypoint rige el tráfico east-west: las solicitudes desde otros pods de la mesh hacia el namespace, servicio o workload etiquetado se envían a través del waypoint de destino para aplicar políticas de capa 7 y recopilar telemetría.

El tráfico desde una Istio ingress gateway hacia ese Service se modela por separado. De forma predeterminada, el tráfico originado en la ingress gateway no usará el waypoint del servicio de destino, incluso cuando istio.io/use-waypoint esté definido en el servicio o en el namespace.

Para dirigir el tráfico de entrada a través del mismo waypoint que el tráfico de la mesh, define istio.io/ingress-use-waypoint como true en el Service de Kubernetes, o en el Namespace para aplicarlo a todos los servicios de ese namespace (soportado a partir de Istio 1.25). Consulta la referencia de etiquetas de recursos para ver los tipos de recursos soportados.

$ kubectl label service reviews istio.io/ingress-use-waypoint=true
service/reviews labeled

El control plane solo aplica este comportamiento cuando ENABLE_INGRESS_WAYPOINT_ROUTING está habilitado en istiod; su valor predeterminado es false. Consulta ENABLE_INGRESS_WAYPOINT_ROUTING en la referencia de variables de entorno de pilot-discovery.

Configurar un servicio para que use un waypoint específico

Usando los servicios de la aplicación de ejemplo bookinfo, podemos desplegar un waypoint llamado reviews-svc-waypoint para el servicio reviews:

$ istioctl waypoint apply -n default --name reviews-svc-waypoint
waypoint default/reviews-svc-waypoint applied

Etiqueta el servicio reviews para que use el waypoint reviews-svc-waypoint:

$ kubectl label service reviews istio.io/use-waypoint=reviews-svc-waypoint
service/reviews labeled

Cualquier solicitud de los pods en la mesh al servicio reviews ahora se enrutará a través del waypoint reviews-svc-waypoint.

Configurar un pod para que use un waypoint específico

Despliega un waypoint llamado reviews-v2-pod-waypoint para el pod reviews-v2.

$ istioctl waypoint apply -n default --name reviews-v2-pod-waypoint --for workload
waypoint default/reviews-v2-pod-waypoint applied

Etiqueta el pod reviews-v2 para que use el waypoint reviews-v2-pod-waypoint:

$ kubectl label pod -l version=v2,app=reviews istio.io/use-waypoint=reviews-v2-pod-waypoint
pod/reviews-v2-5b667bcbf8-spnnh labeled

Cualquier solicitud de los pods en la mesh ambient a la IP del pod reviews-v2 ahora se enrutará a través del waypoint reviews-v2-pod-waypoint para el procesamiento L7 y la aplicación de políticas.

Requerir que el tráfico atraviese el waypoint

La etiqueta istio.io/use-waypoint registra tu intención de enviar el tráfico a través de un waypoint, pero por sí sola no garantiza que esto ocurra. ztunnel enruta el tráfico directamente al destino, en lugar de fallar la solicitud, cuando:

• el waypoint indicado no existe o no tiene dirección; o
• el tipo de tráfico no coincide con el tráfico que maneja el waypoint; por ejemplo, una solicitud enviada directamente a un workload (una IP de pod o de VM) cuando el waypoint solo maneja tráfico de servicio, que es el valor predeterminado.

En cualquiera de los dos casos, las políticas de capa 7 que el waypoint habría aplicado nunca llegan a tener efecto, y el tráfico fluye como si no hubiera ningún waypoint configurado.

Si aplicar las políticas de capa 7 de un waypoint es un requisito de seguridad, haz que el waypoint sea obligatorio con una AuthorizationPolicy que solo permita la identidad del waypoint. Un waypoint usa la cuenta de servicio con el mismo nombre que su Gateway, por lo que una política en los workloads de destino que solo permita esa identidad deniega a cualquier cliente que llegue a ellos sin pasar primero por el waypoint. Continuando con el waypoint reviews-svc-waypoint anterior:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: require-waypoint
  namespace: default
spec:
  selector:
    matchLabels:
      app: reviews
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/default/sa/reviews-svc-waypoint

Esta política usa un selector de workload en lugar de un targetRef, por lo que ztunnel la aplica en capa 4. Por tanto, tiene efecto en ambos casos de evasión: cuando el waypoint no está disponible y cuando un cliente se conecta directamente al workload.

Uso de waypoint entre namespaces

De forma predeterminada, un proxy de waypoint es utilizable por los recursos dentro del mismo namespace. A partir de Istio 1.23, es posible usar waypoints en diferentes namespaces. En esta sección, examinaremos la configuración de la gateway necesaria para habilitar el uso entre namespaces y cómo configurar tus recursos para usar un waypoint de un namespace diferente.

Configurar un waypoint para uso entre namespaces

Para habilitar el uso entre namespaces de un waypoint, la Gateway debe configurarse para permitir rutas de otros namespaces.

La siguiente Gateway permitiría que los recursos en un namespace llamado “cross-namespace-waypoint-consumer” usen esta egress-gateway. Para una guía completa paso a paso sobre cómo usar un waypoint como gateway de salida, consulta Gateways de salida.

kind: Gateway
metadata:
  name: egress-gateway
  namespace: common-infrastructure
spec:
  gatewayClassName: istio-waypoint
  listeners:
  - name: mesh
    port: 15008
    protocol: HBONE
    allowedRoutes:
      namespaces:
        from: Selector
        selector:
          matchLabels:
            kubernetes.io/metadata.name: cross-namespace-waypoint-consumer

Configurar recursos para usar un proxy de waypoint entre namespaces

De forma predeterminada, el control plane de Istio buscará un waypoint especificado usando la etiqueta istio.io/use-waypoint en el mismo namespace que el recurso al que se aplica la etiqueta. Es posible usar un waypoint en otro namespace agregando una nueva etiqueta, istio.io/use-waypoint-namespace. istio.io/use-waypoint-namespace funciona para todos los recursos que admiten la etiqueta istio.io/use-waypoint. Juntas, las dos etiquetas especifican el nombre y el namespace de tu waypoint, respectivamente. Por ejemplo, para configurar un ServiceEntry llamado istio-site para que use un waypoint llamado egress-gateway en el namespace llamado common-infrastructure, podrías usar los siguientes comandos:

$ kubectl label serviceentries.networking.istio.io istio-site istio.io/use-waypoint=egress-gateway
serviceentries.networking.istio.io/istio-site labeled
$ kubectl label serviceentries.networking.istio.io istio-site istio.io/use-waypoint-namespace=common-infrastructure
serviceentries.networking.istio.io/istio-site labeled

Limpieza

Puedes eliminar todos los waypoints de un namespace haciendo lo siguiente:

$ istioctl waypoint delete --all -n default
$ kubectl label ns default istio.io/use-waypoint-

Elimina las CRD de la API de Gateway de Kubernetes:

$ kubectl delete -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.6.0/standard-install.yaml