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

Esta página se ha traducido con Cloud Translation API.

Actualizaciones de configuración para la modernización

En este documento se describen las actualizaciones de configuración que puede que tengas que hacer en tu malla de servicios de Cloud gestionada antes de modernizarla 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 el clúster para la modernización. Consulta cada sección para ver las instrucciones de actualización:

Multiclúster
Habilitar Workload Identity Federation para GKE
Habilitar CNI gestionado
Uso binario no estándar en Sidecar
Migrar a Istio Ingress Gateway

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

Migrar de secretos de Istio a multicluster_mode

No se admiten secretos de varios clústeres cuando un clúster usa el plano de control TRAFFIC_DIRECTOR. En este documento se describe cómo puedes modernizar tu configuración para pasar de usar secretos de varios clústeres de Istio a usar multicluster_mode.

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

El descubrimiento de endpoints multiclúster de Istio de código abierto funciona mediante el uso de istioctl u otras herramientas para crear un secreto de Kubernetes en un clúster. Este secreto permite que un clúster balancee la carga del tráfico a otro clúster de la malla. El plano de control de ISTIOD lee este secreto y empieza a enrutar el tráfico a ese otro clúster.

Cloud Service Mesh tiene una API declarativa para controlar el tráfico entre 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 fiable que crear secretos de Istio manualmente. Las futuras funciones de Cloud Service Mesh dependerán de la API declarativa y no podrás usar esas nuevas funciones directamente con los secretos de Istio. La API declarativa es la única forma de seguir adelante.

Si usas secretos de Istio, migra a la API declarativa lo antes posible. Ten en cuenta que el ajuste 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 puedes configurar para cada clúster a qué otro clúster debe dirigir el tráfico en la malla. Para ver una lista completa de las diferencias entre las funciones admitidas de la API declarativa y los secretos de Istio, consulta Funciones admitidas con las APIs de Istio.

Migrar de secretos de Istio a la API declarativa

Si has aprovisionado Cloud Service Mesh mediante la gestión automática con la API de la función de flota, no es necesario que sigas estas instrucciones. Estos pasos solo se aplican si has completado el proceso de incorporación con asmcli --managed.

Ten en cuenta que este proceso cambia los secretos que apuntan a un clúster. Durante este proceso, los endpoints se quitan y, a continuación, se vuelven a añadir. Entre el momento en que se quitan los endpoints y el momento en que se añaden, el tráfico volverá brevemente al enrutamiento local en lugar de al balanceo de carga a otros clústeres. Para obtener más información, consulta el problema de GitHub.

Para pasar de usar secretos de Istio a la API declarativa, sigue estos pasos. Sigue estos pasos al mismo tiempo o uno tras otro:

Habilita la API declarativa en cada clúster de la flota en la que quieras habilitar la detección de endpoints multiclúster configurando multicluster_mode=connected. Ten en cuenta que debes definir explícitamente multicluster_mode=disconnected si no quieres que se pueda detectar el clúster.

Usa el siguiente comando para habilitar la detección de endpoints multiclúster 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 endpoints en un clúster:
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"disconnected"}}'
```
Elimina secretos antiguos.

Después de configurar multicluster_mode=connected en tus clústeres, cada clúster tendrá un nuevo secreto generado para cada clúster que también tenga multicluster_mode=connected configurado. 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
```
También se aplicará la etiqueta istio.io/owned-by: mesh.googleapis.com a cada secreto.

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

Una vez que se haya migrado, comprueba las métricas de solicitudes para asegurarte de que se enrutan como se espera.

Habilitar Workload Identity Federation para GKE

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

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

Habilitar la federación de identidades de cargas de trabajo en clústeres

Comprueba que la federación de identidades de carga de trabajo esté habilitada en tu clúster. Para ello, asegúrate de que el clúster de GKE tenga configurado un grupo de federación de identidades de carga de trabajo, que es esencial para validar las credenciales de IAM.

Usa el siguiente comando para comprobar el grupo de identidades de carga de trabajo configurado en un clúster:
```
gcloud container clusters describe CLUSTER_NAME \
  --format="value(workloadIdentityConfig.workloadPool)"
```
Sustituye CLUSTER_NAME por el nombre de tu clúster de GKE. Si aún no has especificado una zona o una región predeterminada para gcloud, es posible que también tengas que especificar una marca --region o --zone al ejecutar este comando.
Si la salida está vacía, sigue las instrucciones de Actualizar un clúster para habilitar la identidad de carga de trabajo en los clústeres de GKE que ya tengas.

Habilitar la federación de identidades de carga de trabajo en grupos de nodos

Una vez que se haya habilitado Workload Identity Federation en un clúster, los grupos de nodos deben configurarse para usar el servidor de metadatos de GKE.

Lista 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
```
Sustituye CLUSTER_NAME por el nombre de tu clúster de GKE. Si aún no has especificado una zona o una región predeterminada para gcloud, es posible que también tengas que especificar una marca --region o --zone al ejecutar este comando.
Verifica que cada grupo de nodos esté usando el servidor de metadatos de GKE:
```
gcloud container node-pools describe NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --format="value(config.workloadMetadataConfig.mode)"
```
Haz los cambios siguientes:
- NODEPOOL_NAME con el nombre de tu nodepool.
- CLUSTER_NAME por el nombre de tu clúster de GKE.
Si el resultado no contiene GKE_METADATA, actualiza el grupo de nodos siguiendo la guía para actualizar un grupo de nodos.

Habilitar la interfaz de red de contenedor (CNI) gestionada

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

Información general sobre CNI gestionada

La interfaz de red de contenedores (CNI) gestionada es una implementación gestionada por Google de la CNI de Istio. El plugin CNI simplifica la red de pods configurando reglas de iptables. De esta forma, se habilita la redirección del tráfico entre aplicaciones y proxies de Envoy, lo que elimina la necesidad de tener permisos privilegiados para el init-container necesario para gestionar iptables.

El complemento CNI de Istio sustituye al contenedor istio-init. El contenedor istio-init se encargaba anteriormente de configurar el entorno de red del pod para habilitar la interceptación del tráfico del sidecar de Istio. El complemento CNI realiza la misma función de redirección de red, pero con la ventaja añadida de reducir la necesidad de privilegios elevados, lo que mejora la seguridad.

Por lo tanto, para mejorar la seguridad y la fiabilidad, y para simplificar la gestión y la resolución de problemas, se requiere CNI gestionado en todas las implementaciones de Managed Cloud Service Mesh.

Impacto en los contenedores init

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

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

El complemento CNI configura las interfaces de red de los pods, asigna IPs de pods y redirige el tráfico al proxy sidecar de Istio, que aún no se ha iniciado.
Todos los contenedores de inicialización se ejecutan y se completan.
El proxy 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, las solicitudes de red de los contenedores init pueden descartarse o redirigirse incorrectamente. Esto se debe a que el proxy sidecar de Istio, que gestiona el tráfico de red del pod, no se está ejecutando cuando se realizan las solicitudes. Para obtener más información, consulta la documentación de Istio CNI.

Habilita CNI gestionado en el clúster

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

Elimina las dependencias de red de tu contenedor init. Plantéate usar las siguientes alternativas:
- Modificar la lógica o los contenedores de la aplicación: puedes modificar tus servicios para eliminar la dependencia de los contenedores init que requieren solicitudes de red o realizar operaciones de red en los contenedores de tu aplicación después de que se haya iniciado el proxy sidecar.
- Usa ConfigMaps o secretos de Kubernetes: almacena los datos de configuración obtenidos por la solicitud de red en ConfigMaps o secretos de Kubernetes y móntalos en los contenedores de tu aplicación. Para ver otras soluciones, consulta la documentación de Istio.
Habilita CNI gestionado en el clúster:
1. Haz los siguientes cambios en la configuración:
  1. Ejecuta el siguiente comando para localizar el archivo controlPlaneRevision.
```
kubectl get controlplanerevision -n istio-system
```
  2. En el recurso personalizado (RC) ControlPlaneRevision (CPR), defina la etiqueta mesh.cloud.google.com/managed-cni-enabled como true.
```
kubectl label controlplanerevision CPR_NAME \
    -n istio-system mesh.cloud.google.com/managed-cni-enabled=true \
    --overwrite
```
    Sustituye CPR_NAME por el valor de la columna NAME de la salida del paso anterior.
  3. En el ConfigMap asm-options, defina el valor de ASM_OPTS en CNI=on.
```
kubectl patch configmap asm-options -n istio-system \
    -p '{"data":{"ASM_OPTS":"CNI=on"}}'
```
  4. En el recurso personalizado (RC) ControlPlaneRevision (CPR), defina la etiqueta mesh.cloud.google.com/force-reprovision como 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 debe usarse en 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. Comprueba 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
```
  Sustituye FLEET_PROJECT_ID por el ID de tu proyecto de Fleet Host. 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. Prueba a esperar unos minutos y vuelve a ejecutar el comando.
3. Cuando el controlPlaneManagement.state sea Active en el estado de la función del clúster, reinicia los pods.

Dejar de usar el formato binario 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 sin distribución.

Imágenes de sidecar de proxy Envoy sin distribución

Cloud Service Mesh usa dos tipos de imágenes de sidecar de proxy de Envoy en función de la configuración del plano de control, la imagen basada en Ubuntu que contiene varios archivos binarios y la imagen sin distribución. 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 los componentes esenciales. La superficie de ataque se reduce para evitar vulnerabilidades. Para obtener más información, consulta la documentación sobre la imagen de proxy sin distribución.

Compatibilidad binaria

Como práctica recomendada, solo debes incluir en el contenido de un tiempo de ejecución de contenedor los paquetes necesarios. Este enfoque mejora la seguridad y la relación señal/ruido de los escáneres de vulnerabilidades y exposiciones comunes (CVE). La imagen de Sidecar sin distribución tiene un conjunto mínimo de dependencias, sin 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 u otras utilidades de depuración, como kubectl exec, dentro del contenedor.

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

Elimina de tu configuración las referencias a los archivos binarios no admitidos (como bash o curl). En concreto, en las sondas de preparación, inicio y vivacidad, así como en los hooks de PostStart y PreStop del ciclo de vida de los contenedores istio-proxy, istio-init o istio-validation.
En algunos casos prácticos, puedes usar alternativas como holdApplicationUntilProxyStarts.
Para depurar, puedes usar contenedores efímeros para conectarte a un pod de carga de trabajo en ejecución. Después, puedes inspeccionarlo y ejecutar comandos personalizados. Por ejemplo, consulta Recoger registros de Cloud Service Mesh.

Si no encuentras una solución para tu caso de uso específico, ponte en contacto con el equipo de Asistencia a través de la sección Obtener asistencia. Google Cloud

Migrar a Istio Ingress Gateway

En esta sección se explica cómo migrar a Istio Ingress Gateway. Hay dos métodos para migrar a Istio Ingress Gateway:

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

Este método prioriza minimizar las interrupciones, por lo que enviarás tráfico de forma incremental a la nueva pasarela de Istio, lo que te permitirá monitorizar su rendimiento en un pequeño porcentaje de solicitudes y volver rápidamente a la versión anterior si es necesario. Ten en cuenta que configurar la división del tráfico de la capa 7 puede ser complicado para algunas aplicaciones, por lo que debes gestionar ambos sistemas de gateway simultáneamente durante la transición. Para ver los pasos, consulta Migración gradual con división del tráfico.
Migración directa

Este método consiste en redirigir simultáneamente todo el tráfico a la nueva puerta de enlace de Istio una vez que hayas realizado las pruebas pertinentes. La ventaja de este enfoque es la separación completa de la infraestructura de la antigua pasarela, lo que permite configurar la nueva pasarela de forma flexible sin las limitaciones de la configuración actual. Sin embargo, hay un mayor riesgo de que se produzca un tiempo de inactividad si surgen problemas inesperados con la nueva pasarela durante la transición. Consulta los pasos en Migración directa.

En los siguientes ejemplos de migración se da por hecho que tienes un servicio HTTP (httpbin) que se ejecuta en el espacio de nombres de la aplicación (predeterminado) y que se expone externamente mediante la API Gateway de Kubernetes. Las configuraciones pertinentes son las siguientes:

Pasarela: k8-api-gateway (en el espacio de nombres istio-ingress). Se ha configurado para escuchar el tráfico HTTP en el puerto 80 de cualquier nombre de host que termine en .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 empiece por /get al servicio httpbin del espacio de nombres default.
Se puede acceder a la aplicación httpbin mediante la IP externa 34.57.246.68.

Diagrama de pasarela básica

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

Aprovisionar una nueva pasarela de entrada de Istio

Implementa una nueva pasarela Ingress siguiendo los pasos de la sección Implementar pasarela de ejemplo y personaliza las configuraciones de ejemplo según tus requisitos. Las muestras del repositorio anthos-service-mesh están diseñadas para desplegar un servicio istio-ingressgateway LoadBalancer y los pods ingress-gateway correspondientes.

Recurso de pasarela de ejemplo (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 gestionar el tráfico:
```
kubectl apply -f istio-ingressgateway.yaml -n GATEWAY_NAMESPACE
```
Asegúrate de que el campo "spec.selector" de tu recurso Gateway coincida con las etiquetas de tus pods ingress-gateway. Por ejemplo, si los pods ingress-gateway tienen la etiqueta istio=ingressgateway, tu configuración de Gateway también debe seleccionar la etiqueta istio=ingressgateway.

Configurar el enrutamiento inicial de la nueva pasarela

Define las reglas de enrutamiento iniciales de tu aplicación mediante 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

Acceder al servicio de backend (httpbin) a través de la instancia de Istio Ingress Gateway recién implementada

Asigna a la variable de entorno Ingress Host la dirección IP externa asociada al balanceador de carga istio-ingressgateway que has implementado recientemente:
```
export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
```
Verifica que se puede acceder a la aplicación (httpbin) mediante la nueva pasarela:
```
curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"
```
La salida es similar a la siguiente:
```
HTTP/1.1 200 OK
```

Flujo de solicitudes con la nueva pasarela de entrada de Istio

Modificar un Ingress para dividir el tráfico

Después de confirmar que la configuración de la nueva pasarela (por ejemplo, istio-api-gateway) se ha realizado correctamente, puedes empezar a enrutar una parte de tu tráfico a través de ella. Para ello, actualiza tu HTTPRoute para dirigir un pequeño porcentaje del tráfico a la nueva pasarela, mientras que la mayor parte sigue usando la pasarela actual (k8-api-gateway).

Abre la ruta http para editarla:

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

Añade una nueva referencia de backend que apunte al servicio de balanceador de carga de la nueva Ingress Gateway con un peso inicial del 10% y actualiza el peso del backend de la antigua gateway.

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

Concede permiso para hacer referencia entre espacios de nombres con ReferenceGrant.

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 pasarela (istio-ingress), puede que tengas que crear una concesión de referencia. Este recurso sirve como control de seguridad, ya que define explícitamente qué referencias entre espacios de nombres se permiten.

A continuación, se istio-ingress-grant.yamldescribe 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 la concesión de referencia:

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

Verificar las solicitudes a una dirección IP externa ya creada (por ejemplo, 34.57.246.68) no falla. El siguiente check-traffic-flow.sh describe una secuencia de comandos para comprobar los errores de 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 produce ningún error en las solicitudes, independientemente de la ruta del tráfico:
```
chmod +x check-traffic-flow.sh
./check-traffic-flow.sh
```

Flujo de solicitudes con tráfico dividido entre la pasarela y la nueva pasarela de entrada de Istio

Aumentar lentamente el porcentaje de tráfico

Si no se detectan errores en las solicitudes de la dirección IP externa actual (por ejemplo, 34.57.246.68), transfiere gradualmente más tráfico a la nueva puerta de enlace de entrada de Istio ajustando los pesos del backend en tu HTTPRoute. Aumenta el peso de istio-ingressgateway y disminuye el peso de la antigua pasarela en pequeños incrementos, como el 10%, el 20%, etc.

Usa el siguiente comando para actualizar tu HTTPRoute:

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

Migración completa del tráfico y eliminación de la antigua pasarela

Cuando la nueva Istio Ingress Gateway demuestre un rendimiento estable y gestione las solicitudes correctamente, transfiere todo el tráfico a ella. Actualiza tu HTTPRoute para asignar el valor 0 al peso del backend de la antigua pasarela y el valor 100 al de la nueva.
Una vez que el tráfico se haya enrutado por completo a la nueva pasarela, actualice los registros DNS externos del nombre de host de su aplicación (por ejemplo, httpbin.example.com) para que apunten a la dirección IP externa del servicio de balanceador de carga creado en Aprovisionar una nueva pasarela de entrada de Istio.

Por último, elimina la antigua pasarela y sus recursos asociados:

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

Migración directa