Considerations and CCM resource update policies for configuring Service load balancing - Container Service for Kubernetes

Cuando un Service se configura con Type=LoadBalancer, ACK Cloud Controller Manager (CCM) crea o configura un load balancer (Classic Load Balancer o Network Load Balancer), lo que incluye la instancia, los listeners y los grupos de servidores de backend. Este tema explica las consideraciones para configurar el balanceo de carga de Service y las políticas de actualización de recursos de CCM.

Consideraciones

¿Qué instancias de SLB se pueden reutilizar?

Solo se pueden reutilizar las instancias creadas en la consola de Server Load Balancer (SLB). No es posible reutilizar las instancias de SLB que cloud-controller-manager crea automáticamente ni las que gestiona ACK (como la instancia del API Server).
Para reutilizar una instancia privada de SLB, esta debe estar en la misma Virtual Private Cloud (VPC) que el clúster. La reutilización entre distintas VPC solo aplica a instancias NLB.
El tipo de dirección de la instancia de SLB reutilizada debe coincidir con el tipo de acceso del Service. Si el Service está configurado para Public Access (mediante la anotación service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "internet"), el campo IP Version de la instancia de SLB debe ser Public. Si el Service está configurado para acceso interno (mediante la anotación service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet"), el campo IP Version de la instancia de SLB debe ser Private.
Varios Services no pueden usar el mismo puerto de listener de una misma instancia de SLB.
Al reutilizar una instancia de SLB entre varios clústeres, asegúrese de que la combinación de namespace y nombre del Service sea única en cada clúster.

Consideraciones para las instancias de SLB gestionadas por CCM

CCM solo configura el balanceo de carga para los Services de tipo Type=LoadBalancer.

Importante

Si un Service Type=LoadBalancer cambia a otro tipo, CCM elimina las configuraciones de SLB. El Service deja de ser accesible a través de la instancia de SLB.

CCM utiliza una API declarativa y puede actualizar la configuración de SLB según los cambios del Service. Las modificaciones manuales en la consola de SLB podrían sobrescribirse.

Importante

No modifique las configuraciones de las instancias de SLB gestionadas por ACK desde la consola de SLB. Sus cambios podrían perderse y el Service podría dejar de ser accesible.

No elimine ni modifique el finalizer service.k8s.alibaba/resources ni service.k8s.alibaba/nlb. Esto podría impedir que los recursos de CLB o NLB se liberen correctamente.
En Cloud Controller Manager v2.5.0 o versiones posteriores, especificar una instancia de CLB al crear un Service requiere estar en una lista de permitidos. Envíe una solicitud en Quota Center.

Consideraciones para acceder a la IP externa de un Service LoadBalancer desde dentro del clúster

Cuando accede a la dirección IP de SLB de un Service LoadBalancer desde dentro del clúster, la red del clúster podría interceptar el tráfico y reenviarlo directamente al endpoint del Service de backend. Este comportamiento depende del tipo de complemento de red, su versión y la versión del clúster.

Esto omite la instancia externa de SLB y provoca que fallen las configuraciones que dependen de ella. Los principales escenarios afectados son a continuación:

externalTrafficPolicy está establecido en Local: el acceso puede fallar si el tráfico se reenvía a un nodo sin pods de backend.
Proxy Protocol está habilitado: el servicio de backend no puede obtener el encabezado de Proxy Protocol de la instancia de SLB, lo que provoca un fallo en el handshake.
Listener HTTP/HTTPS: las operaciones que dependen de SLB, como la terminación TLS o la adición de encabezados como X-Forwarded-For, no surten efecto.

Por lo tanto, para acceder a un Service LoadBalancer desde dentro del clúster:

Utilice la dirección interna del Service (ClusterIP o un nombre DNS como <service-name>.<namespace>.svc.cluster.local) para lograr una comunicación estable entre servicios.
Para acceder mediante el punto de entrada de SLB, agregue la anotación service.beta.kubernetes.io/alibaba-cloud-loadbalancer-hostname y use el nombre de dominio configurado en lugar de la dirección IP. Consulte Set a hostname for a Service.

Importante
Al usar esta función, evite programar el pod cliente y el pod servidor en el mismo nodo. El enrutamiento asimétrico puede provocar fallos de acceso.

Consideraciones para gestionar el balanceo de carga a gran escala en un solo clúster con CCM

En clústeres grandes, CCM puede tardar en procesar los eventos de Service. A continuación se muestran los escenarios que pueden retrasar operaciones como la creación o eliminación de instancias de SLB y la actualización de endpoints de grupos de servidores:

Se crean o eliminan muchos Services LoadBalancer al mismo tiempo.
Se actualizan muchos endpoints de Service al mismo tiempo.
Se agregan o eliminan nodos por lotes cuando existen muchos Services LoadBalancer.

Siga estas prácticas:

Antes de aplicar cambios a gran escala, evalúe la capacidad y ejecute pruebas de estrés. Reserve suficiente margen de procesamiento para evitar interrupciones.
Use configuraciones como los hooks readinessGates y preStop para evitar interrupciones de tráfico durante los cambios. Consulte Implement zero-downtime rolling deployments.
Cuando utilice muchos Services LoadBalancer, monitoree de cerca las quota limits de CLB y NLB.
Actualice el clúster y CCM a las versiones más recientes para aprovechar las optimizaciones en escenarios a gran escala.

Reemplazar la instancia de SLB de un Service

No es posible reemplazar directamente la instancia de SLB de un Service LoadBalancer existente. En su lugar, elimine y vuelva a crear el Service.

Acceso externo y ruta del tráfico de red

Cuando usa un Service LoadBalancer para exponer aplicaciones al exterior, comprender la ruta del tráfico le ayuda a dimensionar correctamente el ancho de banda y a localizar los datos de monitoreo.

Ruta del tráfico

La ruta de la solicitud es: Cliente → Internet → Load Balancer (CLB/NLB) → Red interna de Alibaba Cloud → Contenedores o nodos de backend. El tráfico entre el load balancer y los nodos de backend viaja por la red interna de Alibaba Cloud, no por el ancho de banda público de los nodos del clúster.

Error común sobre el ancho de banda

Aumentar el ancho de banda público de los nodos de ACK no resuelve los problemas de alta concurrencia o picos de tráfico en servicios expuestos al exterior. Esto se debe a que el tráfico de negocio no pasa por la salida de red pública del nodo. El consumo de ancho de banda público ocurre únicamente entre el cliente y el load balancer. Para resolver cuellos de botella en el rendimiento del acceso externo, ajuste la especificación de ancho de banda del load balancer en lugar del ancho de banda público del nodo.

Monitoreo del tráfico de subida y bajada

Para consultar el tráfico de subida y bajada de un Service, inicie sesión en la consola de CLB o NLB y revise los datos de monitoreo en la página de monitoreo de la instancia correspondiente. El monitoreo a nivel de nodo no refleja el rendimiento real del tráfico de un Service expuesto al exterior.

Métodos y restricciones de acceso desde fuera del clúster

Restricciones de acceso a ClusterIP

Las instancias de ECS u otros recursos externos al clúster que se encuentran en la misma VPC no pueden acceder directamente a la ClusterIP de un Service. ClusterIP es una dirección IP virtual que solo es accesible dentro de la red del clúster. Cualquier intento de acceder a ClusterIP desde una instancia de ECS externa fallará.

Método de acceso recomendado: LoadBalancer privado

Para acceder a las aplicaciones del clúster desde otras instancias de ECS en la misma VPC, cree un Service de tipo LoadBalancer con un tipo de dirección de intranet. Para ello, agregue la siguiente anotación:

service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: intranet

Esto crea una instancia privada de SLB accesible desde dentro de la VPC. Utilice la dirección IP privada de SLB generada para acceder al Service desde las instancias de ECS externas.

Inestabilidad de las direcciones IP de los pods

Las direcciones IP de los pods se asignan dinámicamente y cambian cuando un pod se reinicia, por lo que no son adecuadas como endpoints de acceso fijos. Use un LoadBalancer privado o un Service NodePort para proporcionar un punto de acceso estable y persistente a las aplicaciones del clúster.

Límites de cuota

VPC

Cada nodo del clúster consume una entrada de la tabla de rutas de VPC. El límite predeterminado es de 200 entradas. Si su clúster supera los 200 nodos, log on to the Quota Center console and submit an application.
Consulte VPC limits and quotas.

Para consultar las cuotas de VPC, consulte gestión de cuotas de VPC.

Server Load Balancer

CCM crea una instancia de SLB por cada Service Type=LoadBalancer. La cuota predeterminada es de 60 instancias de CLB y 60 de NLB. Para aumentar esta cuota, log on to the Quota Center console and submit an application.
CCM adjunta instancias de ECS o Elastic Network Interfaces (ENI) al grupo de servidores de backend de SLB según la configuración del Service, y crea un grupo de servidores independiente por cada targetPort. Límites de cuota:
- Número de servidores de backend: una instancia de CLB admite hasta 200 servidores de backend; una instancia de NLB admite hasta 400 servidores basados en ECS, ENI o IP. Fórmula de la cuota: servidores de backend × targetPorts. Para aumentar la cuota, log on to the Quota Center console and submit an application con anticipación.
- Asignaciones de grupos de servidores por instancia: una instancia de ECS o ENI se puede adjuntar a un máximo de 50 grupos de servidores de backend de CLB y 200 de NLB. Para aumentar este límite, log on to the Quota Center console and submit an application.
- Cuota adicional durante actualizaciones continuas: los nuevos pods se crean antes de destruir los antiguos, lo que consume una cuota adicional que puede superar lo esperado. Reserve suficiente cuota con anticipación.
CCM crea listeners según los puertos del Service. El límite predeterminado es de 50 listeners por instancia de CLB o NLB. Para agregar más, log on to the Quota Center console and submit an application.
Consulte CLB limits y NLB limits.

Consulte las cuotas de SLB en gestión de cuotas de Server Load Balancer.

Políticas de actualización de instancias de SLB

Puede especificar una instancia de SLB existente o permitir que CCM cree una. Las políticas de actualización difieren entre estos dos métodos.

Objeto de recurso	Especificar una instancia de SLB existente	Instancia de SLB gestionada por CCM
Server Load Balancer	Establezca la anotación: `service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id`. CCM utiliza esta instancia como load balancer del Service, la configura según las demás anotaciones y crea grupos vServer. Cuando se elimina el Service, CCM conserva la instancia de SLB especificada.	CCM crea y configura recursos como la instancia de SLB, los listeners y los grupos vServer según la configuración del Service. Cuando se elimina el Service, CCM elimina la instancia de SLB creada automáticamente.
Listener	Establezca la anotación: `service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners`: Si se establece en `"false"`, CCM no gestiona ninguna configuración de listener para la instancia de SLB. Si se establece en `"true"`, CCM gestiona los listeners según la configuración del Service. Si ya existe un listener, CCM lo sobrescribe.	CCM crea y configura la política del listener según la configuración del Service.
Grupo de servidores de backend	Cuando cambian los endpoints de backend del Service o los nodos del clúster, CCM actualiza los grupos vServer de backend. Terway: de forma predeterminada, CCM adjunta las direcciones IP de los pods al backend de SLB en lugar de los nodos de ECS. Flannel: la política de actualización del grupo de servidores de backend varía según el modo del Service. Modo clúster (`spec.externalTrafficPolicy = Cluster`): de forma predeterminada, CCM adjunta todos los nodos al backend de SLB, a menos que el backend esté configurado con BackendLabel. Importante Cada instancia de ECS tiene límites en cuanto a la cantidad de instancias de SLB que puede usar. El modo clúster consume esta cuota rápidamente. Cuando se agota, los Services no se pueden reconciliar. Utilice el modo Local para resolverlo. Modo Local (`spec.externalTrafficPolicy = Local`): CCM solo agrega al backend de SLB los nodos que ejecutan los pods del Service. Esto reduce el consumo de la cuota de SLB y conserva las direcciones IP de origen de capa 4. Flannel: CCM nunca agrega nodos maestro al backend de SLB. Flannel: de forma predeterminada, CCM no quita del backend de SLB los nodos vaciados (`kubectl drain`) ni los no programables (`kubectl cordon`). Para quitarlos, establezca `service.beta.kubernetes.io/alibaba-cloud-loadbalancer-remove-unscheduled-backend` en `on`.

Habilitar la protección contra eliminación para un Service

La protección contra eliminación evita que se quiten accidentalmente Services que manejan operaciones de negocio críticas o datos sensibles. Los recursos protegidos solo se pueden eliminar después de deshabilitar manualmente la protección. Consulte Enable deletion protection for a Service.