Skip to main content

Mejores Prácticas EKS

Arquitectura​

  • Piense en multilocación, aislamiento para entorno diferente o carga de trabajo diferente
    • Aislamiento a nivel de cuenta usando la organización de AWS
    • Aislamiento en la capa de red, es decir, VPC diferente y cluster diferente
    • Use grupos de nodos diferentes (pool de nodos) para propósito/categoría diferente, por ejemplo, cree grupos de nodos dedicados para herramientas operacionales, como herramienta CI/CD, herramienta de monitoreo, sistema de log centralizado.
    • Namespace separado para carga de trabajo diferente

Confiabilidad | Principios​

  • Recomendado usar VPC dedicada para EKS
  • Entienda y verifique Cuota de servicio de EKS/Fargate y otros servicios relacionados
  • Implemente el Cluster Autoscaler para ajustar automáticamente el tamaño de un cluster EKS hacia arriba y hacia abajo basándose en las demandas de programación.
  • Considere el número de nodos del trabajador y la degradación del servicio si hay falla de nodo/AZ.
    • Cuide del RTO.
    • Considere tener un nodo de buffer.
  • Considere no elegir un tipo de instancia muy grande para reducir el radio de explosión.
  • Habilite el Horizontal Pod Autoscaler para usar la utilización de la CPU o métricas personalizadas para expandir los pods.
  • Use la infraestructura como código (archivos y plantillas de manifiesto de Kubernetes para aprovisionar clusters/nodos de EKS, etc.)
  • Use múltiples AZs. Distribuya las réplicas de la aplicación para diferentes zonas de disponibilidad del nodo del trabajador para redundancia
    • Cuidado con sus pods persistentes que usan EBS como PersistentVolume. Use anotación, por ejemplo, topology.kubernetes.io/zone=us-east-1c
  • Nodos de trabajo altamente disponibles y escalables usando grupos de Auto Scaling, use grupo de nodos
    • Considere usar Grupos de nodos gestionados para fácil configuración y alta disponibilidad de nodos durante actualizaciones o terminación
    • Considere usar Fargate para no tener que gestionar nodos de trabajo. Pero cuidado con las limitaciones de Fargate.
  • Considere separar el Node Group para sus funciones de aplicación y utilidad, por ejemplo, base de datos de log, plano de control de service mesh
  • Implemente aws-node-termination-handler. Detecta si el nodo quedará no disponible/terminado, como interrupción de spot, entonces asegúrese de que ningún nuevo trabajo sea programado allí y luego drénelo, removiendo cualquier trabajo existente. Tutorial | Anuncio
  • Configure Pod Disruption Budgets (PDBs) para limitar el número de pods de una aplicación replicada que están inactivos simultáneamente de interrupciones voluntarias, por ejemplo, durante la actualización, despliegue continuo y otros casos de uso.
  • Use AWS Backup para hacer backup de EFS y EBS
  • Use EFS para clase de almacenamiento: el uso de EFS no requiere el pre-aprovisionamiento de la capacidad y permite migraciones de pod más eficientes entre nodos de trabajo (removiendo almacenamiento anexado al nodo)
  • Instale el Node Problem Detector para proporcionar datos accionables para curar clusters.
  • Evite errores de configuración, como el uso de antiafinidad, que hace con que el pod no pueda ser reprogramado debido a falla del nodo.
  • Use sondas de vivacidad y prontitud
  • Practique la ingeniería del caos, use herramientas disponibles para automatizar.
    • Mate pods aleatoriamente durante el test
  • Implementar el gerenciamiento de fallas a nivel de microservicio, por ejemplo, patrón de disyuntor, controlar y limitar llamadas de repetición (retroceso exponencial), limitación, tornar los servicios sin estado siempre que sea posible
  • Practique cómo hacer upgrade del cluster y de los nodos del trabajador para la nueva versión.
    • Practique cómo drenar los nodos del trabajador.
  • Practique la ingeniería del caos
  • Utilizar herramientas de CI/CD, automatizar y tener flujo de procesos (aprobación/revisión) para cambios de infraestructura. Considere implementar Gitops.
  • Use solución multi-AZ para volumen persistente, por ejemplo, Thanos+S3 for Prometheus

Eficiencia de Rendimiento | Principios​

  • Informe al soporte de AWS si necesita pre-escalar el Plano de Control (Nodo maestro y Etcd) en caso de incremento de carga repentino
  • Elija el tipo de instancia de EC2 correcto para su nodo del trabajador.
    • Entienda los pros y contras de usar muchas instancias de nodos pequeños o pocas instancias de nodos grandes. Considere la sobrecarga del SO, el tiempo necesario para extraer la imagen en una nueva instancia cuando es dimensionada, la sobrecarga del kubelet, la sobrecarga del pod del sistema, etc.
    • Entienda la limitación de densidad de pods (número máximo de pods compatible con cada tipo de instancia)
  • Use grupos de nodos single-AZ, si es necesario. Normalmente, una de las mejores prácticas es ejecutar un microservicio en Multi-AZ para disponibilidad, pero para algunas cargas de trabajo (como Spark) que necesitan de latencia de microsegundos, con alta operación de E/S de red y transientes, se hace el envío para usar single-AZ.
  • Entienda la limitación de rendimiento de Fargate. Haga el test de carga antes de ir a la producción.
  • Asegúrese de que su pod solicite los recursos necesarios. Definir recursos request y limit como CPU, memoria
  • Detectar cuello de botella/latencia en un microservicio con el X-Ray u otros productos de rastreo/APM
  • Elija el backend de almacenamiento correcto. Use el Amazon FSx for Lustre y su CSI Driver si su contenedor persistente necesita de un sistema de archivos de alto rendimiento
  • Monitoree el consumo de recursos de pods y nodos y el embudo de tecnología. Puede usar CloudWatch, CloudWatch Container Insight u otros productos
  • Si es necesario, inicie instancias (nodos de trabajo) en Placement Groups para aprovechar la baja latencia sin disminuir la velocidad. Puede usar esta plantilla de CloudFormation para añadir nuevos grupos de nodos con conectividad sin bloqueo, sin exceso de suscripción y totalmente bi-seccional.
  • Si es necesario, configure la política de gerenciamiento de CPU de Kubernetes como 'static' para algunos pods que necesitan CPUs exclusivas

Optimización de costos​

  • Minimice los recursos desperdiciados (no utilizados) al usar EC2 como nodo del trabajador.
    • Elija el tipo de instancia de EC2 correcto y use el dimensionamiento automático de cluster.
    • Considere usar Fargate
    • Considere usar una herramienta como kube-resource-report para visualizar el costo de holgura y dimensionar correctamente las solicitudes para los contenedores en un pod.
  • Use instancias spot o mezcle bajo demanda y spot usando Spot Fleet. Considere usar instancias spot para entorno de test/staging.
  • Usar instancia reservada o planes de ahorro
  • Use grupos de nodos de AZ único para carga de trabajo con alta operación de E/S de red (por ejemplo, Spark) para reducir la comunicación entre AZ. Pero, por favor, valide si la ejecución del Single-AZ no comprometería la disponibilidad de su sistema.
  • Considere los servicios gestionados para herramientas de soporte, como monitoreo, service mesh, log centralizado, para reducir el esfuerzo y el costo de su equipo
  • Marque todos los recursos de AWS cuando sea posible y use etiquetas para marcar los recursos de Kubernetes para que pueda analizar fácilmente el costo.
  • Considere usar Kubernetes de autogestionamiento (no usando EKS) para cluster sin HA. Puede configurar usando Kops para su pequeño cluster k8s.
  • Use Node Affinities usando nodeSelector para pod que requiere un tipo de instancia EC2 específico.

Operación: Principios​

Seguridad | Principios​

Packer for AMI build: Configuración de Packer para crear una AMI EKS personalizada