Exposición privada de aplicaciones con Ingress
Exponga de forma privada varias aplicaciones en su clúster 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.
- función de acceso al servicio Director " en todos los espacios de nombres " IBM Cloud Kubernetes Service " (proyectosRed Hat OpenShift ").
- 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.
- Clusters VPC: Permitir solicitudes de tráfico que son enrutadas por Ingress a puertos de nodos en sus nodos trabajadores.
- Clústeres multizona VPC: Si creó un clúster en la CLI y posteriormente añadió manualmente zonas a sus pools de trabajadores con el comando '
ibmcloud oc zone add vpc-gen2
', debe actualizar el equilibrador de carga de VPC que expone el controlador Ingress para incluir subredes para todas las zonas de su clúster. - Clústeres clásicos: habilite una función de direccionador virtual (VRF) para la cuenta de infraestructura de IBM Cloud. Para comprobar si un VRF ya está habilitado,
utilice el mandato
ibmcloud account show
. Si no puedes o no quieres habilitar VRF, habilita VLAN spanning. 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 privada de apps con un punto final de servicio de nube pública
Clústeres clásicos Virtual Private Cloud
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 las apps de forma privada, primero debe crear un controlador de Ingress privado. 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 la terminación TLS con certificados TLS y secretos de Kubernetes
El certificado TLS debe almacenarse como un secreto de Kubernetes en cada espacio de nombres donde existan las apps.
Secretos TLS para dominios personalizados
Para configurar secretos TLS para un dominio que ha creado usted mismo, como un dominio registrado con un proveedor externo, consulte Configuración de secretos TLS para subdominios personalizados. Estos pasos son válidos tanto para clusters clásicos como para clusters VPC.
Secretos TLS para el dominio gestionado por IBM
-
Clústeres clásicos Para utilizar el dominio de Ingress gestionado por IBMen un clúster clásico, consulteConfiguración de secretos TLS para el subdominio de Ingress proporcionado por IBM.
-
Clústeres de VPC Para utilizar el dominio de Ingress gestionado por IBMen un clúster de VPC, siga estos pasos.
- 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.
En esta salida de ejemplo, el subdominioibmcloud oc nlb-dns ls --cluster <cluster_name_or_id>
mycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud
tiene el valor de000<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 por000<n+1>
. Por ejemplo, el valor del subdominiomycluster-a1b2cdef345678g9hi012j3kl4567890-0002.us-south.containers.appdomain.cloud
se cambia amycluster-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 TLS para el dominio. El nombre del secreto sigue un formato truncado del subdominio, como por ejemplomycluster-a1b2cdef345678g9hi012j3kl4567890-0003
.
Paso 3: Crear y configurar un controlador de Ingress privado
Después preparar el dominio y el certificado de TLS, debe crear un controlador de Ingress privado y configurar el controlador con el dominio.
- Cree un archivo de configuración para un controlador de Ingress privado.
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: private-ingress-controller 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: Internal type: LoadBalancerService
- Cree el recurso de IngressController en el proyecto de
openshift-ingress-operator
del clúster. Al crear el IngressController, se crea automáticamente un controlador Ingress privado y se despliega en el proyectoopenshift-ingress
basándose en la configuración de IngressController que estableció en el paso anterior. Además, se crea un servicio de controlador de entrada para exponer el controlador de entrada con una dirección IP (clústeres clásicos) o un nombre de host VPC (clústeres VPC).oc create -f private-ingress-controller.yaml -n openshift-ingress-operator
- Ejecute el mandato
oc get
y busque la dirección IP o el nombre de host de VPC en el campo EXTERNAL IP del serviciorouter-private-ingress-controller
.
Salida de ejemplo para clústeres clásicos.oc get svc router-private-ingress-controller -n openshift-ingress
Ejemplo de salida para clústeres de VPC:NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE router-private-ingress-controller LoadBalancer 172.21.57.132 10.XX.XX.XX 80/TCP,443/TCP,1940/TCP 3m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE router-private-ingress-controller LoadBalancer 172.21.57.132 1234abcd-us-south.lb.appdomain.cloud 80/TCP,443/TCP,1940/TCP 3m
- Registre la dirección IP externa o 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 la dirección IP externa del servicio
router-private-ingress-controller
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: cree una entrada de DNS para el nombre de host de VPC del servicio
router-private-ingress-controller
. Cuando se ejecute el siguiente mandato, el subdominio que ha especificado en el archivoprivate-ingress-controller.yaml
se genera automáticamente y se registra con el serviciorouter-private-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 ejemplomycluster-a1b2cdef345678g9hi012j3kl4567890-0003
.ibmcloud oc nlb-dns create vpc-gen2 --cluster <cluster_name_or_ID> --lb-host <VPC_hostname> --secret-namespace <project>
- Dominio personalizado: trabaje con el proveedor de DNS para añadir la dirección IP externa del servicio
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> backend: service: name: <app1_service> port: number: 80 - path: /<app2_path> backend: serivce: 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.
- Si desea utilizar TLS, incluya esta sección TLS en el recurso. Sustituya
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.
- Sustituya
path
-
- Sustituye '
<app_path>
' por la ruta en la que tu aplicación está escuchando. 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/
, especifique/
como vía de acceso. Parahttp://domain/app1_path
, especifique/app1_path
como la vía de acceso.
- Sustituye '
serviceName
- 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 Ingress para cada proyecto que contenga aplicaciones que desee exponer. servicePort
- 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 en los eventos describen un error en la configuración de su recurso, corrija los valores en su archivo de recursos y vuelva a aplicar el archivo para el 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 su red privada
-
Clústeres clásicos: para poder acceder a la app, asegúrese de que puede acceder a un servicio DNS. Para utilizar el proveedor de DNS externo predeterminado, debe configurar nodos periféricos con acceso público y configurar un Virtual Router Appliance virtual.
-
Desde dentro de su red privada, especifique el URL del servicio de app en un navegador web.
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 privada de apps en clústeres de VPC solo con un punto final de servicio en la nube privado
Si su clúster se ha creado en una infraestructura VPC y solo ha activado el punto final del servicio de nube privada al crear el clúster, puede utilizar el controlador de entrada privado predeterminado para exponer las aplicaciones de su clúster a las solicitudes de la red privada.
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 la terminación TLS con certificados TLS y secretos de Kubernetes
El certificado TLS debe almacenarse como un secreto de Kubernetes en cada espacio de nombres donde existan las apps.
-
Para utilizar el dominio de Ingress gestionado por IBM, consulte Configuración de secretos TLS para el subdominio de Ingress proporcionado por IBM.
-
Para utilizar un dominio que ha creado usted mismo, como un dominio registrado con un proveedor externo, consulte Configuración de secretos 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: - <custom_domain> secretName: <custom_secret_name> rules: - host: <domain> http: paths: - path: /<app1_path> 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 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
osubdomain1.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.
- Sustituya
path
-
- Sustituye '
<app_path>
' por la ruta en la que tu aplicación está escuchando. 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/
, especifique/
como vía de acceso. Parahttp://domain/app1_path
, especifique/app1_path
como la vía de acceso.
- Sustituye '
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 en los eventos describen un error en la configuración de su recurso, corrija los valores en su archivo de recursos y vuelva a aplicar el archivo para el 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 aplicación
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.