Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Equilibrio de carga

Los balanceadores de carga reciben el tráfico entrante y lo distribuyen entre los destinos de la aplicación prevista alojada en un clúster de EKS. Esto mejora la resiliencia de la aplicación. Cuando se implementa en un clúster de EKS, el controlador de AWS Load Balancer creará y administrará los AWS Elastic Load Balancers para ese clúster. Cuando se crea un servicio de Kubernetes de tipo LoadBalancer similar, el controlador de balanceo de carga de AWS crea un balanceador de carga de red (NLB) que equilibra la carga del tráfico recibido en la capa 4 del modelo OSI. Al crear un objeto de Kubernetes Ingress, el controlador de equilibrio de carga de AWS crea un balanceador de carga de aplicaciones (ALB) que equilibra la carga del tráfico en la capa 7 del modelo OSI.

Elegir el tipo de balanceador de carga

La gama de productos de AWS Elastic Load Balancing (ELB) admite los siguientes balanceadores de carga: balanceadores de carga de aplicaciones (ALB), balanceadores de cargas de red (NLB), balanceadores de carga de puertas de enlace (GWLB) y balanceadores de carga clásicos (CLB). Esta sección de prácticas recomendadas se centrará en el ALB y el NLB, que son los dos más relevantes para los clústeres de EKS.

La consideración principal al elegir el tipo de balanceador de cargas son los requisitos de carga de trabajo.

Para obtener información más detallada y como referencia para todos los balanceadores de carga de AWS, consulte las comparaciones de productos

Elija el balanceador de carga de aplicaciones (ALB) si su carga de trabajo es HTTP/HTTPS

Si una carga de trabajo requiere un equilibrio de carga en la capa 7 del modelo OSI, la controladora del balanceador de carga de AWS se puede usar para aprovisionar un ALB. En la siguiente sección, abordamos el aprovisionamiento. El ALB se controla y configura mediante el recurso Ingress mencionado anteriormente y dirige el tráfico HTTP o HTTPS a diferentes pods del clúster. El ALB brinda a los clientes la flexibilidad de cambiar el algoritmo de enrutamiento del tráfico de las aplicaciones; el algoritmo de enrutamiento predeterminado es de forma rotatoria, y el algoritmo de enrutamiento de solicitudes menos pendientes también es una alternativa.

Elija el balanceador de carga de red (NLB) si su carga de trabajo es TCP o si su carga de trabajo requiere la preservación de la IP de origen de los clientes

El balanceador de cargas de red funciona en la cuarta capa (transporte) del modelo de interconexión de sistemas abiertos (OSI). Es adecuado para cargas de trabajo basadas en TCP y UDP. El balanceador de carga de red también conserva de forma predeterminada la dirección IP de origen de los clientes al presentar el tráfico al pod.

Elija el balanceador de carga de red (NLB) si su carga de trabajo no puede utilizar el DNS

Otra razón clave para usar el NLB es si sus clientes no pueden utilizar el DNS. En este caso, el NLB puede ser más adecuado para su carga de trabajo, ya que las IP de un balanceador de cargas de red son estáticas. Si bien se recomienda a los clientes que utilicen el DNS para convertir los nombres de dominio en direcciones IP cuando se conecten a los balanceadores de carga, si la aplicación de un cliente no admite la resolución de DNS y solo acepta direcciones IP codificadas de forma rígida, entonces una NLB es la opción más adecuada, ya que las IP son estáticas y permanecen inalteradas durante toda la vida del NLB.

Aprovisionamiento de balanceadores de carga

Tras determinar el balanceador de cargas que mejor se adapta a sus cargas de trabajo, los clientes tienen varias opciones para aprovisionar un balanceador de cargas.

Aprovisione los balanceadores de carga mediante la implementación del controlador de balanceo de carga de AWS

Hay dos métodos clave para aprovisionar balanceadores de carga en un clúster de EKS.

De forma predeterminada, el Kubernetes Service Controller, también conocido como controlador integrado en árbol, concilia el tipo de recurso del servicio de Kubernetes. LoadBalancer Este controlador está integrado en el componente AWS Cloud Provider, que funciona como Kubernetes Cloud Controller Manager. https://kubernetes.io/docs/concepts/architecture/cloud-controller/

La configuración del Elastic Load Balancer aprovisionado se controla mediante anotaciones que se deben agregar al manifiesto de Kubernetes Service. Las anotaciones que utilizan el Service Controller y el AWS Load Balancer Controller son diferentes.

El Service Controller es antiguo y, por el momento, solo se están corrigiendo errores críticos. Al crear un servicio de tipo Kubernetes LoadBalancer, el controlador de servicios crea una CLB de AWS de forma predeterminada, pero también puede crear AWS NLB si utilizas la anotación correcta. Vale la pena señalar que Service Controller no admite los recursos de Kubernetes Ingress y tampoco es compatible con IPv6.

Recomendamos usar el AWS Load Balancer Controller en los clústeres de EKS para conciliar los recursos de Kubernetes Service e Ingress. Debe usar las anotaciones correctas en su manifiesto de Kubernetes Service o Ingress para que AWS Load Balancer Controller sea el propietario del proceso de reconciliación. (en lugar de Service Controller)

Si utiliza el modo automático de EKS, se le proporcionará automáticamente la controladora del balanceador de carga de AWS; no es necesaria ninguna instalación.

Cómo elegir Load Balancer Target-Type

Registra los pods como objetivos mediante IP Target-Type

Un Elastic Load Balancer: Network & Application de AWS envía el tráfico recibido a los objetivos registrados de un grupo objetivo. En el caso de un clúster de EKS, hay dos tipos de objetivos que puede registrar en el grupo objetivo: instancia e IP. El tipo de destino que se utilice influye en lo que se registra y en la forma en que se dirige el tráfico del balanceador de carga al pod. De forma predeterminada, el controlador del balanceador de cargas de AWS registrará los objetivos utilizando el tipo «instancia» y este objetivo será la IP del nodo de trabajoNodePort, lo que implica lo siguiente:

Por el contrario, si configuras el tipo de destino como «IP», como recomendamos, la implicación será la siguiente:

Para crear un AWS Elastic Load Balancing que utilice objetivos de IP, añada:

Configuración de las comprobaciones de estado del balanceador de carga

Si bien Kubernetes ofrece sus propios mecanismos de control de estado (que se detallan en la siguiente sección), recomendamos implementar los controles de estado de ELB como una medida de seguridad complementaria que funcione fuera del plano de control de Kubernetes. Esta capa independiente sigue supervisando tu aplicación incluso durante:

Para las cargas de trabajo críticas que requieren la máxima disponibilidad y una recuperación acelerada en los escenarios mencionados anteriormente, las comprobaciones de estado de ELB proporcionan una red de seguridad esencial que funciona junto con los mecanismos nativos de Kubernetes, y no los reemplaza.

Para configurar y ajustar con precisión las comprobaciones de estado de tu ELB, debes usar anotaciones en el manifiesto de Ingress o Service de Kubernetes que puedan conciliar con Service Controller o AWS Load Balancer Controller.

Disponibilidad y ciclo de vida del pod

Durante la actualización de una aplicación, debe asegurarse de que la aplicación esté siempre disponible para procesar las solicitudes, de modo que los usuarios no sufran ningún tiempo de inactividad. Un desafío común en este escenario es sincronizar el estado de disponibilidad de las cargas de trabajo entre la capa de Kubernetes y la infraestructura, por ejemplo, con los balanceadores de carga externos. En las siguientes secciones se destacan las mejores prácticas para abordar estos escenarios.

Utilice comprobaciones de estado

De forma predeterminada, Kubernetes ejecuta la verificación del estado del proceso, en la que el proceso de kubelet del nodo verifica si el proceso principal del contenedor se está ejecutando o no. De lo contrario, de forma predeterminada, reinicia ese contenedor. Sin embargo, también puedes configurar las sondas de Kubernetes para identificar cuándo un proceso contenedor se está ejecutando pero está en un estado de interbloqueo, o si una aplicación se ha iniciado correctamente o no. Las sondas se pueden basar en los mecanismos exec, grpc, HttpGet y TCPSocket. https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#probe-check-methods Según el tipo y el resultado de la sonda, se puede reiniciar el contenedor.

Consulta la sección sobre la creación de un pod en el apéndice que aparece a continuación para revisar la secuencia de eventos del proceso de creación del pod.

Usa sondas de preparación

De forma predeterminada, cuando todos los contenedores de un pod están en funcionamiento, el estado del pod se considera «Listo». Sin embargo, es posible que la aplicación aún no pueda procesar las solicitudes de los clientes. Por ejemplo, es posible que la aplicación necesite extraer algunos datos o configuraciones de un recurso externo para poder procesar las solicitudes. En ese estado, no querrá eliminar la aplicación ni reenviarle ninguna solicitud. La sonda de preparación le permite asegurarse de que el pod no se considera «listo», lo que significa que no se agregará al EndpointSlice objeto hasta que se obtenga el resultado de la sondasuccess. Por otro lado, si la sonda falla más adelante, la cápsula se retira del EndpointSlice objeto. Puedes configurar una sonda de disponibilidad en el manifiesto del pod para cada contenedor. kubeletEl proceso de cada nodo ejecuta la sonda de disponibilidad en los contenedores de ese nodo.

Utilice las compuertas de preparación de las cápsulas

Un aspecto de la sonda de disponibilidad es el hecho de que no contiene ningún feedback/influence mecanismo externo. El proceso kubelet del nodo ejecuta la sonda y define el estado de la sonda. Esto no tiene ningún impacto en las solicitudes entre los propios microservicios de la capa de Kubernetes (tráfico de este a oeste), ya que el EndpointSlice controlador mantiene la lista de puntos finales (pods) siempre actualizada. Entonces, ¿por qué y cuándo necesitarías un mecanismo externo?

Cuando expones tus aplicaciones usando el tipo Load Balancer o Kubernetes Ingress (para tráfico norte-sur), la lista de direcciones IP de pod del servicio de Kubernetes correspondiente debe propagarse al balanceador de cargas de la infraestructura externa para que el balanceador de cargas también tenga una lista de objetivos actualizada. En este sentido, AWS Load Balancer Controller cierra esta brecha. Cuando utiliza AWS Load Balancer Controller y lo aprovechatarget group: IP, kube-proxy al igual que el AWS Load Balancer Controller, también recibe una actualización (víawatch) y, a continuación, se comunica con la API del ELB para configurar y empezar a registrar la IP del pod como destino en el ELB.

Al realizar una actualización continua de una implementación, se crean nuevos pods y, en cuanto el estado de un nuevo pod es «Listo», se cancela el pod. old/existing Durante este proceso, el EndpointSlice objeto de Kubernetes se actualiza más rápido que el tiempo que tarda el ELB en registrar los nuevos pods como objetivos (consulta la sección sobre el registro de objetivos). https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-register-targets.html Durante un breve período de tiempo, es posible que haya una discrepancia de estado entre la capa de Kubernetes y la capa de infraestructura, lo que podría provocar que se eliminaran las solicitudes de los clientes. Durante este período, dentro de la capa de Kubernetes, los nuevos pods estarían listos para procesar las solicitudes, pero desde el punto de vista de ELB, no lo están.

Pod Readiness Gates te permite definir los requisitos adicionales que deben cumplirse antes de que la condición del pod se considere «lista». En el caso del AWS ELB, la controladora del balanceador de carga de AWS monitoriza el estado del objetivo (el pod) en el AWS ELB y, una vez que se complete el registro del objetivo y su estado pase a ser «correcto», el controlador actualizará el estado del pod a «Listo». Con este enfoque, se influye en el estado del pod en función del estado de la red externa, que es el estado objetivo en el AWS ELB. El sistema Pod Readiness Gates es crucial en los escenarios de actualizaciones sucesivas, ya que permite evitar que la actualización continua de una implementación cancele los pods antiguos hasta que el estado objetivo de los pods recién creados pase a ser «correcto» en el AWS ELB.

Cierre correctamente las aplicaciones

Su aplicación debería responder a una señal de SIGTERM iniciando su cierre correcto para que los clientes no sufran ningún tiempo de inactividad. Esto significa que la aplicación debe ejecutar procedimientos de limpieza, como guardar datos, cerrar los descriptores de los archivos, cerrar las conexiones a las bases de datos, completar correctamente las solicitudes en curso y salir a tiempo para cumplir con la solicitud de finalización del pod. Debes establecer el período de gracia para que sea lo suficientemente largo como para que la limpieza pueda finalizar. Para aprender a responder a la señal SIGTERM, puede consultar los recursos del lenguaje de programación correspondiente que utilice para su aplicación.

Si su aplicación no puede cerrarse correctamente al recibir una señal SIGTERM o si ignores/does no recibe la señal, puede utilizar PreStop Hook para iniciar un cierre correcto de la aplicación. El enlace Prestop se ejecuta inmediatamente antes de enviar la señal SIGTERM y puede realizar operaciones arbitrarias sin tener que implementarlas en el propio código de la aplicación.

La secuencia general de eventos se muestra en el siguiente diagrama. Nota: independientemente del resultado de un procedimiento de cierre correcto de la aplicación o del enlace, los PreStop contenedores de la aplicación terminan eventualmente al final del período de gracia mediante SIGKILL.

Consulte la sección sobre la eliminación de un pod en el apéndice que aparece a continuación para revisar la secuencia de eventos del proceso de eliminación de un pod.

Gestione con elegancia las solicitudes de los clientes

La secuencia de eventos en la eliminación de un pod es diferente a la de la creación de un pod. Cuando se crea un pod, se kubelet actualiza la IP del pod en la API de Kubernetes y solo entonces se actualiza el EndpointSlice objeto. Por otro lado, cuando se cierra un pod, la API de Kubernetes notifica al kubelet y al controlador al mismo tiempo. EndpointSlice Revisa cuidadosamente el siguiente diagrama, que muestra la secuencia de eventos.

La forma en que el estado se propaga desde el servidor API hasta las reglas de iptables en los nodos explicadas anteriormente crea una condición de carrera interesante. Como existe una alta probabilidad de que el contenedor reciba la señal SIGKILL mucho antes de que el kube-proxy de cada nodo actualice las reglas locales de iptables. En tal caso, dos escenarios que vale la pena mencionar son:

Definir el período de gracia en las especificaciones del Pod durante el tiempo suficiente puede solucionar este problema, pero dependiendo del retraso de propagación y del número de solicitudes reales de los clientes, es difícil anticipar el tiempo que tardará la aplicación en cerrar las conexiones correctamente. Por lo tanto, el enfoque no tan perfecto pero más factible es usar un PreStop gancho para retrasar la señal SIGTERM hasta que se actualicen las reglas de iptables para garantizar que no se envíen nuevas solicitudes de clientes a la aplicación, sino que solo se mantengan las conexiones existentes. PreStop hook puede ser un controlador Exec simple, como. sleep 10

El comportamiento y la recomendación mencionados anteriormente serían igualmente aplicables cuando expongas tus aplicaciones utilizando el tipo Load Balancer de Kubernetes Service o Kubernetes Ingress (para el tráfico de norte a sur) utilizando AWS Load Balancer Controller y apalancamiento. target group: IP Porque, kube-proxy al igual que AWS Load Balancer, el controlador también recibe una actualización (a través de un reloj) sobre el EndpointSlice objeto y, a continuación, se comunica con la API del ELB para empezar a anular el registro de la IP del pod del ELB. Sin embargo, dependiendo de la carga de la API de Kubernetes o de la API de ELB, esto también puede llevar tiempo y es posible que el SIGTERM ya se haya enviado a la aplicación hace mucho tiempo. Una vez que el ELB comienza a anular el registro del objetivo, deja de enviar solicitudes a ese objetivo, por lo que la aplicación no recibirá ninguna solicitud nueva. Además, el ELB inicia un retraso de cancelación del registro, que es de 300 segundos de forma predeterminada. Durante el proceso de cancelación del registro, el ELB básicamente espera a que se agoten las conexiones draining en vuelo con ese objetivo. requests/existing Una vez transcurrido el plazo de anulación del registro, el objetivo no se utiliza y se descarta por la fuerza cualquier solicitud dirigida a ese objetivo durante el vuelo.

Usa Pod Disruption Budget

Configure un presupuesto de interrupción de módulos (PDB) para sus aplicaciones. El PDB limita la cantidad de pods de una aplicación replicada que están inactivos simultáneamente debido a interrupciones voluntarias. https://kubernetes.io/docs/concepts/workloads/pods/disruptions/#voluntary-and-involuntary-disruptions Garantiza que haya un número o porcentaje mínimo de pods disponibles en una implementación o implementación. StatefulSet Por ejemplo, una aplicación basada en quórum debe garantizar que el número de réplicas en ejecución nunca sea inferior al número necesario para un quórum. O bien, una interfaz web puede garantizar que la cantidad de réplicas que se sirven nunca caiga por debajo de un determinado porcentaje del total. PDB protegerá la aplicación contra acciones como el agotamiento de los nodos o el lanzamiento de nuevas versiones de las implementaciones. Tenga en cuenta que los PDB no protegerán la aplicación contra interrupciones involuntarias, como un fallo del sistema operativo del nodo o la pérdida de la conectividad de la red. Para obtener más información, consulta la documentación sobre cómo especificar un presupuesto de interrupción para tu aplicación en Kubernetes.

Referencias

Apéndice

Creación de pods

Es imprescindible entender cuál es la secuencia de eventos en un escenario en el que se despliega un pod y luego pasa healthy/ready a recibir y procesar las solicitudes de los clientes. Hablemos de la secuencia de eventos.

Eliminación del pod

Al igual que ocurre con la creación de un pod, es imprescindible entender cuál es la secuencia de eventos que se producen durante la eliminación de un pod. Hablemos de la secuencia de eventos.