Composants d'intégration de Kubernetes

L'intégration New Relic Kubernetes vous offre une visibilité complète sur la santé et les performances de votre cluster, que vous exécutiez Kubernetes sur site ou dans le cloud. Il vous donne une visibilité sur l'espace de nommage, le déploiement, les réplicasets, les nœuds, le pod et le conteneur Kubernetes .

Le graphiquenewrelic-infrastructure est le composant principal de l'intégration. Apprenez-en plus sur son architecture ici.

Le graphiquenri-bundle regroupe les graphiques individuels de l'intégration, y compris newrelic-infrastructure, ce qui vous permet d'installer et de mettre à niveau facilement l'intégration à l'aide d'un seul graphique. Découvrez les composants par défaut et facultatifs que vous pouvez installer avec ce tableau ici.

Architecture

Il y a 3 composants dans le graphique newrelic-infrastructure : nrk8s-ksm, nrk8s-kubelet et nrk8s-controlplane. Le premier est un déploiement et les deux suivants sont des DaemonSets.

Chacun des composants possède 2 conteneurs :

1. Un conteneur pour l'intégration, chargé de collecter les métriques.
2. Un conteneur avec l'agent New Relic Infrastructure, qui est utilisé pour envoyer les métriques à New Relic.

Composant Kube-state-métriques

Nous construisons nos métriques d’état de cluster sur la base du projet OSSkube-state-metrics, qui est hébergé sous l’organisation Kubernetes elle-même.

Un déploiement spécifique nrk8s-ksm se charge de trouver KSM et de le récupérer. Ce pod étant unique et de longue durée de vie, il peut utiliser en toute sécurité un informateur de point de terminaison pour localiser l'IP du pod KSM et le récupérer. L'informateur met automatiquement en cache la liste des informateurs du cluster localement et monitore les nouveaux, évitant ainsi de submerger le serveur API avec requests pour déterminer où se trouvait le pod .

les clients doivent permettre à toutes les métriques cibles d'être monitorées sur KSM si ces métriques ne sont pas activées par défaut. Par exemple, KSM v2+ désactive les métriques d’étiquettes et d’annotations par défaut. les clients peuvent activer les métriques des étiquettes et des annotations cibles à monitorer en utilisant les options metric-labels-allowlist ou metric-annotations-allowlist décrites ici dans votre cluster Kubernetes.

Consultez Apportez votre propre KSM pour plus d'informations sur les versions prises en charge par KSM.

Composant Kubelet

Le Kubelet est l'« agent Kubernetes », un service qui s'exécute sur chaque nœud Kubernetes et est responsable de la création du conteneur selon les instructions du control plane. Étant donné que c'est le Kubelet qui travaille en étroite collaboration avec le conteneur Runtime, il constitue la principale source de métriques infrastructure pour notre intégration, telles que l'utilisation du CPU, de la mémoire, du disque, du réseau, etc. Bien que non entièrement documentée, l'API Kubelet est la source de facto de la plupart des métriques Kubernetes.

Le scraping du Kubelet est généralement une opération nécessitant peu de ressources. Compte tenu de cela et de notre intention de minimiser le trafic entre les nœuds autant que possible, nrk8s-kubelet est exécuté en tant que DaemonSet où chaque instance collecte les métriques du Kubelet exécuté dans le même nœud qu'elle.

nrk8s-kubelet se connecte au Kubelet en utilisant l'IP du nœud. Si ce processus échoue, nrk8s-kubelet reviendra pour atteindre le nœud via le proxy du serveur API. Ce mécanisme de secours vous aide avec les clusters très volumineux, car le proxy de nombreux kubelets peut augmenter la charge sur le serveur API. Vous pouvez vérifier si le serveur API est utilisé comme proxy en recherchant un message comme celui-ci dans le log :

Trying to connect to kubelet through API proxy

composant du plan de contrôle

En tant que distributions Kubernetes majeures, nous avons déployé nrk8s-controlplane comme DaemonSet avec hostNetwork: true. La configuration est structurée pour prendre en charge la découverte automatique et le point de terminaison statique. Pour être compatible avec une large gamme de distributions prêtes à l'emploi, nous fournissons une large gamme de valeurs par défaut connues comme entrées de configuration. Faire cela dans la configuration au lieu du code vous permet d'ajuster la découverte automatique à vos besoins.

Il existe la possibilité d'avoir plusieurs points de terminaison par sélecteur et d'ajouter un mécanisme de sonde qui détecte automatiquement le bon. Cela vous permet d'essayer différentes configurations telles que des ports ou des protocoles en utilisant le même sélecteur.

configuration de scraping pour le composant CP etcd ressemble à ce qui suit, où la même structure et les mêmes fonctionnalités s'appliquent à tous les composants :

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 staticEndpoint est défini, le composant essaie de le récupérer. Si le point de terminaison n'est pas atteint, l'intégration échoue, il n'y a donc pas d'erreurs silencieuses lorsque les points de terminaison manuels sont configurés.

Si staticEndpoint n'est pas défini, le composant parcourra les entrées de découverte automatique à la recherche du premier pod correspondant à selector dans le namespace spécifié et s'exécutant éventuellement dans le même nœud du DaemonSet (si matchNode est défini sur true). Une fois qu'un pod est découvert, le composant sonde, en émettant une requête http HEAD, le point de terminaison répertorié dans l'ordre et récupère le premier point sondé avec succès en utilisant le type d'autorisation sélectionné.

Bien que nous montrions ci-dessus un extrait de configuration pour le composant etcd , la logique de scraping est la même pour les autres composants.

Pour des instructions plus détaillées sur la façon de configurer control plane monitoring, veuillez consulter la page control plane monitoring .

Cartes de Helm

Helm est le principal moyen que nous proposons pour déployer notre solution dans votre cluster. Le graphique Helm gère un déploiement et deux DaemonSets où chacun a une configuration légèrement différente. Cela vous donne plus de flexibilité pour adapter la solution à vos besoins, sans avoir besoin d'appliquer des correctifs manuels sur le graphique et les manifestes générés.

Certaines des nouvelles fonctionnalités de notre nouvel exposant de cartes Helm sont les suivantes :

• Contrôle total du securityContext pour tous les pods
• Contrôle total des pod labels et annotations pour tous les pods
• Possibilité d'ajouter des variables d'environnement supplémentaires, volumes et volumeMounts
• Contrôle total sur la configuration de l'intégration, y compris les points de terminaison atteints, le comportement de découverte automatique et les intervalles de scraping
• Meilleur alignement avec les idiomes et les normes Helm

Vous pouvez voir les détails complets de tous les commutateurs que vous pouvez basculer dans le graphiqueREADME.md .

Composants

Lorsque vous installez l’intégration Kubernetes à l’aide de nri-bundle, ces 2 composants sont installés par défaut :

Il s'agit de composants facultatifs que vous pouvez installer à l'aide de nri-bundle ou séparément :