Cargas de trabajo

Las cargas de trabajo influyen en el tamaño que puede escalar su clúster. Las cargas de trabajo que utilizan APIs mucho Kubernetes limitarán la cantidad total de cargas de trabajo que puedes tener en un solo clúster, pero hay algunos valores predeterminados que puedes cambiar para reducir la carga.

Las cargas de trabajo de un clúster de Kubernetes tienen acceso a funciones que se integran con la API de Kubernetes (por ejemplo, Secrets y ServiceAccounts), pero estas funciones no siempre son obligatorias y se deben deshabilitar si no se utilizan. Limitar el acceso a las cargas de trabajo y la dependencia del plano de control de Kubernetes aumentará la cantidad de cargas de trabajo que puede ejecutar en el clúster y mejorará la seguridad de los clústeres al eliminar el acceso innecesario a las cargas de trabajo e implementar prácticas de privilegios mínimos. Lea las prácticas recomendadas de seguridad para obtener más información.

Úselo IPv6 para redes de pods

No se puede hacer la transición de una VPC IPv4 a otra, IPv6 por lo que es importante habilitarla IPv6 antes de aprovisionar un clúster. Si la habilitas IPv6 en una VPC, no significa que tengas que usarla y, si tus pods y servicios la utilizan, IPv6 puedes seguir enrutando el tráfico hacia y desde IPv4 las direcciones. Consulte las prácticas recomendadas de redes de EKS para obtener más información.

El uso IPv6 en su clúster evita algunos de los límites de escalado de clústeres y cargas de trabajo más comunes. IPv6 evita el agotamiento de las direcciones IP cuando no se pueden crear pods y nodos porque no hay ninguna dirección IP disponible. También presenta mejoras en el rendimiento por nodo, ya que los pods reciben las direcciones IP más rápido al reducir la cantidad de adjuntos ENI por nodo. Puede lograr un rendimiento de nodo similar mediante el modo de IPv4 prefijo en la CNI de la VPC, pero aun así debe asegurarse de tener suficientes direcciones IP disponibles en la VPC.

Limite la cantidad de servicios por espacio de nombres

La cantidad máxima de servicios en un espacio de nombres es de 5000 y la cantidad máxima de servicios en un clúster es de 10 000. Para ayudar a organizar las cargas de trabajo y los servicios, aumentar el rendimiento y evitar el impacto en cascada de los recursos incluidos en el ámbito de los espacios de nombres, recomendamos limitar la cantidad de servicios por espacio de nombres a 500.

La cantidad de reglas de tablas de IP que se crean por nodo con kube-proxy aumenta con la cantidad total de servicios del clúster. La generación de miles de reglas de tablas IP y el enrutamiento de paquetes mediante esas reglas repercute en el rendimiento de los nodos y añade latencia a la red.

Cree espacios de nombres de Kubernetes que abarquen un único entorno de aplicaciones siempre que el número de servicios por espacio de nombres sea inferior a 500. Esto hará que la detección de servicios sea lo suficientemente pequeña como para evitar los límites de detección de servicios y también puede ayudarte a evitar colisiones en los nombres de los servicios. Los entornos de aplicaciones (p. ej., dev, test, prod) deben utilizar clústeres de EKS independientes en lugar de espacios de nombres.

Comprenda las cuotas de Elastic Load Balancer

Al crear sus servicios, tenga en cuenta qué tipo de equilibrio de carga utilizará (por ejemplo, Network Load Balancer (NLB) o Application Load Balancer (ALB)). Cada tipo de balanceador de carga proporciona una funcionalidad diferente y tiene cuotas diferentes. Algunas de las cuotas predeterminadas se pueden ajustar, pero hay algunas cuotas máximas que no se pueden cambiar. Para ver las cuotas y el uso de su cuenta, consulte el panel Service Quotas en la consola de AWS.

Por ejemplo, el objetivo predeterminado de ALB es 1000. Si tienes un servicio con más de 1000 puntos de conexión, tendrás que aumentar la cuota, dividir el servicio en varios ALBs o utilizar Kubernetes Ingress. Los objetivos predeterminados de NLB son 3000, pero están limitados a 500 objetivos por zona de disponibilidad. Si tu clúster ejecuta más de 500 pods para un servicio NLB, tendrás que usar varios AZs o solicitar un aumento del límite de cuota.

Una alternativa a usar un balanceador de carga acoplado a un servicio es usar un controlador de ingreso. El controlador AWS Load Balancer puede crear recursos ALBs para la entrada, pero puede considerar la posibilidad de ejecutar un controlador dedicado en su clúster. Un controlador de entrada integrado en el clúster le permite exponer varios servicios de Kubernetes desde un único balanceador de cargas mediante la ejecución de un proxy inverso dentro del clúster. Los controladores tienen diferentes funciones, como la compatibilidad con la API Gateway, que pueden tener ventajas según el número y el tamaño de las cargas de trabajo.

Utilice Route 53, Global Accelerator o CloudFront

Para que un servicio que utilice varios balanceadores de carga esté disponible como un único punto de enlace, debe usar Amazon CloudFront, AWS Global Accelerator o Amazon Route 53 para exponer todos los balanceadores de carga como un único punto de enlace orientado al cliente. Cada opción tiene diferentes ventajas y se puede utilizar por separado o en conjunto, según sus necesidades.

Route 53 puede exponer varios balanceadores de carga con un nombre común y puede enviar tráfico a cada uno de ellos en función del peso asignado. Puede obtener más información sobre los pesos de DNS en la documentación y cómo implementarlos con el controlador de DNS externo de Kubernetes en la documentación del controlador Load Balancer de AWS.

Global Accelerator puede enrutar las cargas de trabajo a la región más cercana en función de la dirección IP solicitada. Esto puede resultar útil para las cargas de trabajo que se implementan en varias regiones, pero no mejora el enrutamiento a un solo clúster en una sola región. El uso de Route 53 en combinación con Global Accelerator ofrece beneficios adicionales, como la comprobación del estado y la conmutación automática por error si no hay una zona de disponibilidad disponible. Puedes ver un ejemplo del uso de Global Accelerator con Route 53 en esta entrada de blog.

CloudFront se puede usar con Route 53 y Global Accelerator o por sí solo para dirigir el tráfico a varios destinos. CloudFront almacena en caché los activos que se suministran desde las fuentes de origen, lo que puede reducir los requisitos de ancho de banda en función del tipo de servicio.

Úselo EndpointSlices en lugar de puntos finales

Cuando descubras pods que coincidan con una etiqueta de servicio, deberías usarlos EndpointSlicesen lugar de Endpoints. Los endpoints eran una forma sencilla de exponer los servicios a pequeña escala, pero los servicios grandes que se escalan automáticamente o se actualizan generan mucho tráfico en el plano de control de Kubernetes. EndpointSlices tienen una agrupación automática que permite cosas como sugerencias que tengan en cuenta la topología.

No todos los controladores lo utilizan de forma EndpointSlices predeterminada. Debe verificar la configuración del mando y habilitarlo si es necesario. En el caso del controlador Load Balancer de AWS, debe activar el indicador --enable-endpoint-slices opcional que desee utilizar. EndpointSlices

Si es posible, utilice secretos externos e inmutables

El kubelet guarda en caché las claves y valores actuales de los secretos que se utilizan en los volúmenes de los pods de ese nodo. El kubelet vigila los Secretos para detectar cambios. A medida que el clúster se amplía, el creciente número de relojes puede afectar negativamente al rendimiento del servidor API.

Existen dos estrategias para reducir el número de reproducciones en Secrets:

• Para las aplicaciones que no necesitan acceso a los recursos de Kubernetes, puedes deshabilitar el montaje automático de los secretos de las cuentas de servicio configurando Token: false automountServiceAccount

• Si los secretos de su aplicación son estáticos y no se modificarán en el futuro, márquelos como inmutables. El kubelet no mantiene una API que vigile los secretos inmutables.

Para deshabilitar el montaje automático de una cuenta de servicio en los pods, puedes usar la siguiente configuración en tu carga de trabajo. Puedes anular esta configuración si determinadas cargas de trabajo necesitan una cuenta de servicio.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app
automountServiceAccountToken: true

Supervisa la cantidad de secretos del clúster antes de que supere el límite de 10 000. Puede ver el recuento total de secretos de un clúster con el siguiente comando. Debe supervisar este límite a través de las herramientas de supervisión de clústeres.

kubectl get secrets -A | wc -l

Debe configurar la supervisión para alertar al administrador del clúster antes de que se alcance este límite. Considere la posibilidad de utilizar opciones de administración de secretos externas, como AWS Key Management Service (AWS KMS) o Hashicorp Vault con el controlador CSI de Secrets Store.

Limite el historial de despliegues

Los pods pueden tardar en crearse, actualizarse o eliminarse porque los objetos antiguos se siguen rastreando en el clúster. Puedes reducir las implementaciones para limpiar revisionHistoryLimit las antiguas, ReplicaSets lo que reducirá la cantidad total de objetos rastreados por el Kubernetes Controller Manager. El límite de historial predeterminado para las implementaciones es de 10.

Si su clúster crea muchos objetos de trabajo mediante CronJobs u otros mecanismos, debe usar la ttlSecondsAfterFinishedconfiguración para limpiar automáticamente los módulos antiguos del clúster. Esto eliminará los trabajos ejecutados correctamente del historial de trabajos después de un período de tiempo específico.

Desactivar enableServiceLinks de forma predeterminada

Cuando un pod se ejecuta en un nodo, el kubelet añade un conjunto de variables de entorno para cada servicio activo. Los procesos de Linux tienen un tamaño máximo para su entorno, que se puede alcanzar si tienes demasiados servicios en tu espacio de nombres. La cantidad de servicios por espacio de nombres no debe superar los 5000. Después de esto, el número de variables del entorno de servicio supera los límites del shell, lo que provoca que los pods se bloqueen al iniciarse.

Existen otros motivos por los que los pods no deberían usar variables de entorno de servicio para la detección de servicios. Algunos ejemplos son los conflictos en los nombres de las variables de entorno, la filtración de nombres de servicios y el tamaño total del entorno. Debe usar CoredNS para descubrir los puntos finales del servicio.

Limite los webhooks de admisión dinámica por recurso

Los webhooks de admisión dinámica incluyen los webhooks de admisión y los webhooks mutantes. Son puntos finales de la API que no forman parte del plano de control de Kubernetes y que se invocan en secuencia cuando se envía un recurso a la API de Kubernetes. Cada webhook tiene un tiempo de espera predeterminado de 10 segundos y puede aumentar el tiempo que tarda una solicitud de API si tienes varios webhooks o si se agota el tiempo de espera de alguno de ellos.

Asegúrate de que tus webhooks tengan una alta disponibilidad, especialmente durante un incidente de zona de disponibilidad, y de que la Política de errores esté configurada correctamente para rechazar el recurso o ignorar el error. No llames a los webhooks cuando no los necesites, ya que permite que los comandos --dry-run kubectl pasen por alto el webhook.

apiVersion: admission.k8s.io/v1
kind: AdmissionReview
request:
  dryRun: False

Los webhooks mutantes pueden modificar los recursos de forma sucesiva y frecuente. Si tienes 5 webhooks mutantes y despliegas 50 recursos, etcd almacenará todas las versiones de cada recurso hasta que se realice la compactación (cada 5 minutos) para eliminar las versiones antiguas de los recursos modificados. En este escenario, cuando etcd elimine los recursos sustituidos, se eliminará una versión de 200 recursos de etcd y, según el tamaño de los recursos, puede ocupar un espacio considerable en el host de etcd hasta que la desfragmentación se ejecute cada 15 minutos.

Esta desfragmentación puede provocar pausas en etcd, lo que podría tener otros efectos en la API y los controladores de Kubernetes. Debes evitar la modificación frecuente de grandes recursos o la modificación rápida de cientos de recursos.

Compare las cargas de trabajo en varios clústeres

Si tiene dos clústeres que deberían tener un rendimiento similar pero no lo tienen, intente comparar las métricas para identificar el motivo.

Por ejemplo, comparar la latencia de los clústeres es un problema habitual. Esto suele deberse a una diferencia en el volumen de solicitudes de API. Puedes ejecutar la siguiente CloudWatch LogInsight consulta para entender la diferencia.

filter @logStream like "kube-apiserver-audit"
| stats count(*) as cnt by objectRef.apiGroup, objectRef.apiVersion, objectRef.resource, userAgent, verb, responseStatus.code
| sort cnt desc
| limit 1000

Puedes añadir filtros adicionales para acotarlo, por ejemplo, centrándote en todas las listas solicitadasfoo.

filter @logStream like "kube-apiserver-audit"
| filter verb = "list"
| filter user.username like "foo"
| stats count(*) as cnt by objectRef.apiGroup, objectRef.apiVersion, objectRef.resource, responseStatus.code
| sort cnt desc
| limit 1000