Modifications introduites dans la version 3 de l'intégration Kubernetes

À partir de la version 3, la fonctionnalité d'intégration New Relic Kubernetes propose une architecture qui permet de monitorer l'IA de manière plus modulaire et configurable, vous donnant plus de pouvoir pour choisir comment elle est déployée et la rendant compatible avec davantage d'environnements.

Les données rapportées par l'intégration Kubernetes version 3 n'ont pas changé depuis la version 2. Pour la version 3, nous nous sommes concentrés sur la configurabilité, la stabilité et l'expérience utilisateur. Voir les dernières notes de sortie pour l'intégration ici.

Guide de migration

Pour rendre la migration depuis des versions antérieures aussi simple que possible, nous avons développé une couche de compatibilité qui traduit la plupart des options configurables de l'ancien graphique newrelic-infrastructure vers leurs nouveaux homologues. Cette couche de compatibilité est temporaire et sera supprimée à l'avenir. Nous vous encourageons à lire attentivement ce guide et à migrer la configuration sous supervision humaine. Vous pouvez en savoir plus sur le graphique newrelic-infrastructure mis à jour ici.

Configuration de Kube State Métriques (KSM)

• disableKubeStateMetrics a été remplacé par ksm.enabled. La valeur par défaut reste la même (scraping KSM activé).
• kubeStateMetricsScheme, kubeStateMetricsPort, kubeStateMetricsUrl, kubeStateMetricsPodLabel et kubeStateMetricsNamespace ont été remplacés par le ksm.config plus complet et plus flexible.
• Notez que KSM v2+ désactive les métriques d'étiquettes par défaut. Vous pouvez activer les métriques des étiquettes cibles à monitorer en utilisant les options metric-labels-allowlist décrites ici dans votre cluster Kubernetes.

L'objet ksm.config a la structure suivante :

ksm:
  config:
    # When autodiscovering KSM, force the following scheme. By default, `http` is used.
    scheme: "http"
    # Label selector to find kube-state-metrics endpoints. Defaults to `app.kubernetes.io/name=kube-state-metrics`.
    selector: "app.kubernetes.io/name=kube-state-metrics"
    # Restrict KSM discovery to this particular namespace. Defaults to all namespaces.
    namespace: ""
    # When autodiscovering, only consider endpoints that use this port. By default, all ports from the discovered `endpoint` are probed.
    # port: 8080
    # Override autodiscovery mechanism completely and specify the KSM url directly instead
    # staticUrl: "http://test.io:8080/metrics"

Configuration du plan de contrôle

configuration du plan de contrôle a considérablement changé. Si vous avez déjà control plane monitoring activé control plane monitoring , nous vous encourageons à consulter notre documentation Configurer .

Les options suivantes ont été remplacées par une configuration plus complète, abordée dans la section liée ci-dessus :

• apiServerSecurePort
• etcdTlsSecretName
• etcdTlsSecretNamespace
• controllerManagerEndpointUrl, etcdEndpointUrl, apiServerEndpointUrl, et schedulerEndpointUrl

Configuration de l'agent

Le fichier de configuration de l'agent, précédemment spécifié dans config, a été déplacé vers common.agentConfig. Le format du fichier n'a pas changé et la gamme complète des options configurables peut être trouvée ici.

Les options d'agent suivantes étaient auparavant « aliasées » à la racine du fichier values.yml et sont no longer available:

• logFile a été remplacé par common.agentConfig.log_file.
• eventQueueDepth a été remplacé par common.agentConfig.event_queue_depth.
• customAttributes a changé de format en un objet yaml. Le format précédent, une chaîne codée manuellement en JSON, par exemple {"team": "devops"}, est obsolète.
• Auparavant, customAttributes avait une entrée clusterName par défaut qui pouvait avoir des conséquences indésirables si elle était supprimée. Ce n'est plus le cas ; l'utilisateur peut désormais remplacer customAttributes dans son intégralité en toute sécurité.
• discoveryCacheTTL a été complètement supprimé, car la découverte est désormais effectuée à l'aide d'informateurs Kubernetes, qui disposent d'un cache intégré.

Configuration d'intégration

l'intégration a été précédemment configurée sous integrations_config, en utilisant un format éventail :

integrations_config:
  - name: nri-redis.yaml
    data:
      discovery:  # ...
      integrations:  # ...

Le mécanisme reste le même, mais nous avons modifié le format pour le rendre plus convivial :

integrations:
  nri-redis-sampleapp:
    discovery:  # ...
    integrations:  # ...

De plus, les indicateurs --port et --tls sont désormais obligatoires dans la commande de découverte. Dans le passé, les solutions suivantes fonctionnaient :

integrations:
  nri-redis-sampleapp:
    discovery:
      command:
        exec: /var/db/newrelic-infra/nri-discovery-kubernetes

A partir de la v3, vous devez spécifier --port et --tls:

integrations:
  nri-redis-sampleapp:
    discovery:
      command:
        exec: /var/db/newrelic-infra/nri-discovery-kubernetes --tls --port 10250

Ce changement est nécessaire car dans les versions 2 et antérieures, le composant nrk8s-kubelet (ou son équivalent) fonctionnait avec hostNetwork: true, donc nri-discovery-kubernetes pouvait se connecter au kubelet en utilisant localhost et http simple. Pour des raisons de sécurité, ce n'est plus le cas ; d'où la nécessité de spécifier désormais les deux flags.

Pour plus de détails sur la façon de configurer l'intégration sur hôte dans Kubernetes, veuillez consulter notre documentation sur les services de monitoring dans Kubernetes .

Valeurs diverses du graphique

Bien que cela ne soit pas lié à la configuration de l'intégration, les diverses options suivantes pour le graphique Helm ont également changé :

• runAsUser a été remplacé par securityContext, qui est directement modélisé dans le pod et plus configurable.

• resources a été supprimé, car nous avons maintenant trois charges de travail différentes. Les ressources pour chacun peuvent être configurées individuellement sous :

  • ksm.resources
  • kubelet.resources
  • controlPlane.resources

• tolerations a été divisé en trois et le précédent n'est plus valable. Tous les trois tolèrent par défaut n’importe quelle valeur pour NoSchedule et NoExecute:

  • ksm.tolerations
  • kubelet.tolerations
  • controlPlane.tolerations

• image et toutes ses sous-clés ont été remplacées par des sections individuelles pour chacune des trois images qui sont maintenant déployées :

  • images.forwarder.* pour configurer le transitaire de l'agent d'infrastructure.
  • images.agent.* pour configurer l'image regroupant l' infrastructure-agent et l'intégration sur hôte.
  • images.integration.* pour configurer l'image en charge du scraping des données k8s.