Descripción general

La versión 2 de integración de Kubernetes tiene algunas configuraciones y requisitos diferentes a los de la versión 3. Este documento repasa las configuraciones que son diferentes de la versión 3 y que necesitará para la versión 2. Si no especificamos nada diferente, puede usar la configuración de la versión 3.

Para comprender los cambios de la versión 3, consulte los cambios introducidos en el documento de integración de Kubernetes versión 3 .

Monitoreo plano de control con integración versión 2

Esta sección cubre cómo configurar el monitoreo del plano de control en las versiones 2 y anteriores de la integración.

Tenga en cuenta que estas versiones tenían opciones de descubrimiento automático menos flexibles y no admitían extremos externos. Le recomendamos encarecidamente que actualice a la versión 3 lo antes posible.

Detección automática y configuración predeterminada: hostNetwork y privileged

En versiones inferiores a la v3, cuando la integración se implementa usando privileged: false, la configuración hostNetwork para el componente del plano de control también se establecerá en false.

Descubrimiento de nodos maestros y componentes del plano de control.

La integración de Kubernetes se basa en las convenciones de etiquetado kubeadm para descubrir los nodos maestros y los componentes del plano de control. Esto significa que los nodos maestros deben etiquetar con node-role.kubernetes.io/master="" o kubernetes.io/role="master".

Los componentes del plano de control deben tener las etiquetas k8s-app o tier y component . Consulte esta tabla para conocer las combinaciones de etiquetas y los valores aceptados:

Cuando la integración detecta que se está ejecutando dentro de un nodo maestro, intenta encontrar qué componentes se están ejecutando en el nodo buscando pods que coincidan con las etiquetas enumeradas en la tabla anterior. Para cada componente en ejecución, la integración realiza una solicitud a su extremo métrico.

Configuración

El monitoreo del plano de control es automático para el agente que se ejecuta dentro de los nodos maestros. El único componente que requiere un paso adicional para ejecutarse es etcd, porque utiliza autenticación TLS mutua (mTLS) para las solicitudes de los clientes. El servidor API también se puede configurar para consultar mediante el puerto seguro.

etcd

Para configurar mTLS para consultar etcd, debe configurar estas dos opciones de configuración:

Servidor API

De forma predeterminada, el servidor API métrico se consulta utilizando el extremo no seguro localhost:8080. Si este puerto está deshabilitado, también puedes consultar estas métricas a través del puerto seguro. Para habilitar esto, establezca la siguiente opción de configuración en el archivo de manifiesto de integración de Kubernetes:

Configuración de OpenShift

Los componentes del plano de control en OpenShift 4.x emplean URL extremas que requieren SSL y autenticación basada en cuenta de servicio. Por lo tanto, no puede emplear las URL extremas predeterminadas .

Para configurar el monitoreo del plano de control en OpenShift, descomente las siguientes variables de entorno en el manifiesto personalizado. Los valores de URL están preconfigurados según las URL base predeterminadas para el monitoreo métrico extremo del plano de control en OpenShift 4.x.

- name: "SCHEDULER_ENDPOINT_URL"
        value: "https://localhost:10259
        - name: "ETCD_ENDPOINT_URL"
        value: "https://localhost:9979"
        - name: "CONTROLLER_MANAGER_ENDPOINT_URL"
        value: "https://localhost:10257"
        - name: "API_SERVER_ENDPOINT_URL"
        value: "https://localhost:6443"

Registro Kubernetes

Si desea generar un registro detallado y obtener información de versión y configuración, simplemente consulte la información a continuación.

Monitor los servicios que se ejecutan en Kubernetes

Los servicios de monitoreo en Kubernetes funcionan aprovechando nuestro agente de infraestructura e integración en el host y un mecanismo de descubrimiento automático para señalarlos al pod con un selector específico.

Consulte el documento Habilitar el monitoreo de servicios usando el Helm Chart para saber cómo hacerlo. Consulte este ejemplo para la versión 2, que muestra la configuración yaml para la integración de Redis agregada al archivo values.yml del gráfico nri-bundle .

newrelic-infrastructure:
    integrations_config:
    - name: nri-redis.yaml
    data:
    discovery:
    command:
    # Run NRI Discovery for Kubernetes
    # https://github.com/newrelic/nri-discovery-kubernetes
    exec: /var/db/newrelic-infra/nri-discovery-kubernetes --tls --port 10250
    match:
    label.app: redis
    integrations:
    - name: nri-redis
    env:
    # using the discovered IP as the hostname address
    HOSTNAME: ${discovery.ip}
    PORT: 6379
    labels:
    env: test

Agregue un servicio YAML a la configuración de integración de Kubernetes

Si está empleando la versión 2 de integración de Kubernetes, debe agregar una entrada para este ConfigMap en las secciones volumes y volumeMounts del spec de DaemonSet, para garantizar que todos los archivos en ConfigMap estén montados en /etc/newrelic-infra/integrations.d/.