Entrada en IBM Cloud
Ingress es un método de descubrimiento de servicios Kubernetes que expone los servicios del clúster a la red pública o privada reenviando solicitudes a las apps y equilibrando las cargas de trabajo de 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
Si no desea utilizar los componentes proporcionados por IBM, puede crear componentes personalizados que especifique en su lugar en el recurso de Ingress.
Dominio de ingreso
El dominio de Ingress predeterminado se utiliza para formar un URL exclusivo para cada app del clúster y es el dominio al que hacen referencia las direcciones IP de los ALB del 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 cree o añada su propio dominio registrado con IBM Cloud 's proveedor de dominio interno o con un IBM Cloud Internet Services proveedor externo.
Los ALB privados no hacen referencia al subdominio de Ingress proporcionado por IBMy, en su lugar, requieren un dominio personalizado.
El subdominio se registra en 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 |
|---|---|
* |
El carácter comodín para el subdominio está registrado de forma predeterminada para el clúster. |
<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 de 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 de HTTP, HTTPSo TCP y, a continuación, reenvían dichas solicitudes al pod de app adecuado de acuerdo con las reglas que defina en el recurso de 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 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.
Tenga en cuenta que si una zona falla, puede experimentar fallos intermitentes en las peticiones al ALB de entrada en esa zona.
Certificado TLS predeterminado
Cuando crea un clúster, se crea un certificado TLS predeterminado que puede utilizar con el subdominio de Ingress proporcionado por IBM. Puede especificar el certificado TLS predeterminado, o un certificado personalizado que proporcione, en el recurso de Ingress.
Considere la posibilidad de utilizar Secrets Manager para gestionar de forma centralizada y actualizar automáticamente los certificados de subdominio de Ingress y otros secretos.
La configuración de Ingress con certificados TLS implica la creación o importación de secretos. Si desea utilizar la API de Ingress de IBM Cloud para completar estos pasos, debe tener una instancia predeterminada de 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.