Gestión de clústeres de Kubernetes: realice un seguimiento de los agentes y los componentes del sistema de Kubernetes

1. Seguimiento de los componentes del sistema Kubernetes

Estado de la característica: Kubernetes v1.27 [beta]

La función de seguimiento de componentes del sistema registra la información de latencia de las operaciones de clúster individuales y la relación entre estas operaciones.

El componente de Kubernetes envía información de seguimiento basada en el protocolo OpenTelemetry del exportador de gRPC, recopila la información de seguimiento con OpenTelemetry Collector y luego la transfiere al fondo del sistema de seguimiento.

1. Recopilación de información de seguimiento

Puede encontrar una guía completa para recopilar información de seguimiento y usar el recopilador en Primeros pasos con el recopilador de OpenTelemetry. Sin embargo, hay algunas cosas específicas de los componentes de Kubernetes que vale la pena mencionar.

De manera predeterminada, los componentes de Kubernetes usan el exportador OTLP de gRPC para exportar información de seguimiento y escribir la información en el puerto IANA OpenTelemetry. Por ejemplo, si el recopilador se ejecuta como un sidecar de componentes de Kubernetes, la siguiente configuración del receptor recopilará información de intervalo y la escribirá en la salida estándar.

receivers:
  otlp:
    protocols:
      grpc:
exporters:
  # 用适合你后端环境的导出器替换此处的导出器
  logging:
    logLevel: debug
service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [logging]

2. Seguimiento de componentes

Seguimiento de 2.1 kube-apiserver

kube-apiserver genera tramos para solicitudes HTTP entrantes, solicitudes salientes a webhooks y etcd, y solicitudes de reentrada. Dado que kube-apiserver suele ser un punto de conexión público, propaga el contexto de seguimiento de W3C en las solicitudes salientes, pero no utiliza el contexto de seguimiento en las solicitudes entrantes.

2.2 Habilitar el seguimiento en kube-apiserver

Para habilitar la función de seguimiento, se debe proporcionar un archivo de configuración de seguimiento a kube-apiserver con --tracing-config-file=<<ruta del archivo de configuración>. A continuación, se muestra una configuración de ejemplo que registra intervalos para la solicitud diezmilésima y usa el punto final predeterminado de OpenTelemetry.

apiVersion: apiserver.config.k8s.io/v1beta1
kind: TracingConfiguration
# 默认值
#endpoint: localhost:4317
samplingRatePerMillion: 100

Para obtener más información sobre la estructura de TracingConfiguration, consulte API de configuración del servidor API (v1beta1).

2.3 seguimiento de kubelet

Estado de la característica: Kubernetes v1.27 [beta]

La interfaz CRI de kubelet y el servidor HTTP que implementan la autenticación están instrumentados para generar intervalos de rastreo. Al igual que el servidor API, los puntos finales y las frecuencias de muestreo son configurables. La propagación del contexto de seguimiento también se puede configurar. La decisión de muestreo del tramo principal siempre tiene prioridad. La tasa de muestreo de la configuración de seguimiento proporcionada por el usuario se aplicará a los intervalos sin un padre. Si se habilita sin un punto final configurado, se usará la dirección de receptor predeterminada de OpenTelemetry Collector "localhost:4317".

2.4 Habilitar el seguimiento en kubelet

Para habilitar el seguimiento, se debe aplicar una configuración de seguimiento. El siguiente es un fragmento de código de ejemplo para una configuración de kubelet, registrando un intervalo solicitado cada 10 000 solicitudes y utilizando el punto de conexión predeterminado de OpenTelemetry:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
  KubeletTracing: true
tracing:
  # 默认值
  #endpoint: localhost:4317
  samplingRatePerMillion: 100

Si samplingRatePerMillion se establece en un millón (1000000), todos los tramos se enviarán al exportador.

El kubelet en Kubernetes v1.27 recopila intervalos de recolección de elementos no utilizados, rutinas de sincronización de Pod y todos los métodos de gRPC. Los tiempos de ejecución de contenedores asociados, como CRI-O y containerd, pueden vincular enlaces a los tramos que exportan para proporcionar más contexto.

Tenga en cuenta que la exportación de intervalos siempre tiene una pequeña sobrecarga de rendimiento en la red y la CPU, según la configuración general del sistema. Si se producen problemas de rendimiento similares en un clúster con el seguimiento habilitado, el problema se puede mitigar reduciendo la tasa de muestreo por millón o deshabilitando el seguimiento por completo eliminando esta configuración.

3. Estabilidad

La herramienta de seguimiento aún se encuentra en desarrollo activo y cambiará de muchas maneras en el futuro. Estos cambios incluyen: nombres de intervalo, propiedades adjuntas, puntos finales de detección y más. Estas funciones no garantizan la compatibilidad con versiones anteriores de las herramientas de seguimiento hasta que lleguen a una versión estable.

dos, agencia

Los usuarios pueden encontrar varios proxies (proxy) diferentes en el proceso de uso de Kubernetes:

1. proxy kubectl:
2. Se ejecuta en el escritorio o pod del usuario
3. Proxy desde la dirección de la máquina local a Kubernetes apiserver
4. Cliente a proxy usando el protocolo HTTP
5. Proxy a apserver usando el protocolo HTTPS
6. apserver orientado
7. Agregar información de encabezado de autenticación

1. servidor proxy:
2. Es una "fortaleza" construida dentro del servidor ap
3. Conecte a los usuarios fuera del clúster a las direcciones IP del clúster que, de otro modo, serían inaccesibles
4. Se ejecuta en el proceso apserver
5. El cliente para el agente usa el protocolo HTTPS (si el apserver está configurado para usar el protocolo HTTP, se usa el protocolo HTTP)
6. Seleccionado por la información disponible, el proxy al destino puede usar el protocolo HTTP o HTTPS
7. Se puede usar para acceder a Node, Pod o Service
8. Cuando se utiliza para acceder al Servicio, se realizará el equilibrio de carga

1. ser representante:
2. ejecutar en cada nodo
3. Proxy UDP, TCP y SCTP
4. No es compatible con HTTP
5. Proporciona capacidades de equilibrio de carga
6. Solo se usa para acceder al Servicio

1. Equilibrador de carga/proxy antes de apserver:
2. Diferentes formas de existencia e implementación en diferentes clústeres (como nginx)
3. se encuentra entre todos los clientes y uno o más servidores API
4. Actúa como equilibrador de carga cuando hay varios servidores API

1. Equilibrador de carga en la nube para servicios externos:
2. Proporcionado por algunos proveedores de la nube (p. ej., AWS ELB, Google Cloud Load Balancer)
3. Se crea automáticamente cuando el tipo de servicio de Kubernetes es LoadBalancer
4. Por lo general, solo admite el protocolo UDP/TCP
5. La compatibilidad con SCTP depende de la implementación del equilibrador de carga del proveedor de la nube
6. Diferentes proveedores de nube implementan diferentes balanceadores de carga en la nube

Por lo general, los usuarios de Kubernetes solo deben preocuparse por los dos primeros tipos de proxies, y los administradores de clústeres generalmente deben asegurarse de que los últimos tipos de proxies estén configurados correctamente.