Habilitar el modo ambient

lectura de 7 minutos prueba de página

Habilita el modo ambient un namespace a la vez. Esto te permite validar cada namespace antes de continuar, y revertir un solo namespace si algo sale mal.

Migración de un namespace

Requisitos de orden

No seguir esta secuencia puede resultar en que el tráfico no sea procesado ni por el sidecar ni por ztunnel, causando interrupciones en tus workloads.

Paso 1: Activar waypoints

Activa los waypoints desplegados en el paso anterior agregando la etiqueta istio.io/use-waypoint.

Para activar un waypoint para todo un namespace:

$ kubectl label namespace <namespace> istio.io/use-waypoint=waypoint

Para activar un waypoint para un Service específico únicamente:

$ kubectl label service <service-name> -n <namespace> istio.io/use-waypoint=waypoint

Verifica que el waypoint está listo:

$ kubectl get gateway waypoint -n <namespace>

La columna READY debería mostrar True.

Paso 2: Habilitar el modo ambient para el namespace

Agrega la etiqueta istio.io/dataplane-mode=ambient al namespace. Esto indica al plugin CNI que los pods nuevos y reiniciados en este namespace deben usar ztunnel en lugar de (o junto a) un sidecar:

$ kubectl label namespace <namespace> istio.io/dataplane-mode=ambient

Verifica que el namespace ahora está incorporado a la mesh ambient:

$ istioctl ztunnel-config workloads -n istio-system | grep <namespace>

Los workloads del namespace aparecerán con HBONE como su protocolo. Los pods aún tienen sus sidecars en este punto. El sidecar tiene prioridad sobre ztunnel para pods que tienen ambos.

Paso 3: Eliminar la inyección de sidecar

Elimina la etiqueta de inyección de sidecar del namespace:

Si usas la etiqueta de inyección por defecto:

$ kubectl label namespace <namespace> istio-injection-

Si usas una etiqueta de revisión:

$ kubectl label namespace <namespace> istio.io/rev-

Paso 4: Reiniciar pods

Reinicia los workloads del namespace. Al reiniciarse, los pods se activarán sin contenedores sidecar y usarán ztunnel (y el waypoint, si está configurado) en su lugar:

$ kubectl rollout restart deployment -n <namespace>
$ kubectl rollout status deployment -n <namespace>

Paso 5: Eliminar las antiguas políticas de sidecar

Haz esto inmediatamente después del reinicio del pod, antes de realizar cualquier validación. Una vez que se eliminan los sidecars, ztunnel toma el control de la aplicación de políticas. ztunnel solo comprende atributos L4 y descarta silenciosamente cualquier condición L7 (métodos HTTP, paths, headers, request principals) de las reglas de AuthorizationPolicy. El efecto depende de la acción de la política:

Política ALLOW con reglas L7: ztunnel descarta las condiciones L7. Si cada regla de la política dependía únicamente de atributos L7, la política resultante no tiene reglas y no coincide con nada, lo que hace que ztunnel deniegue todo el tráfico a ese workload (una política ALLOW sin reglas coincidentes no permite nada).
Política DENY con reglas L7: ztunnel descarta las condiciones L7. Si una regla no tenía condiciones L4 para empezar (por ejemplo, solo coincidía con request principals o paths HTTP), eliminar las partes L7 deja una coincidencia vacía que se aplica a todo el tráfico, efectivamente denegando todo el tráfico a ese workload.

En ambos casos, dejar activas las antiguas políticas L7 basadas en selector después de eliminar los sidecars bloqueará el tráfico. Elimínalas inmediatamente.

Elimina cualquier recurso AuthorizationPolicy que usara un selector de workload con reglas L7, ahora que han sido reemplazados por equivalentes basados en targetRefs:

$ kubectl delete authorizationpolicy <sidecar-policy-name> -n <namespace>

También elimina los recursos VirtualService y DestinationRule reemplazados por HTTPRoute:

$ kubectl delete virtualservice <name> -n <namespace>
$ kubectl delete destinationrule <name> -n <namespace>

Los recursos L4 de AuthorizationPolicy que usan selector (sin reglas L7) son seguros de mantener; ztunnel los aplica correctamente.

Paso 6: Validar

Verifica que los pods estén ejecutándose sin contenedores sidecar:

$ kubectl get pods -n <namespace>

Confirma que ztunnel está gestionando los workloads:

$ istioctl ztunnel-config workloads -n istio-system | grep <namespace>

Si desplegaste waypoints, verifica que las políticas L7 y las reglas de enrutamiento se están aplicando probando los comportamientos específicos (enrutamiento basado en headers, restricciones de método HTTP, etc.) que definen tus recursos HTTPRoute y AuthorizationPolicy.

Repetir para cada namespace

Repite los pasos de Migración de un namespace para cada namespace que quieras migrar. Los namespaces no etiquetados con istio.io/dataplane-mode=ambient continúan usando sus sidecars y no se ven afectados.

Reversión

Cada paso es reversible de forma independiente. Usa el procedimiento de reversión que corresponda a cuánto has avanzado:

Paso	Acción de reversión
Después del Paso 1 (waypoints activados)	`kubectl label namespace <ns> istio.io/use-waypoint-`
Después del Paso 2 (ambient habilitado)	`kubectl label namespace <ns> istio.io/dataplane-mode-`
Después del Paso 3 (inyección eliminada)	Vuelve a agregar la etiqueta de inyección: `kubectl label namespace <ns> istio-injection=enabled`
Después del Paso 4 (pods reiniciados)	Vuelve a agregar la etiqueta de inyección, luego `kubectl rollout restart deployment -n <ns>`
Después del Paso 5 (antiguas políticas eliminadas)	`kubectl apply -f istio-config-backup.yaml` para restaurar desde la copia de seguridad

Después de cualquier reversión que implique reinicios de pods, verifica que los pods muestren 2/2 contenedores (lo que indica que el sidecar ha sido reinyectado) y confirma que el tráfico fluye antes de continuar.

Cambios en la observabilidad post-migración

Después de migrar al modo ambient, ten en cuenta los siguientes cambios en la telemetría:

Métricas: En modo sidecar, las métricas se reportan con reporter="source" y reporter="destination". En modo ambient, las métricas de ztunnel usan reporter="source", mientras que las métricas de los waypoint proxies usan reporter="waypoint". Actualiza cualquier panel de control o regla de alertas que dependa de la etiqueta reporter.

Fusión de métricas: En modo sidecar, el agente proxy soporta la fusión de métricas, que combina las métricas de Istio y las de la aplicación en un único destino de scrape usando las anotaciones estándar prometheus.io. Esta característica no está disponible en modo ambient. Después de la migración, debes configurar Prometheus para hacer scrape de los componentes de Istio (pods de ztunnel y waypoint) y de tus pods de aplicación como destinos separados. Actualiza cualquier recurso PodMonitor o ServiceMonitor que dependía de un único endpoint fusionado.

Trazado: En modo sidecar, cada salto genera dos spans (uno del sidecar de origen, otro del sidecar de destino). En modo ambient con waypoints, se genera un span por waypoint. Actualiza los SLOs basados en trazas en consecuencia.

istioctl proxy-status: Este comando no muestra los workloads de ztunnel. Usa istioctl ztunnel-config workloads en su lugar para inspeccionar el estado del proxy ambient.

Para más información, consulta: