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.
Plano de datos EKS
Para operar aplicaciones resilientes y de alta disponibilidad, necesita un plano de datos resiliente y de alta disponibilidad. Un plano de datos elástico garantiza que Kubernetes pueda escalar y reparar sus aplicaciones automáticamente. Un plano de datos resiliente consta de dos o más nodos de trabajo, puede crecer y reducirse con la carga de trabajo y recuperarse automáticamente de los fallos.
Tiene dos opciones para los nodos de trabajo con EKS: EC2instancias y Fargate. Si elige EC2 instancias, puede administrar los nodos de trabajo usted mismo o usar los grupos de nodos administrados por EKS. Puede tener un clúster con una combinación de nodos de trabajo gestionados y autogestionados y Fargate.
EKS on Fargate ofrece la ruta más sencilla hacia un plano de datos resiliente. Fargate ejecuta cada pod en un entorno informático aislado. Cada pod que se ejecuta en Fargate tiene su propio nodo de trabajo. Fargate escala automáticamente el plano de datos a medida que Kubernetes escala los pods. Puede escalar tanto el plano de datos como su carga de trabajo mediante el escalador automático de cápsulas horizontales.
La forma preferida de escalar los EC2 nodos de trabajo es usar Kubernetes Cluster Autoscaler,
Recomendaciones
Use EC2 Auto Scaling Groups para crear nodos de trabajo
Se recomienda crear nodos de trabajo mediante grupos de EC2 Auto Scaling en lugar de crear EC2 instancias individuales y unirlas al clúster. Auto Scaling Groups reemplazará automáticamente cualquier nodo terminado o fallido, garantizando que el clúster siempre tenga la capacidad de ejecutar su carga de trabajo.
Usa el escalador automático de clústeres de Kubernetes para escalar los nodos
El escalador automático de clústeres ajusta el tamaño del plano de datos cuando hay pods que no se pueden ejecutar porque el clúster no tiene recursos suficientes, por lo que sería útil añadir otro nodo de trabajo. Si bien el escalador automático de clústeres es un proceso reactivo, espera hasta que los pods estén en estado pendiente debido a la capacidad insuficiente del clúster. Cuando se produce un evento de este tipo, agrega EC2 instancias al clúster. Cuando el clúster se quede sin capacidad, las nuevas réplicas (o nuevos pods) no estarán disponibles (en estado pendiente) hasta que se agreguen los nodos de trabajo. Este retraso puede afectar a la confiabilidad de sus aplicaciones si el plano de datos no puede escalarse lo suficientemente rápido como para satisfacer las demandas de la carga de trabajo. Si un nodo de trabajo se subutiliza constantemente y todos sus módulos se pueden programar en otros nodos de trabajo, Cluster Autoscaler lo cierra.
Configure el sobreaprovisionamiento con Cluster AutoScaler
El escalador automático de clústeres activa una ampliación del plano de datos cuando los pods del clúster ya están pendientes. Por lo tanto, puede haber un retraso entre el momento en que la aplicación necesita más réplicas y el momento en que, de hecho, recibe más réplicas. Una opción para tener en cuenta este posible retraso consiste en añadir más réplicas de las necesarias, lo que aumentará el número de réplicas de la aplicación.
Otro patrón que recomienda Cluster Autoscaler es el de los pods de pausa y
Uso del Autoescalador de clústeres con varios grupos de Auto Scaling
Ejecute el escalador automático de clústeres con el indicador activado. --node-group-auto-discovery Si lo hace, el escalador automático de clústeres podrá encontrar todos los grupos de escalado automático que incluyan una etiqueta definida en particular y evitará la necesidad de definir y mantener cada grupo de escalado automático en el manifiesto.
Uso del escalador automático de clústeres con almacenamiento local
De forma predeterminada, el escalador automático de clústeres no reduce la escala de los nodos que tienen pods implementados con almacenamiento local conectado. Defina el --skip-nodes-with-local-storage indicador en false para permitir que Cluster Autoscaler reduzca la escala de estos nodos.
Distribuya los nodos de trabajo y la carga de trabajo entre varios AZs
Puede proteger sus cargas de trabajo de los fallos en una zona de disponibilidad individual ejecutando nodos y módulos de trabajo en varios AZs nodos. Puede controlar la zona de disponibilidad en la que se crean los nodos de trabajo mediante las subredes en las que crea los nodos.
La siguiente implementación distribuye los pods entre sí, AZs si es posible, y deja que esos pods se ejecuten de todos modos si no es así:
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-server
spec:
replicas: 3
selector:
matchLabels:
app: web-server
template:
metadata:
labels:
app: web-server
spec:
topologySpreadConstraints:
- maxSkew: 1
whenUnsatisfiable: ScheduleAnyway
topologyKey: topology.kubernetes.io/zone
labelSelector:
matchLabels:
app: web-server
containers:
- name: web-app
image: nginx
resources:
requests:
cpu: 1nota
kube-schedulersolo conoce los dominios de topología a través de los nodos que existen con esas etiquetas. Si la implementación anterior se implementa en un clúster con nodos solo en una zona, todos los módulos se programarán en esos nodos, al kube-scheduler igual que en las demás zonas. Para que esta distribución de topología funcione según lo previsto con el programador, los nodos deben existir ya en todas las zonas. Este problema se resolverá en Kubernetes 1.24 con la adición de la MinDomainsInPodToplogySpread función Feature GateminDomains propiedad para informar al programador del número de dominios aptos.
aviso
Si DoNotSchedule se establece whenUnsatisfiable en, los pods no se podrán programar si no se cumple la restricción de dispersión de la topología. Solo debe configurarse si es preferible que los pods no se ejecuten en lugar de infringir la restricción de dispersión de la topología.
En las versiones anteriores de Kubernetes, puedes usar las reglas de antiafinidad de los pods para programar varios pods en varios. AZs En el siguiente manifiesto se indica al programador de Kubernetes que prefiera programar los pods por separado. AZs
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-server
labels:
app: web-server
spec:
replicas: 4
selector:
matchLabels:
app: web-server
template:
metadata:
labels:
app: web-server
spec:
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- web-server
topologyKey: failure-domain.beta.kubernetes.io/zone
weight: 100
containers:
- name: web-app
image: nginxaviso
No es necesario que los pods se programen de AZs forma distinta; de lo contrario, la cantidad de pods en una implementación nunca superará la cantidad de. AZs
Garantice la capacidad en cada zona de disponibilidad cuando utilice volúmenes de EBS
Si utilizas Amazon EBS para proporcionar volúmenes persistentes, debes asegurarte de que los pods y el volumen de EBS asociado estén ubicados en la misma zona de disponibilidad. En el momento de redactar este artículo, los volúmenes de EBS solo están disponibles en una única zona de disponibilidad. Un pod no puede acceder a los volúmenes persistentes respaldados por EBS ubicados en una zona de disponibilidad diferente. El programador de Kubernetes sabe en qué zona de disponibilidad se encuentra un nodo de trabajo
Cree un grupo de Auto Scaling para cada zona de disponibilidad con capacidad suficiente para garantizar que el clúster siempre tenga capacidad para programar los pods en la misma zona de disponibilidad que los volúmenes de EBS que necesite. Además, debe habilitar la --balance-similar-node-groups función en Cluster AutoScaler.
Si está ejecutando una aplicación que utiliza un volumen de EBS pero no requiere una alta disponibilidad, puede restringir la implementación de la aplicación a una única zona de disponibilidad. En EKS, a los nodos de trabajo se les agrega automáticamente una failure-domain.beta.kubernetes.io/zone etiqueta que contiene el nombre de la AZ. Puede ver las etiquetas adheridas a sus nodos corriendokubectl get nodes --show-labels. Encontrará más información sobre las etiquetas de nodos integradas aquí
En el siguiente ejemplo, el pod solo se programará en us-west-2c AZ:
apiVersion: v1
kind: Pod
metadata:
name: single-az-pod
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: failure-domain.beta.kubernetes.io/zone
operator: In
values:
- us-west-2c
containers:
- name: single-az-container
image: kubernetes/pauseLos volúmenes persistentes (respaldados por EBS) también se etiquetan automáticamente con el nombre de AZ; puede ver a qué AZ pertenece su volumen persistente al kubectl get pv -L topology.ebs.csi.aws.com/zone ejecutarlos. Cuando se crea un pod y reclama un volumen, Kubernetes programará el pod en un nodo de la misma zona de disponibilidad que el volumen.
Considera este escenario: tienes un clúster de EKS con un grupo de nodos. Este grupo de nodos tiene tres nodos de trabajo repartidos en tres AZs. Tiene una aplicación que utiliza un volumen persistente respaldado por EBS. Al crear esta aplicación y el volumen correspondiente, su pod se crea en el primero de los tres. AZs A continuación, el nodo de trabajo que ejecuta este pod deja de estar en buen estado y, por lo tanto, no está disponible para su uso. El escalador automático de clústeres reemplazará el nodo en mal estado por un nuevo nodo de trabajo; sin embargo, dado que el grupo de escalado automático se extiende por tres AZs, el nuevo nodo de trabajo puede lanzarse en la segunda o tercera AZ, pero no en la primera AZ, según lo exija la situación. Como el volumen de EBS con restricciones de zona geográfica solo existe en la primera zona de disponibilidad, pero no hay nodos de trabajo disponibles en esa zona, no se puede programar el pod. Por lo tanto, debes crear un grupo de nodos en cada zona de disponibilidad, de modo que siempre haya suficiente capacidad disponible para ejecutar pods que no se puedan programar en otras zonas. AZs
Como alternativa, EFS
Detecte problemas en los nodos con el agente de monitoreo de nodos
Los fallos en los nodos de trabajo pueden afectar a la disponibilidad de sus aplicaciones. Puede usar el agente de monitoreo de nodos para detectar y mostrar problemas de estado. También puede habilitar la reparación automática de nodos para sustituirlos automáticamente cuando se detecten problemas.
El agente de supervisión de nodos se incluye como una capacidad para todos los clústeres del modo automático de Amazon EKS. Para otros tipos de clústeres, puede agregar el agente de supervisión como complemento de Amazon EKS. Para obtener más información, consulte Habilitar la reparación automática de nodos e investigar problemas de estado de los nodos en la Guía del usuario de Amazon EKS.
Reserve recursos para los daemons del sistema y de Kubernetes
Puede mejorar la estabilidad de los nodos de trabajo reservando la capacidad de procesamiento para el sistema operativo y los daemons delimits declarados, pueden saturar los recursos del sistema, lo que hace que los nodos se encuentren en una situación en la que los procesos del sistema operativo y los daemons de Kubernetes (kubeletel tiempo de ejecución de los contenedores, etc.) compitan con los pods por los recursos del sistema. Puedes usar kubelet indicadores --system-reserved y reservar recursos --kube-reserved para los daemons de procesos del sistema (udev, etc.) y de sshd Kubernetes, respectivamente.
Si utiliza la AMI de Linux optimizada para EKS, la CPU, la memoria y el almacenamiento están reservados para el sistema y los daemons de Kubernetes de forma predeterminada. Cuando se lanzan los nodos de trabajo basados en esta AMI, EC2 los datos de usuario se configuran para activar el bootstrap.shscriptKubeletConfiguration archivo ubicado en/etc/kubernetes/kubelet/kubelet-config.json.
Es posible que necesite aumentar la reserva de recursos del sistema si ejecuta demonios personalizados en el nodo y la cantidad de CPU y memoria reservada de forma predeterminada es insuficiente.
eksctlofrece la forma más sencilla de personalizar la reserva de recursos para los daemons del sistema y de Kubernetes
Implemente QoS
En el caso de las aplicaciones críticas, considere la posibilidad de definir requests = limits para el contenedor del pod. Esto garantizará que el contenedor no se destruya si otro pod solicita recursos.
Se recomienda implementar límites de CPU y memoria para todos los contenedores, ya que así se evita que un contenedor consuma recursos del sistema de forma inadvertida y afecte a la disponibilidad de otros procesos ubicados en el mismo lugar.
Configure y dimensione las solicitudes/límites de recursos para todas las cargas de trabajo
Se pueden aplicar algunas pautas generales para dimensionar las solicitudes de recursos y los límites de las cargas de trabajo:
-
No especifique los límites de recursos de la CPU. Si no hay límites, la solicitud actúa como un indicador del tiempo relativo de CPU que ocupan los contenedores
. Esto permite que sus cargas de trabajo utilicen toda la CPU sin límites artificiales ni privaciones de recursos. -
Para los recursos que no son de CPU, configuration
requests=limitsproporciona el comportamiento más predecible. ¡Si!requests=limits, también se ha reducido la QOSdel contenedor, de garantizada a explotable, por lo que es más probable que se desaloje en caso de presión en el nodo. -
En el caso de los recursos que no sean de la CPU, no especifique un límite que sea mucho mayor que el solicitado. Cuanto mayor sea
limitsla configuración relativa arequests, mayor será la probabilidad de que los nodos estén sobrecargados, lo que aumentará las probabilidades de que se interrumpa la carga de trabajo. -
Las solicitudes del tamaño correcto son particularmente importantes cuando se utiliza una solución de autoescalado de nodos como Karpenter
o Cluster. AutoScaler Estas herramientas analizan las solicitudes de carga de trabajo para determinar la cantidad y el tamaño de los nodos que se van a aprovisionar. Si tus solicitudes son demasiado pequeñas y los límites son mayores, es posible que tus cargas de trabajo se desalojen o que la OOM se cancele si se encuentran agrupadas en un nodo.
Determinar las solicitudes de recursos puede resultar difícil, pero herramientas como el escalador automático Vertical Pod
Configure las cuotas de recursos para los espacios de nombres
Los espacios de nombres se utilizan en entornos con muchos usuarios distribuidos en varios equipos o proyectos. Proporcionan un margen para los nombres y son una forma de dividir los recursos del clúster entre varios equipos, proyectos y cargas de trabajo. Puedes limitar el consumo total de recursos en un espacio de nombres. El ResourceQuota
Si la cuota de recursos está habilitada para un espacio de nombres para recursos informáticos como la CPU y la memoria, los usuarios deben especificar las solicitudes o los límites para cada contenedor de ese espacio de nombres.
Considere la posibilidad de configurar cuotas para cada espacio de nombres. Considere la posibilidad de LimitRanges aplicar automáticamente límites preconfigurados a los contenedores dentro de un espacio de nombres.
Limite el uso de los recursos del contenedor dentro de un espacio de nombres
Las cuotas de recursos ayudan a limitar la cantidad de recursos que puede usar un espacio de nombres. El LimitRangeobjetoLimitRange puede establecer una solicitud y límites predeterminados para los contenedores, lo que resulta útil si establecer límites de recursos de cómputo no es una práctica estándar en su organización. Como su nombre indica, LimitRange puede imponer un uso mínimo y máximo de los recursos de cómputo por pod o contenedor en un espacio de nombres. Además, impone una solicitud de almacenamiento mínima y máxima por cada espacio de PersistentVolumeClaim nombres.
Considere la posibilidad LimitRange de usarlo junto con ResourceQuota para hacer cumplir los límites tanto a nivel de contenedor como de espacio de nombres. Al establecer estos límites, se garantizará que un contenedor o un espacio de nombres no afecte a los recursos utilizados por otros inquilinos del clúster.
CoreDNS
CoredNS cumple con las funciones de resolución de nombres y descubrimiento de servicios en Kubernetes. Se instala de forma predeterminada en los clústeres de EKS. Por motivos de interoperabilidad, el servicio de Kubernetes para CoreDNS sigue denominándose kube-dns.kube-system en el espacio de nombres, y en EKS, de forma predeterminada, ejecutan dos réplicas con solicitudes y límites declarados. Las consultas de DNS se envían al kube-dns servicio que se ejecuta en el espacio de nombres. kube-system
Recomendaciones
Supervise las métricas de CoredNS
CoredNS ha incorporado el soporte para Prometheus.coredns_dns_request_duration_seconds_sum (antescore_dns_response_rcode_count_total llamaba a la métrica), los errores coredns_dns_responses_total (, NXDOMAIN, SERVFAIL FormErr) y el consumo de memoria del CoreDNS Pod.
Para solucionar problemas, puedes usar kubectl para ver los registros de CoredNS:
for p in $(kubectl get pods -n kube-system -l k8s-app=kube-dns -o jsonpath='{.items[*].metadata.name}'); do kubectl logs $p -n kube-system; done
Utilice NodeLocal DNSCache
Puede mejorar el rendimiento del DNS del clúster ejecutando NodeLocalDNSCachekube-dns el Servicio.
Configurar cluster-proportional-scaler para CoredNS
Otro método para mejorar el rendimiento del DNS del clúster consiste en escalar automáticamente y de forma horizontal la implementación de CoreDNS
Los nodos y el conjunto de núcleos de CPU en los nodos son las dos métricas con las que puede escalar CoredNS. Puede utilizar ambas métricas simultáneamente. Si utiliza nodos más grandes, el escalado de CoredNS se basa en la cantidad de núcleos de la CPU. Mientras que, si utiliza nodos más pequeños, la cantidad de réplicas de CoredNS depende de los núcleos de la CPU del plano de datos. La configuración del escalador automático proporcional tiene el siguiente aspecto:
linear: '{"coresPerReplica":256,"min":1,"nodesPerReplica":16}'Elegir una AMI con un grupo de nodos
EKS ofrece soluciones optimizadas EC2 AMIs que los clientes utilizan para crear grupos de nodos autogestionados y gestionados. AMIs Se publican en todas las regiones para todas las versiones de Kubernetes compatibles. EKS las marca AMIs como obsoletas cuando se descubre algún error CVEs o error. Por lo tanto, se recomienda no consumir productos obsoletos AMIs al elegir una AMI para el grupo de nodos.
Los archivos obsoletos se AMIs pueden filtrar mediante la API describe-images de Ec2 mediante el siguiente comando:
aws ec2 describe-images --image-id ami-0d551c4f633e7679c --no-include-deprecatedTambién puede reconocer una AMI obsoleta comprobando si el resultado describe-image contiene un campo as. DeprecationTime Por ejemplo:
aws ec2 describe-images --image-id ami-xxx --no-include-deprecated
{
"Images": [
{
"Architecture": "x86_64",
"CreationDate": "2022-07-13T15:54:06.000Z",
"ImageId": "ami-xxx",
"ImageLocation": "123456789012/eks_xxx",
"ImageType": "machine",
"Public": false,
"OwnerId": "123456789012",
"PlatformDetails": "Linux/UNIX",
"UsageOperation": "RunInstances",
"State": "available",
"BlockDeviceMappings": [
{
"DeviceName": "/dev/xvda",
"Ebs": {
"DeleteOnTermination": true,
"SnapshotId": "snap-0993a2fc4bbf4f7f4",
"VolumeSize": 20,
"VolumeType": "gp2",
"Encrypted": false
}
}
],
"Description": "EKS Kubernetes Worker AMI with AmazonLinux2 image, (k8s: 1.19.15, docker: 20.10.13-2.amzn2, containerd: 1.4.13-3.amzn2)",
"EnaSupport": true,
"Hypervisor": "xen",
"Name": "aws_eks_optimized_xxx",
"RootDeviceName": "/dev/xvda",
"RootDeviceType": "ebs",
"SriovNetSupport": "simple",
"VirtualizationType": "hvm",
"DeprecationTime": "2023-02-09T19:41:00.000Z"
}
]
}