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.

Servicios de clúster

Los servicios de clúster se ejecutan dentro de un clúster de EKS, pero no son cargas de trabajo de usuarios. Si tiene un servidor Linux, con frecuencia necesitará ejecutar servicios como NTP, syslog y un entorno de ejecución de contenedor para soportar sus cargas de trabajo. Los servicios de clúster son similares y admiten servicios que le ayudan a automatizar y operar su clúster. En Kubernetes, normalmente se ejecutan en el espacio de nombres del sistema kube y algunos se ejecutan como. DaemonSets

Se espera que los servicios de clúster tengan un tiempo de actividad elevado y, a menudo, son fundamentales durante las interrupciones y para la solución de problemas. Si un servicio de clúster básico no está disponible, es posible que pierda el acceso a los datos que pueden ayudar a recuperar o evitar una interrupción (por ejemplo, un uso elevado del disco). Deben ejecutarse en instancias informáticas dedicadas, como un grupo de nodos independiente o AWS Fargate. Esto garantizará que los servicios del clúster no se vean afectados en las instancias compartidas por cargas de trabajo que puedan ampliarse o consumir más recursos.

Escale CoreDNS

El escalado de CoreDNS tiene dos mecanismos principales. Reducir la cantidad de llamadas al servicio CoreDNS y aumentar la cantidad de réplicas.

Reduzca las consultas externas al reducir los puntos

La configuración ndots especifica cuántos puntos (también conocidos como «puntos») en un nombre de dominio se consideran suficientes para evitar consultar el DNS. Si tu aplicación tiene un valor de 5 puntos (predeterminado) y solicitas recursos de un dominio externo, como api.example.com (2 puntos), se consultará CoreDNS para cada dominio de búsqueda definido en/.conf para un dominio más específico. etc/resolv De forma predeterminada, se buscarán los siguientes dominios antes de realizar una solicitud externa.

api.example.<namespace>.svc.cluster.local
api.example.svc.cluster.local
api.example.cluster.local
api.example.<region>.compute.internal

regionLos valores namespace y se sustituirán por el espacio de nombres de tu carga de trabajo y tu región de procesamiento. Es posible que tengas dominios de búsqueda adicionales en función de la configuración de tu clúster.

Puedes reducir la cantidad de solicitudes a CoreDNS reduciendo la opción ndots de tu carga de trabajo o calificando completamente tus solicitudes de dominio al incluir un final. (p. ej.). api.example.com. Si su carga de trabajo se conecta a servicios externos a través de DNS, le recomendamos establecer ndots en 2 para que las cargas de trabajo no hagan innecesarias las consultas de DNS en clúster. Puedes configurar un servidor DNS y un dominio de búsqueda diferentes si la carga de trabajo no requiere acceso a los servicios del clúster.

spec:
  dnsPolicy: "None"
  dnsConfig:
    options:
      - name: ndots
        value: "2"
      - name: edns0

Si reduces los ndots a un valor demasiado bajo o los dominios a los que te estás conectando no incluyen suficiente especificidad (incluido el final), es posible que las búsquedas de DNS fallen. Asegúrese de comprobar cómo afectará esta configuración a sus cargas de trabajo.

Escale CoreDNS horizontalmente

Las instancias de CoreDNS se pueden escalar añadiendo réplicas adicionales a la implementación. Se recomienda usar el NodeLocal DNS o el escalador automático proporcional del clúster para escalar CoreDNS.

NodeLocal El DNS requerirá ejecutar una instancia por nodo (como tal), DaemonSet lo que requiere más recursos informáticos en el clúster, pero evitará errores en las solicitudes de DNS y reducirá el tiempo de respuesta de las consultas de DNS en el clúster. El escalador automático proporcional del clúster escalará el CoreDNS en función del número de nodos o núcleos del clúster. No se trata de una correlación directa con las consultas de solicitud, pero puede resultar útil en función de las cargas de trabajo y del tamaño del clúster. La escala proporcional predeterminada consiste en agregar una réplica adicional por cada 256 núcleos o 16 nodos del clúster, lo que ocurra primero.

Si usas el complemento CoreDNS EKS, considera la posibilidad de habilitar la opción de escalado automático. https://docs.aws.amazon.com/eks/latest/userguide/coredns-autoscaling.html El escalador automático de CoreDNS ajusta de forma dinámica el número de réplicas de CoreDNS monitorizando el recuento de nodos y los núcleos de la CPU. Para ello, utiliza una fórmula que toma el máximo de (nodos ÷ 16) o (núcleos de CPU ÷ 256), se amplía inmediatamente cuando es necesario y se reduce gradualmente para mantener la estabilidad.

Escale verticalmente el servidor Kubernetes Metrics

El servidor Kubernetes Metrics admite el escalado horizontal y vertical. Al escalar horizontalmente el servidor de métricas, tendrá una alta disponibilidad, pero no se escalará horizontalmente para gestionar más métricas del clúster. Tendrás que escalar verticalmente el servidor de métricas en función de sus recomendaciones a medida que los nodos y las métricas recopiladas se añadan al clúster.

El Metrics Server guarda en la memoria los datos que recopila, agrega y sirve. A medida que crece un clúster, aumenta la cantidad de datos que almacena Metrics Server. En clústeres grandes, el Metrics Server necesitará más recursos informáticos que la reserva de memoria y CPU especificada en la instalación predeterminada. Puedes usar el escalador automático (VPA) de Vertical Pod o el redimensionador adicional para escalar el Metrics Server. El Addon Resizer se escala verticalmente en proporción a los nodos de trabajo, y el VPA se escala en función del uso de la CPU y la memoria.

CoreDNS tiene una duración mínima

Los pods usan el kube-dns Servicio para la resolución de nombres. Kubernetes usa la NAT de destino (DNAT) para redirigir el kube-dns tráfico de los nodos a los pods de backend de CoreDNS. A medida que escalas la implementación de CoreDNS, kube-proxy actualiza las reglas de iptables y las cadenas en los nodos para redirigir el tráfico de DNS a los pods de CoreDNS. Propagar nuevos puntos de enlace al escalar hacia arriba y eliminar reglas cuando se reduce la escala de CoreDNS puede tardar entre 1 y 10 segundos, según el tamaño del clúster.

Este retraso de propagación puede provocar errores en la búsqueda de DNS cuando se cierra un pod de CoreDNS pero las reglas de iptables del nodo no se han actualizado. En este escenario, el nodo puede seguir enviando consultas de DNS a un pod de CoreDNS terminado.

Para reducir los errores de búsqueda de DNS, establece una duración mínima en tus pods de CoreDNS. Mientras esté en modo lameduck, CoreDNS seguirá respondiendo a las solicitudes en curso. Si se establece una duración mínima, se retrasará el proceso de cierre de CoreDNS, lo que permitirá a los nodos disponer del tiempo necesario para actualizar sus reglas y cadenas de iptables.

Recomendamos establecer la duración del lameduck de CoreDNS en 30 segundos.

Sonda de preparación de CoreDNS

Recomendamos utilizarla /ready en lugar de /health para la sonda de preparación de CoreDNS.

De acuerdo con la recomendación anterior de establecer la duración del lameduck en 30 segundos, lo que proporciona tiempo suficiente para que las reglas de iptables del nodo se actualicen antes de que finalice el pod, /ready en lugar de utilizar la sonda de preparación de CoreDNS garantiza que el pod de CoreDNS esté completamente preparado al inicio /health para responder rápidamente a las solicitudes de DNS.

readinessProbe:
  httpGet:
    path: /ready
    port: 8181
    scheme: HTTP

Para obtener más información sobre el complemento CoreDNS Ready, consulte https://coredns.io/plugins/ready/

Agentes de registro y supervisión

Los agentes de registro y supervisión pueden añadir una carga considerable al plano de control del clúster, ya que consultan el servidor de API para enriquecer los registros y las métricas con metadatos de la carga de trabajo. El agente de un nodo solo tiene acceso a los recursos del nodo local para ver cosas como el nombre del contenedor y del proceso. Al consultar el servidor de API, puede agregar más detalles, como el nombre y las etiquetas de la implementación de Kubernetes. Esto puede resultar extremadamente útil para la resolución de problemas, pero es perjudicial para la escalabilidad.

Como hay tantas opciones diferentes para el registro y la supervisión, no podemos mostrar ejemplos para todos los proveedores. Con fluentbit, recomendamos habilitar Use_Kubelet la recuperación de metadatos del kubelet local en lugar del servidor de API de Kubernetes y establecer Kube_Meta_Cache_TTL un número que reduzca las llamadas repetidas cuando los datos se puedan almacenar en caché (por ejemplo, 60).

La escalabilidad, el monitoreo y el registro tienen dos opciones generales:

La desactivación de las integraciones no suele ser una opción porque se pierden los metadatos del registro. Esto elimina el problema de escalado de la API, pero introducirá otros problemas al no disponer de los metadatos necesarios cuando sean necesarios.

El muestreo y el filtrado reducen la cantidad de métricas y registros que se recopilan. Esto reducirá la cantidad de solicitudes a la API de Kubernetes y reducirá la cantidad de almacenamiento necesaria para las métricas y los registros que se recopilan. La reducción de los costos de almacenamiento reducirá el costo del sistema en general.

La capacidad de configurar el muestreo depende del software del agente y se puede implementar en diferentes puntos de ingestión. Es importante añadir el muestreo lo más cerca posible del agente, ya que es probablemente allí donde se producen las llamadas al servidor de API. Póngase en contacto con su proveedor para obtener más información sobre la compatibilidad con el muestreo.

Si utiliza CloudWatch And CloudWatch Logs, puede añadir el filtrado de agentes utilizando los patrones descritos en la documentación.

Para evitar perder los registros y las métricas, debe enviar los datos a un sistema que pueda almacenar los datos en búfer en caso de que se produzca una interrupción en el terminal receptor. Con fluentbit, puede usar Amazon Kinesis Data Firehose para conservar temporalmente los datos, lo que reduce la posibilidad de sobrecargar su ubicación final de almacenamiento de datos.