IBM Cloud Docs
Exposición de apps con rutas en Red Hat OpenShift 4

Exposición de apps con rutas en Red Hat OpenShift 4

Exponga servicios en su clúster de Red Hat® OpenShift® on IBM Cloud® en la dirección IP externa del direccionador mediante una ruta.

Esta información es para clústeres que ejecutan Red Hat OpenShift versión 4.

¿No está seguro de si debe utilizar rutas de Red Hat OpenShift o Ingress? Consulte el tema sobre Elección entre soluciones de equilibrio de carga.

Visión general

Por defecto, se despliega un controlador de entrada Red Hat OpenShift en su clúster que funciona como punto final de entrada para el tráfico de red externo.

Puede utilizar el controlador Red Hat OpenShift Ingress para crear rutas para sus aplicaciones. A las rutas se les asigna un nombre de host de acceso público o privado desde el subdominio del controlador de Ingress que los clientes externos pueden utilizar para enviar solicitudes a la aplicación. Puede elegir crear rutas no seguras o seguras utilizando el certificado TLS del controlador de Ingress para proteger su nombre de host. Cuando la solicitud externa llega al nombre de host, el controlador de Ingress ejecuta el proxy en la solicitud y la envía a la dirección IP privada donde escucha la aplicación.

El tipo de controlador de Ingress que se crea de forma predeterminada varía en función del proveedor de infraestructura del clúster y de la configuración de punto final de servicio.

  • Clústeres clásicos / clústeres VPC con punto final de servicio de nube pública: Su clúster se crea con un controlador de entrada público de forma predeterminada. El controlador de Ingress asigna rutas de acceso público para sus aplicaciones y escucha las solicitudes en sus aplicaciones en la interfaz de red de host pública. Cuando se recibe una solicitud, el controlador de Ingress dirige la solicitud a la dirección IP privada donde escucha la aplicación. Si prefiere exponer de forma privada sus aplicaciones, primero debe crear un controlador de Ingress privado y, a continuación, crear rutas privadas.
  • Clústeres VPC sólo con punto final de servicio de nube privada: Su clúster se crea con un controlador de entrada privado de forma predeterminada. El controlador de Ingress asigna rutas de acceso privado para sus aplicaciones y escucha en la interfaz de red de host privada. Solo los clientes que están conectados a su red de VPC privada pueden acceder a apps que están expuestas por una ruta privada. Si prefiere exponer de forma pública sus aplicaciones, primero debe crear un controlador de Ingress público y, a continuación, crear rutas públicas.

Si tiene un clúster multizona, se despliega un controlador de Ingress de alta disponibilidad en el clúster y se crea un servicio de controlador de Ingress en cada zona. Se necesitan dos nodos de trabajador por zona para que las dos réplicas del controlador de Ingress se puedan desplegar y actualizar correctamente. Tenga en cuenta que el servicio de controlador de Ingress en la primera zona donde tiene nodos de trabajador siempre se denomina router-default, y los servicios de controlador de Ingress en las zonas que se añaden posteriormente al clúster tienen nombres como, por ejemplo, router-dal12.

  • Para ver los servicios del controlador de Ingress en cada zona del clúster, ejecute oc get svc -n openshift-ingress.
  • Para ver el subdominio de controlador de Ingress del clúster y las direcciones IP del servicio de controlador de Ingress en cada zona, ejecute ibmcloud oc nlb-dns ls -c <cluster_name_or_ID> y busque el subdominio formateado como <cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud.

En el panel de control de la infraestructura de VPC, el equilibrador de carga de VPC solo notifica como correctos los dos nodos de trabajador que ejecutan los pods de réplica del controlador de Ingress, porque estos nodos de trabajador se configuran como escuchas para el equilibrador de carga de VPC. Aunque sólo los nodos trabajadores de escucha se notifican como en buen estado, Red Hat OpenShift on IBM Cloud mantiene actualizada la agrupación de fondo de nodos trabajadores de los escuchas, de forma que todos los nodos trabajadores del clúster pueden seguir recibiendo solicitudes del equilibrador de carga de VPC.

Flujo del tráfico en un clúster clásico de una sola zona

El diagrama siguiente muestra cómo un direccionador dirige el tráfico de red desde Internet a una aplicación en un clúster clásico de una sola zona.

Expose an app in a single-zone Red Hat OpenShift cluster by using a
una aplicación en un clúster de una sola zona utilizando un

  1. Una solicitud a la app utiliza el nombre de host de ruta que ha configurado para la app.

  2. Un servicio DNS resuelve el subdominio en la dirección IP pública portátil del servicio de direccionador.

  3. El direccionador recibe la solicitud y la reenvía a la dirección IP privada del pod de la app a través de la red privada. La dirección IP de origen del paquete de la solicitud se cambia por la dirección IP pública del nodo trabajador en el que se ejecuta el pod del direccionador. Si se despliegan varias instancias de la app en el clúster, el direccionador direcciona las solicitudes entre los pods de app.

  4. Cuando la app devuelve un paquete de respuesta, utiliza la dirección IP del nodo trabajador donde está el direccionador que ha reenviado la solicitud de cliente. Luego el direccionador envía el paquete de respuesta al cliente a través del equilibrador de carga.

Flujo del tráfico en un clúster clásico multizona

El diagrama siguiente muestra cómo un direccionador dirige el tráfico de red desde Internet a una aplicación en un clúster clásico multizona.

Exponer una aplicación en un clúster Red Hat OpenShift multizona utilizando un
una aplicación en un clúster multizona utilizando un

  1. Una solicitud a la app utiliza el nombre de host de ruta que ha configurado para la app.

  2. Un servicio DNS resuelve el subdominio de direccionador en la dirección IP pública portátil de un servicio de direccionador marcado como en buen estado por el equilibrador de carga multizona (MZLB). MZLB comprueba continuamente las direcciones IP públicas portátiles de los servicios que exponen el direccionador en cada zona del clúster. Los servicios de direccionador de las distintas zonas gestionan las solicitudes en un ciclo en rueda.

  3. En función de la dirección IP resuelta del servicio direccionador, el direccionador recibe la solicitud.

  4. El direccionador reenvía la solicitud a la dirección IP privada del pod de la app a través de la red privada. La dirección IP de origen del paquete de la solicitud se cambia por la dirección IP pública del nodo trabajador en el que se ejecuta el pod del direccionador. Cada direccionador envía las solicitudes a las instancias de la app en su propia zona y a las instancias de la app en otras zonas. Además, si se despliegan varias instancias de la app en una zona, el direccionador alterna las solicitudes entre pods de la app.

  5. Cuando la app devuelve un paquete de respuesta, utiliza la dirección IP del nodo trabajador donde está el direccionador que ha reenviado la solicitud de cliente. Luego el direccionador envía el paquete de respuesta al cliente a través del equilibrador de carga.

Flujo de tráfico en un clúster de VPC multizona con un punto final de servicio en la nube público

Cuando se crea un clúster de VPC multizona con el punto final de servicio de nube pública habilitado, se crea un controlador de Ingress público de forma predeterminada. El controlador de Ingress asigna rutas de acceso público para sus aplicaciones y escucha las solicitudes en sus aplicaciones en la interfaz de red de host pública.

El diagrama siguiente muestra cómo un controlador de Ingress dirige el tráfico de red desde Internet a una aplicación en un clúster de VPC multizona.

Exponer una aplicación en un clúster VPC multizona mediante un " caption-side="bottom"}{: caption="IngressExponer una aplicación en un clúster VPC multizona mediante un controlador Ingress

  1. Una solicitud a la app utiliza el nombre de host de ruta que ha configurado para la app.

  2. Un servicio DNS resuelve el subdominio de ruta en el nombre de host del equilibrador de carga de VPC que se asigna a los servicios para el controlador de Ingress. En los clústeres de VPC, las direcciones IP externas de los servicios del controlador Ingress son flotantes y se mantienen detrás de un nombre de host asignado por VPC.

  3. El equilibrador de carga de VPC resuelve el nombre de host de VPC en una dirección IP externa disponible de un servicio de controlador de Ingress que se ha notificado como con un estado correcto. El equilibrador de carga de VPC comprueba continuamente las direcciones IP externas de los servicios que exponen el controlador de Ingress en cada zona del clúster.

  4. Basándose en la dirección IP resuelta, el equilibrador de carga de VPC envía la solicitud a un servicio de controlador de Ingress.

  5. El controlador de Ingress reenvía la solicitud a la dirección IP privada del pod de aplicación a través de la red privada. La dirección IP de origen del paquete de solicitud se cambia por la dirección IP del nodo de trabajador donde se ejecuta el pod del controlador de Ingress. Cada controlador de Ingress envía solicitudes a las instancias de aplicación en su propia zona y a las instancias de aplicación en otras zonas. Adicionalmente, si se despliegan varias instancias de aplicación en una zona, el controlador de Ingress alterna las solicitudes entre los pods de aplicación.

  6. Cuando la aplicación devuelve un paquete de respuesta, utiliza la dirección IP del nodo de trabajador donde existe el controlador de Ingress que reenvió la solicitud de cliente. A continuación, el controlador de Ingress envía al cliente el paquete de respuesta a través del equilibrador de carga de VPC.

Flujo de tráfico en un clúster de VPC multizona con solo un punto final de servicio en la nube privado

Cuando se crea un clúster de VPC multizona con solo el punto final de servicio de nube privada, se crea un controlador de Ingress privado de forma predeterminada. El controlador de Ingress asigna rutas de acceso privado para sus aplicaciones y escucha en la interfaz de red de host privada. Solo los clientes que están conectados a su red de VPC privada pueden acceder a apps que están expuestas por una ruta privada.

El diagrama siguiente muestra cómo un controlador de Ingress dirige el tráfico de red desde redes privadas a una aplicación en un clúster de VPC multizona.

Exponer una aplicación en un clúster VPC privado y multizona mediante un " caption-side="bottom"}{: caption="una aplicación en un clúster VPC privado y multizona mediante un controlador Ingress*

  1. Un cliente que está conectado a su red privada de VPC envía una solicitud a su app utilizando la ruta privada de la app. Por ejemplo, puede utilizar la VPN de Virtual Private Cloud, IBM Cloud Transit Gateway o IBM Cloud Direct Link para permitir solicitudes desde una red en local, desde otra VPC o desde la infraestructura clásica de IBM Cloud hacia apps que se ejecuten en su clúster.

  2. Un servicio DNS resuelve el subdominio de ruta en el nombre de host del equilibrador de carga de VPC que se asigna a los servicios para el controlador de Ingress. En los clústeres de VPC, las direcciones IP de los servicios del controlador de Ingress son flotantes y se mantienen detrás de un nombre de host asignado por VPC. Recuerde que aunque el registro de DNS del subdominio de la ruta está registrado en el sistema DNS público, se puede acceder a los servidores de resolución de DNS desde la VPC.

  3. El equilibrador de carga de VPC privado resuelve el nombre de host de VPC en una dirección IP privada disponible de un servicio de controlador de Ingress que se ha notificado como un estado correcto. El equilibrador de carga de VPC comprueba continuamente las direcciones IP de los servicios que exponen el controlador de Ingress en cada zona del clúster.

  4. Basándose en la dirección IP resuelta, el equilibrador de carga de VPC envía la solicitud a un servicio de controlador de Ingress.

  5. El controlador de Ingress reenvía la solicitud a la dirección IP privada del pod de aplicación a través de la red privada. La dirección IP de origen del paquete de solicitud se cambia por la dirección IP del nodo de trabajador donde se ejecuta el pod del controlador de Ingress. Cada controlador de Ingress envía solicitudes a las instancias de aplicación en su propia zona y a las instancias de aplicación en otras zonas. Adicionalmente, si se despliegan varias instancias de aplicación en una zona, el controlador de Ingress alterna las solicitudes entre los pods de aplicación.

  6. Cuando la aplicación devuelve un paquete de respuesta, utiliza la dirección IP del nodo de trabajador donde existe el controlador de Ingress que reenvió la solicitud de cliente. A continuación, el controlador de Ingress envía el paquete de respuesta a través del equilibrador de carga de VPC y a través de IBM Cloud VPC VPN, Transit Gateway o Direct Link al cliente.

Tipos de rutas y terminación TLS

Red Hat OpenShift ofrece cuatro tipos de rutas en función del tipo de terminación TLS que requiera la app. Se da soporte a cada tipo de ruta para rutas públicas y privadas.

Tipos de rutas en función de la terminación TLS
Tipo de ruta Caso de uso
Simple Si no necesita el cifrado TLS, cree una ruta simple para manejar el tráfico HTTP no cifrado.
Paso a través Cuando desea que las conexiones TLS pasen del cliente al pod de la app de forma ininterrumpida, cree una ruta de paso a través. El direccionador no interviene en la terminación de TLS para el tráfico HTTPS cifrado, por lo que el pod de la app debe terminar la conexión TLS. Este tipo también se puede utilizar para puntos finales HTTP/2 y para TLS no HTTP.
Edge Cuando el pod de app se exponga en un punto final HTTP no cifrado, pero deba gestionar tráfico HTTPS cifrado, cree una ruta de extremo. La conexión TLS entre el cliente y el servicio de direccionador se termina, y la conexión entre el servicio de direccionador y el pod de la app no está cifrada. Para obtener más información, consulte la documentación de la ruta de borde de Internet(Red Hat OpenShift ).
Recifrada Cuando el pod de app se exponga en un punto final de HTTPS cifrado y deba gestionar el tráfico HTTPS, cree una ruta recifrada. La conexión TLS entre el cliente y el servicio de direccionador se termina, y se crea una nueva conexión entre el servicio de direccionador y el pod de la app. Para obtener más información, consulte la documentación de la ruta de recodificación de Red Hat OpenShift.

Si no necesita utilizar un dominio personalizado, puede utilizar un nombre de host de ruta proporcionado por IBMcon el formato <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud.

Comprobaciones de estado del controlador de Ingress

Permita el acceso a través de políticas de red u otras reglas de cortafuegos para que los servicios de controlador de Ingress sean accesibles para la comprobación de estado del controlador de Ingress.

Clásico: Si utiliza las políticas de red pre-DNAT de Calico u otro cortafuegos personalizado para bloquear el tráfico entrante a su clúster, debe permitir el acceso entrante en el puerto 443 desde las direcciones IP de origen del monitor de salud del dominio de Ingress a las direcciones IP de sus servicios de Ingress Controller, para que el proveedor del dominio pueda monitorizar la salud de las direcciones registradas y devolver sólo los endpoints sanos.

VPC: Si configura grupos de seguridad VPC o listas de control de acceso(ACL)VPC para proteger su red de clúster, asegúrese de que permite el acceso entrante en el puerto 443 desde las direcciones IP de origen del monitor de salud del dominio de Ingress a las direcciones IP de sus servicios de Ingress Controller, de modo que el proveedor de dominio pueda monitorizar la salud de las direcciones registradas y devolver sólo endpoints sanos.

Configuración de rutas públicas

Utilice un controlador de Ingress público para exponer las aplicaciones en el clúster.

El método para configurar rutas públicas varía en función del proveedor de la infraestructura del clúster y de la configuración del punto final de servicio.

Configuración de rutas públicas en clústeres clásicos o en clústeres de VPC con un punto final de servicio en la nube público

Si su clúster se ha creado en una infraestructura clásica, o si su clúster se ha creado en una infraestructura VPC y ha activado el punto final del servicio de nube pública durante la creación del clúster, su clúster se creará con un controlador de entrada público de forma predeterminada. Puede utilizar este controlador de Ingress para crear rutas públicas para su aplicación.

  1. Cree un servicio ClusterIP de Kubernetes para el despliegue de la app. El servicio proporciona una dirección IP interna para la aplicación a la que el controlador de Ingress puede enviar tráfico.

    oc expose deploy <app_deployment_name> --name my-app-svc
    
  2. Elija un dominio para la app. Tenga en cuenta que las URL de ruta deben tener 130 caracteres o menos IBM-dominio proporcionado: Si no necesita utilizar un dominio personalizado, se le generará un nombre de host de ruta con el formato <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud. Dominio personalizado: para especificar un dominio personalizado, trabaje con el proveedor de DNS o con IBM Cloud® Internet Services.

    1. Obtenga la dirección IP pública para del servicio de controlador de Ingress público en cada zona de la columna EXTERNAL-IP. Tenga en cuenta que el servicio de controlador de Ingress en la primera zona donde tiene nodos de trabajador siempre se denomina router-default, y los servicios de controlador de Ingress en las zonas que se añaden posteriormente al clúster tienen nombres como, por ejemplo, router-dal12.

      oc get svc -n openshift-ingress
      
    2. Cree un dominio personalizado con el proveedor de DNS. Si desea utilizar el mismo subdominio para varios servicios del clúster, puede registrar un subdominio comodín, como por ejemplo *.example.com.

    3. Correlacione el dominio personalizado con la dirección IP pública del controlador de Ingress añadiendo la dirección IP como un registro A.

  3. Configure una ruta que se base en el tipo de terminación TLS que necesita la app. Si no tiene un dominio personalizado, no incluya la opción --hostname. Se genera un nombre de host de ruta con el formato <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud. Si ha registrado un subdominio comodín, especifique un subdominio exclusivo en cada ruta que cree. Por ejemplo, puede especificar --hostname svc1.example.com en esta ruta y --hostname svc2.example.com en otra ruta.

    • Simple:
      oc expose service <app_service_name> [--hostname <subdomain>]
      
    • Paso a través:
      oc create route passthrough --service <app_service_name> [--hostname <subdomain>]
      
      ¿Necesita gestionar conexiones HTTP/2? Después de crear la ruta, ejecute oc edit route <app_service_name> y cambie el valor targetPort de la ruta a https. Puede probar la ruta ejecutando curl -I --http2 https://<route> --insecure.
    • Edge: Si utiliza un dominio personalizado, incluya las opciones --hostname, --cert, y --key, y opcionalmente la opción --ca-cert. Para obtener más información sobre los requisitos del certificado TLS, consulte la documentación de Red Hat OpenShift edge route.
      oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
      
    • Reencriptar: Si utiliza un dominio personalizado, incluya las opciones --hostname, --cert, y --key, y opcionalmente la opción --ca-cert. Para más información sobre los requisitos del certificado TLS, consulte la documentación de la ruta Red Hat OpenShift re-encrypt.
      oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
      
  4. Verifique que se ha creado la ruta para el servicio de la app.

    oc get routes
    
  5. Opcional: Personalice las reglas de enrutamiento predeterminadas con configuraciones opcionales. Por ejemplo, puede utilizar anotaciones HAProxy específicas de la ruta.

Configuración de rutas públicas en clústeres de VPC solo con un punto final de servicio en la nube privado

Si el clúster se crea en la infraestructura de VPC y solo ha habilitado el punto final de servicio de nube privada durante la creación del clúster, el clúster se crea solo con un direccionador privado de forma predeterminada. Para exponer de forma pública sus aplicaciones, primero debe crear un recurso de IngressController público y configurarlo con un subdominio. El operador de Ingress crea y configura automáticamente un nuevo controlador de Ingress público basado en IngressController, que puede utilizar para crear rutas públicas para sus aplicaciones.

Tenga en cuenta que, aunque cree un recurso de IngressController en los pasos siguientes, IngressController solo es necesario para crear y configurar el controlador de Ingress que necesita. Después de crear el controlador de Ingress, utilícelo directamente para crear rutas.

  1. Prepare el dominio que desea utilizar para el controlador de Ingress.

    • Dominio personalizado: para registrar un dominio personalizado, póngase en contacto con su proveedor de DNS (Domain Name Service) o utilice un DNS de IBM Cloud. Si desea utilizar el mismo subdominio para varios servicios del clúster, puede registrar un subdominio comodín, como por ejemplo *.example.com. Si utiliza un dominio personalizado, también debe especificar el certificado de dominio en la especificación IngressController. Para obtener más información, consulte Establecimiento de un certificado predeterminado personalizado
    • Dominio proporcionado por IBM:
      1. Obtenga una lista de los subdominios existentes del clúster. En la columna Subdominio de la salida, copie el subdominio que tiene el valor de 000<n> más alto.
        ibmcloud oc nlb-dns ls --cluster <cluster_name_or_id>
        
        En esta salida de ejemplo, el subdominio mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud tiene el valor de 000<n> más alto, 0002.
        Subdomain                                                                               Load Balancer Hostname                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud     ["1234abcd-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0000
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["5678efgh-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0001
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud     ["9012ijkl-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0002
        
      2. En el subdominio que ha copiado, cambie el valor de 000<n> en el subdominio por 000<n+1>. Por ejemplo, el subdominio mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud se cambia a mycluster-a1b2cdef345678g9hi012j3kl4567890-0003.us-south.containers.appdomain.cloud. Registrará este subdominio en pasos posteriores.
  2. Cree un archivo YAML con configure un controlador de Ingress público con el dominio del paso 1.

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: public
      namespace: openshift-ingress-operator
    spec:
      # defaultCertificate: If you are using a custom domain, specify the domain certificate
        # name: custom-certs-default
      replicas: 2
      domain: <domain>
      endpointPublishingStrategy:
        loadBalancer:
          scope: External
        type: LoadBalancerService
    
  3. Cree el recurso de IngressController en el espacio de nombres de openshift-ingress-operator del clúster. Cuando se crea IngressController, se crea automáticamente un controlador de Ingress público y se despliega en el espacio de nombres de openshift-ingress en función de los valores de IngressController. Adicionalmente, se crea un servicio de controlador de Ingress para exponer al controlador de Ingress.

    oc create -f public.yaml -n openshift-ingress-operator
    
  4. Obtenga el nombre de host de VPC del campo EXTERNAL IP del servicio router-public. En los clústeres de VPC, las direcciones IP externas de los servicios de direccionador son flotantes y se mantienen detrás de un nombre de host asignado por VPC.

    oc get svc router-public -n openshift-ingress
    

    Salida de ejemplo

    NAME                         TYPE           CLUSTER-IP       EXTERNAL-IP                             PORT(S)                      AGE
    router-public                LoadBalancer   172.21.57.132    1234abcd-us-south.lb.appdomain.cloud    80/TCP,443/TCP,1940/TCP      3m
    
  5. Registre el nombre de host de VPC del servicio con el dominio que ha elegido en el paso 1. Este paso garantiza que las direcciones IP de los servicios del controlador de Ingress, que se mantienen detrás del nombre de host de VPC, estén registradas con el dominio que ha elegido para el controlador de Ingress.

    • Dominio personalizado: trabaje con el proveedor de DNS para añadir el nombre de host de VPC del servicio como CNAME que se correlaciona con el dominio personalizado.

    • Dominio proporcionado por IBM: cree una entrada de DNS para el nombre de host de VPC del servicio. Cuando ejecuta el mandato siguiente, el subdominio que ha especificado en el paso 2 se genera automáticamente y se registra con el servicio de controlador de Ingress.

      ibmcloud oc nlb-dns create vpc-gen2 --cluster <cluster_name_or_ID> --lb-host <router_VPC_hostname>
      
  6. Opcional: si desea utilizar la fragmentación del controlador de Ingress para que un controlador de Ingress específico maneje que rutas específicas, por ejemplo, para que solo se admitan rutas privadas a un direccionador privado, puede utilizar etiquetas de ruta o etiquetas de espacio de nombres para especificar el método de fragmentación. Para añadir el selector en el tiempo de creación, inclúyalo en ingresscontroller yaml, en spec. Por ejemplo, para permitir que un controlador de Ingress solo maneje Ingress/rutas con la etiqueta type=sharded, puede añadir un routeSelector. Para obtener más información, consulte Fragmentación del controlador de Ingress.

      routeSelector:
        matchLabels:
          type: sharded
    
    1. Para añadir selectores a un controlador de Ingress existente, obtenga una lista de controladores de Ingress.

      oc get ingresscontroller -n openshift-ingress-operator
      
    2. Añada los selectores a los controladores de Ingress donde desee utilizar la fragmentación.

      oc patch  -n openshift-ingress-operator IngressController/<name>   --type='merge'   -p '{"spec":{"routeSelector":{"matchLabels":{"type":"sharded"}}}}'
      
    3. Tenga en cuenta que no se añaden selectores al IngressController predeterminado, por lo que todas las rutas siguen admitiendo el controlador de Ingress predeterminado en el clúster. Puede utilizar la ruta relevante o selectores de etiqueta de espacio de nombres para cambiar este comportamiento. Por ejemplo, para ajustar el direccionador predeterminado para omitir Ingress/rutas con la etiqueta type=sharded, ejecute el siguiente mandato de parche.

      oc patch -n openshift-ingress-operator IngressController/default --type='merge'   -p '{"spec":{"routeSelector":{"matchExpressions":[{"key":"type","operator":"NotIn","values":["sharded"]}]}}}'
      

      Varias rutas y varios Ingress en el clúster dependen del controlador de Ingress público predeterminado. Asegúrese de que los cambios son correctos antes de editar el controlador de entrada predeterminado. Para obtener más información, consulte Fragmentación del controlador de Ingress.

  7. Cree un servicio ClusterIP de Kubernetes para el despliegue de la app. El servicio proporciona una dirección IP interna para la aplicación a la que el controlador de Ingress puede enviar tráfico.

    oc expose deploy <app_deployment_name> --name <app_service_name> -n <app_project>
    
  8. Configure una ruta que se base en el tipo de terminación TLS que necesita la app. Si no incluye la opción --hostname, el nombre de host de la ruta se genera por usted en el formato <app_service_name>-<app_project>.<router-subdomain>.

    • Simple:
      oc expose service <app_service_name> [--hostname <subdomain>]
      
    • Paso a través:
      oc create route passthrough --service <app_service_name> [--hostname <subdomain>]
      
      ¿Necesita gestionar conexiones HTTP/2? Después de crear la ruta, ejecute oc edit route <app_service_name> y cambie el valor targetPort de la ruta a https. Puede probar la ruta ejecutando curl -I --http2 https://<route> --insecure.
    • Edge: Si utiliza un dominio personalizado, incluya las opciones --hostname, --cert, y --key, y opcionalmente la opción --ca-cert. Para obtener más información sobre los requisitos del certificado TLS, consulte la documentación de Red Hat OpenShift edge route.
      oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
      
    • Reencriptar: Si utiliza un dominio personalizado, incluya las opciones --hostname, --cert, y --key, y opcionalmente la opción --ca-cert. Para más información sobre los requisitos del certificado TLS, consulte la documentación de la ruta Red Hat OpenShift re-encrypt.
      oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
      
  9. Verifique que se ha creado la ruta para la app.

    oc get routes
    
  10. Opcional: Personalice las reglas de direccionamiento del controlador de Ingress público con configuraciones opcionales. Por ejemplo, puede utilizar anotaciones HAProxy específicas de la ruta.

  11. Para crear rutas para más aplicaciones utilizando el mismo subdominio, puede repetir los pasos 7-10 para que el mismo controlador de Ingress público genere la ruta. Si desea crear rutas para más aplicaciones utilizando un subdominio diferente, repita todos los pasos de esta sección para crear un nuevo controlador de Ingress público con un dominio distinto.

Configuración de rutas privadas

Utilice un controlador de Ingress privado para exponer las aplicaciones del clúster en la red privada.

El método para configurar rutas privadas varía en función del proveedor de la infraestructura del clúster y de la configuración del punto final de servicio.

Configuración de rutas privadas en clústeres clásicos o en clústeres de VPC con un punto final de servicio en la nube público

Si su clúster se ha creado en una infraestructura clásica, o si su clúster se ha creado en una infraestructura VPC y ha activado el punto final del servicio de nube pública durante la creación del clúster, su clúster se creará con un único controlador de entrada público de forma predeterminada. Para exponer de forma privada sus aplicaciones, primero debe crear un recurso de IngressController privado y configurar el controlador con un subdominio. El operador de Ingress crea y configura automáticamente un nuevo controlador de Ingress privado, que puede utilizar para crear rutas privadas para sus aplicaciones.

Tenga en cuenta que, aunque cree un recurso de IngressController en los pasos siguientes, el recurso de IngressController solo es necesario para crear y configurar el controlador de Ingress que necesita. Después de crear el controlador de Ingress, utilice el direccionador directamente para crear rutas.

  1. Prepare el dominio que desea utilizar para el controlador de Ingress.

    • Dominio personalizado, clústeres clásicos o de VPC: para registrar un dominio personalizado, póngase en contacto con su proveedor de DNS (Domain Name Service) o utilice un DNS de IBM Cloud. Si desea utilizar el mismo subdominio para varios servicios del clúster, puede registrar un subdominio comodín, como por ejemplo *.example.com.
    • Dominio proporcionado por IBM, solo clústeres de VPC:
      1. Obtenga una lista de los subdominios existentes del clúster. En la columna Subdominio de la salida, copie el subdominio que tiene el valor de 000<n> más alto.
        ibmcloud oc nlb-dns ls --cluster <cluster_name_or_id>
        
        En esta salida de ejemplo, el subdominio mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud tiene el valor de 000<n> más alto, 0002.
        Subdomain                                                                               Load Balancer Hostname                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud     ["1234abcd-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0000
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["5678efgh-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0001
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud     ["9012ijkl-us-south.lb.appdomain.cloud"]      None             created                   mycluster-a1b2cdef345678g9hi012j3kl4567890-0002
        
      2. En el subdominio que ha copiado, cambie el valor de 000<n> en el subdominio por 000<n+1>. Por ejemplo, el subdominio mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud se cambia a mycluster-a1b2cdef345678g9hi012j3kl4567890-0003.us-south.containers.appdomain.cloud. Registrará este subdominio en pasos posteriores.
  2. Cree un archivo de configuración con configure un controlador de Ingress privado con el dominio del paso 1.

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: private
      namespace: openshift-ingress-operator
    spec:
      replicas: 2
      domain: <domain>
      endpointPublishingStrategy:
        loadBalancer:
          scope: Internal
        type: LoadBalancerService
    
  3. Cree el recurso de IngressController en el espacio de nombres de openshift-ingress-operator del clúster. Cuando se crea el recurso de IngressController, se crea automáticamente un controlador de Ingress privado y se despliega en el espacio de nombres de openshift-ingress en función de los valores de IngressController. Además, se crea un servicio de controlador de Ingress para exponer el controlador de Ingress con una dirección IP (clústeres clásicos) o un nombre de host de VPC (clústeres VPC).

    oc create -f private.yaml -n openshift-ingress-operator
    
  4. Obtenga la dirección IP o el nombre de host de VPC del campo EXTERNAL IP del servicio router-private.

    oc get svc router-private -n openshift-ingress
    

    Ejemplo de salida para clústeres clásicos:

    NAME                         TYPE           CLUSTER-IP       EXTERNAL-IP    PORT(S)                      AGE
    router-private               LoadBalancer   172.21.57.132    10.XX.XX.XX    80/TCP,443/TCP,1940/TCP      3m
    

    Ejemplo de salida para clústeres de VPC:

    NAME                         TYPE           CLUSTER-IP       EXTERNAL-IP                             PORT(S)                      AGE
    router-private               LoadBalancer   172.21.57.132    1234abcd-us-south.lb.appdomain.cloud    80/TCP,443/TCP,1940/TCP      3m
    
  5. Registre la dirección IP externa o el nombre de host de VPC del servicio con el dominio que ha elegido en el paso 1.

    • Dominio personalizado, clústeres clásicos o VPC: trabaje con el proveedor de DNS para añadir la dirección IP externa del servicio como un registro A (clústeres clásicos) o el nombre de host de VPC como CNAME (clústeres de VPC) que se correlaciona con el dominio personalizado.
    • Dominio proporcionado por IBM, solo clústeres VPC: cree una entrada de DNS para el nombre de host de VPC del servicio. Cuando ejecuta el mandato siguiente, el subdominio que ha especificado en el paso 2 se genera automáticamente y se registra con el servicio de controlador de Ingress.
      ibmcloud oc nlb-dns create vpc-gen2 --cluster <cluster_name_or_ID> --lb-host <router_VPC_hostname>
      
  6. Opcional: si desea utilizar la fragmentación del controlador de Ingress para que un controlador de Ingress específico maneje que rutas específicas, por ejemplo, para que solo se admitan rutas privadas a un direccionador privado, puede utilizar etiquetas de ruta o etiquetas de espacio de nombres para especificar el método de fragmentación. Para añadir el selector en el tiempo de creación, inclúyalo en ingresscontroller yaml, en spec. Por ejemplo, para permitir que un controlador de Ingress solo maneje Ingress/rutas con la etiqueta type=sharded, puede añadir un routeSelector. Para obtener más información, consulte Fragmentación del controlador de Ingress.

      routeSelector:
        matchLabels:
          type: sharded
    
    1. Para añadir selectores a un controlador de Ingress existente, obtenga una lista de controladores de Ingress.

      oc get ingresscontroller -n openshift-ingress-operator
      
    2. Añada los selectores a los controladores de Ingress donde desee utilizar la fragmentación.

      oc patch  -n openshift-ingress-operator IngressController/<name>   --type='merge'   -p '{"spec":{"routeSelector":{"matchLabels":{"type":"sharded"}}}}'
      
    3. Tenga en cuenta que no se añaden selectores al IngressController predeterminado, por lo que todas las rutas siguen admitiendo el controlador de Ingress predeterminado en el clúster. Puede utilizar la ruta relevante o selectores de etiqueta de espacio de nombres para cambiar este comportamiento. Por ejemplo, para ajustar el direccionador predeterminado para omitir Ingress/rutas con la etiqueta type=sharded, ejecute el siguiente mandato de parche.

      oc patch -n openshift-ingress-operator IngressController/default --type='merge'   -p '{"spec":{"routeSelector":{"matchExpressions":[{"key":"type","operator":"NotIn","values":["sharded"]}]}}}'
      
  7. Cree un servicio ClusterIP de Kubernetes para el despliegue de la app. El servicio proporciona una dirección IP interna para la aplicación a la que el controlador de Ingress puede enviar tráfico.

    oc expose deploy <app_deployment_name> --name <app_service_name> -n <app_project>
    
  8. Configure una ruta que se base en el tipo de terminación TLS que necesita la app. Especifique el nombre de host que ha establecido en el paso 5.

    • Simple:
      oc expose service <app_service_name> --hostname <subdomain>
      
    • Paso a través:
      oc create route passthrough --service <app_service_name> --hostname <subdomain>
      
      ¿Necesita gestionar conexiones HTTP/2? Después de crear la ruta, ejecute oc edit route <app_service_name> y cambie el valor targetPort de la ruta a https. Puede probar la ruta ejecutando curl -I --http2 https://<route> --insecure.
    • Edge: Si utiliza un dominio personalizado, incluya las opciones --cert y --key, y opcionalmente la opción --ca-cert. Para obtener más información sobre los requisitos del certificado TLS, consulte la documentación de Red Hat OpenShift edge route.
      oc create route edge --service <app_service_name> --hostname <subdomain> [--cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
      
    • Reencriptar: Si utiliza un dominio personalizado, incluya las opciones --cert y --key, y opcionalmente la opción --ca-cert. Para más información sobre los requisitos del certificado TLS, consulte la documentación de la ruta Red Hat OpenShift re-encrypt.
      oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> --hostname <subdomain> [--cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
      
  9. Verifique que se ha creado la ruta para la app.

    oc get routes
    
  10. Opcional: personalice las reglas de direccionamiento del controlador de Ingress privado con configuraciones opcionales. Por ejemplo, puede utilizar anotaciones HAProxy específicas de la ruta.

  11. Para crear rutas para más aplicaciones utilizando el mismo subdominio, puede repetir los pasos 7-10 para que el mismo controlador de Ingress privado genere la ruta. Si desea crear rutas para más aplicaciones utilizando un subdominio diferente, repita todos los pasos de esta sección para crear un nuevo controlador de Ingress privado.

Configuración de rutas privadas en clústeres de VPC solo con un punto final de servicio en la nube privado

Si el clúster se crea en la infraestructura de VPC y ha habilitado el único punto final de servicio de nube privada durante la creación del clúster, el clúster se crea con un controlador de Ingress privado de forma predeterminada. Puede utilizar este controlador de Ingress para crear rutas privadas para su aplicación.

  1. Cree un servicio ClusterIP de Kubernetes para el despliegue de la app. El servicio proporciona una dirección IP interna para la aplicación a la que el controlador de Ingress puede enviar tráfico.

    oc expose deploy <app_deployment_name> --name my-app-svc
    
  2. Elija un dominio para la app.

    • Dominio proporcionado por IBM: si no necesita un dominio personalizado, se genera un subdominio de ruta automáticamente con el formato <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud.
    • Dominio personalizado: para especificar un dominio personalizado, trabaje con el proveedor de DNS o con IBM Cloud® Internet Services.
      1. Obtenga la dirección IP externa para el servicio de controlador de Ingress privado en cada zona de la columna EXTERNAL-IP. Tenga en cuenta que el servicio de controlador de Ingress en la primera zona donde tiene nodos de trabajador siempre se denomina router-default, y los servicios de controlador de Ingress en las zonas que se añaden posteriormente al clúster tienen nombres como, por ejemplo, router-dal12.

        oc get svc -n openshift-ingress
        
      2. Cree un dominio personalizado con el proveedor de DNS. Si desea utilizar el mismo subdominio para varios servicios del clúster, puede registrar un subdominio comodín, como por ejemplo *.example.com.

      3. Correlacione el dominio personalizado con la dirección IP privada de los servicios del controlador de Ingress añadiendo las direcciones IP como registros A.

  3. Configure una ruta basada en el tipo de terminación TLS que requiere su aplicación. Si no tiene un dominio personalizado, no incluya la opción --hostname. Se genera un subdominio de ruta automáticamente con el formato <service_name>-<project>.<cluster_name>-<random_hash>-0000.<region>.containers.appdomain.cloud. Si ha registrado un subdominio comodín, especifique un subdominio exclusivo en cada ruta que cree. Por ejemplo, puede especificar --hostname svc1.example.com en esta ruta y --hostname svc2.example.com en otra ruta.

    • Simple:

      oc expose service <app_service_name> [--hostname <subdomain>]
      
    • Paso a través:

      oc create route passthrough --service <app_service_name> [--hostname <subdomain>]
      

      ¿Necesita gestionar conexiones HTTP/2? Después de crear la ruta, ejecute oc edit route <app_service_name> y cambie el valor targetPort de la ruta a https. Puede probar la ruta ejecutando curl -I --http2 https://<route> --insecure.

    • Edge: Si utiliza un dominio personalizado, incluya las opciones --hostname, --cert, y --key, y opcionalmente la opción --ca-cert. Para obtener más información sobre los requisitos del certificado TLS, consulte la documentación de Red Hat OpenShift edge route.

      oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
      
    • Reencriptar: Si utiliza un dominio personalizado, incluya las opciones --hostname, --cert, y --key, y opcionalmente la opción --ca-cert. Para más información sobre los requisitos del certificado TLS, consulte la documentación de la ruta Red Hat OpenShift re-encrypt.

      oc create route reencrypt --service <app_service_name> --dest-ca-cert <destca.crt> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
      
  4. Verifique que se ha creado la ruta para el servicio de la app.

    oc get routes
    
  5. Opcional: Personalice las reglas de enrutamiento predeterminadas con configuraciones opcionales. Por ejemplo, puede utilizar anotaciones HAProxy específicas de la ruta.

Traslado de servicios de controlador de Ingress a través de VLAN en clústeres clásicos

Cuando se cambian las conexiones VLAN de los nodos trabajadores, éstos se conectan a la nueva VLAN y se les asignan nuevas direcciones IP públicas o privadas. Sin embargo, los servicios de controlador de Ingress no pueden migrar automáticamente a la nueva VLAN porque se les asigna una dirección IP pública o privada estable y portátil, de una subred que pertenece a la VLAN antigua. Cuando los nodos de trabajador y los controladores de Ingress están conectados a distintas VLAN, los controladores de Ingress no pueden reenviar el tráfico de red entrante a los pods de aplicación en los nodos de trabajador. Para mover los servicios de controlador de Ingress a una VLAN distinta, debe crear el servicio de controlador de Ingress en la nueva VLAN y suprimir el servicio de controlador de Ingress en la VLAN antigua.

  1. Cree un servicio de controlador de Ingress en la nueva VLAN.

    1. Cree un archivo de configuración YAML para un nuevo servicio de controlador de Ingress. Especifique la zona donde se despliega el servicio de controlador de Ingress. Guarde el archivo como router-new-<zone>.yaml.
      • Servicio de controlador de Ingress público:
        apiVersion: v1
        kind: Service
        metadata:
          annotations:
            service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: <zone>
            service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: public
          finalizers:
          - service.kubernetes.io/load-balancer-cleanup
          labels:
            app: router
            ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
            router: router-default
          name: router-new-<zone>
          namespace: openshift-ingress
        spec:
          externalTrafficPolicy: Local
          ports:
          - name: http
            port: 80
            protocol: TCP
            targetPort: http
          - name: https
            port: 443
            protocol: TCP
            targetPort: https
          selector:
            ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
          sessionAffinity: None
          type: LoadBalancer
        
      • Servicio de controlador de Ingress privado:
        apiVersion: v1
        kind: Service
        metadata:
          annotations:
            service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: <zone>
            service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: private
          finalizers:
          - service.kubernetes.io/load-balancer-cleanup
          labels:
            app: router
            ingresscontroller.operator.openshift.io/deployment-ingresscontroller: private
            router: router-private
          name: router-new-<zone>
          namespace: openshift-ingress
        spec:
          externalTrafficPolicy: Local
          ports:
          - name: http
            port: 80
            protocol: TCP
            targetPort: http
          - name: https
            port: 443
            protocol: TCP
            targetPort: https
          selector:
            ingresscontroller.operator.openshift.io/deployment-ingresscontroller: private
          sessionAffinity: None
          type: LoadBalancer
        
    2. Cree el nuevo servicio de controlador de Ingress.
      oc apply -f router-new-<zone>.yaml -n openshift-ingress
      
    3. Obtenga la dirección EXTERNAL-IP del nuevo servicio de controlador de Ingress. Esta dirección IP procede de una subred de la nueva VLAN.
      oc get svc router-new -n openshift-ingress
      
      Salida de ejemplo de un servicio de controlador de Ingress público:
      NAME                         TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                                     AGE
      router-new                   LoadBalancer   172.21.XX.XX     169.XX.XXX.XX   80:31049/TCP,443:30219/TCP                  2m
      
    4. Clústeres multizona: si ha cambiado las VLAN de nodos de trabajador en varias zonas, repita estos pasos para crear un servicio de controlador de Ingress en las nuevas VLAN de cada zona.
  2. Anote el Nombre de host del controlador de Ingress. En la salida, busque el nombre de host formateado como <cluster_name>-<random_hash>-0001.<region>.containers.appdomain.cloud.

    ibmcloud oc nlb-dns ls -c <cluster_name_or_ID>
    

    Salida de ejemplo

    Hostname                                                                             IP(s)           Health Monitor   SSL Cert Status   SSL Cert Secret Name                            Secret Namespace
    mycluster-35366fb2d3d90fd50548180f69e7d12a-0001.us-east.containers.appdomain.cloud   169.XX.XXX.XX   None             created           roks-ga-35366fb2d3d90fd50548180f69e7d12a-0001   default
    ...
    
  3. Añada la dirección IP del nuevo servicio de controlador Ingress que ha encontrado en el paso 1 al nombre de host del controlador de Ingress. Si ha creado servicios para varias zonas en el paso 1, incluya cada dirección IP por separado en las opciones repetidas de --ip.

    ibmcloud oc nlb-dns add -c <cluster_name_or_ID> --ip <new_IP> --nlb-host <subdomain>
    

    El servicio de controlador de Ingress en la nueva VLAN está ahora registrado con el dominio del controlador de Ingress predeterminado en el clúster y puede reenviar las solicitudes entrantes a las aplicaciones.

  4. Obtenga la dirección IP del servicio de controlador de Ingress antiguo en la VLAN antigua. Clústeres multizona: si ha cambiado las VLAN de nodos de trabajador en varias zonas, obtenga la dirección IP del servicio de controlador de Ingress en cada zona donde hayan cambiado las VLAN. Tenga en cuenta que el servicio de controlador de Ingress en la primera zona donde tiene nodos de trabajador siempre se denomina router-default, y los servicios de controlador de Ingress en las zonas que se añaden posteriormente al clúster tienen nombres como, por ejemplo, router-dal12.

    oc get svc -n openshift-ingress
    

    Salida de ejemplo para un clúster multizona:

    NAME                          TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)                      AGE
    router-dal12                  LoadBalancer   172.21.190.62    169.XX.XX.XX     80:32318/TCP,443:30915/TCP   51d
    router-default                LoadBalancer   172.21.47.119    169.XX.XX.XX     80:31311/TCP,443:32561/TCP   78d
    router-internal-default       ClusterIP      172.21.51.30     <none>           80/TCP,443/TCP,1936/TCP      78d
    
  5. Elimine la dirección IP del servicio de controlador de Ingress antiguo que ha encontrado en el paso 2 del nombre de host del controlador de Ingress. Agrupaciones multizona: Incluya cada dirección IP por separado en las opciones repetidas de --ip.

    ibmcloud oc nlb-dns rm classic -c <cluster_name_or_ID> --ip <old_IP> --nlb-host <hostname>
    
  6. Verifique que el nombre de host del controlador de Ingress esté ahora registrado con la nueva dirección IP. Después de actualizar el nombre de host del controlador de Ingress con la dirección IP del nuevo servicio, no se necesitan más cambios en las rutas o el controlador de Ingress.

    ibmcloud oc nlb-dns ls -c <cluster_name_or_ID>
    
  7. Suprima el servicio del controlador de Ingress en la VLAN antigua.

    oc delete svc <old_router_svc> -n openshift-ingress
    
  8. Opcional: si ya no necesita las subredes en las VLAN antiguas, puede eliminarlas.