Componentes de integración de Kubernetes

La integración de New Relic Kubernetes le brinda total observabilidad del estado y el rendimiento de su clúster, ya sea que esté ejecutando Kubernetes localmente o en la nube. Le brinda visibilidad del espacio de nombres Kubernetes , su implementación, conjuntos de réplicas, nodos, pods y contenedores.

El gráficonewrelic-infrastructure es el componente principal de la integración. Conoce su arquitectura aquí.

El gráficonri-bundle agrupa gráficos individuales para la integración, incluido newrelic-infrastructure, lo que le permite instalar y actualizar fácilmente la integración utilizando un solo gráfico. Conozca los componentes predeterminados y opcionales que puede instalar con esta tabla aquí.

Arquitectura

El gráfico newrelic-infrastructure se divide en tres componentes diferentes: nrk8s-ksm, nrk8s-kubelet y nrk8s-controlplane. El primero es un despliegue y los dos siguientes son DaemonSets.

Cada uno de los componentes tiene dos contenedores:

1. Un contenedor para la integración, encargado de la recogida métrica.
2. Un contenedor con el agente New Relic Infrastructure , que se utiliza para enviar la métrica a New Relic.

Componente Kube-state-métrica

Construimos nuestro clúster state métrica sobre el proyecto OSSkube-state-metrics, que está alojado bajo la propia organización Kubernetes .

Un despliegue específico nrk8s-ksm se encarga de encontrar KSM y eliminarlo. Dado que este pod es único y de larga duración, puede utilizar de forma segura un informador extremo para localizar la IP del pod KSM y extraerlo. El informante almacena en caché automáticamente la lista de informantes en el clúster localmente y busca otros nuevos, evitando asaltar el servidor API con solicitudes para averiguar dónde estaba ubicado el pod.

Los clientes deben habilitar el seguimiento de cualquier métrica objetivo en KSM si esas métricas no están habilitadas de forma predeterminada. Por ejemplo, KSM v2+ deshabilita las etiquetas y anotaciones métricas de forma predeterminada. Los clientes pueden habilitar las etiquetas de destino y anotaciones métricas para ser monitoreadas utilizando las opciones metricLabelsAllowlist o metricAnnotationsAllowList descritas aquí en su clúster de Kubernetes.

Consulte Traiga su propio KSM para obtener más información sobre las versiones compatibles con KSM.

Componente kubelet

El Kubelet es el “agente Kubernetes ”, un servicio que se ejecuta en cada nodo Kubernetes y es responsable de crear el contenedor según las instrucciones del plano de control. Dado que es Kubelet quien se asocia estrechamente con el contenedor Runtime, es la principal fuente de infraestructura métrica para nuestra integración, como uso de CPU, memoria, disco, red, etc. Aunque no está completamente documentada, la API de Kubelet es la fuente de facto para la mayoría de las métricas Kubernetes .

Eliminar el Kubelet suele ser una operación que requiere pocos recursos. Teniendo esto en cuenta, y nuestra intención de minimizar el tráfico entre nodos siempre que sea posible, nrk8s-kubelet se ejecuta como un DaemonSet donde cada instancia recopila métricas del Kubelet que se ejecuta en el mismo nodo.

nrk8s-kubelet se conecta al Kubelet utilizando la IP del nodo. Si este proceso falla, nrk8s-kubelet recurrirá para llegar al nodo a través del proxy del servidor API. Este mecanismo alternativo le ayuda con clústeres muy grandes, ya que el proxy de muchos kubelets podría aumentar la carga en el servidor API . Puede comprobar si el servidor API se está utilizando como proxy buscando un mensaje como este en el registro:

Trying to connect to kubelet through API proxy

Componente del plano de control

Como distribuciones principales Kubernetes , implementamos nrk8s-controlplane como DaemonSet con hostNetwork: true. La configuración está estructurada para admitir detección automática y extremo estático. Para ser compatible con una amplia gama de distribuciones listas para usar, proporcionamos una amplia gama de valores predeterminados conocidos como entradas de configuración. Hacer esto en la configuración en lugar del código le permite ajustar el descubrimiento automático a sus necesidades.

Existe la posibilidad de tener varios extremos por selector y añadir un mecanismo de sonda que detecte automáticamente el correcto. Esto le permite probar diferentes configuraciones, como puertos o protocolos, utilizando el mismo selector.

La configuración de scraping para el componente etcd CP se parece a la siguiente, donde se aplica la misma estructura y característica para todos los componentes:

config:
  etcd:
    enabled: true
    autodiscover:
      - selector: "tier=control-plane,component=etcd"
        namespace: kube-system
        matchNode: true
        endpoints:
          - url: https://localhost:4001
            insecureSkipVerify: true
            auth:
              type: bearer
          - url: http://localhost:2381
    staticEndpoint:
      url: https://url:port
      insecureSkipVerify: true
      auth: {}

Si se establece staticEndpoint , el componente intenta eliminarlo. Si no puede llegar al extremo, la integración falla, por lo que no hay errores silenciosos cuando se configura el extremo manual.

Si staticEndpoint no está configurado, el componente iterará sobre las entradas de detección automática buscando el primer pod que coincida con selector en el namespace especificado y, opcionalmente, se ejecutará en el mismo nodo de DaemonSet (si matchNode está establecido en true). Después de descubrir un pod , el componente sondea, emitiendo una solicitud http HEAD, el extremo enumerado en orden y elimina el primer extremo sondeado con éxito utilizando el tipo de autorización seleccionado.

Si bien arriba mostramos un extracto de configuración para el componente etcd , la lógica de raspado es la misma para otros componentes.

Para obtener instrucciones más detalladas sobre cómo configurar el monitoreo del plano de control, consulte la página de monitoreo del plano de control .

Cartas de timón

Helm es el medio principal que ofrecemos para implementar nuestra solución en su clúster. El gráfico Helm gestiona un despliegue y dos DaemonSets donde cada uno tiene una configuración ligeramente diferente. Esto le brinda más flexibilidad para adaptar la solución a sus necesidades, sin la necesidad de aplicar parches manuales en la parte superior del gráfico y los manifiestos generados.

Algunas de las nuevas características que expone nuestro nuevo gráfico Helm son estas:

• Control total del securityContext para todos los pods
• Control total de pod labels y annotations para todos los pods
• Posibilidad de agregar variables de entorno adicionales, volumes y volumeMounts
• Control total sobre la configuración de integración, incluido el extremo al que se llega, el comportamiento de descubrimiento automático y los intervalos de raspado.
• Mejor alineación con los modismos y estándares de Helm

Puede consultar todos los detalles sobre todos los interruptores que se pueden activar en el README.mddel gráfico.

Componentes

Cuando instalas la integración de Kubernetes usando nri-bundle, estos dos componentes se instalan de forma predeterminada:

Estos son componentes opcionales que puedes instalar usando nri-bundle o por separado: