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.
Mejores prácticas de confiabilidad
En esta sección se proporciona orientación sobre cómo hacer que las cargas de trabajo que se ejecutan en EKS sean resilientes y tengan un alto nivel de disponibilidad
Cómo usar esta guía
Esta guía está dirigida a desarrolladores y arquitectos que desean desarrollar y operar servicios de alta disponibilidad y tolerantes a errores en EKS. La guía está organizada en diferentes áreas temáticas para facilitar su uso. Cada tema comienza con una breve descripción general, seguida de una lista de recomendaciones y mejores prácticas para la confiabilidad de los clústeres de EKS.
Introducción
Las prácticas recomendadas de confiabilidad para EKS se han agrupado en los siguientes temas:
-
Aplicaciones
-
Plano de control
-
Plano de datos
¿Qué hace que un sistema sea confiable? Si un sistema puede funcionar de manera consistente y satisfacer las demandas a pesar de los cambios en su entorno durante un período de tiempo, se puede decir que es confiable. Para lograrlo, el sistema debe detectar las fallas, repararse automáticamente y tener la capacidad de escalar en función de la demanda.
Los clientes pueden usar Kubernetes como base para operar de manera confiable las aplicaciones y los servicios de misión crítica. Sin embargo, además de incorporar los principios de diseño de aplicaciones basados en contenedores, la ejecución confiable de las cargas de trabajo también requiere una infraestructura confiable. En Kubernetes, la infraestructura comprende el plano de control y el plano de datos.
EKS proporciona un plano de control de Kubernetes de nivel de producción que está diseñado para ofrecer alta disponibilidad y tolerancia a fallos.
En EKS, AWS es responsable de la confiabilidad del plano de control de Kubernetes. EKS ejecuta el plano de control de Kubernetes en tres zonas de disponibilidad de una región de AWS. Gestiona automáticamente la disponibilidad y escalabilidad de los servidores de API de Kubernetes y del clúster, etc.
La responsabilidad de la confiabilidad del plano de datos la comparten usted, el cliente y AWS. EKS ofrece cuatro opciones de nodos de trabajo para implementar el plano de datos de Kubernetes.
El modo automático de EKS, que es la opción más gestionada, gestiona el aprovisionamiento, el escalado y las actualizaciones del plano de datos, además de proporcionar capacidades gestionadas de procesamiento, redes y almacenamiento. Las AMI en modo automático se publican con frecuencia y los clústeres se actualizan automáticamente a la AMI más reciente para implementar las correcciones de CVE y los parches de seguridad. Puede controlar cuándo ocurre esto configurando los controles de interrupción en el modo automático. NodePools
Fargate gestiona el aprovisionamiento y el escalado del plano de datos mediante la ejecución de un pod por nodo. La tercera opción, la gestión de los grupos de nodos, gestiona el aprovisionamiento y las actualizaciones del plano de datos. Y, por último, los nodos autogestionados son la opción menos gestionada para el plano de datos. Cuanto más plano AWS-managed de datos utilice, menor será la responsabilidad que tendrá.
Los grupos de nodos administrados automatizan el aprovisionamiento y la administración del ciclo de vida de los nodos de EC2. Puede utilizar la API de EKS (mediante la consola de EKS, la API de AWS, la CLI de AWSCloudFormation, Terraform oeksctl) para crear, escalar y actualizar los nodos gestionados. Los nodos gestionados ejecutan instancias EC2 de EKS-optimized Amazon Linux 2 en su cuenta y puede instalar paquetes de software personalizados habilitando el acceso por SSH. Cuando aprovisionas nodos gestionados, estos se ejecutan como parte de un grupo de EKS-managed Auto Scaling que puede abarcar varias zonas de disponibilidad; esto lo controlas a través de las subredes que proporcionas al crear los nodos gestionados. EKS también etiqueta automáticamente los nodos gestionados para que puedan usarse con Cluster Autoscaler.
Amazon EKS sigue el modelo de responsabilidad compartida para CVE y los parches de seguridad en grupos de nodos administrados. Como los nodos administrados ejecutan las EKS-optimized AMI de Amazon, Amazon EKS es responsable de crear versiones parcheadas de estas AMI cuando se corrigen los errores. Sin embargo, es responsable de implementar estas versiones de AMI parcheadas en los grupos de nodos administrados.
EKS también gestiona la actualización de los nodos, aunque usted tiene que iniciar el proceso de actualización. El proceso de actualización del nodo gestionado se explica en la documentación de EKS.
Si ejecuta nodos autogestionados, puede usar la AMI de Amazon EKS-optimized Linux para crear nodos de trabajo. Usted es responsable de aplicar parches y actualizar la AMI y los nodos. Se recomienda utilizar eksctl la infraestructura como herramientas de código para aprovisionar los nodos autogestionados CloudFormation, ya que esto facilitará la actualización de los nodos autogestionados. Considere la posibilidad de migrar a nodos nuevos al actualizar los nodos de trabajo, ya que el proceso de migración mancha el grupo de nodos anterior NoSchedule y agota los nodos una vez que una pila nueva está lista para aceptar la carga de trabajo de los pods existente. Sin embargo, también puede realizar una actualización in situ de los nodos autogestionados.
Modelo de responsabilidad compartida: Fargate
Modelo de responsabilidad compartida - MNG
Esta guía incluye un conjunto de recomendaciones que puedes usar para mejorar la confiabilidad de tu plano de datos de EKS, de los componentes principales de Kubernetes y de tus aplicaciones.
Comentarios
Esta guía se publica el GitHub para recopilar comentarios y sugerencias directos de la comunidad en general. EKS/Kubernetes Si tiene una buena práctica que cree que deberíamos incluir en la guía, presente un problema o envíe un PR al GitHub repositorio. Tenemos la intención de actualizar la guía periódicamente a medida que se agreguen nuevas funciones al servicio o cuando surja una nueva práctica recomendada.