Ingress: NGINX en IBM Cloud
Ingress es un método de descubrimiento de servicios de Kubernetes que expone los servicios de su clúster a la red pública o privada reenviando solicitudes a sus aplicaciones y equilibrando las cargas de trabajo del tráfico de red. Ingress gestiona el acceso externo a los servicios basándose en un conjunto de reglas de direccionamiento que configura y que se aplican a todo el tráfico de entrada.
Al suministrar un clúster IBM Cloud Kubernetes Service, IBM proporciona todos los componentes necesarios para utilizar Ingress. A continuación, cuando esté preparado para empezar, cree un recurso de Ingress para especificar cómo funcionan juntos estos componentes.
Para obtener más información sobre Kubernetes Ingress, consulte la documentación deKubernetes.
Componentes de Ingress proporcionados por IBM
Todos los componentes necesarios para utilizar Ingress se proporcionan al crear un clúster. Especifique estos componentes al crear el recurso de Ingress.
- Dominio de ingreso
- Clase Ingress
- Equilibradores de carga de aplicación (ALB)
- Certificado TLS
Dominio de ingreso
El dominio de entrada predeterminado se utiliza para formar un URL único para cada aplicación de su clúster, y es el dominio al que hacen referencia las direcciones IP de cualquier ALB de su clúster. Cuando crea un clúster, se crea automáticamente un subdominio de Ingress exclusivo y se registra como dominio predeterminado. Puede cambiar el dominio predeterminado por cualquier dominio que exista en el clúster.
También puede crear o añadir su propio dominio registrado con el proveedor de dominios interno de IBM Cloud o con un proveedor externo de IBM Cloud Internet Services.
Los ALB privados no hacen referencia al subdominio Ingress proporcionado por IBM, sino que requieren un dominio personalizado.
El subdominio está registrado con el siguiente formato.
<cluster_name>-<globally_unique_account_HASH>-0000.<region>.containers.appdomain.cloud
La siguiente tabla describe cada parte del subdominio.
| Componente del subdominio | Descripción |
|---|---|
<cluster_name> |
El nombre del clúster.
|
<globally_unique_account_HASH> |
Se crea un HASH globalmente exclusivo para su cuenta de IBM Cloud. Todos los subdominios que cree para NLB en clústeres de su cuenta utilizan este HASH globalmente exclusivo. |
0000 |
Actúa como contador para cada subdominio que se crea en el clúster. |
<region> |
La región donde se ha creado el clúster. |
containers.appdomain.cloud |
El subdominio de los subdominios de IBM Cloud Kubernetes Service. |
Para formar un URL exclusivo para cada app, las vías de acceso a los servicios de la app se añaden a la ruta pública. Por ejemplo, consulte el siguiente URLde la app.
mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud/myapp1
Clase Ingress
La clase de Ingress determina el tipo de controlador de Ingress que se utiliza. IBM proporciona dos clases Ingress, una pública (public-iks-k8s-nginx) y otra privada (private-iks-k8s-nginx). Ambas clases implementan
el controlador NGINX Ingress. Al crear el recurso de Ingress, la clase de Ingress que especifique determina si las apps se exponen pública o privadamente.
Puede utilizar una clase de Ingress personalizada creando su propio recurso de IngressClass.
Equilibradores de carga de aplicación (ALB)
Los ALB escuchan las solicitudes de servicio entrantes HTTP, HTTPS o TCP y, a continuación, las reenvían al pod de aplicaciones adecuado de acuerdo con las reglas definidas en el recurso Ingress. Cuando crea un clúster estándar con infraestructura clásica o de VPC, se crea automáticamente un ALB público y uno privado en cada zona.
ALB en clústeres clásicos
Cuando crea un clúster clásico, se crea automáticamente un ALB público y uno privado en cada zona. A los ALB públicos y privados de los clústeres clásicos se les asigna una dirección IP estática que no cambia durante la vida del clúster.
Los ALB públicos comparten el mismo subdominio de Ingress proporcionado por IBMque está registrado al suministrar un clúster, y cada dirección IP individual del ALB público está enlazada a este subdominio. Para buscar la dirección IP de
un ALB público, ejecute ibmcloud ks ingress alb ls y compruebe el campo IP de ALB en la salida.
Los ALB privados en clústeres clásicos no utilizan el subdominio de Ingress proporcionado por IBMy no se habilitan automáticamente. Primero debe habilitar los ALB privados en la CLI y, a continuación, especificar la clase private-iks-k8s-nginx en el recurso de Ingress. Después de habilitar los ALB privados, puede encontrar las direcciones IP privadas ejecutando ibmcloud ks ingress alb ls y comprobando el campo IP de ALB en la salida.
Si se vuelve a planificar un pod de ALB público o privado, mantiene la misma dirección IP. Sin embargo, si se elimina una zona con un ALB, o se eliminan todos los trabajadores de una VLAN de esa zona, se elimina la dirección IP del ALB.
ALB en VPC
Cuando crea un clúster de VPC, se crea automáticamente un ALB público y uno privado en cada zona. Además, se crea automáticamente un equilibrador de carga de VPC público fuera del clúster en la VPC. Cuando habilita los ALB privados en el clúster de VPC, también se crea un equilibrador de carga de VPC privado.
Las direcciones IP para los ALB en los clústeres de VPC no son estáticas y pueden cambiar con el tiempo, por lo que los equilibradores de carga de VPC colocan la dirección IP pública o privada de los ALB detrás de un nombre de host estático. Se aplican nombres de host separados para ALB públicos o privados. Tenga en cuenta que el nombre de host de ALB está separado del subdominio de Ingress del clúster.
Para buscar el nombre de host de un ALB en un clúster de VPC, ejecute ibmcloud ks ingress alb ls. Los nombres de host privados sólo se listan si los ALB privados están habilitados.
Requisitos de nodo trabajador para ALB
Se necesitan al menos dos nodos trabajadores por zona en el clúster para que los ALB funcionen con alta disponibilidad y para recibir actualizaciones periódicas. Las reglas de antiafinidad en los pods de ALB garantizan que sólo se planifique un pod en cada nodo trabajador. Cuando se aplican actualizaciones automáticas a los pods de ALB, el pod se recarga. Si solo tiene un nodo trabajador y, por lo tanto, un pod de ALB, el pod no se actualiza automáticamente para evitar interrupciones de tráfico, y las actualizaciones sólo se aplican cuando suprime manualmente el pod y vuelve a planificar uno nuevo. Tener al menos dos nodos trabajadores por zona evita este escenario.
Ten en cuenta que, si una zona deja de funcionar, es posible que se produzcan fallos intermitentes en las solicitudes dirigidas al ALB de Ingress de dicha zona.
Certificado por defecto TLS
Al crear un clúster, se crea un certificado predeterminado TLS que puede utilizar con el subdominio Ingress proporcionado por IBM. Puede especificar el certificado predeterminado TLS, o un certificado personalizado que usted proporcione, en el recurso Ingress.
Considere el uso de Secrets Manager para gestionar de forma centralizada y actualizar automáticamente sus certificados de subdominio Ingress y otros secretos.
Configurar Ingress con certificados TLS implica crear o importar secretos. Si desea utilizar la API IBM Cloud Ingress para completar estos pasos, debe disponer de una instancia predeterminada Secrets Manager. De lo contrario, puede utilizar
mandatos kubectl para copiar los certificados.
Iniciación a Ingress
Cuando esté preparado para utilizar Ingress en el clúster, cree un recurso de Ingress para configurar los componentes de Ingress, defina reglas para las solicitudes de direccionamiento y especifique la vía de acceso a los servicios de la app. Se necesita un recurso de Ingress independiente para cada espacio de nombres que contenga una app o un servicio que desee exponer.