Equilibrio de carga para apps mediante el descubrimiento de servicios de Kubernetes

El descubrimiento de servicios de Kubernetes proporciona apps con conexión de red utilizando servicios de red y un proxy de Kubernetes local.

A todas las pods que se despliegan en un nodo trabajador se les asigna una dirección IP privada en el rango 172.30.0.0/16 y se direccionan únicamente entre nodos trabajadores. Para evitar conflictos, no utilice este rango de IP en ningún otro nodo que se vaya a comunicar con los nodos trabajadores. Los nodos trabajadores y los pods pueden comunicarse de forma segura a través de la red privada utilizando direcciones IP privadas. Sin embargo, cuando un pod se cuelga o cuando es necesario volver a crear un nodo trabajador, se signa una nueva dirección IP privada.

En lugar de intentar realizar un seguimiento de direcciones IP privadas cambiantes para las apps que deben ofrecer una alta disponibilidad, puede utilizar funciones integradas de descubrimiento de servicios de Kubernetes para exponer las apps como servicios. Un servicio de Kubernetes agrupa un conjunto de pods y proporciona una conexión de red a estos pods. El servicio selecciona los pods de destino a los que direcciona el tráfico, a través de etiquetas.

Un servicio proporciona conectividad entre los pods de app y los demás servicios del clúster sin exponer la dirección IP privada real de cada pod. A los servicios se les asigna una dirección IP interna, la clusterIP, a la que solo se puede acceder dentro del clúster. Esta dirección IP está vinculada al servicio durante toda su vida útil y no cambia mientras existe el servicio. A los servicios se les asigna una IP de una de las 65.000 IP del rango 172.21.0.0/16.

Para evitar conflictos, no utilice este rango de IP en ningún otro nodo que se vaya a comunicar con los nodos trabajadores. También se crea una entrada de búsqueda de DNS para el servicio y se almacena en el componente kube-dns del clúster. La entrada DNS contiene el nombre del servicio, el espacio de nombres en el que se ha creado el servicio y el enlace a la dirección IP asignada interna del clúster.

Si tiene previsto conectar el clúster a las redes locales mediante IBM Cloud o un servicio VPN, es posible que tenga conflictos de subred con el rango predeterminado 172.30.0.0/16 para los pods y el rango 172.21.0.0/16 para los servicios. Puede evitar conflictos de subred cuando crear un clúster especifique un CIDR de subred personalizado para los pods en la opción --pod-subnet y un CIDR de subred personalizado para los servicios en la opción --service-subnet.

Para proporcionar el equilibrio de carga básico de todo el tráfico de red TCP y UDP para servicios, un proxy de red Kubernetes local, kube-proxy, se ejecuta como un daemon en cada nodo de trabajador en el espacio de nombres kube-system. kube-proxy utiliza las reglas de Iptables, una característica de kernel de Linux, para dirigir las solicitudes al pod detrás de un servicio por igual, independientemente de las direcciones IP en clúster de los pods y del nodo de trabajador en el que están desplegados.

Por ejemplo, las apps de dentro del clúster pueden acceder a un pod detrás de un servicio de clúster utilizando la IP interna del clúster del servicio o enviando una solicitud al nombre del servicio. Cuando se utiliza el nombre del servicio, kube-proxy busca el nombre en el proveedor de DNS del clúster y direcciona la solicitud a la dirección IP interna del clúster del servicio.

Si utiliza un servicio que proporciona una dirección IP de clúster interna y una dirección IP externa, los clientes de fuera del clúster pueden enviar solicitudes a la dirección IP pública o privada externa del servicio. kube-proxy reenvía las solicitudes a la dirección IP en clúster del servicio y equilibra la carga entre los pods de aplicación detrás del servicio.

Tipos de servicio de Kubernetes

Kubernetes admite cuatro tipos básicos de servicios de red: ClusterIP, NodePort, LoadBalancer, y Ingress. Los servicios de ClusterIP facilitan el acceso a las aplicaciones a nivel interno para permitir la comunicación entre pods solo en el clúster. Los servicios de NodePort, LoadBalancer y Ingress facilitan el acceso a las aplicaciones a nivel externo desde Internet público o desde una red privada.

En la tabla siguiente se comparan las características de cada tipo de servicio de red.

* Un certificado SSL para el equilibrio de carga de HTTPS se proporciona mediante mandatos ibmcloud ks nlb-dns. En clústeres clásicos, estos mandatos solo reciben soporte para NLB públicos.

NodePort

Cuando expones aplicaciones con un servicio NodePort, se asigna al servicio un NodePort en el rango de 30000 - 32767 y una dirección IP interna del cluster. Para acceder al servicio desde fuera del clúster, se utiliza la dirección IP pública o privada de cualquier nodo trabajador y el NodePort en el formato <IP_address>:<nodeport>. No obstante, las direcciones IP públicas y privadas del nodo trabajador no son permanentes. Cuando un nodo trabajador se elimina o se vuelve a crear, se le asigna una nueva dirección IP pública.

Los NodePorts son ideales para probar el acceso público o privado o para proporcionar acceso sólo por un breve período de tiempo. Nota:: puesto que los nodos de trabajador de los clústeres de VPC no tienen una dirección IP pública, sólo puede acceder a una aplicación a través de un NodePort si está conectado a la red privada de VPC, como por ejemplo a través de una conexión VPN.

LoadBalancer

El tipo de servicio LoadBalancer se implementa de forma diferente en función del proveedor de infraestructura del clúster.

Servicios de LoadBalancer en clústeres clásicos

Infraestructura clásica

Equilibrador de carga de red(NLB). Cada clúster estándar se suministra con cuatro direcciones IP públicas portátiles y cuatro privadas portátiles que puede utilizar para crear un equilibrador de carga de red (NLB) TCP/UDP de capa 4 para la app. Puede personalizar el NLB exponiendo cualquier puerto que necesite la app. Las direcciones IP públicas y privadas portátiles que se asignan al NLB son permanentes y no cambian cuando se vuelve a crear un nodo de trabajador en el clúster. Puede crear un subdominio para la app que registre las direcciones IP de NLB pública con una entrada de DNS. También puede habilitar los supervisores de comprobación de estado en las IP de NLB para cada subdominio.

Servicios de LoadBalancer en clústeres de VPC

Nube privada virtual

Equilibrador de carga para VPC. Cuando crea un servicio LoadBalancer de Kubernetes para una app en el clúster, se crea automáticamente un equilibrador de carga de VPCde capa 7 en la VPC fuera del clúster. El equilibrador de carga de VPC es multizona y direcciona las solicitudes de la app a través de los NodePorts privados que se abren automáticamente en los nodos trabajadores. De forma predeterminada, el equilibrador de carga también se crea con un nombre de host que se puede utilizar para acceder a la app.

Ingress

Exponga varias aplicaciones en un clúster configurando el enrutamiento con el equilibrador de carga de aplicaciones (ALB) de Ingress. El ALB utiliza un punto de entrada único público o privado protegido y un subdominio de Ingress para direccionar las solicitudes entrantes a sus apps. Puede utilizar un subdominio para exponer varias apps en el clúster como servicios. Ingress consta de tres componentes:

• El recurso de Ingress define las reglas sobre cómo direccionar y equilibrar la carga de las solicitudes de entrada para una app.
• El ALB está a la escucha de solicitudes entrantes de servicio HTTP, HTTPS o TCP. Reenvía las solicitudes a través de los pods de las apps con base a las reglas que se definen en el recurso Ingress.
• El equilibrador de carga multizona (MZLB) para clústeres clásicos o el equilibrador de carga de VPC para clústeres de VPC gestiona todas las solicitudes de entrada a las apps y equilibra la carga de las solicitudes entre los ALB de diversas zonas. También habilita las comprobaciones de estado para las direcciones IP públicas de Ingress.

Planificación del equilibrio de carga externo público

Exponer públicamente una app del clúster en internet.

En los clústeres clásicos, puede conectar nodos trabajadores a una VLAN pública. La VLAN pública determina la dirección IP pública que se asigna a cada nodo trabajador, lo que proporciona a cada nodo trabajador una interfaz de red pública. Los servicios de red públicos se conectan a esta interfaz de red pública proporcionando a su app una dirección IP pública y, opcionalmente, un URL público.

En clústeres de VPC, los nodos trabajadores solo se conectan a subredes de VPC privadas. Sin embargo, cuando se crean servicios de red públicos, se crea automáticamente un equilibrador de carga de VPC. El equilibrador de carga de VPC puede direccionar solicitudes públicas a la app especificando la app en un URL público. Cuando se expone públicamente una app, cualquiera que tenga el URL público puede enviar una solicitud a la app.

Cuando se expone públicamente una app, cualquiera que tenga la dirección IP pública del servicio o el URL que haya establecido para la app puede enviar una solicitud a la app. Por este motivo, exponga las menos apps posibles. Exponga una app al público solo cuando la app esté preparada para aceptar tráfico procedente de clientes o usuarios web externos.

La interfaz de red pública de los nodos trabajadores está protegida por valores predefinidos de política de red de Calico que se configuran en cada nodo trabajador durante la creación del clúster. De forma predeterminada, todo el tráfico de red de salida está permitido para todos los nodos trabajadores. El tráfico de red de entrada está bloqueado, excepto en algunos puertos. Estos puertos están abiertos para que IBM pueda supervisar el tráfico de red e instalar automáticamente actualizaciones de seguridad para el maestro de Kubernetes, de modo que se puedan establecer conexiones con los servicios NodePort, LoadBalancer e Ingress. Para obtener más información sobre estas políticas, incluido cómo modificarlas, consulte Políticas de red.

Elección de un patrón de despliegue para clústeres clásicos

Para hacer que una app esté disponible públicamente en Internet en un clúster clásico, elija un patrón de despliegue de equilibrio de carga que utilice los servicios públicos NodePort, LoadBalancer o Ingress. En la tabla siguiente se describe cada patrón de despliegue posible, por qué se puede utilizar y cómo configurarlo. Para obtener información básica acerca de los servicios de red que utilizan estos patrones de despliegue, consulte Tipos de servicio de Kubernetes.

Elección de un patrón de despliegue para clústeres de VPC

Para hacer que una app esté disponible públicamente en Internet en un clúster de VPC, elija un patrón de despliegue de equilibrio de carga que utilice los servicios públicos LoadBalancer o Ingress. En la tabla siguiente se describe cada patrón de despliegue posible, por qué se puede utilizar y cómo configurarlo. Para obtener información básica acerca de los servicios de red que utilizan estos patrones de despliegue, consulte Tipos de servicio de Kubernetes.

Planificación del equilibrio de carga externo privado

Exponer de forma privada una app del clúster solo en la red privada.

Al desplegar una app en un clúster de Kubernetes en IBM Cloud Kubernetes Service, puede que desee que la app sea accesible sólo para usuarios y servicios que se encuentren en la misma red privada que el clúster. El equilibrio de carga privado es ideal para hacer que la app esté disponible para las solicitudes desde fuera del clúster sin exponer la app al público en general. También puede utilizar el equilibrio de carga privado para probar el acceso, el direccionamiento de solicitudes y otras configuraciones para la app antes de exponer su app al público con los servicios de red públicos.

Como ejemplo, supongamos que ha creado un equilibrador de carga privado para la app. Puede acceder a este equilibrador de carga privado:

• Cualquier pod en ese mismo clúster.
• Cualquier pod en cualquier clúster de la misma cuenta de IBM Cloud.
• Si no está en la cuenta de IBM Cloud sino todavía detrás del cortafuegos de la empresa, cualquier sistema a través de una conexión VPN a la subred donde se encuentra la IP del equilibrador de carga.
• Si está en una cuenta de IBM Cloud distinta, cualquier sistema a través de una conexión VPN a la subred donde se encuentra la IP del equilibrador de carga.
• En clústeres clásicos, si tiene habilitado VRF o la distribución de VLAN, cualquier sistema que esté conectado a cualquiera de las VLAN privadas de la misma cuenta de IBM Cloud.
• En clústeres de VPC:
  • Si permite el tráfico entre subredes de VPC, cualquier sistema de la misma VPC.
  • Si permite el tráfico entre VPC, cualquier sistema que tenga acceso a la VPC en la que se encuentra el clúster.