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 es posible que debas realizar en tu Cloud Service Mesh administrado antes de modernizar tu malla al plano de control TRAFFIC_DIRECTOR desde el plano de control ISTIOD.

A continuación, se muestra 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:

Varios clústeres
Habilita la federación de identidades para cargas de trabajo para GKE
Habilita la CNI administrada
Uso de objetos binarios 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 secretos de varios clústeres no son compatibles cuando un clúster usa el plano de control TRAFFIC_DIRECTOR. En este documento, se describe cómo puedes modernizarte del uso de secretos de varios clústeres de Istio al uso de multicluster_mode.

Descripción general de los secretos de Istio en comparación con las APIs declarativas

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

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

Si usas Istio Secrets, migra a la API declarativa lo antes posible. Ten en cuenta que la configuración de multicluster_mode dirige a cada clúster a dirigir el tráfico a todos los demás clústeres de la malla. El uso de secretos permite una configuración más flexible, lo 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.

Cómo migrar de los secretos de Istio a la API declarativa

Si aprovisionaste Cloud Service Mesh con la administración automática con la API de funciones de flota, no necesitas seguir 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, los extremos se quitan y, luego, se vuelven a agregar. Entre los extremos que se quitan y se agregan, el tráfico volverá brevemente al enrutamiento local en lugar de balancear la carga en otros clústeres. Para obtener más información, consulta el problema de GitHub.

Para pasar del uso de secretos de Istio a la API declarativa, sigue estos pasos. Ejecuta estos pasos al mismo tiempo o en rápida sucesión:

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 configurar multicluster_mode=disconnected de forma explícita si no deseas que el clúster sea detectable.

Usa el siguiente comando para habilitar un clúster para el descubrimiento de extremos de varios clústeres:
```
 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 clúster tendrá un secreto nuevo generado para todos 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
```
A cada secreto también se le aplicará la etiqueta istio.io/owned-by: mesh.googleapis.com.

Una vez que se creen los secretos nuevos, puedes borrar los secretos que se hayan creado de forma manual con istioctl create-remote-secret:
```
kubectl delete secret SECRET_NAME -n istio-system
```

Una vez que se hayan migrado, verifica las métricas de solicitud para asegurarte de que se enruten como se espera.

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 Google Cloud servicios como Compute Engine, BigQuery y las APIs de Machine Learning. 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 la cuenta de servicio, porque usa políticas de IAM. Para obtener más detalles sobre Workload Identity Federation, 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 los clústeres

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

Usa el siguiente comando para verificar el grupo de identidades para cargas de trabajo configurado 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 que se indican en Cómo actualizar un clúster existente para habilitar la identidad de cargas de trabajo en los clústeres de GKE existentes.

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 usar el servidor de metadatos de GKE.

Muestra una lista de todos los grupos de nodos de un clúster estándar. 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 Cómo actualizar un grupo de nodos existente.

Habilita la interfaz de red de contenedor (CNI) administrada

En esta sección, se te guiará para 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 administrada (CNI) es una implementación de la CNI de Istio administrada por Google. El complemento CNI optimiza las redes de los pods configurando reglas de iptables. Esto permite la redirección de tráfico entre aplicaciones y proxies de Envoy, lo que elimina la necesidad de permisos de privilegio para el contenedor de init necesario 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 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 resolución de problemas, se requiere CNI administrado en todas las implementaciones de Cloud Service Mesh administradas.

Impacto en los contenedores de init

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

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

El complemento de CNI configura las interfaces de red del pod, asigna las IP del pod y redirecciona el tráfico al proxy de sidecar de Istio, que aún no se inició.
Se ejecutan y completan todos los contenedores init.
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 desvíen 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 de CNI de Istio.

Habilita la CNI administrada para tu clúster

Sigue los pasos que se indican en esta sección para habilitar CNI administrado en tu clúster.

Quita las dependencias de red de tu contenedor de init. 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 inicie el proxy de sidecar.
- Usa ConfigMaps o secretos de Kubernetes: Almacena los datos de configuración que recupera la solicitud de red en ConfigMaps o secretos de Kubernetes y actívalos en los contenedores de tu aplicación. Para conocer 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 de host de flota. Por lo general, FLEET_PROJECT_ID tiene el mismo nombre que el proyecto.
  - Verifica que se haya quitado la condición MANAGED_CNI_NOT_ENABLED 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.

Se dejó de usar el uso de objetos 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 tu configuración del plano de control: una imagen basada en Ubuntu que contiene varios objetos binarios y una imagen 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. La superficie de ataque se reduce para ayudar a prevenir vulnerabilidades. Para obtener más información, consulta la documentación sobre la imagen de proxy sin distribución.

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 sin distribución tiene un conjunto mínimo de dependencias, despojado de todos los ejecutables, bibliotecas y herramientas de depuración no esenciales. Por lo tanto, no es posible ejecutar un comando de shell ni usar curl, ping ni 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 la configuración las referencias a cualquier objeto binario no admitido (como bash o curl). En particular, dentro de los sondeos de preparación, inicio y funcionamiento, y los hooks de PostStart y PreStop del ciclo de vida 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 conectarte 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 Cloud equipo 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 en las que enviarás el 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 de tráfico para conocer los pasos.
Migración directa

Este método implica redireccionar 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 la configuración adaptable de la puerta de enlace nueva 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 Kubernetes Gateway. Las configuraciones relevantes son las siguientes:

Puerta de enlace: k8-api-gateway (en el espacio de nombres istio-ingress), configurado para detectar 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 que se indican en la sección Implementa una puerta de enlace de ejemplo y personaliza las configuraciones de muestra según tus requisitos. Los ejemplos del repositorio anthos-service-mesh están diseñados para implementar un servicio de balanceador de cargas 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 Puerta de enlace para administrar el tráfico:
```
kubectl apply -f istio-ingressgateway.yaml -n GATEWAY_NAMESPACE
```
Asegúrate de que "spec.selector" en tu recurso de puerta de enlace coincida con las etiquetas de tus pods ingress-gateway. Por ejemplo, si los pods ingress-gateway tienen la etiqueta istio=ingressgateway, la configuración de la puerta de enlace también debe seleccionar esta etiqueta.istio=ingressgateway

Configura el enrutamiento inicial de la nueva puerta de enlace

Define las reglas de enrutamiento iniciales de 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 del host de Ingress en la dirección IP externa asociada con el balanceador de cargas istio-ingressgateway que se implementó 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 Ingress existente para la división del tráfico

Después de confirmar que la nueva puerta de enlace se configuró correctamente (p. ej., istio-api-gateway), 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 parte más grande sigue usando la puerta de enlace existente (k8-api-gateway).

Abre 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 el otorgamiento 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 un otorgamiento de referencia. Este recurso funciona como un control de seguridad y define de forma explícita qué referencias entre espacios de nombres se permiten.

En el siguiente istio-ingress-grant.yaml, se describe un ejemplo de subvenció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 la concesión 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. En el siguiente check-traffic-flow.sh, se describe una secuencia de comandos para verificar las fallas de la solicitud:

# 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 la secuencia de comandos para confirmar que no se produzcan errores en las solicitudes, independientemente de la ruta de tráfico:
```
chmod +x check-traffic-flow.sh
./check-traffic-flow.sh
```

Flujo de solicitudes con división de 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 fallas de solicitud para la dirección IP externa existente (por ejemplo, 34.57.246.68), ajusta las ponderaciones del backend en tu HTTPRoute para transferir gradualmente más tráfico a la nueva puerta de enlace de Ingress de Istio. Aumenta el peso de istio-ingressgateway y disminuye el peso de la puerta de enlace anterior en incrementos pequeños, como el 10%, el 20% y así sucesivamente.

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 manejo correcto de las solicitudes, cambia 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 los registros DNS externos del nombre de host de tu aplicación (por ejemplo, httpbin.example.com) para 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