Instalar la integración de Kubernetes

Utilice esta opción cuando tenga un sistema Kubernetes basado en Windows. Tenga en cuenta que existen varias limitaciones para la integración de Windows.

Compatibilidad y requisitos

Antes de instalar la integración de Kubernetes, revise la compatibilidad y los requisitos.

Para verificar su versión de Windows:

1. Abra una ventana de comando.

2. Ejecute el siguiente comando:

   bash

   Copia

   $
   Reg Query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v
   $
   ReleaseIdcmd.exe

   Ejemplo: obtener Kubernetes para Windows desde un contenedor BusyBox

   Ejecute este comando:

   bash

   Copia

   $
   kubectl exec -it busybox1-766bb4d6cc-rmsnj -- Reg Query
   $
   "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v ReleaseId

   Debería ver algo como esto:

   bash

   Copia

   $
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
   $
   ReleaseId   REG_SZ  1809

   Para obtener un mapeo útil entre los ID de versión y las versiones del sistema operativo, consulte aquí.

   Instalar

   Puede instalar la integración de Kubernetes para Windows usando Helm. Vea un ejemplo sobre cómo instalar la integración en un clúster con nodos que tienen diferentes versiones de compilación de Windows (1809 y 2004):

3. Agregue el repositorio de gráficos de New Relic Helm:

   bash

   Copia

   $
   helm repo add newrelic https://helm-charts.newrelic.com

4. Crea un namespace para newrelic:

   bash

   Copia

   $
   kubectl create namespace newrelic

5. Instalar kube-state-métrica.

   bash

   Copia

   $
   helm repo add ksm https://kubernetes.github.io/kube-state-metrics
   $
   helm install ksm ksm/kube-state-metrics --version 2.13.2

   Importante

   Este comando es para instalar kube-state-métrica, una dependencia obligatoria de la integración, en un nodo Linux. No admitimos la instalación de esto para nodos que no sean Linux y, si lo instala en un nodo que no sea Linux, la implementación podría fallar. Recomendamos utilizar nodeSelector para elegir un nodo de Linux. Esto se puede hacer editando kube-state-desplegable.

6. Cree un archivo values-newrelic.yaml con los siguientes datos para que Helm los utilice:

   global:
     licenseKey: _YOUR_NEW_RELIC_LICENSE_KEY_
     cluster: _K8S_CLUSTER_NAME_
   
   enableLinux: true        # Set to true if your cluster also has linux nodes
   enableWindows: true
   windowsOsList:
     - version: 2019            # Human-readable version identifier
       imageTag: 2-windows-1809-alpha  # Tag to be used for nodes running the windows version above
       buildNumber: 10.0.17763         # Build number for your nodes running the version above. Used as a selector.
     - version: 20h2
       imageTag: 2-windows-20H2-alpha
       buildNumber: 10.0.19042
     - version: 2022
       imageTag: 2-windows-ltsc2022-alpha
       buildNumber: 10.0.20348
   nodeSelector:
     kubernetes.io/os: linux         # Selector for Linux installation.
   windowsNodeSelector:
     kubernetes.io/os: windows       # Selector for Windows installation.

   Copia

7. Instale la integración con:

   bash

   Copia

   $
   helm upgrade --install newrelic newrelic/newrelic-infrastructure \
   >
   --namespace newrelic --create-namespace \
   >
   --version 2.7.2 \
   >
   -f values-newrelic.yaml

8. Verifique que los pods se estén desplegando y alcancen un estado estable:

   bash

   Copia

   $
   kubectl -n newrelic get pods -w

   El gráfico Helm creará un DaemonSet por cada versión de Windows que esté en la lista y usará NodeSelector para desplegar el pod correspondiente por nodo.

   Limitaciones

   Se aplican las siguientes limitaciones a la integración de Kubernetes para Windows:

• El agente de Windows solo envía las muestras de Kubernetes (K8sNodeSample, K8sPodSample, etc.)

  • SystemSample, StorageSample, NetworkSample y ProcessSample no se generan.
  • Faltan algunas Kubernetes métricas porque el kubelet de Windows no las tiene:

• Nodo:

  • fsInodes: no enviado
  • fsInodesFree: no enviado
  • fsInodesUsed: no enviado
  • memoryMajorPageFaultsPerSecond: siempre devuelve cero como valor
  • memoryPageFaults: siempre devuelve cero como valor
  • memoryRssBytes: siempre devuelve cero como valor
  • runtimeInodes: no enviado
  • runtimeInodesFree: no enviado
  • runtimeInodesUsed: no enviado

• Pod:

  • net.errorsPerSecond: no enviado
  • net.rxBytesPerSecond: no enviado
  • net.txBytesPerSecond: no enviado

• Contenedor:

  • containerID: no enviado
  • containerImageID: no enviado
  • memoryUsedBytes: en la UI, esto se muestra en la tarjeta pod que aparece cuando haces clic en un pod y no mostrará datos. Pronto solucionaremos este problema actualizando nuestros gráficos para utilizar memoryWorkingSetBytes en su lugar.

• Volumen:

  • fsUsedBytes: cero, entonces fsUsedPercent es cero

  Problemas conocidos con Windows Kubelet

  Hay un par de problemas con la versión de Windows de Kubelet que pueden impedir que la integración obtenga datos:

• Problema 90554: Este problema hace que Kubelet devuelva 500 errores cuando la integración realiza una solicitud al extremo /stats/summary . Se incluirá en la versión Kubernetes 1.19 y se ha compatible con las versiones 1.16.11. 1.17.7 y 1.18.4. No existe una solución para este problema en el lado de la integración; le recomendamos que actualice a una de las versiones del parche lo antes posible. Puedes ver si este problema te afecta habilitando el registro detallado y buscando mensajes del tipo:

  bash

  Copia

  $
  error querying Kubelet. Get "https://<KUBELET_IP>/stats/summary": error calling kubelet endpoint. Got status code: 500

• Problema 87730: Este problema hace que Kubelet métrica sea muy lento cuando se ejecuta con una carga mínima. Hace que la integración falle con un error de tiempo de espera. Se agregó un parche para este problema para Kubernetes 1.18 y se actualizó a 1.15.12. 1.16.9 y 1.17.5. Le recomendamos que actualice a una de las versiones del parche lo antes posible. Para mitigar este problema, puede aumentar el tiempo de espera de integración con la opción de configuraciónTIMEOUT . Puedes ver si este problema te afecta habilitando el registro detallado y buscando mensajes del tipo:

  bash

  Copia

  $
  error querying Kubelet. Get "https://<KUBELET_IP>/stats/summary": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

Utilice esta opción cuando monitoree la carga de trabajo Kubernetes en EKS Fargate. Esta integración inyecta automáticamente un sidecar que contiene el agente de infraestructura y la integración nri-Kubernetes en cada pod que necesita ser monitoreado.

New Relic admite el monitoreo de carga de trabajo Kubernetes en EKS Fargate al inyectar automáticamente un sidecar que contiene el agente de infraestructura y la integración nri-kubernetes en cada pod que necesita ser monitoreado.

Si el mismo clúster de Kubernetes también contiene nodos EC2, nuestra solución también será desplegar como DaemonSet en todos ellos. No se inyectará ningún sidecar en el módulo programado en los nodos EC2 y no se desplegará ningún DaemonSet en los nodos Fargate. A continuación se muestra un ejemplo de una instancia híbrida con nodos Fargate y EC2:

New Relic recopila todas las métricas admitidas para todos los objetos Kubernetes independientemente de dónde estén programados, ya sean nodos Fargate o EC2. Tenga en cuenta que, debido a las limitaciones impuestas por Fargate, la integración de New Relic se limita a ejecutarse en modo sin privilegios en los nodos de Fargate. Esto significa que las métricas que generalmente se obtienen directamente del host, como los procesos en ejecución, no estarán disponibles para los nodos Fargate.

El agente en ambos escenarios extraerá datos de Kube State métrica (KSM), Kubelet y cAdvisor y los enviará en el mismo formato.

Otros componentes de la solución New Relic para Kubernetes, como nri-prometheus, nri-metadata-injection y nri-kube-events, no tienen ninguna particularidad y se desplegarán mediante nuestro Helm Chart normalmente como lo harían en entornos que no son de Fargate.

Instalacion

Puede elegir entre dos alternativas para instalar la observabilidad total de New Relic en su clúster EKS Fargate:

• Inyección automática (recomendado)

• Inyección manual

  Independientemente del enfoque que elija, la experiencia es exactamente la misma después de su instalación. La única diferencia es cómo se inyecta el contenedor. Recomendamos configurar la inyección automática con el operador de monitoreo de infraestructura New Relic porque eliminará la necesidad de editar manualmente cada despliegue que desee monitor.

  Inyección automática (recomendado)

  De forma predeterminada, cuando el soporte de Fargate está habilitado, New Relic desplegará un operador en el clúster (newrelic-infra-operator). Una vez implementado, este operador inyectará automáticamente el sidecar de monitoreo en los pods que están programados en los nodos de Fargate, mientras también administra la creación y actualización de Secrets, ClusterRoleBindings y cualquier otro recurso relacionado.

  Este operador acepta una variedad de opciones de configuración avanzadas que se pueden usar para limitar o ampliar el alcance de la inyección, mediante el uso de selectores de etiquetas tanto para el pod como para el espacio de nombres.

  Que hace el operador

  Detrás de escena, el operador configura un MutatingWebhookConfiguration, que le permite modificar los objetos del pod que están a punto de crearse en el clúster. En este evento, y cuando el pod que se está creando coincida con la configuración del usuario, el operador:

1. Agregue un contenedor sidecar al pod que contiene la integración de New Relic Kubernetes.

2. Si no existe un secreto, cree uno en el mismo namespace que el pod que contiene la New Relic

   clave de licencia

   , que es necesaria para que el sidecar informe datos.

3. Agregue la cuenta de servicio del pod a un ClusterRoleBinding creado previamente por el gráfico del operador, lo que otorgará a este sidecar los permisos necesarios para alcanzar el extremo métrico Kubernetes .

   El ClusterRoleBinding otorga los siguientes permisos al pod que se inyecta:

   rules:

   Copia

• apiGroups: [""] resources:

  • "nodes"
  • "nodes/metrics"
  • "nodes/stats"
  • "nodes/proxy"
  • "pods"
  • "services"
  • "namespaces" verbs: ["get", "list"]

• nonResourceURLs: ["/metrics"] verbs: ["get"]

  <Callout variant="tip">
    Para que el sidecar pueda inyectarse y, por tanto, obtener la métrica del pod desplegar antes de que se haya instalado el operador, es necesario realizar manualmente un despliegue (reinicio) del despliegue afectado. De esta manera, cuando se creen los pod, el operador podrá inyectar el sidecar de monitoreo. New Relic ha optado por no hacer esto automáticamente para evitar interrupciones inesperadas del servicio y picos de uso de recursos.
  </Callout>
  
  <Callout variant="important">
    Recuerda crear un perfil de Fargate con un selector que declare el namespace `newrelic` (o el namespace que elijas para la instalación).
  </Callout>
  
  Aquí está el flujo de trabajo de inyección:
  
  <img
    title="Diagram showing the workflow of sidecar injection"
    alt="Diagram showing the workflow of sidecar injection"
    src={kubernetesFargateWorkflow}
  />
  
  #### Instalación de inyección automática [#auto-injection-install]
  
  <Callout variant="tip">
    Los siguientes pasos son para una configuración predeterminada. Antes de completarlos, le sugerimos que eche un vistazo a la sección [de configuración](#config-auto) a continuación para ver si desea modificar algún aspecto de la inyección automática.
  </Callout>
  
  Primero, agregue el repositorio New Relic Helm si no lo ha hecho antes:
  
  ```shell
  helm repo add newrelic https://helm-charts.newrelic.com

  Copia

  Luego, para instalar el operador encargado de inyectar el sidecar de infraestructura, cree un archivo llamado values.yaml, que se utilizará para definir su configuración:

  ## Global values
  global:
    # -- The cluster name for the Kubernetes cluster.
    cluster: "_YOUR_K8S_CLUSTER_NAME_"
  
    # -- The license key for your New Relic Account. This will be preferred configuration option if both `licenseKey` and `customSecret` are specified.
    licenseKey: "_YOUR_NEW_RELIC_LICENSE_KEY_"
  
    # -- (bool) In each integration it has different behavior. Enables operating system metric collection on each EC2 K8s node. Not applicable to Fargate nodes.
    # @default -- false
    privileged: true
  
    # -- (bool) Must be set to `true` when deploying in an EKS Fargate environment
    # @default -- false
    fargate: true
  
  ## Enable nri-bundle sub-charts
  
  newrelic-infra-operator:
    # Deploys the infrastructure operator, which injects the monitoring sidecar into Fargate pods
    enabled: true
    tolerations: 
    - key: "eks.amazonaws.com/compute-type"
      operator: "Equal"
      value: "fargate"
      effect: "NoSchedule"
    config:
      ignoreMutationErrors: true
      infraAgentInjection:
        # Injection policies can be defined here.  See [values file](https://github.com/newrelic/newrelic-infra-operator/blob/main/charts/newrelic-infra-operator/values.yaml#L114-L125) for more detail.
        policies:
        - namespaceName: namespace-a
        - namespaceName: namespace-b
  
  newrelic-infrastructure:
    # Deploys the Infrastructure Daemonset to EC2 nodes.  Disable for Fargate-only clusters.
    enabled: true
  
  nri-metadata-injection:
    # Deploy our mutating admission webhook to link APM and Kubernetes entities
    enabled: true
  
  kube-state-metrics:
    # Deploys Kube State Metrics.  Disable if you are already running KSM in your cluster.
    enabled: true
  
  nri-kube-events:
    # Deploy the Kubernetes events integration.
    enabled: true
  
  newrelic-logging:
    # Deploys the New Relic's Fluent Bit daemonset to EC2 nodes.  Disable for Fargate-only clusters.
    enabled: true
  
  newrelic-prometheus-agent:
    # Deploys the Prometheus agent for scraping Prometheus endpoints.
    enabled: true
    config:
      kubernetes:
        integrations_filter:
          enabled: true
          source_labels: ["app.kubernetes.io/name", "app.newrelic.io/name", "k8s-app"]
          app_values: ["redis", "traefik", "calico", "nginx", "coredns", "kube-dns", "etcd", "cockroachdb", "velero", "harbor", "argocd", "istio"]

  Copia

  Finalmente, después de crear y modificar el archivo, puede desplegar la solución usando el siguiente comando de Helm:

  bash

  Copia

  $
  helm upgrade --install newrelic-bundle newrelic/nri-bundle -n newrelic --create-namespace -f values.yaml

  Importante

  Cuando implemente la solución en un clúster híbrido (con nodos EC2 y Fargate), asegúrese de que la solución no esté seleccionada por ningún perfil de Fargate; de lo contrario, la instancia DaemonSet quedará bloqueada en un estado pendiente. Para entornos exclusivos de Fargate, esto no es una preocupación porque no se crea ninguna instancia DaemonSet .

  Configuración

  Puedes configurar diferentes aspectos de la inyección automática. De forma predeterminada, el operador inyectará el sidecar de monitoreo en todos los pods desplegar en los nodos de Fargate que no formen parte de un Job o un BatchJob.

  Este comportamiento se puede cambiar a través de las opciones de configuración. Por ejemplo, puede definir selectores para limitar o ampliar la selección de pods que se inyectan, asignar recursos al operador y ajustar el sidecar. Además, puedes agregar otros atributos, etiquetas y variables de entorno. Consulte el gráfico README.md y values.yaml.

  Importante

  Al especificar sus propias reglas de inyección personalizadas, se descartará el conjunto de reglas predeterminado que impide la inyección de sidecar en pods que no están programados en Fargate. Asegúrese de que sus reglas personalizadas tengan el mismo efecto; de lo contrario, en el clúster híbrido que también tiene DaemonSet desplegar, el pod programado en EC2 se monitoreará dos veces, lo que generará datos incorrectos o duplicados.

  Actualizar a la última versión o a una nueva configuración

  Para actualizar a la última versión de la integración EKS Fargate, actualice el repositorio Helm usando helm repo update newrelic y reinstale el paquete simplemente ejecutando nuevamente el comando anterior.

  Para actualizar la configuración del agente de infraestructura inyectado o del propio operador, modifique values-newrelic.yaml y actualice la versión de Helm con la nueva configuración. El operador se actualiza inmediatamente y su carga de trabajo quedará instrumentada con la nueva versión en su próximo reinicio. Si deseas actualizarlos inmediatamente, puedes forzar un reinicio de tu carga de trabajo ejecutando:

  bash

  Copia

  $
  kubectl rollout restart deployment YOUR_APP

  Desinstalar la integración de Fargate

  Para desinstalar el sidecar que realiza la inyección automática pero conservar el resto de la solución New Relic, usando Helm, desactive el infraoperador configurando infra-operator.enabled en false, ya sea en el archivo values.yaml o en la línea de comando (--set) y vuelva a ejecutar el comando de instalación anterior.

  Recomendamos encarecidamente mantener el indicador --set global.fargate=true , ya que no habilita la inyección automática pero hace que otros componentes de la instalación sean compatibles con Fargate, evitando comportamientos no deseados.

  Para desinstalar toda la solución:

1. Desinstale completamente la versión Helm.

2. Despliegue la cápsula para quitar el sidecar:

   bash

   Copia

   $
   kubectl rollout restart deployment YOUR_APP

3. Basura recoge los secretos:

   bash

   Copia

   $
   kubectl delete secrets -n YOUR_NAMESPACE -l newrelic/infra-operator-created=true

   Limitaciones conocidas: inyección automática

   A continuación se detallan algunas cuestiones que debe tener en cuenta al utilizar la inyección automática:

4. Actualmente no existe ningún controlador que vigile todo el clúster para asegurarse de que los secretos que ya no son necesarios se recopilen como basura. Sin embargo, todos los objetos comparten la misma etiqueta que puedes usar para eliminar todos los recursos, si es necesario. Inyectamos la etiqueta newrelic/infra-operator-created: true, que puedes usar para eliminar recursos con un solo comando.

5. Por el momento, no es posible utilizar el sidecar inyectado para monitor los servicios que se ejecutan en el pod. El sidecar solo monitor el propio Kubernetes . Sin embargo, es posible que el usuario avanzado desee excluir estos pods de la inyección automática e inyectar manualmente una versión personalizada del sidecar con la integración en el host habilitada configurándolos y montando su configuración en el lugar adecuado. Para obtener ayuda, consulte este tutorial.

   Inyección manual

   Si tiene alguna inquietud sobre la inyección automática, puede inyectar el sidecar manualmente directamente modificando los manifiestos de la carga de trabajo programada que se programarán en los nodos Fargate. Tenga en cuenta que agregar el sidecar al despliegue programado en los nodos EC2 puede generar datos incorrectos o duplicados, especialmente si esos nodos ya se están monitoreando con DaemonSet.

   Se requieren los siguientes objetos para que el sidecar informe datos correctamente:

• El ClusterRole que proporciona el permiso necesario para la integración nri-kubernetes

• Un ClusterRoleBinding que vincula el ClusterRole y la cuenta de servicio del pod

• El secreto que almacena la New Relic licenseKey en cada namespacede Fargate

• El contenedor sidecar en la plantilla de especificaciones del monitor carga de trabajo

  Instalación de inyección manual

  Sugerencia

  Estos pasos de configuración manual son para una instalación genérica. Antes de completarlos, eche un vistazo a la sección de configuración a continuación para ver si desea modificar algún aspecto de la inyección automática.

  Complete lo siguiente para la inyección manual:

1. Si ClusterRole no existe, créelo y otorgue los permisos necesarios para alcanzar la métrica extrema. Esto sólo necesita hacerse una vez, incluso para monitoreo de múltiples aplicaciones en el mismo clúster.

   Función del clúster

   Puede utilizar este fragmento tal como aparece a continuación, sin ningún cambio:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     labels:
       app: newrelic-infrastructure
     name: newrelic-newrelic-infrastructure-infra-agent
   rules:
   - apiGroups:
     - ""
     resources:
     - nodes
     - nodes/metrics
     - nodes/stats
     - nodes/proxy
     - pods
     - services
     verbs:
     - get
     - list
   - nonResourceURLs:
     - /metrics
     verbs:
     - get

   Copia

2. Para cada carga de trabajo que desee monitor, agregue un contenedor adicional para la imagen newrelic/infrastructure-k8s. A continuación se muestra un ejemplo de un sidecar inyectado.

   Contenedor para inyectar

   Toma el contenedor del siguiente fragmento e inyéctalo en la carga de trabajo que deseas monitor, especificando el nombre de tu FargateProfile en la variable customAttributes. Tenga en cuenta que los volúmenes se pueden definir como emptyDir: {}.

   Sugerencia

   En el caso especial de un KSM implementado, también debe eliminar la variable de entorno DISABLE_KUBE_STATE_METRICS y aumentar las solicitudes y límites de recursos.

   apiVersion: apps/v1
   kind: Deployment
   spec:
   template:
   spec:
   containers:
   - name: newrelic-infrastructure
     env:
     - name: NRIA_LICENSE_KEY
       valueFrom:
         secretKeyRef:
           key: license
           name: newrelic-newrelic-infrastructure-config
     - name: NRIA_VERBOSE
       value: "1"
     - name: DISABLE_KUBE_STATE_METRICS
       value: "true"
     - name: CLUSTER_NAME
       value: testing-injection
     - name: COMPUTE_TYPE
       value: serverless
     - name: NRK8S_NODE_NAME
       valueFrom:
         fieldRef:
           apiVersion: v1
           fieldPath: spec.nodeName
     - name: NRIA_DISPLAY_NAME
       valueFrom:
         fieldRef:
           apiVersion: v1
           fieldPath: spec.nodeName
     - name: NRIA_CUSTOM_ATTRIBUTES
       value: '{"clusterName":"$(CLUSTER_NAME)", "computeType":"$(COMPUTE_TYPE)", "fargateProfile":"[YOUR FARGATE PROFILE]"}'
     - name: NRIA_PASSTHROUGH_ENVIRONMENT
       value: KUBERNETES_SERVICE_HOST,KUBERNETES_SERVICE_PORT,CLUSTER_NAME,CADVISOR_PORT,NRK8S_NODE_NAME,KUBE_STATE_METRICS_URL,KUBE_STATE_METRICS_POD_LABEL,TIMEOUT,ETCD_TLS_SECRET_NAME,ETCD_TLS_SECRET_NAMESPACE,API_SERVER_SECURE_PORT,KUBE_STATE_METRICS_SCHEME,KUBE_STATE_METRICS_PORT,SCHEDULER_ENDPOINT_URL,ETCD_ENDPOINT_URL,CONTROLLER_MANAGER_ENDPOINT_URL,API_SERVER_ENDPOINT_URL,DISABLE_KUBE_STATE_METRICS,DISCOVERY_CACHE_TTL
     image: newrelic/infrastructure-k8s:2.4.0-unprivileged
     imagePullPolicy: IfNotPresent
     resources:
       limits:
         memory: 100M
         cpu: 200m
       requests:
         cpu: 100m
         memory: 50M
     securityContext:
       allowPrivilegeEscalation: false
       readOnlyRootFilesystem: true
       runAsUser: 1000
     terminationMessagePath: /dev/termination-log
     terminationMessagePolicy: File
     volumeMounts:
     - mountPath: /var/db/newrelic-infra/data
       name: tmpfs-data
     - mountPath: /var/db/newrelic-infra/user_data
       name: tmpfs-user-data
     - mountPath: /tmp
       name: tmpfs-tmp
     - mountPath: /var/cache/nr-kubernetes
       name: tmpfs-cache
   [...]

   Copia

3. Cree un ClusterRoleBinding, o agregue a uno creado previamente el ServiceAccount de la aplicación que se va a monitorear. Todas las cargas de trabajo pueden compartir el mismo ClusterRoleBinding, pero a él se le deben sumar los ServiceAccount de cada una.

   Enlace de roles de clúster

   Crea el siguiente ClusterRoleBinding que tenga como asunto la cuenta de servicio del pod que deseas monitor.

   Sugerencia

   No es necesario repetir la misma cuenta de servicio dos veces. Cada vez que desee monitor un pod con una cuenta de servicio que aún no está incluida, simplemente agréguelo a la lista.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: newrelic-newrelic-infrastructure-infra-agent
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: newrelic-newrelic-infrastructure-infra-agent
   subjects:
   - kind: ServiceAccount
     name: [INSERT_SERVICE_ACCOUNT_NAME_OF_WORKLOAD]
     namespace: [INSERT_SERVICE_ACCOUNT_NAMESPACE_OF_WORKLOAD]

   Copia

4. Crea un secreto que contenga la New Relic clave de licencia. Cada namespace necesita su propio secreto.

   Secreto

   Cree el siguiente Secret que tenga una licencia con el valor codificado en Base64 de su clave de licencia. Se necesita un secreto en cada namespace donde se ejecuta un pod que desea monitor .

   apiVersion: v1
   data:
     license: INSERT_YOUR_NEW_RELIC_LICENSE_ENCODED_IN_BASE64
     kind: Secret
   metadata:
     name: newrelic-newrelic-infrastructure-config
     namespace: [INSERT_NAMESPACE_OF_WORKLOAD]
     type: Opaque

   Copia

   Configuración

   Al agregar manualmente el manifiesto del agente complementario, puede utilizar cualquier opción de configuración del agente para configurar el comportamiento del agente. Para obtener ayuda, consulte Valores de configuración del agente de infraestructura.

   Actualizar a la última versión

   Para actualizar cualquiera de los componentes, solo necesitas modificar desplegar yaml.

   La actualización de cualquiera de los campos del contenedor inyectado hará que se vuelva a crear el pod.

   Importante

   El agente no puede cargar en caliente la New Relic clave de licencia. Después de actualizar el secreto, debes implementar el despliegue nuevamente.

   Desinstalar la integración de Fargate

   Para eliminar el contenedor inyectado y los recursos relacionados, sólo tienes que eliminar lo siguiente:

• El sidecar de la carga de trabajo que ya no debería ser monitoreado.

• Todos los secretos que contiene la licencia newrelic.

• ClusterRole y ClusterRoleBinding objetos.

  Tenga en cuenta que eliminar el contenedor sidecar hará que se vuelva a crear el pod .

  Inicio sesión

  El registro de New Relic no está disponible en los nodos de Fargate debido a restricciones de seguridad impuestas por AWS, pero aquí hay algunas opciones de registro:

• Si estás utilizando Fluentbit para iniciar sesión, consulta el complementoKubernetes para reenvío de registros.

• Si FireLens log ya supervisa sus datos AWS , consulte AWS el complemento FireLens para obtener información sobre el reenvío de registros .

• Si sus datos log ya están siendo monitoreados por el registro de Amazon CloudWatch, consulte Transmitir registro mediante Kinesis Data Firehose.

• Consulte AWS Lambda para enviar registros de CloudWatch.

• Consulte Tres formas de reenviar registros de Amazon ECS a New Relic.

  Resolución de problemas

  Se están implementando réplicas de DaemonSet en nodos de Fargate

  Si observa que se están programando réplicas de Infra DaemonSet en nodos de Fargate, es posible que se deba a que las reglas nodeAffinity no están configuradas correctamente.

  Vuelva a verificar que la solución se instaló con la opción global.fargate para true, ya sea a través de la línea de comando (--set global.fargate=true) o en el archivo values.yaml . Si el método de instalación no fue Helm, deberá agregar manualmente nodeAffinity reglas para excluir los nodos de Fargate.

  Evento FailedScheduling debido a contaminación no tolerada

  Recuerda agregar en el archivo values.yaml el tolerations descrito en Instalación de inyección automática si obtienes el siguiente evento al intentar crear un pod:

  LAST SEEN | TYPE | REASON | OBJECT | MESSAGE
  :--|:--|:--|:--|:--
  3m9s (x2 over 8m10s) | Warning | FailedScheduling | Pod/no-fargate-deploy-cbddd6ccf-8f9x4 | 0/2 nodes are available: 2 node(s) had untolerated taint {eks.amazonaws.com/compute-type: fargate}. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling..

  Copia

  Evento FailedScheduling debido a demasiados pods

  Verifique si hay un perfil de Fargate con un selector que nombre el namespace donde se realiza la instalación si obtiene el siguiente evento al intentar crear un pod:

  LAST SEEN | TYPE | REASON | OBJECT | MESSAGE
  :--|:--|:--|:--|:--
  61s | Warning | FailedScheduling | Pod/newrelic-bundle-newrelic-infra-operator-admission-create-d8ggt | 0/2 nodes are available: 2 Too many pods. preemption: 0/2 nodes are available: 2 No preemption victims found for incoming pod..

  Copia

  Ver sus datos EKS

  A continuación se muestra un ejemplo de cómo se ve un nodo Fargate en la New Relic UI:

  

  Para ver sus datos de AWS:

1. Vaya a

   one.newrelic.com > All capabilities > Infrastructure > Kubernetes

   y realice una de las siguientes acciones:

   • Seleccione un nombre de integración para ver los datos.
   • Seleccione el icono Explorar datos para ver los datos de AWS.

2. Filtra tus datos usando dos etiquetas Fargate:

   • computeType=serverless
   • fargateProfile=[name of the Fargate profile to which the workload belongs]

Si desea utilizar Helm para instalar la integración, tiene dos opciones:

1. Nuestra experiencia de instalación guiada, que proporcionará un comando Helm con los campos obligatorios completados previamente. Esta opción también permite instalar nuestra integración como manifiestos simples en lugar de una versión de Helm.

2. Configuración manual a través del archivo values.yaml . Esta pestaña le guiará sobre cómo hacerlo.

   Helm es un administrador de paquetes además de Kubernetes. Facilita la instalación, actualizaciones o seguimiento de revisiones, y gestiona la dependencia de los servicios que instalas en Kubernetes. Si aún no lo ha hecho, cree su cuenta New Relic gratuita a continuación para comenzar a monitorear sus datos hoy.

   Iniciar el instalador

   Compatibilidad y requisitos

   Asegúrese de que Helm esté instalado en su máquina. La versión 3 de la integración de Kubernetes requiere la versión 3 de Helm.

   Para instalar la integración de Kubernetes usando Helm, necesitará su New Relic clave de licenciay el nombre de su clúster de Kubernetes:

3. Busque y copie su clave de licencia.

4. Elija un nombre para mostrar para su clúster. Por ejemplo, podría utilizar la salida de:

   bash

   Copia

   $
   kubectl config current-context

   Importante

   Guarde estos valores en un lugar seguro, ya que los necesitará más adelante durante el proceso de instalación.

   Instale la integración de Kubernetes con Helm

   New Relic tiene varios gráficos de Helm para los diferentes componentes que ofrecen diferentes características para la plataforma:

• newrelic-infrastructure: contiene la integración principal de Kubernetes y el agente de infraestructura. Este es el componente central de la New Relic Kubernetes experiencia , responsable de informar la mayoría de los datos que aparecen en el Kubernetes dashboard y el clúster de Kubernetes Explorer.

• newrelic-logging: proporciona un DaemonSet con el New Relic complemento de salida Fluent Bit de para reenviar fácilmente su registro a New Relic.

• nri-kube-events: recopila y notifica el evento del clúster (como kubectl get events) a New Relic.

• newrelic-prometheus-agent: El Configurador Prometheus de New Relic configura un Prometheus en modo agente y utiliza nuestro extremo de escritura remota para generar informes métricos a New Relic.

• nri-metadata-injection: configura un MutatingAdmissionWebhook mínimo que inyecta un par de variables de entorno en el contenedor. Estos contienen metadatos sobre el clúster y la instalación New Relic y serán posteriormente recogidos por la aplicación instrumentada usando APM, permitiendo correlacionar datos APM e infraestructura.

• nri-statsd: New Relic StatsD.

  Aunque puede instalar estos componentes por separado, le recomendamos encarecidamente que utilice la tabla nri-bundle . New Relic proporciona este gráfico, que actúa como un contenedor o metapaquete para los gráficos individuales mencionados anteriormente. El uso de este gráfico le permite estas ventajas:

• Proporciona control total sobre qué componentes están instalados. Cada componente se instala como una dependencia de Helm independiente. Puede configurarlos individualmente usando el parámetro mencionado aquí.

• Garantiza que sus versiones instaladas sean compatibles entre sí.

• Garantiza que sus valores de configuración sean consistentes en todos los gráficos instalados.

  El gráfico nri-bundle es el que instala y configura nuestra instalación guiada de Kubernetes.

  Instalación y configuración nri-bundle con Helm

1. Asegúrese de utilizar el contexto adecuado en la máquina donde ejecutará Helm y kubectl:

   Puedes consultar los contextos disponibles con:

   bash

   Copia

   $
   kubectl config get-contexts

   Y cambie al contexto deseado usando:

   bash

   Copia

   $
   kubectl config use-context _CONTEXT_NAME_

2. Agregue el repositorio de gráficos de New Relic Helm:

   bash

   Copia

   $
   helm repo add newrelic https://helm-charts.newrelic.com

3. Cree un archivo llamado values-newrelic.yaml, que se utilizará para definir su configuración:

   global:
     licenseKey: _YOUR_NEW_RELIC_LICENSE_KEY_
     cluster: _K8S_CLUSTER_NAME_
   
   newrelic-prometheus-agent:
     # Automatically scrape prometheus metrics for annotated services in the cluster
     # Collecting prometheus metrics for large clusters might impact data usage significantly
     enabled: true
   nri-metadata-injection:
     # Deploy our webhook to link APM and Kubernetes entities
     enabled: true
   nri-kube-events:
     # Report Kubernetes events
     enabled: true
   newrelic-logging:
     # Report logs for containers running in the cluster
     enabled: true
   kube-state-metrics:
     # Deploy kube-state-metrics in the cluster.
     # Set this to true unless it is already deployed.
     enabled: true

   Copia

4. Asegúrese de que todo esté configurado correctamente en el gráfico ejecutando el siguiente comando. Tenga en cuenta que estamos especificando --dry-run y --debug, por lo que no se instalará nada en este paso:

   bash

   Copia

   $
   helm upgrade --install newrelic-bundle newrelic/nri-bundle \
   >
   --namespace newrelic --create-namespace \
   >
   -f values-newrelic.yaml \
   >
   --dry-run \
   >
   --debug

   Tenga en cuenta y ajuste las siguientes banderas:

   • global.licenseKey=YOUR_NEW_RELIC_LICENSE_KEY: Debe configurarse en un

     clave de licencia

     válido para su cuenta.

   • global.cluster=K8S_CLUSTER_NAME: Se utiliza para identificar el clúster en la New Relic UI, por lo que debe ser un valor descriptivo no utilizado por ningún otro clúster de Kubernetes configurado en su New Relic cuenta .

   • kube-state-metrics.enabled=true: Establecer esto en true instalará automáticamente Kube State métrica (KSM), que es necesario para que se ejecute nuestra integración. Puede establecer esto en falso si KSM ya está presente en su clúster, incluso si está en un namespace diferente.

   • newrelic-prometheus-agent.enabled=true: desplegará nuestro agente Prometheus, que recopila automáticamente datos del extremo Prometheus presente en el clúster.

   • nri-metadata-injection.enabled=true: Instalaremos nuestro webhook mínimo, que agrega variables de entorno que, a su vez, permiten vincular la aplicación instrumentada con New Relic APM a Kubernetes.

   Nuestros gráficos de Kubernetes tienen un conjunto completo de indicadores y parámetros ajustables que se pueden editar para adaptarse mejor a sus necesidades particulares. Por favor, consulte la sección Configurar la integración a continuación para ver qué se puede cambiar.

5. Instale la integración de Kubernetes ejecutando el comando sin --debug y --dry-run:

   bash

   Copia

   $
   helm upgrade --install newrelic-bundle newrelic/nri-bundle \
   >
   --namespace newrelic --create-namespace \
   >
   -f values-newrelic.yaml

   Importante

   Asegúrese de utilizar Kubernetes versión 1.27.x o una versión inferior que admitamos.

6. Verifique que los pods se estén desplegando y alcancen un estado estable:

   bash

   Copia

   $
   kubectl -n newrelic get pods -w

   Debería ver:

• newrelic-nrk8s-ksm pod.

• newrelic-nrk8s-kubelet pod para cada nodo de su clúster.

• newrelic-nrk8s-control-plane pod para cada nodo maestro de su clúster, si lo hubiera.

• newrelic-kube-state-metrics pod, si incluyó KSM con nuestra instalación.

• newrelic-nri-kube-events pod, si habilitó los informes de eventos Kubernetes .

• prometheus-agent pod, si habilitó la integración del agente Prometheus .

• newrelic-newrelic-logging pod para cada nodo de su clúster, si habilitó la integración de registro.

  ¿Te ha ayudado este documento con la instalación?

  Comparte tus comentarios.

  Configurar la integración

  Nuestro gráfico nri-bundle . cuyas instrucciones de instalación se pueden encontrar arriba, actúa como un contenedor o un metapaquete para un par de gráficos más, que son los que contienen los componentes de nuestra solución. Al ofrecer un contenedor de este tipo, podemos proporcionar un conjunto controlado de nuestros componentes con versiones que sabemos que son compatibles entre sí, manteniendo los gráficos de los componentes relativamente simples.

  El gráfico nri-bundle envuelve varios gráficos individuales para recopilar diferentes telemetry data y enviarlos a New Relic. El paquete permite habilitar selectivamente los gráficos secundarios deseados según sus necesidades. Para configurar cada componente individual, debe utilizar el sistema de dependencia de Helm, lo que en resumen significa que la configuración de cada gráfico secundario debe colocarse en una sección separada (que lleva el nombre de cada gráfico secundario) en el archivo values-newrelic.yml. Por ejemplo, para configurar el gráfico newrelic-infrastructure , agregaría lo siguiente al values-newrelic.yaml:

  # General settings that apply to all the child charts
  global:
    licenseKey: _YOUR_NEW_RELIC_LICENSE_KEY_
    cluster: _K8S_CLUSTER_NAME_
  
  # ... Other settings as shown above
  
  # Specific configuration for the newrelic-infrastructure child chart
  newrelic-infrastructure:
    verboseLog: true  # Enable debug logs
    privileged: false  # Install with minimal privileges
    # Other options from https://github.com/newrelic/helm-charts/tree/master/charts/newrelic-infrastructure-v3
  
  # Specific configuration for the newrelic-logging child chart
  newrelic-logging:
    fluentBit:
    retryLimit: 10

  Copia

  También puede pasar opciones de gráfico secundario a través de la línea de comando prefijándolas con el nombre del gráfico secundario y reemplazando el anidamiento por puntos:

  helm upgrade --install newrelic-bundle newrelic/nri-bundle \
  --namespace=newrelic \
  --set global.licenseKey=_YOUR_NEW_RELIC_LICENSE_KEY_ \
  --set global.cluster=_K8S_CLUSTER_NAME_ \
  --set newrelic-infrastructure.privileged=false \
  --set newrelic-infrastructure.verboseLog=true \
  --set newrelic-logging.fluentBit.retryLimit=10

  Copia

  La lista completa de indicadores que puede modificar (como scrape-interval) para cada gráfico secundario se puede encontrar en su respectivo repositorio:

• newrelic-infrastructure

• Configurar log de depuración, modo de privilegios, monitoreo del plano de control, etc.

• nri-kube-events

• nri-metadata-injection

• Configurar cómo se desplegará el webhook para la vinculación APM .

• Configure qué extremo de Prometheus se raspa.

• newrelic-logging

• Configura qué registro o atributo log se envían a New Relic.

  Sugerencia

  Al especificar opciones de configuración para los gráficos secundarios, debe colocarlas en una sección que lleve el nombre del gráfico en su values-newrelic.yaml.

  Sugerencia

  Para pasar opciones de gráficos secundarios a través de la línea de comando, debe anteponerles el nombre del gráfico secundario y reemplazar el anidamiento por puntos.

Hay tres formas de instalar la integración de Kubernetes en tu clúster de GKE Autopilot:

• La CLI de New Relic que se encuentra en nuestra instalación guiada

• Un comando de Helm con valores requeridos previamente completados

• Un manifiesto simple con valores requeridos precargados

  Instalación guiada (recomendado)

  Puedes instalar en el piloto automático de GKE usando el mismo flujo de instalación que nuestra pestaña de instalación guiada .

  Timón manual

  Su comando Helm completo debería parecerse al siguiente:

  bash

  Copia

  $
  KSM_IMAGE_VERSION="v2.10.0" && \
  >
  helm repo add newrelic https://helm-charts.newrelic.com && helm repo update && \
  >
  kubectl create namespace newrelic ; helm upgrade --install newrelic-bundle newrelic/nri-bundle \
  >
  --set global.licenseKey=<Your License Key> \
  >
  --set global.cluster=<Your Cluster Name> \
  >
  --namespace=newrelic \
  >
  --set newrelic-infrastructure.privileged=false \
  >
  --set newrelic-infrastructure.controlPlane.enabled=false \
  >
  --set newrelic-infrastructure.kubelet.config.scheme=http \
  >
  --set newrelic-infrastructure.kubelet.config.port=10255 \
  >
  --set global.lowDataMode=true \
  >
  --set kube-state-metrics.image.tag=${KSM_IMAGE_VERSION} \
  >
  --set kube-state-metrics.enabled=true \
  >
  --set kubeEvents.enabled=true \
  >
  --set newrelic-prometheus-agent.enabled=true \
  >
  --set newrelic-prometheus-agent.lowDataMode=true \
  >
  --set newrelic-prometheus-agent.config.kubernetes.integrations_filter.enabled=false \
  >
  --set newrelic-pixie.enabled=false
  $
  --set logging.enabled=true 
  $
  --set newrelic-logging.lowDataMode=true 
  $
  --set newrelic-logging.fluentBit.linuxMountPath=/var/log  
  $
  --set newrelic-logging.fluentBit.persistence.mode=persistentVolume 
  $
  --set newrelic-logging.fluentBit.persistence.persistentVolume.storageClass=standard-rwx

  Fluent Bit puede usar un volumen de FileStore para evitar la pérdida de datos o registros duplicados durante los reinicios o redespliegues pod de Fluent Bit. El uso de FileStore genera costos adicionales, según los cobra Google. Recomendamos consultar a su administrador de Google Cloud o visitar los documentos de FileStore para obtener más detalles. La API de Google FileStore debe estar habilitada en tu proyecto de GKE. Consulte este documento para saber más sobre cómo habilitar las API.

  Si no desea utilizar FileStore, agregue lo siguiente:

  • Establezca "newrelic-logging.fluentBit.persistence.mode" en "none"
  • Eliminar "newrelic-logging.fluentBit.persistence.persistentVolume.storageClass"

  Consulte nuestros documentos del gráfico Helm para obtener más información.

  Manifiesto

  Actualice su comando de manifiesto con las siguientes banderas:

  • Establezca "newrelic-infrastructure.privileged", "newrelic-infrastructure.controlPlane.enabled" en false.

  • Agregar "newrelic-infrastructure.kubelet.config.scheme":"http"

  • Agregar "newrelic-infrastructure.kubelet.config.port":"10255"

  • Agregar "logging.enabled":"true"

  • Agregar "newrelic-logging.lowDataMode":"true"

  • Agregar "newrelic-logging.fluentBit.linuxMountPath":"/var/log"

  • Agregar "newrelic-logging.fluentBit.persistence.mode":"persistentVolume"

  • Agregar "newrelic-logging.fluentBit.persistence.persistentVolume.storageClass":"standard-rwx"

  • Elimina la carga útil de Pixie del comando, ya que Pixie no es compatible actualmente con GKE Autopilot.

    Fluent Bit puede usar un volumen de FileStore para evitar la pérdida de datos o registros duplicados durante los reinicios o redespliegues pod de Fluent Bit. El uso de FileStore genera costos adicionales, según los cobra Google. Recomendamos consultar a su administrador de Google Cloud o visitar los documentos de FileStore para obtener más detalles. La API de Google FileStore debe estar habilitada en tu proyecto de GKE. Consulte este documento para saber más sobre cómo habilitar las API.

    Si no desea utilizar FileStore, agregue lo siguiente:

  • Establezca "newrelic-logging.fluentBit.persistence.mode" en "none"

  • Eliminar "newrelic-logging.fluentBit.persistence.persistentVolume.storageClass"

    Aquí hay un comando que crea un archivo de manifiesto y luego lo aplica al clúster:

    bash

    Copia

    $
    KSM_IMAGE_VERSION="v2.10.0" && \
    >
    curl -X POST https://k8s-config-generator.service.newrelic.com/generate -H 'Content-Type: application/json' -d '{"global.cluster":"<Your Cluster Name>","global.namespace":"newrelic","newrelic-infrastructure.privileged":"false","newrelic-infrastructure.controlPlane.enabled":"false","newrelic-infrastructure.kubelet.config.scheme":"http","newrelic-infrastructure.kubelet.config.port":"10255","global.lowDataMode":"true","kube-state-metrics.image.tag":"'${KSM_IMAGE_VERSION}'","kube-state-metrics.enabled":"true","kubeEvents.enabled":"true","newrelic-prometheus-agent.enabled":"true","newrelic-prometheus-agent.lowDataMode":"true","newrelic-prometheus-agent.config.kubernetes.integrations_filter.enabled":"false","logging.enabled":"true", "newrelic-logging.lowDataMode":"true", "newrelic-logging.fluentBit.linuxMountPath":"/var/log", "newrelic-logging.fluentBit.persistence.mode":"persistentVolume", "newrelic-logging.fluentBit.persistence.persistentVolume.storageClass":"standard-rwx","global.licenseKey":"<Your License Key"}'  > newrelic.yaml && (kubectl create namespace newrelic ; kubectl apply -f newrelic.yaml)