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 los usuarios. Si tiene un servidor Linux, a menudo necesita ejecutar servicios como NTP, syslog y un motor de ejecución de contenedores para soportar sus cargas de trabajo. Los servicios de clúster son servicios de soporte similares 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 alto tiempo de actividad y, a menudo, son fundamentales durante las interrupciones y para la solución de problemas. Si un servicio de clúster principal no está disponible, puede perder 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 de clúster no se vean afectados en las instancias compartidas por cargas de trabajo que puedan estar aumentando o consumiendo más recursos.

CoredNS de escala

El escalado de CoredNS tiene dos mecanismos principales. Reducir el número de llamadas al servicio CoreDNS y aumentar el número de réplicas.

Reduzca las consultas externas reduciendo los puntos

La configuración ndots especifica cuántos puntos (también conocidos como «puntos») de un nombre de dominio se consideran suficientes para evitar consultar el DNS. Si su aplicación tiene una configuración de ndots de 5 (predeterminada) y solicita recursos de un dominio externo como api.example.com (2 puntos), se consultará CoreDNS para cada dominio de búsqueda definido en /etc/resolv.conf para un dominio más específico. 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 las cargas de trabajo y la región de procesamiento. Es posible que tengas dominios de búsqueda adicionales en función de la configuración del clúster.

Puedes reducir el número de solicitudes a CoreDNS reduciendo la opción ndots de tu carga de trabajo o calificando completamente tus solicitudes de dominio al incluir un registro final. (por ejemplo). api.example.com. Si tu carga de trabajo se conecta a servicios externos a través de DNS, te recomendamos configurar ndots en 2 para que las cargas de trabajo no hagan innecesarias las consultas de DNS en clústeres dentro del 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 reduce los puntos a un valor demasiado bajo o si los dominios a los que se va a conectar no incluyen suficiente especificidad (incluso al final), es posible que se produzcan errores en las búsquedas de DNS. Asegúrese de probar cómo afectará esta configuración a sus cargas de trabajo.

Escalar coredNS horizontalmente

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

NodeLocal El DNS requerirá ejecutar una instancia por nodo, lo DaemonSet que requiere más recursos de procesamiento en el clúster, pero evitará solicitudes de DNS fallidas y reducirá el tiempo de respuesta de las consultas de DNS en el clúster. El escalador automático proporcional del clúster escalará los 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 añadir una réplica adicional por cada 256 núcleos o 16 nodos del clúster, lo que ocurra primero.

Escale Kubernetes Metrics Server verticalmente

El servidor de métricas de Kubernetes 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 de clústeres. Deberás escalar verticalmente el servidor de métricas según sus recomendaciones a medida que los nodos y las métricas recopiladas se agreguen al clúster.

El servidor de métricas guarda en la memoria los datos que recopila, agrega y almacena. A medida que crece un clúster, aumenta la cantidad de datos que almacena el servidor de métricas. En clústeres grandes, el servidor de métricas requerirá más recursos informáticos que la reserva de memoria y CPU especificada en la instalación predeterminada. Puedes usar el escalador automático Vertical Pod (VPA) o el Addon Resizer para escalar el servidor de métricas. 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.

Duración lamentable de CoredNS

Los pods utilizan 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 escala la implementación de CoreDNSkube-proxy, actualiza las reglas y cadenas de iptables en los nodos para redirigir el tráfico de DNS a los pods de CoreDNS. La propagación de nuevos puntos finales al aumentar la escala y eliminar las reglas al reducir 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 termina un pod de CoreDNS y 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.

Puedes reducir los errores de búsqueda de DNS configurando una duración mínima en tus pods de CoreDNS. Mientras esté en modo lameduck, CoreDNS seguirá respondiendo a las solicitudes durante el vuelo. Si se establece una duración mínima, se retrasará el proceso de cierre de CoreDNS, lo que dará a los nodos el tiempo que necesitan 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 utilizarla /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 la finalización del pod, si se emplea, /ready en lugar de para /health la sonda de preparación de CoreDNS, se garantiza que el pod de CoreDNS esté completamente preparado al inicio 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 monitoreo

Los agentes de registro y supervisión pueden añadir una carga significativa 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 datos como el contenedor y el nombre del proceso. Al consultar el servidor de API, puede añadir más detalles, como el nombre y las etiquetas de la implementación de Kubernetes. Esto puede ser extremadamente útil para solucionar problemas, pero perjudicial para el escalado.

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 para obtener metadatos del kubelet local en lugar del servidor API de Kubernetes y Kube_Meta_Cache_TTL establecerlo en un número que reduzca las llamadas repetidas cuando los datos se puedan almacenar en caché (por ejemplo, 60).

Escalar la supervisión y el registro tiene dos opciones generales:

• Desactivar las integraciones

• Muestreo y filtrado

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 generará otros problemas al no disponer de los metadatos necesarios cuando se necesiten.

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. Al reducir los costes de almacenamiento, se reducirán los costes del sistema en general.

La capacidad de configurar el muestreo depende del software del agente y se puede implementar en diferentes puntos de ingesta. 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 la API. Póngase en contacto con su proveedor para obtener más información sobre el soporte de muestreo.

Si utiliza CloudWatch y CloudWatch Logs, puede añadir el filtrado de agentes mediante los patrones que se describen en la documentación.

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