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

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.

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.

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.

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.

{: 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.

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 tu clúster se ha creado en una infraestructura clásica, o si se ha creado en una infraestructura VPC y has habilitado el punto de conexión del servicio en la nube pública durante la creación del clúster, este se creará con un controlador Ingress 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. Ten en cuenta que las URL de las rutas deben tener 130 caracteres o menos IBM-dominio proporcionado: si no necesitas utilizar un dominio personalizado, se generará automáticamente un nombre de host para la 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
       ```
   1. 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`.
   {: tip}
   
   1. 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 tienes un dominio propio, no incluyas 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:
   ```sh {: pre}
       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`.
   * Nota: Si utilizas un dominio personalizado, incluye las opciones `--hostname`, `--cert` y `--key`, y, si lo deseas, la opción `--ca-cert`. Para obtener más información sobre los requisitos de los certificados « TLS », consulta la [documentación sobre rutas de borde de Red Hat OpenShift](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-an-edge-route-with-a-custom-certificate_secured-routes){: external}.
   ```sh {: pre}
       oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   * Volver a cifrar: Si utilizas un dominio personalizado, incluye las opciones `--hostname`, `--cert` y `--key`, y, si lo deseas, la opción `--ca-cert`. Para obtener más información sobre los requisitos de los certificados « TLS », consulta la [documentación sobre la ruta de recifrado de Red Hat OpenShift](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes){: external}.
   ```sh {: pre}
       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, puedes utilizar anotaciones « HAProxy » específicas para cada 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 pasa a ser 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
       ```
   1. Añada los selectores a los controladores de Ingress donde desee utilizar la fragmentación.
   
   ```sh {: pre}
       oc patch  -n openshift-ingress-operator IngressController/<name>   --type='merge'   -p '{"spec":{"routeSelector":{"matchLabels":{"type":"sharded"}}}}'
       ```
   
   1. 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.
   ```sh {: pre}
       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úrate de que los cambios sean correctos antes de editar el controlador predeterminado de Ingress. Para obtener más información, consulte [Fragmentación del controlador de Ingress](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/networking_overview/index#nw-ingress-sharding_configuring-ingress){: external}.
       {: note}
   
   
   

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 incluyes la opción « --hostname », el nombre de host de la ruta se generará automáticamente con el formato <app_service_name>-<app_project>.<router-subdomain>.

   • Simple:

       oc expose service <app_service_name> [--hostname <subdomain>]
       ```
   * Paso a través:
   ```sh {: pre}
       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`.
   * Nota: Si utilizas un dominio personalizado, incluye las opciones `--hostname`, `--cert` y `--key`, y, si lo deseas, la opción `--ca-cert`. Para obtener más información sobre los requisitos de los certificados « TLS », consulta la [documentación sobre rutas de borde de Red Hat OpenShift](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-an-edge-route-with-a-custom-certificate_secured-routes){: external}.
   ```sh {: pre}
       oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   * Volver a cifrar: Si utilizas un dominio personalizado, incluye las opciones `--hostname`, `--cert` y `--key`, y, si lo deseas, la opción `--ca-cert`. Para obtener más información sobre los requisitos de los certificados « TLS », consulta la [documentación sobre la ruta de recifrado de Red Hat OpenShift](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes){: external}.
   ```sh {: pre}
       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, puedes utilizar anotaciones « HAProxy » específicas para cada 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 en clústeres clásicos o en clústeres de VPC con un punto final de servicio en la nube público

Si tu clúster se ha creado en una infraestructura clásica, o si se ha creado en una infraestructura VPC y has habilitado el punto de conexión del servicio en la nube pública durante la creación del clúster, este se creará, por defecto, únicamente con un controlador Ingress público. 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 pasa a ser 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
       ```
   1. Añada los selectores a los controladores de Ingress donde desee utilizar la fragmentación.
   
   ```sh {: pre}
       oc patch  -n openshift-ingress-operator IngressController/<name>   --type='merge'   -p '{"spec":{"routeSelector":{"matchLabels":{"type":"sharded"}}}}'
       ```
   
   1. 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.
   ```sh {: pre}
       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:
   ```sh {: pre}
       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`.
   * Nota: Si utilizas un dominio personalizado, incluye las opciones `--cert` y `--key` y, si lo deseas, la opción `--ca-cert`. Para obtener más información sobre los requisitos de los certificados « TLS », consulta la [documentación sobre rutas de borde de Red Hat OpenShift](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-an-edge-route-with-a-custom-certificate_secured-routes){: external}.
   ```sh {: pre}
       oc create route edge --service <app_service_name> --hostname <subdomain> [--cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   * Volver a cifrar: Si utilizas un dominio personalizado, incluye las opciones `--cert` y `--key` y, si lo deseas, la opción `--ca-cert`. Para obtener más información sobre los requisitos de los certificados « TLS », consulta la [documentación sobre la ruta de recifrado de Red Hat OpenShift](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes){: external}.
   ```sh {: pre}
       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, puedes utilizar anotaciones « HAProxy » específicas para cada 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 tienes un dominio propio, no incluyas 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:
   ```sh {: pre}
       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`.
   
   * Nota: Si utilizas un dominio personalizado, incluye las opciones `--hostname`, `--cert` y `--key`, y, si lo deseas, la opción `--ca-cert`. Para obtener más información sobre los requisitos de los certificados « TLS », consulta la [documentación sobre rutas de borde de Red Hat OpenShift](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-an-edge-route-with-a-custom-certificate_secured-routes){: external}.
   ```sh {: pre}
       oc create route edge --service <app_service_name> [--hostname <subdomain> --cert <tls.crt> --key <tls.key> --ca-cert <ca.crt>]
       ```
   * Volver a cifrar: Si utilizas un dominio personalizado, incluye las opciones `--hostname`, `--cert` y `--key`, y, si lo deseas, la opción `--ca-cert`. Para obtener más información sobre los requisitos de los certificados « TLS », consulta la [documentación sobre la ruta de recifrado de Red Hat OpenShift](https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/ingress_and_load_balancing/routes#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes){: external}.
   ```sh {: pre}
       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, puedes utilizar anotaciones « HAProxy » específicas para cada ruta.