Publicar aplicaciones con Ingress

Expone públicamente varias aplicaciones en tu clúster de « Red Hat® OpenShift® on IBM Cloud® » creando recursos Ingress gestionados por el controlador Ingress.

Requisitos previos

Antes de empezar a trabajar con Ingress, revise los siguientes requisitos previos.

La configuración de Ingress requiere los siguientes roles de IBM Cloud IAM:
- Rol de acceso a la plataforma de administrador para el clúster en IBM Cloud Kubernetes Service.
- Rol de acceso de servicio de administrador en todos los espacios de nombres de IBM Cloud Kubernetes Service ( Red Hat OpenShift proyectos).
Si una zona falla, es posible que vea anomalías intermitentes en las solicitudes de las aplicaciones expuestas por el controlador de Ingress en esa zona.
Para garantizar la alta disponibilidad, se recomiendan al menos dos nodos trabajadores por zona.

Clústeres de VPC: Permite que las solicitudes de tráfico enrutadas por Ingress lleguen a los puertos de los nodos de trabajo. Para obtener más información, consulte Comprensión de las redes VPC de clúster seguras por defecto y Creación y gestión de grupos de seguridad VPC.
Clústeres VPC multizona: Si has creado un clúster en la CLI y posteriormente has añadido manualmente zonas a tus grupos de trabajadores con el comando « ibmcloud oc zone add vpc-gen2 », debes actualizar el equilibrador de carga de la VPC que expone el controlador Ingress para incluir las subredes de todas las zonas de tu clúster.
Clústeres clásicos: habilite una función de direccionador virtual (VRF) para la cuenta de infraestructura de IBM Cloud. Para habilitar VRF, consulte Habilitación de VRF. Para comprobar si un VRF ya está habilitado, utilice el mandato ibmcloud account show. Si no puede o no desea habilitar VRF, habilite Expansión de VLAN. Cuando hay una VRF o una expansión de VLAN habilitada, el controlador de Ingress puede direccionar paquetes a varias subredes de la cuenta.

Exposición pública de aplicaciones en clústeres mediante un punto de conexión de un servicio en la nube pública

Grupos clásicos Nube privada virtual

Si tu clúster se ha creado en una infraestructura clásica, o si se ha creado en una infraestructura VPC y activaste el punto de conexión del servicio en la nube pública al crearlo, puedes utilizar el controlador Ingress público predeterminado para exponer las aplicaciones de tu clúster y que puedan recibir solicitudes procedentes de la red pública.

Antes de empezar:

Revise los requisitos previos de Ingress.
Acceda al clúster de Red Hat OpenShift.

Paso 1: Desplegar apps y crear servicios de app

Empiece desplegando sus apps y crear servicios de Kubernetes para exponerlos.

Despliegue la app en el clúster. Asegúrese de añadir una etiqueta a su despliegue en la sección de metadatos del archivo de configuración como, por ejemplo, app: code. Esta etiqueta es necesaria para identificar todos los pods donde se ejecuta la aplicación para que los pods estén en el equilibrio de carga de Ingress.
Para cada despliegue de app que desee exponer, cree un servicio ClusterIP de Kubernetes. El servicio de Kubernetes debe exponer la app para que se incluya en el equilibrio de carga de Ingress.

oc expose deploy <app_deployment_name> --name my-app-svc --port <app_port> -n <namespace>

Paso 2: Configurar una terminació TLS e con certificados de TLS y secretos de Kubernetes

Tu certificado « TLS » debe almacenarse como un secreto « Kubernetes » en cada espacio de nombres en el que se encuentren tus aplicaciones.

Para utilizar el dominio de Ingress gestionado por IBM, consulta la sección « Configuración de secretos de TLS para el subdominio de Ingress proporcionado por IBM ».
Para utilizar un dominio que hayas creado tú mismo, como por ejemplo uno registrado con un proveedor externo, consulta la sección « Configuración de secretos de TLS para subdominios personalizados ».

Paso 3: Crear el recurso de Ingress

Los recursos de Ingress definen las reglas de direccionamiento que el controlador de Ingress utiliza para direccionar el tráfico a su servicio de app.

Defina un archivo de configuración de recursos de Ingress que utilice el dominio proporcionado por IBM o su dominio personalizado para direccionar el tráfico de entrada de red a los servicios que ha creado anteriormente.
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myingressresource
spec:
  tls:
  - hosts:
    - <domain>
    secretName: <secret_name>
  rules:
  - host: <domain>
    http:
      paths:
      - path: /<app1_path>
        pathType: Prefix
        backend:
            service:
                name: test
                port:
                    number: 80
      - path: /<app2_path>
        backend:
            service:
                name: <app2_service>
                port:
                    number: 80
```
tls

Si desea utilizar TLS, incluya esta sección TLS en el recurso. Sustituya <domain> por el subdominio. No utilice * para el host o deje la propiedad de host vacía para evitar anomalías durante la creación de Ingress. Sustituya <tls_secret_name> por el secreto que ha creado anteriormente que contiene el certificado TLS y la clave para un dominio personalizado o el secreto TLS que se ha generado automáticamente para un subdominio proporcionado por IBM.

host

Sustituya <domain> por el subdominio de Ingress proporcionado por IBM o por el dominio personalizado. Si el clúster tiene varios proyectos donde se exponen las apps, se necesita un recurso de Ingress por proyecto. Puede utilizar el mismo subdominio en cada recurso o distintos subdominios en cada recurso. Por ejemplo, si utiliza un dominio comodín, puede añadir un subdominio comodín al principio del dominio, por ejemplo, subdomain1.custom_domain.net o subdomain1.mycluster-<hash>-0000.us-south.containers.appdomain.cloud. No utilice * para el host o deje la propiedad de host vacía para evitar anomalías durante la creación de Ingress.

path

Sustituye « <app_path> » por la ruta en la que tu aplicación está a la escucha. La vía de acceso se añade al dominio personalizado o proporcionado por IBM para crear una ruta exclusiva a su app. Cuando especifica esta ruta en un navegador web, el tráfico de la red se direcciona al controlador de Ingress. El controlador de Ingress busca el servicio asociado y envía el tráfico de red al servicio. A continuación, el servicio reenvía el tráfico a los pods en los que se ejecuta la app. Muchas aplicaciones no escuchan en una ruta específica, sino que utilizan la vía de acceso raíz y un puerto específico. En este caso, defina la vía de acceso raíz como / y no especifique una vía de acceso individual para la aplicación. Para http://domain/, especifique / como la vía de acceso. Para http://domain/app1_path, especifique /app1_path como la vía de acceso.

pathType

El método de comparación de vías de acceso de URL. Los valores admitidos son ImplementationSpecific, Exact o Prefix. Para obtener más información y ver ejemplos de cada tipo de ruta, consulta la guía « Documentación de la comunidad « Kubernetes » ».

name

Sustituya <app1_service> y <app2_service>, y así sucesivamente, por el nombre de los servicios que ha creado para exponer las aplicaciones. Si sus apps están expuestas mediante servicios en diferentes proyectos en el clúster, incluya únicamente los servicios de app que se encuentran en el mismo proyecto. Debe crear un recurso de Ingress para cada proyecto donde tiene las apps que desea exponer.

port

El puerto en el que el servicio está a la escucha. Utilice el mismo puerto que ha definido al crear el servicio de Kubernetes para la app.
Cree el recurso de Ingress para el clúster. Asegúrese de que el recurso se despliega en el mismo proyecto que los servicios de apps que ha especificado en el recurso.
```
oc apply -f myingressresource.yaml -n <project>
```
Verifique que el recurso de Ingress se haya creado correctamente. Si los mensajes de los eventos indican un error en la configuración de tu recurso, corrige los valores en tu archivo de recursos y vuelve a aplicar el archivo al recurso.
```
oc describe ingress myingressresource
```

El recurso de Ingress se crea en el mismo proyecto que los servicios de app y sus apps se registran con el controlador de Ingress.

Paso 4: Acceder a la app desde Internet

En un navegador web, escriba el URL del servicio de la app al que va a acceder.

https://<domain>/<app1_path>

Si tiene varias apps expuestas, acceda a dichas apps cambiando la vía de acceso que se añade al final del URL.

https://<domain>/<app2_path>

Si utiliza un dominio comodín, acceda a dichas apps con sus propios subdominios.

http://<subdomain1>.<domain>/<app1_path>

http://<subdomain2>.<domain>/<app1_path>

¿No se puede conectar a la app a través de Ingress? Intente resolverlos consultando Resolución de problemas de Ingress.

Exposición pública de apps en clústeres de VPC solo con un punto final de servicio en la nube privado

Nube privada virtual

Si tu clúster se ha creado en una infraestructura VPC y, al crearlo, solo habilitaste el punto de conexión del servicio en la nube privada, tu clúster se creará, por defecto, únicamente con un controlador de Ingress privado. Para exponer las apps públicamente, primero debe crear un controlador de Ingress público. Luego debe registrar el controlador de Ingress con un subdominio y, si lo desea, importar su propio certificado TLS.

Paso 1: Desplegar apps y crear servicios de app

Empiece desplegando sus apps y crear servicios de Kubernetes para exponerlos.

Despliegue la app en el clúster. Asegúrese de añadir una etiqueta a su despliegue en la sección de metadatos del archivo de configuración como, por ejemplo, app: code. Esta etiqueta es necesaria para identificar todos los pods donde se ejecuta la aplicación para que los pods estén en el equilibrio de carga de Ingress.
Para cada despliegue de app que desee exponer, cree un servicio ClusterIP de Kubernetes. El servicio de Kubernetes debe exponer la app para que se incluya en el equilibrio de carga de Ingress.

oc expose deploy <app_deployment_name> --name my-app-svc --port <app_port> -n <namespace>

Paso 2: Configurar una terminació TLS e con certificados de TLS y secretos de Kubernetes

Tu certificado « TLS » debe almacenarse como un secreto « Kubernetes » en cada espacio de nombres en el que se encuentren tus aplicaciones.

TLS Secretos para crear dominios personalizados de Ingress

Para utilizar un dominio que hayas creado tú mismo, como por ejemplo uno registrado con un proveedor externo, consulta la sección « Configuración de secretos de TLS para subdominios personalizados ».

TLS Secretos para los dominios de Ingress gestionados por « IBM »

Sigue los pasos para configurar los secretos de « TLS » para el dominio de Ingress gestionado por « IBM ».

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

En el subdominio que ha copiado, cambie el valor de 000<n> en el subdominio por 000<n+1>. Por ejemplo, el valor del subdominio mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud se cambia a mycluster-a1b2cdef345678g9hi012j3kl4567890-0003.us-south.containers.appdomain.cloud. n+1 indica el siguiente subdominio consecutivo que crea en este clúster. Registrará este subdominio en pasos posteriores. Al registrar el dominio, se genera automáticamente un secreto de « TLS » para dicho dominio. El nombre del secreto sigue un formato truncado del subdominio, como por ejemplo mycluster-a1b2cdef345678g9hi012j3kl4567890-0003.

Paso 3: Crear y configurar un controlador de Ingress público

Después preparar el dominio y el certificado de TLS, debe crear un controlador de Ingress público y configurar el controlador con el dominio.

Cree un archivo de configuración para un controlador de Ingress público.

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: public-ingress-controller
  namespace: openshift-ingress-operator
spec:
  replicas: 2
  domain: <domain>
  endpointPublishingStrategy:
    loadBalancer:
      scope: External
    type: LoadBalancerService

Cree el recurso de IngressController en el proyecto 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 proyecto 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-ingress-controller.yaml -n openshift-ingress-operator
```

Ejecute el mandato oc get y busque el nombre de host de VPC en el campo EXTERNAL IP del servicio router-public-ingress-controller. En los clústeres de VPC, las direcciones IP externas de los servicios son no estáticas y se mantienen detrás de un nombre de host asignado por VPC.

oc get svc router-public-ingress-controller -n openshift-ingress

Salida de ejemplo

NAME                                  TYPE           CLUSTER-IP       EXTERNAL-IP                             PORT(S)                      AGE
router-public-ingress-controller     LoadBalancer   172.21.57.132    1234abcd-us-south.lb.appdomain.cloud    80/TCP,443/TCP,1940/TCP      3m

Registre el nombre de host de VPC del servicio con el dominio que ha elegido anteriormente.
- Dominio personalizado: trabaje con el proveedor de DNS para añadir el nombre de host de VPC del servicio router-public-ingress-controller 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 router-public-ingress-controller. Cuando ejecute el siguiente mandato, el subdominio que ha especificado en el archivo public-ingress-controller.yaml se generará automáticamente y se registrará con el servicio router-public-ingress-controller. Se genera automáticamente un secreto TLS para el dominio en el proyecto que especifique donde se ejecuta la app. El nombre del secreto sigue un formato truncado del subdominio, como por ejemplo mycluster-a1b2cdef345678g9hi012j3kl4567890-0003.
```
    ibmcloud oc nlb-dns create vpc-gen2 --cluster <cluster_name_or_ID> --lb-host <VPC_hostname> --secret-namespace <project>
    ```
```

Paso 4: Crear el recurso de Ingress

Los recursos de Ingress definen las reglas de direccionamiento que el controlador de Ingress utiliza para direccionar el tráfico a su servicio de app.

Defina un archivo de configuración de recursos de Ingress que utilice el dominio proporcionado por IBM o su dominio personalizado para direccionar el tráfico de entrada de red a los servicios que ha creado anteriormente.
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myingressresource
spec:
  tls:
  - hosts:
    - <subdomain>
    secretName: <custom_secret_name>
  rules:
  - host: <subdomain>
    http:
      paths:
      - path: /<app1_path>
        pathType: Prefix
        backend:
            service:
              name: <app1_service>
              port:
                number: 80
      - path: /<app2_path>
        backend:
            service:
              name: <app2_service>
              port:
                number: 80
```
tls

Si desea utilizar TLS, incluya esta sección TLS en el recurso.

Sustituya <domain> por el subdominio. No utilice * para el host o deje la propiedad de host vacía para evitar anomalías durante la creación de Ingress.

Sustituya <tls_secret_name> por el secreto que ha creado anteriormente que contiene el certificado TLS y la clave para un dominio personalizado o el secreto TLS que se ha generado automáticamente para un subdominio proporcionado por IBM.

host

Sustituya <domain> por el subdominio. Si el clúster tiene varios proyectos donde se exponen las apps, se necesita un recurso de Ingress por proyecto. Puede utilizar el mismo subdominio en cada recurso o distintos subdominios en cada recurso. Por ejemplo, si utiliza un dominio comodín, puede añadir un subdominio comodín al principio del dominio, como por ejemplo subdomain1.custom_domain.net. No utilice * para el host o deje la propiedad de host vacía para evitar anomalías durante la creación de Ingress.

path

Sustituye <app_path> por la ruta en la que tu aplicación está a la escucha. La vía de acceso se añade al dominio personalizado o proporcionado por IBM para crear una ruta exclusiva a su app. Cuando especifica esta ruta en un navegador web, el tráfico de la red se direcciona al controlador de Ingress. El controlador de Ingress busca el servicio asociado y envía el tráfico de red al servicio. A continuación, el servicio reenvía el tráfico a los pods en los que se ejecuta la app. Muchas aplicaciones no escuchan en una ruta específica, sino que utilizan la vía de acceso raíz y un puerto específico. En este caso, defina la vía de acceso raíz como / y no especifique una vía de acceso individual para la aplicación. Por ejemplo, para utilizar http://domain/, introduzca / como ruta. Para http://domain/app1_path, especifique /app1_path como la vía de acceso.

pathType

El método de comparación de vías de acceso de URL. Los valores admitidos son ImplementationSpecific, Exact o Prefix. Para obtener más información y ver ejemplos de cada tipo de ruta, consulta la guía « Documentación de la comunidad « Kubernetes » ».

name

Sustituya <app1_service> y <app2_service>, y así sucesivamente, por el nombre de los servicios que ha creado para exponer las aplicaciones. Si sus apps están expuestas mediante servicios en diferentes proyectos en el clúster, incluya únicamente los servicios de app que se encuentran en el mismo proyecto. Debe crear un recurso de Ingress para cada proyecto donde tiene las apps que desea exponer.

port

El puerto en el que el servicio está a la escucha. Utilice el mismo puerto que ha definido al crear el servicio de Kubernetes para la app.
Cree el recurso de Ingress para el clúster. Asegúrese de que el recurso se despliega en el mismo proyecto que los servicios de apps que ha especificado en el recurso.
```
oc apply -f myingressresource.yaml -n <project>
```
Verifique que el recurso de Ingress se haya creado correctamente. Si los mensajes de los eventos indican un error en la configuración de tu recurso, corrige los valores en tu archivo de recursos y vuelve a aplicar el archivo al recurso.
```
oc describe ingress myingressresource
```

El recurso de Ingress se crea en el mismo proyecto que los servicios de app y sus apps se registran con el controlador de Ingress.

Paso 5: Acceder a la app desde Internet

En un navegador web, escriba el URL del servicio de la app al que va a acceder.

https://<domain>/<app1_path>

Si tiene varias apps expuestas, acceda a dichas apps cambiando la vía de acceso que se añade al final del URL.

https://<domain>/<app2_path>

Si utiliza un dominio comodín, acceda a dichas apps con sus propios subdominios.

http://<subdomain1>.<domain>/<app1_path>

http://<subdomain2>.<domain>/<app1_path>

¿No se puede conectar a la app a través de Ingress? Intente resolverlos consultando Resolución de problemas de Ingress.

Exposición pública de apps que están fuera del clúster

Exponga las apps que están fuera de su clúster al público incluyéndolas en el equilibrio de carga de Ingress público. Las solicitudes públicas entrantes en el dominio personalizado o proporcionado por IBM se reenvían automáticamente a la app externa.

Antes de empezar, asegúrate de que se pueda acceder a la aplicación externa que deseas incluir en el equilibrio de carga del clúster mediante una dirección IP pública.

Para hacer públicas las aplicaciones que se encuentran fuera de tu clúster, sigue estos pasos.

Define un archivo de configuración del servicio « Kubernetes » para la aplicación que expone el controlador Ingress. Este servicio reenvía las solicitudes de entrada a un punto final externo que creará en los siguientes pasos.
```
apiVersion: v1
kind: Service
metadata:
  name: myexternalservice
spec:
  ports:
   - protocol: TCP
     port: <app_port>
```
Cree el servicio en el clúster.
```
oc apply -f myexternalservice.yaml
```
Defina un archivo de configuración de punto final externo. Incluya todas las direcciones IP públicas y puertos que puede utilizar para acceder a la app externa. Ten en cuenta que el nombre del punto final debe coincidir con el nombre del servicio que has creado en el paso anterior; por ejemplo, myexternalservice.
```
kind: Endpoints
apiVersion: v1
metadata:
  name: myexternalservice
subsets:
  - addresses:
      - ip: <external_IP1>
      - ip: <external_IP2>
    ports:
      - port: <external_port>
```
name

Sustituya <myexternalendpoint> por el nombre del servicio de Kubernetes que ha creado anteriormente.

ip

Sustituya <external_IP> por las direcciones IP públicas que se utilizan para conectarse a la aplicación externa.

port

Sustituya <external_port> por el puerto donde escucha la aplicación externa.
Cree el punto final en el clúster.
```
oc apply -f myexternalendpoint.yaml
```
Continúe con el segundo paso en Exponer públicamente apps en clústeres de VPC solo con un punto final de servicio de nube privada o Exponer públicamente apps en clústeres con un punto final de servicio de nube pública.