Traefik Ingress en IBM Cloud
Ingress expone los servicios de tu clúster a una red pública o privada. Reenvía las solicitudes a tus aplicaciones y gestiona el acceso externo según las reglas de enrutamiento que configures.
Al configurar un clúster de IBM Cloud Kubernetes Service, puedes habilitar uno o varios controladores de Ingress basados en Traefik. IBM proporciona los componentes necesarios para utilizar el controlador de Ingress. Para definir cómo interactúan los componentes, crea recursos de Ingress.
Para obtener más información sobre Ingress de Kubernetes, consulta la documentación de Kubernetes.
IBM-componentes de Ingress proporcionados
Al crear un clúster, « IBM » proporciona los componentes necesarios para utilizar Ingress. En tu recurso de Ingress, debes especificar cómo se utilizan estos componentes.
- Dominio de ingreso
- Clase de Ingress
- Equilibradores de carga de aplicación (ALB)
- Certificado TLS
Dominio de ingreso
El dominio predeterminado de Ingress genera una dirección URL única para cada aplicación de tu clúster. A este dominio hacen referencia las direcciones IP de cualquier ALB de tu clúster.
Al crear un clúster, se crea automáticamente un subdominio de Ingress único y se registra como dominio predeterminado. Puedes cambiar el dominio predeterminado por cualquier dominio que exista en tu clúster.
Los ALB privados no hacen referencia al subdominio de Ingress proporcionado por IBM, sino que requieren un dominio personalizado.
También puedes crear o añadir tu propio dominio registrado con el proveedor de dominios interno de IBM Cloud o con un proveedor externo de IBM Cloud Internet Services.
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 de tu clúster.
|
<globally_unique_account_HASH> |
Se crea un HASH globalmente exclusivo para su cuenta de IBM Cloud. Todos los subdominios que crees para los NLB de los clústeres de tu cuenta utilizan este hash. |
0000 |
Sirve como contador para cada subdominio que se cree en tu clúster. |
<region> |
La región en la que se crea el clúster. |
containers.appdomain.cloud |
El subdominio de los subdominios de IBM Cloud Kubernetes Service. |
Para generar una URL única URL para cada aplicación, las rutas de los servicios de la aplicación se añaden a la ruta pública. Por ejemplo, echa un vistazo a la siguiente aplicación: URL.
mycluster-a1b2cdef345678g9hi012j3kl4567890-0000.us-south.containers.appdomain.cloud/myapp1
Clase de Ingress
La clase «Ingress» determina el tipo de controlador Ingress que se utiliza. IBM ofrece dos clases «Ingress»: una pública (public-iks-traefik) y otra privada (private-iks-traefik). Ambas clases implementan el controlador
Ingress de Traefik. Al crear tu recurso de Ingress, la clase de Ingress que especifiques determina si tus aplicaciones se exponen de forma pública o privada.
Puedes utilizar una clase de Ingress personalizada configurando ingressClass en la configuración de implementación personalizable.
Equilibradores de carga de aplicación (ALB)
Los ALB escuchan las solicitudes de servicio entrantes dirigidas a HTTP, HTTPS o TCP y las reenvían al pod de la aplicación correspondiente, según las reglas que definas en el recurso Ingress.
Al crear un clúster estándar con infraestructura clásica o VPC, se crean automáticamente un ALB público y otro privado en cada zona.
ALB en clústeres clásicos
Al crear un clúster clásico, se crean automáticamente un ALB público y otro 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 toda la vida útil del clúster.
Los ALB públicos comparten el mismo subdominio de Ingress proporcionado por IBM, que se registra a tu nombre al aprovisionar un clúster, y la dirección IP individual de cada ALB público está vinculada a este subdominio. Para averiguar la
dirección IP de un ALB público, ejecuta el comando « ibmcloud ks ingress alb ls » y comprueba el campo «ALB IP» en el resultado.
Los ALB privados en clústeres clásicos no utilizan el subdominio de Ingress proporcionado por IBM y no se activan automáticamente. Primero debes habilitar los ALB privados en la CLI y, a continuación, especificar la clase « private-iks-traefik » en tu recurso Ingress. Una vez habilitados los ALB privados, puedes averiguar las direcciones IP privadas ejecutando el comando « ibmcloud ks ingress alb ls » y consultando el campo «ALB IP» en el resultado.
Si se reprograma un pod ALB público o privado, conserva la misma dirección IP. Sin embargo, al eliminar una zona con un ALB, o al eliminar todos los servidores de una VLAN de esa zona, se elimina la dirección IP de dicho ALB.
ALB en VPC
Al crear un clúster de VPC, se crean automáticamente un ALB público y otro privado en cada zona. Además, se crea automáticamente un equilibrador de carga público de VPC fuera de tu clúster, dentro de tu VPC. Al habilitar los ALB privados en tu clúster de VPC, también se crea un equilibrador de carga privado de VPC.
Las direcciones IP de los ALB en los clústeres de VPC no son estáticas y pueden cambiar con el tiempo. Por lo tanto, los equilibradores de carga de VPC sitúan la dirección IP pública o privada de tus ALB detrás de un nombre de host estático. Se utilizan nombres de host distintos para los ALB públicos y privados. El nombre de host de ALB es independiente del subdominio de Ingress del clúster.
Para averiguar el nombre de host de un ALB en un clúster de VPC, ejecuta el comando « ibmcloud ks ingress alb ls ». Los nombres de host privados solo aparecen en la lista si se han habilitado los ALB privados.
Requisitos de los nodos de trabajo para los ALB
Se necesitan al menos dos nodos de trabajo por zona en el clúster para que los ALB funcionen con alta disponibilidad y reciban actualizaciones periódicas.
Las reglas de anti-afinidad en los pods de ALB garantizan que solo se programe un pod por cada nodo de trabajo. Cuando se aplican actualizaciones automáticas a los pods de ALB, el pod se recarga.
Si solo tienes un nodo de trabajo y, por lo tanto, un único pod de ALB, el pod no se actualiza automáticamente para evitar interrupciones en el tráfico. En ese caso, las actualizaciones solo se aplican cuando se elimina manualmente el pod y se programa uno nuevo. Contar con al menos dos nodos de trabajo por zona evita que se produzca esta situación.
Ten en cuenta que, si una zona falla, es posible que se produzcan fallos intermitentes en las solicitudes dirigidas al ALB de Ingress de esa zona.
Certificado predeterminado de « TLS »
Al crear un clúster, se genera un certificado predeterminado de TLS que puedes utilizar con el subdominio de Ingress proporcionado por IBM. Puedes especificar el certificado predeterminado de TLS o un certificado personalizado que facilites en el recurso Ingress.
Te recomendamos que utilices Secrets Manager para gestionar de forma centralizada y actualizar automáticamente los certificados de tus subdominios de Ingress y otros secretos.
La configuración de Ingress con certificados de TLS implica crear o importar secretos. Si quieres utilizar la API de Ingress de IBM Cloud para seguir estos pasos, debes disponer de una instancia predeterminada de Secrets Manager. Si no, puedes
utilizar comandos de « kubectl » para copiar tus certificados.
Primeros pasos con Ingress
Cuando estés listo para utilizar Ingress en tu clúster, crea un recurso Ingress para configurar los componentes de Ingress, definir reglas de enrutamiento de solicitudes y especificar la ruta de acceso a los servicios de aplicaciones. Se necesita un recurso de Ingress independiente para cada espacio de nombres que contenga una aplicación o un servicio que quieras hacer público.