Cloud Service Mesh y Traffic Director ahora son Cloud Service Mesh. Para obtener más información, consulta la descripción general de Cloud Service Mesh.

Se usó la API de Cloud Translation para traducir esta página.

Actualizaciones de configuración para la modernización

En este documento, se describen las actualizaciones de configuración que tal vez debas realizar en tu Cloud Service Mesh administrado antes de modernizar tu malla al plano de control de TRAFFIC_DIRECTOR desde el plano de control de ISTIOD.

A continuación, se incluye una lista de las posibles actualizaciones de configuración necesarias para preparar tu clúster para la modernización. Consulta cada sección para obtener instrucciones de actualización:

Multi-cluster
Habilita la federación de identidades para cargas de trabajo para GKE
Habilita la CNI administrada
Uso binario no estándar en Sidecar
Migra a la puerta de enlace de entrada de Istio

Para obtener más información sobre el flujo de trabajo de modernización, consulta la página Modernización del plano de control administrado.

Migra de los secretos de Istio a multicluster_mode

Los Secrets de varios clústeres no se admiten cuando un clúster usa el plano de control TRAFFIC_DIRECTOR. En este documento, se describe cómo puedes modernizar el uso de secretos de varios clústeres de Istio para usar multicluster_mode.

Comparación entre los secretos de Istio y la descripción general de la API declarativa

El descubrimiento de extremos de Istio de código abierto para varios clústeres funciona con istioctl o con otras herramientas para crear un Secret de Kubernetes en un clúster. Este secreto permite que un clúster balancee la carga del tráfico hacia otro clúster de la malla. Luego, el plano de control de ISTIOD lee este secreto y comienza a enrutar el tráfico hacia ese otro clúster.

Cloud Service Mesh tiene una API declarativa para controlar el tráfico de varios clústeres en lugar de crear directamente secretos de Istio. Esta API trata los secretos de Istio como un detalle de implementación y es más confiable que crear secretos de Istio de forma manual. Las futuras funciones de Cloud Service Mesh dependerán de la API declarativa, y no podrás usar esas funciones nuevas directamente con los secretos de Istio. La API declarativa es la única ruta de acceso compatible para avanzar.

Si usas Secrets de Istio, migra a la API declarativa lo antes posible. Ten en cuenta que el parámetro de configuración multicluster_mode dirige cada clúster para que dirija el tráfico a todos los demás clústeres de la malla. El uso de secretos permite una configuración más flexible, ya que te permite configurar para cada clúster a qué otro clúster debe dirigir el tráfico en la malla. Para obtener una lista completa de las diferencias entre las funciones compatibles de la API declarativa y los secretos de Istio, consulta Funciones compatibles con las APIs de Istio.

Migra de los secretos de Istio a la API declarativa

Si aprovisionaste Cloud Service Mesh con la administración automática a través de la API de la función de flota, no es necesario que sigas estas instrucciones. Estos pasos solo se aplican si realizaste la integración con asmcli --managed.

Ten en cuenta que este proceso cambia los secretos que apuntan a un clúster. Durante este proceso, se quitan los extremos y, luego, se vuelven a agregar. Entre la eliminación y la adición de los extremos, el tráfico volverá brevemente al enrutamiento local en lugar de balancearse a otros clústeres. Para obtener más información, consulta el problema de GitHub.

Para dejar de usar los secretos de Istio y comenzar a usar la API declarativa, sigue estos pasos. Ejecuta estos pasos al mismo tiempo o en una sucesión cercana:

Habilita la API declarativa para cada clúster de la flota en el que desees habilitar el descubrimiento de extremos de varios clústeres configurando multicluster_mode=connected. Ten en cuenta que debes establecer multicluster_mode=disconnected de forma explícita si no quieres que se pueda detectar el clúster.

Usa el siguiente comando para habilitar la detección de extremos de varios clústeres en un clúster:
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"connected"}}'
```
Usa el siguiente comando para inhabilitar la detección de extremos en un clúster:
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"disconnected"}}'
```
Borra los secretos antiguos.

Después de configurar multicluster_mode=connected en tus clústeres, cada uno tendrá un nuevo secreto generado para cada uno de los demás clústeres que también tengan configurado multicluster_mode=connected. El secreto se coloca en el espacio de nombres istio-system y tiene el siguiente formato:
```
istio-remote-secret-projects-PROJECT_NAME-locations-LOCATION-memberships-MEMBERSHIPS
```
Cada secreto también tendrá aplicada la etiqueta istio.io/owned-by: mesh.googleapis.com.

Una vez que se creen los nuevos secretos, puedes borrar manualmente los secretos creados con istioctl create-remote-secret:
```
kubectl delete secret SECRET_NAME -n istio-system
```

Una vez que se realice la migración, verifica las métricas de solicitudes para asegurarte de que se enruten según lo previsto.

Habilita la federación de identidades para cargas de trabajo para GKE

La federación de identidades para cargas de trabajo es el método seguro recomendado para las cargas de trabajo de Google Kubernetes Engine. Esto permite el acceso a servicios como Compute Engine, BigQuery y las APIs de aprendizaje automático. Google Cloud La federación de identidades para cargas de trabajo no requiere configuración manual ni métodos menos seguros, como los archivos de claves de cuentas de servicio, ya que usa políticas de IAM. Para obtener más detalles sobre la federación de identidades para cargas de trabajo, consulta Cómo funciona la federación de identidades para cargas de trabajo para GKE.

En la siguiente sección, se describe cómo habilitar la federación de identidades para cargas de trabajo.

Habilita Workload Identity Federation en clústeres

Verifica que Workload Identity Federation esté habilitada para tu clúster. Para ello, asegúrate de que el clúster de GKE tenga configurado un grupo de federación de identidades para cargas de trabajo, lo cual es fundamental para la validación de credenciales de IAM.

Usa el siguiente comando para verificar el grupo de identidades para cargas de trabajo establecido para un clúster:
```
gcloud container clusters describe CLUSTER_NAME \
  --format="value(workloadIdentityConfig.workloadPool)"
```
Reemplaza CLUSTER_NAME por el nombre de tu clúster de GKE. Si aún no especificaste una zona o región predeterminada para gcloud, es posible que también debas especificar una marca --region o --zone cuando ejecutes este comando.
Si el resultado está vacío, sigue las instrucciones en Actualiza un clúster existente para habilitar la identidad de cargas de trabajo en los clústeres existentes de GKE.

Habilita la federación de identidades para cargas de trabajo en grupos de nodos

Después de habilitar la federación de identidades para cargas de trabajo en un clúster, se deben configurar los grupos de nodos para que usen el servidor de metadatos de GKE.

Enumera todos los grupos de nodos de un clúster Standard. Ejecuta el comando gcloud container node-pools list:
```
gcloud container node-pools list --cluster CLUSTER_NAME
```
Reemplaza CLUSTER_NAME por el nombre de tu clúster de GKE. Si aún no especificaste una zona o región predeterminada para gcloud, es posible que también debas especificar una marca --region o --zone cuando ejecutes este comando.
Verifica que cada grupo de nodos use el servidor de metadatos de GKE:
```
gcloud container node-pools describe NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --format="value(config.workloadMetadataConfig.mode)"
```
Reemplaza lo siguiente:
- NODEPOOL_NAME por el nombre de tu grupo de nodos.
- CLUSTER_NAME por el nombre de tu clúster de GKE.
Si el resultado no contiene GKE_METADATA, actualiza el grupo de nodos con la guía Actualiza un grupo de nodos existente.

Habilita la interfaz de red de contenedor (CNI) administrada

En esta sección, se explica cómo habilitar la CNI administrada para Cloud Service Mesh en Google Kubernetes Engine.

Descripción general de la CNI administrada

La interfaz de red de contenedor (CNI) administrada es una implementación administrada por Google de la CNI de Istio. El complemento de CNI optimiza las redes de pods configurando reglas de iptables. Esto permite el redireccionamiento del tráfico entre las aplicaciones y los proxies de Envoy, lo que elimina la necesidad de permisos privilegiados para el init-container requerido para administrar iptables.

El complemento de CNI de Istio reemplaza el contenedor istio-init. Anteriormente, el contenedor istio-init era responsable de configurar el entorno de red del pod para habilitar la intercepción de tráfico del sidecar de Istio. El complemento de CNI realiza la misma función de redireccionamiento de red, pero con el beneficio adicional de reducir la necesidad de privilegios elevados, lo que mejora la seguridad.

Por lo tanto, para mejorar la seguridad y la confiabilidad, y simplificar la administración y la solución de problemas, se requiere una CNI administrada en todas las implementaciones de Managed Cloud Service Mesh.

Impacto en los contenedores de inicialización

Los contenedores init son contenedores especializados que se ejecutan antes de los contenedores de la aplicación para realizar tareas de configuración. Las tareas de configuración pueden incluir la descarga de archivos de configuración, la comunicación con servicios externos o la inicialización previa a la aplicación. Los contenedores de inicialización que dependen del acceso a la red pueden tener problemas cuando se habilita la CNI administrada en el clúster.

El proceso de configuración de pods con CNI administrado es el siguiente:

El complemento de CNI configura las interfaces de red del Pod, asigna IPs de Pod y redirecciona el tráfico al proxy de sidecar de Istio que aún no se inició.
Todos los contenedores init se ejecutan y completan.
El proxy de sidecar de Istio se inicia junto con los contenedores de la aplicación.

Por lo tanto, si un contenedor init intenta establecer conexiones de red salientes o conectarse a servicios dentro de la malla, es posible que se descarten o se redireccionen de forma incorrecta las solicitudes de red de los contenedores init. Esto se debe a que el proxy de Istio sidecar, que administra el tráfico de red del Pod, no se ejecuta cuando se realizan las solicitudes. Para obtener más detalles, consulta la documentación del CNI de Istio.

Habilita la CNI administrada para tu clúster

Sigue los pasos de esta sección para habilitar la CNI administrada en tu clúster.

Quita las dependencias de red de tu contenedor de inicialización. Considera las siguientes alternativas:
- Modifica la lógica o los contenedores de la aplicación: Puedes modificar tus servicios para quitar la dependencia de los contenedores init que requieren solicitudes de red o realizar operaciones de red dentro de los contenedores de la aplicación, después de que se haya iniciado el proxy de sidecar.
- Usa ConfigMaps o secretos de Kubernetes: Almacena los datos de configuración recuperados por la solicitud de red en ConfigMaps o secretos de Kubernetes y móntalos en los contenedores de tu aplicación. Para ver soluciones alternativas, consulta la documentación de Istio.
Habilita la CNI administrada en tu clúster:
1. Realiza los siguientes cambios de configuración:
  1. Ejecuta el siguiente comando para ubicar el controlPlaneRevision.
```
kubectl get controlplanerevision -n istio-system
```
  2. En tu recurso personalizado (CR) ControlPlaneRevision (CPR), establece la etiqueta mesh.cloud.google.com/managed-cni-enabled en true.
```
kubectl label controlplanerevision CPR_NAME \
    -n istio-system mesh.cloud.google.com/managed-cni-enabled=true \
    --overwrite
```
    Reemplaza CPR_NAME por el valor de la columna NAME del resultado del paso anterior.
  3. En el ConfigMap asm-options, establece el valor de ASM_OPTS en CNI=on.
```
kubectl patch configmap asm-options -n istio-system \
    -p '{"data":{"ASM_OPTS":"CNI=on"}}'
```
  4. En tu recurso personalizado (CR) ControlPlaneRevision (CPR), establece la etiqueta mesh.cloud.google.com/force-reprovision en true. Esta acción activa el reinicio del plano de control.
    
    Nota: Este método no es el recomendado para reiniciar el plano de control y solo se debe usar para los esfuerzos de modernización de Cloud Service Mesh.
```
kubectl label controlplanerevision CPR_NAME \
    -n istio-system mesh.cloud.google.com/force-reprovision=true \
    --overwrite
```
2. Verifica el estado de la función. Recupera el estado de la función con el siguiente comando:
```
gcloud container fleet mesh describe --project FLEET_PROJECT_ID
```
  Reemplaza FLEET_PROJECT_ID por el ID de tu proyecto host de flota. Por lo general, el FLEET_PROJECT_ID tiene el mismo nombre que el proyecto.
  - Verifica que la condición MANAGED_CNI_NOT_ENABLED se haya quitado de servicemesh.conditions.
  - Ten en cuenta que el estado puede tardar entre 15 y 20 minutos en actualizarse. Intenta esperar unos minutos y vuelve a ejecutar el comando.
3. Una vez que controlPlaneManagement.state sea Active en el estado de la función del clúster, reinicia los pods.

Migra del uso de binarios no estándar en Sidecar

En esta sección, se sugieren formas de hacer que tus implementaciones sean compatibles con la imagen de proxy de Envoy distroless.

Imágenes de sidecar de proxy de Envoy distroless

Cloud Service Mesh usa dos tipos de imágenes de sidecar de proxy de Envoy según la configuración del plano de control: una imagen basada en Ubuntu que contiene varios archivos binarios y una imagen de Distroless. Las imágenes base de Distroless son imágenes de contenedor mínimas que priorizan la seguridad y la optimización de recursos, ya que solo incluyen componentes esenciales. Se reduce la superficie de ataque para ayudar a prevenir vulnerabilidades. Para obtener más información, consulta la documentación sobre la imagen de proxy de Distroless.

Compatibilidad con objetos binarios

Como práctica recomendada, debes restringir el contenido de un entorno de ejecución de un contenedor solo a los paquetes necesarios. Este enfoque mejora la seguridad y la relación entre las señales y el ruido de los analizadores de vulnerabilidades y riesgos comunes (CVE). La imagen de Sidecar de Distroless tiene un conjunto mínimo de dependencias, sin todos los ejecutables, las bibliotecas y las herramientas de depuración no esenciales. Por lo tanto, no es posible ejecutar un comando de shell ni usar curl, ping u otras utilidades de depuración, como kubectl exec, dentro del contenedor.

Haz que los clústeres sean compatibles con imágenes sin distribución

Quita de tu configuración las referencias a cualquier archivo binario no admitido (como bash o curl). En particular, dentro de los sondeos de preparación, inicio y funcionamiento, y los hooks de ciclo de vida PostStart y PreStop dentro de los contenedores istio-proxy, istio-init o istio-validation.
Considera alternativas como holdApplicationUntilProxyStarts para ciertos casos de uso.
Para la depuración, puedes usar contenedores efímeros para adjuntarlos a un Pod de carga de trabajo en ejecución. Luego, puedes inspeccionarlo y ejecutar comandos personalizados. Para ver un ejemplo, consulta Cómo recopilar registros de Cloud Service Mesh.

Si no encuentras una solución para tu caso de uso específico, comunícate con el Google Cloudequipo de asistencia en Obtén asistencia.

Migra a la puerta de enlace de entrada de Istio

En esta sección, se muestra cómo migrar a la puerta de enlace de entrada de Istio. Existen dos métodos para migrar a la puerta de enlace de entrada de Istio:

Migración por fases con división del tráfico

Este método prioriza la minimización de las interrupciones, ya que enviarás tráfico de forma incremental a la nueva puerta de enlace de Istio, lo que te permitirá supervisar su rendimiento en un pequeño porcentaje de solicitudes y revertir rápidamente si es necesario. Ten en cuenta que configurar la división del tráfico de la capa 7 puede ser un desafío para algunas aplicaciones, por lo que debes administrar ambos sistemas de puerta de enlace de forma simultánea durante la transición. Consulta Migración por fases con división del tráfico para conocer los pasos.
Migración directa

Este método implica redireccionar simultáneamente todo el tráfico a la nueva puerta de enlace de Istio una vez que hayas realizado pruebas exhaustivas. La ventaja de este enfoque es la separación completa de la infraestructura de la puerta de enlace anterior, lo que permite una configuración adaptable de la nueva puerta de enlace sin las limitaciones de la configuración existente. Sin embargo, existe un mayor riesgo de tiempo de inactividad en caso de que surjan problemas inesperados con la nueva puerta de enlace durante la transición. Consulta Migración directa para conocer los pasos.

En los siguientes ejemplos de migración, se supone que tienes un servicio HTTP (httpbin) que se ejecuta en el espacio de nombres de la aplicación (predeterminado) y que se expone de forma externa con la API de Gateway de Kubernetes. Las configuraciones pertinentes son las siguientes:

Puerta de enlace: k8-api-gateway (en el espacio de nombres istio-ingress), configurada para escuchar el tráfico HTTP en el puerto 80 para cualquier nombre de host que termine con .example.com.
HTTPRoute: httpbin-route (en el espacio de nombres default): Dirige cualquier solicitud HTTP con el nombre de host httpbin.example.com y una ruta que comienza con /get al servicio httpbin dentro del espacio de nombres default.
Se puede acceder a la aplicación httpbin con la IP externa 34.57.246.68.

Diagrama básico de la puerta de enlace

Migración por fases con división del tráfico

Aprovisiona una nueva puerta de enlace de entrada de Istio

Implementa una nueva puerta de enlace de entrada siguiendo los pasos de la sección Implementa una puerta de enlace de ejemplo y personaliza la configuración de ejemplo según tus requisitos. Los ejemplos del repositorio anthos-service-mesh están diseñados para implementar un servicio loadBalancer istio-ingressgateway y los pods ingress-gateway correspondientes.

Ejemplo de recurso de puerta de enlace (istio-ingressgateway.yaml)

 apiVersion: networking.istio.io/v1beta1
 kind: Gateway
 metadata:
   name: istio-api-gateway
   namespace: GATEWAY_NAMESPACE
 spec:
   selector:
     istio: ingressgateway  # The selector should match the ingress-gateway pod labels.
   servers:
   - port:
       number: 80
       name: http
       protocol: HTTP
     hosts:   # or specific hostnames if needed
     - "httpbin.example.com"

Aplica la configuración de Gateway para administrar el tráfico:
```
kubectl apply -f istio-ingressgateway.yaml -n GATEWAY_NAMESPACE
```
Asegúrate de que "spec.selector" en tu recurso de Gateway coincida con las etiquetas de tus Pods de ingress-gateway. Por ejemplo, si los Pods de ingress-gateway tienen la etiqueta istio=ingressgateway, la configuración de tu puerta de enlace también debe seleccionar esta etiqueta istio=ingressgateway.

Configura el enrutamiento inicial para la nueva puerta de enlace

Define las reglas de enrutamiento iniciales para tu aplicación con un VirtualService de Istio.

Ejemplo de VirtualService (my-app-vs-new.yaml):

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-vs
  namespace: APPLICATION_NAMESPACE
spec:
    gateways:
    - istio-ingress/istio-api-gateway  # Replace with <gateway-namespace/gateway-name>
    hosts:
    - httpbin.example.com
    http:
    - match:
      - uri:
          prefix: /get
      route:
      - destination:
          host: httpbin
          port:
            number: 8000

Aplica el VirtualService:

kubectl apply -f my-app-vs-new.yaml -n MY_APP_NAMESPACE

Accede al servicio de backend (httpbin) a través de la puerta de enlace de entrada de Istio recién implementada

Configura la variable de entorno Ingress Host en la dirección IP externa asociada con el balanceador de cargas istio-ingressgateway implementado recientemente:
```
export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
```
Verifica que se pueda acceder a la aplicación (httpbin) con la nueva puerta de enlace:
```
curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"
```
El resultado es similar al siguiente:
```
HTTP/1.1 200 OK
```

Flujo de solicitudes con la nueva puerta de enlace de entrada de Istio

Modifica el objeto Ingress existente para la división del tráfico

Después de confirmar que la nueva puerta de enlace (p. ej., istio-api-gateway) se configuró correctamente, puedes comenzar a enrutar una parte de tu tráfico a través de ella. Para ello, actualiza tu HTTPRoute actual para dirigir un pequeño porcentaje del tráfico a la nueva puerta de enlace, mientras que la mayor parte sigue usando la puerta de enlace existente (k8-api-gateway).

Abre el objeto HttpRoute para editarlo:

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

Agrega una nueva referencia de backend que apunte al servicio de balanceador de cargas de la nueva puerta de enlace de entrada con un peso inicial del 10% y actualiza el peso del backend de la puerta de enlace anterior.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: httpbin-route
  namespace: MY_APP_NAMESPACE  # your application's namespace
spec:
  parentRefs:
  - name: k8-api-gateway
    namespace: istio-ingress
  hostnames: ["httpbin.example.com"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /get
    backendRefs:
    - name: httpbin
      port: 8000
      weight: 90
    - name: istio-ingressgateway # Newly deployed load balancer service
      namespace: GATEWAY_NAMESPACE
      port: 80
      weight: 10

Otorga permiso para la referencia entre espacios de nombres con la concesión de referencia.

Para permitir que tu HTTPRoute en el espacio de nombres de la aplicación (predeterminado) acceda al servicio loadbalancer en el espacio de nombres de la puerta de enlace (istio-ingress), es posible que debas crear una concesión de referencia. Este recurso funciona como un control de seguridad, ya que define de forma explícita qué referencias entre espacios de nombres están permitidas.

El siguiente comando istio-ingress-grant.yaml describe un ejemplo de concesión de referencia:
```
apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: istio-ingressgateway-grant
  namespace: istio-ingress # Namespace of the referenced resource
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute 
    namespace: MY_APP_NAMESPACE # Namespace of the referencing resource
  to:
  - group: ""               # Core Kubernetes API group for Services
    kind: Service
    name: istio-ingressgateway # Loadbalancer Service of the new ingress gateway
```

Aplica el subsidio de referencia:

kubectl apply -f istio-ingress-grant.yaml -n GATEWAY_NAMESPACE

Verifica las solicitudes a la dirección IP externa existente (p. ej., 34.57.246.68) no fallan. El siguiente check-traffic-flow.sh describe una secuencia de comandos para verificar las fallas de solicitudes:

# Update the following values based on your application setup
external_ip="34.57.246.68" # Replace with existing external IP
url="http://$external_ip/get"
host_name="httpbin.example.com"

# Counter for successful requests
success_count=0

# Loop 50 times
for i in {1..50}; do
  # Perform the curl request and capture the status code
  status_code=$(curl -s -HHost:"$host_name" -o /dev/null -w "%{http_code}" "$url")
  # Check if the request was successful (status code 200)
  if [ "$status_code" -eq 200 ]; then
    ((success_count++))  # Increment the success counter
  else
    echo "Request $i: Failed with status code $status_code"
  fi
done

# After the loop, check if all requests were successful
if [ "$success_count" -eq 50 ]; then
  echo "All 50 requests were successful!"
else
  echo "Some requests failed.  Successful requests: $success_count"
fi

Ejecuta el script para confirmar que no fallan solicitudes, independientemente de la ruta de tráfico:
```
chmod +x check-traffic-flow.sh
./check-traffic-flow.sh
```

Flujo de solicitudes con división del tráfico entre la puerta de enlace existente y la nueva puerta de enlace de entrada de Istio

Aumenta lentamente el porcentaje de tráfico

Si no se observan errores de solicitud para la dirección IP externa existente (por ejemplo, 34.57.246.68), cambia gradualmente más tráfico a la nueva puerta de enlace de Istio Ingress ajustando los pesos del backend en tu HTTPRoute. Aumenta el peso de istio-ingressgateway y disminuye el peso de la puerta de enlace anterior en incrementos pequeños, como 10%, 20%, etcétera.

Usa el siguiente comando para actualizar tu HTTPRoute existente:

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

Migración completa del tráfico y eliminación de la puerta de enlace anterior

Cuando la nueva puerta de enlace de entrada de Istio demuestre un rendimiento estable y un procesamiento de solicitudes exitoso, transfiere todo el tráfico a ella. Actualiza tu HTTPRoute para establecer el peso del backend de la puerta de enlace anterior en 0 y el de la puerta de enlace nueva en 100.
Una vez que el tráfico se enrute por completo a la nueva puerta de enlace, actualiza tus registros DNS externos para el nombre de host de tu aplicación (por ejemplo, httpbin.example.com) de modo que apunten a la dirección IP externa del servicio de balanceador de cargas creado en Aprovisiona una nueva puerta de enlace de entrada de Istio.

Por último, borra la puerta de enlace anterior y sus recursos asociados:

kubectl delete gateway OLD_GATEWAY -n GATEWAY_NAMESPACE
kubectl delete service OLD_GATEWAY_SERVICE -n GATEWAY_NAMESPACE

Migración directa