Configurer control plane monitoring

New Relic fournit une prise en charge pour control plane votre Kubernetes intégration , vous permettant de monitorer et de collecter des métriques à partir cluster des control plane composants de votre . Ces données peuvent ensuite être trouvées dans New Relic et utilisées pour créer des requêtes et des graphiques.

Caractéristiques

Nous monitorons et collectons les métriques des composants control plane suivants :

• etcd: informations sur le leader, taille de la mémoire résidente, nombre de threads du système d'exploitation, données sur les propositions de consensus, etc. Pour une liste des métriques prises en charge, voir etcd data.
• API server: taux de apiserver requests, répartition de apiserver requests par méthode HTTP et code de réponse, etc. Pour la liste complète des métriques prises en charge, consultez Données du serveur API.
• Scheduler: CPU/mémoire demandés par rapport à la mémoire disponible sur le nœud, tolérances aux souillures, toute affinité ou anti-affinité définie, etc. Pour la liste complète des métriques prises en charge, voir Données du planificateur.
• Controller manager: taille de la mémoire résidente, nombre de threads du système d'exploitation créés, goroutines actuellement existantes, etc. Pour la liste complète des métriques prises en charge, voir Données du gestionnaire de contrôleur.

Compatibilité et exigences

• La plupart des clusters gérés, y compris AKS, EKS et GKE, n'autorisent pas l'accès extérieur à leurs composants control plane . C'est pourquoi sur un cluster géré, New Relic ne peut obtenir que les métriques control plane pour le serveur API, et non pour etcd, le planificateur ou le gestionnaire de contrôleur.
• Lorsque vous utilisez la solution en mode non privilégié, la configuration control plane nécessitera des étapes supplémentaires et certaines mises en garde peuvent s'appliquer.
• OpenShift 4.x utilise des points de terminaison métriques de composant control plane qui sont différents de ceux par défaut.

composant du plan de contrôle

La tâche de monitoring du Kubernetes control plane est une responsabilité du nrk8s-controlplane composant, qui par défaut est déployé en tant que DaemonSet. Ce composant est automatiquement déployé sur les nœuds control plane , grâce à l'utilisation d'une liste par défaut de nodeSelectorTerms qui inclut des étiquettes couramment utilisées pour identifier les nœuds control plane , tels que node-role.kubernetes.io/control-plane. Quoi qu'il en soit, ce sélecteur est exposé dans le fichier values.yml et peut donc être reconfiguré pour s'adapter à d'autres environnements.

les clusters qui n'ont aucun nœud correspondant à ces sélecteurs pod n'obtiendront aucun planifié, ne gaspillant ainsi aucune ressource et étant fonctionnellement équivalent à la désactivation totale control plane monitoring en définissant controlPlane.enabled sur false dans le Helm graphique .

Chaque composant du control plane dispose d'une section dédiée, qui permet individuellement de :

• Activer ou désactiver monitoring de ce composant
• Définir des sélecteurs spécifiques et un espace de nommage pour découvrir ce composant
• Définir le point de terminaison et les chemins qui seront utilisés pour récupérer les métriques de ce composant
• Définir les mécanismes d'authentification qui doivent être utilisés pour obtenir des métriques pour ce composant
• Spécifiez manuellement le point de terminaison qui ignore complètement la découverte automatique

Vous pouvez vérifier toutes les options configuration disponibles dans le fichier values.yaml du graphique nri-Kubernetes sous la clé controlPlane.

Si vous installez l'intégration via le graphique nri-bundle , vous devez transmettre les valeurs au sous-graphique correspondant. Par exemple, pour désactiver la monitoring etcd dans le composant controlPlane, vous pouvez procéder comme suit :

newrelic-infrastructure:
  controlPlane:
    config:
      etcd:
        enabled: false

Découverte automatique et configuration par défaut

Par défaut, notre graphiqueHelm fournit une configuration qui devrait fonctionner immédiatement pour certains composants control plane pour les distributions sur site qui exécutent le control plane à l'intérieur du cluster, tels que Kubeadm ou minikube.

Notez que, comme la découverte automatique repose sur les étiquettes pod comme mécanisme de découverte, elle ne fonctionne pas dans les environnements cloud ou lorsque les composants control plane ne s'exécutent pas à l'intérieur du cluster. Cependant, le point de terminaison statique peut être exploité dans ces scénarios si les composants control plane sont accessibles.

hostNetwork et privileged

Dans les versions supérieures à 3, l'indicateur privileged affecte uniquement les objets securityContext , c'est-à-dire si le conteneur est exécuté en tant que root avec accès aux métriques de l'hôte ou non. Tous les composants d'intégration sont désormais par défaut sur hostNetwork: false, à l'exception du pod qui obtient les métriques du control plane qui ont hostNetwork: true car il est nécessaire pour atteindre le point de terminaison control plane dans la plupart des distributions. La valeur hostNetwork de tous les composants peut être modifiée, individuellement ou globalement, à l'aide de la bascule hostNetwork dans votre values.yaml.

Si l'exécution du pod avec n'est pas acceptable, en raison du hostNetwork cluster ou d'autres politiques, control plane monitoring n'est pas possible et doit être désactivée en controlPlane.enabled définissant false sur.

Si vous disposez d'une configuration avancée qui inclut la découverte automatique personnalisée ou un point de terminaison statique qui peut être utilisé pour monitorer le control plane sans hostNetwork, consultez READMEdu projet et recherchez controlPlane.hostNetwork dans le fichiervalues.yaml.

Découverte automatique personnalisée

Les sélecteurs utilisés pour la découverte automatique sont entièrement exposés en tant qu'entrées configuration dans le fichier values.yaml, ce qui signifie qu'ils peuvent être modifiés ou remplacés pour s'adapter à presque tous les environnements où le control plane est exécuté dans le cadre du cluster.

Une section de découverte automatique ressemble à ce qui suit :

autodiscover:
  - selector: "tier=control-plane,component=etcd"
    namespace: kube-system
    # Set to true to consider only pods sharing the node with the scraper pod.
    # This should be set to `true` if Kind is Daemonset, `false` otherwise.
    matchNode: true
    # Try to reach etcd using the following endpoints.
    endpoints:
      - url: https://localhost:4001
        insecureSkipVerify: true
        auth:
          type: bearer
      - url: http://localhost:2381
  - selector: "k8s-app=etcd-manager-main"
    namespace: kube-system
    matchNode: true
    endpoints:
      - url: https://localhost:4001
        insecureSkipVerify: true
        auth:
          type: bearer

La section autodiscover contient une liste d’entrées de découverte automatique. Chaque entrée contient :

• selector:Un sélecteur d'étiquette codé en chaîne qui sera utilisé pour rechercher un pod.
• matchNode: Si défini sur true, il limitera en outre la découverte au pod exécuté sur le même nœud que l' instance particulière du DaemonSet effectuant la découverte.
• endpoints:Une liste de points de terminaison à essayer si un pod est trouvé pour le sélecteur spécifié.

De plus, chaque endpoint possède :

• url: URL vers la cible, y compris le schéma. Peut être http ou https.
• insecureSkipVerify: Si défini sur vrai, le certificat ne sera pas vérifié pour https URL.
• auth.type:Quel mécanisme utiliser pour authentifier la demande. Actuellement, les méthodes suivantes sont prises en charge :
• Aucun : si auth n’est pas spécifié, la demande ne contiendra aucune authentification.
• bearer:Le même jeton porteur utilisé pour s'authentifier auprès de l'API Kubernetes sera envoyé à cette demande.
• mtls: mTLS sera utilisé pour exécuter la requête.

mTLS

Pour le type mtls , les éléments suivants doivent être spécifiés :

endpoints:
  - url: https://localhost:4001
    auth:
      type: mtls
      mtls:
        secretName: secret-name
        secretNamespace: secret-namespace

Où secret-name est le nom d'un secret TLS Kubernetes, qui se trouve dans secret-namespace et contient le certificat, la clé et l'autorité de certification requis pour se connecter à ce point de terminaison particulier.

L'intégration récupère ce secret lors de l'exécution plutôt que de le monter, ce qui signifie qu'elle nécessite un rôle RBAC lui accordant l'accès. Notre graphique Helm détecte automatiquement les entrées auth.mtls au moment du rendu et créera automatiquement des entrées pour ces secrets particuliers et cet espace de nommage pour vous, sauf si rbac.create est défini sur faux.

Notre intégration accepte un secret avec les clés suivantes :

• cacert:Le certificat CA codé en PEM utilisé pour signer le cert
• cert:Le certificat codé en PEM qui sera présenté à etcd
• key:La clé privée codée en PEM correspondant au certificat ci-dessus

Ces certificats doivent être signés par la même autorité de certification qu'etcd utilise pour fonctionner.

La manière de générer ces certificats n'entre pas dans le cadre de cette documentation, car elle varie considérablement selon les différentes distributions Kubernetes. Veuillez vous référer à la documentation de votre distribution pour voir comment récupérer les certificats homologues etcd requis. Dans Kubeadm, par exemple, ils peuvent être trouvés dans /etc/kubernetes/pki/etcd/peer.{crt,key} dans le nœud control plane .

Une fois que vous avez localisé ou généré les certificats homologues etcd, vous devez renommer les fichiers pour qu'ils correspondent aux clés que nous nous attendons à voir présentes dans le secret et créer le secret dans le cluster.

$
mv peer.crt cert
$
mv peer.key key
$
mv ca.crt cacert
$

$
kubectl -n newrelic create secret tls newrelic-etcd-tls-secret --cert=./cert --key=./key --certificate-authority=./cacert

Enfin, vous pouvez saisir le nom secret (newrelic-etcd-tls-secret) et l'espace de nommage (newrelic) dans le snippet de configuration affiché au début de cette section. N'oubliez pas que le graphique Helm analysera automatiquement cette configuration et créera un rôle RBAC pour accorder l'accès à ce secret spécifique et à cet espace de nommage pour le composant nrk8s-controlplane, aucune action manuelle n'est donc nécessaire à cet égard.

Point de terminaison statique

Bien que la découverte automatique doive couvrir les cas où le control plane réside à l'intérieur du cluster Kubernetes, certaines distributions ou environnements Kubernetes sophistiqués exécutent le control plane ailleurs, pour diverses raisons, notamment la disponibilité ou l'isolement des ressources.

Dans ces cas, l'intégration peut être configurée pour récupérer une URL fixe arbitraire, indépendamment du fait qu'un pod avec une étiquette control plane soit trouvé dans le nœud. Cela se fait en spécifiant une entrée staticEndpoint . Par exemple, une instance etcd externe ressemblerait à ceci :

controlPlane:
  etcd:
    staticEndpoint:
      url: https://url:port
      insecureSkipVerify: true
      auth: {}

staticEndpoint est le même type d'entrée que endpoints dans l'entrée autodiscover , dont les champs sont décrits ci-dessus. Les mécanismes et schémas d’authentification sont pris en charge ici.

Veuillez garder à l’esprit que si staticEndpoint est défini, la section autodiscover sera ignorée dans son intégralité.

Limites

Lors de l'utilisation staticEndpoint, tous les pods nrk8s-controlplane tenteront d'atteindre et de gratter ledit point de terminaison. Cela signifie que, si nrk8s-controlplane est un DaemonSet (la valeur par défaut), toutes les instances du DaemonSet gratteront ce point de terminaison. Bien que cela soit acceptable si vous les pointez vers localhost, si le point de terminaison n'est pas local sur le nœud, vous pourriez potentiellement produire des métriques en double et augmenter l'utilisation facturable. Si vous utilisez staticEndpoint et le pointez vers une URL non locale, assurez-vous de remplacer controlPlane.kind par déploiement.

Pour la même raison ci-dessus, il n'est actuellement pas possible d'utiliser la découverte automatique pour certains composants control plane et un point de terminaison statique pour d'autres. Il s’agit d’une limitation connue que nous travaillons à résoudre dans les futures versions de l’intégration.

Enfin, staticEndpoint permet uniquement de définir un seul point de terminaison par composant. Cela signifie que si vous avez plusieurs fragments control plane dans différents hôtes, il n'est actuellement pas possible de pointer vers eux séparément. Il s’agit également d’une limitation connue sur laquelle nous travaillons pour remédier dans les versions futures. Pour le moment, une solution de contournement pourrait être d'utiliser une métrique agrégée pour différents fragments ailleurs et de pointer l'URL staticEndpoint vers la sortie agrégée.

monitoring du plan de contrôle pour les environnements gérés et cloud

Certains environnements cloud, comme EKS ou GKE, permettent de récupérer des métriques à partir du serveur API Kubernetes. Cela peut être facilement configuré comme un point de terminaison statique :

controlPlane:
  affinity: false  # https://github.com/helm/helm/issues/9136
  kind: Deployment
  # `hostNetwork` is not required for monitoring API Server on AKS, EKS
  hostNetwork: false
  config:
    etcd:
      enabled: false
    scheduler:
      enabled: false
    controllerManager:
      enabled: false
    apiServer:
     staticEndpoint:
       url: "https://kubernetes.default:443"
       insecureSkipVerify: true
       auth:
         type: bearer

Veuillez noter que cela s'applique uniquement au serveur API et qu'etcd, le planificateur et le gestionnaire de contrôleur restent inaccessibles dans les environnements cloud.

De plus, sachez que, selon l’environnement géré ou cloud spécifique, le service Kubernetes peut équilibrer la charge du trafic entre différentes instances du serveur API. Dans ce cas, les métriques qui dépendent de l’instance spécifique sélectionnée par l’équilibreur de charge ne sont pas fiables.

monitoring du plan de contrôle pour Rancher RKE1

Le cluster déployé en utilisant Rancher Kubernetes Engine (RKE1) exécute les composants control plane en tant que conteneur Docker , et non en tant que pod géré par Kubelet. C'est pourquoi l'intégration ne peut pas détecter automatiquement ces conteneurs, et chaque point de terminaison doit être spécifié manuellement dans la section staticEndpoint de la configuration de l'intégration.

L'intégration doit pouvoir atteindre les différents points de terminaison soit en se connectant directement, avec les méthodes d'authentification disponibles (jeton de compte de service, certificats mTLS personnalisés ou aucun), soit via un proxy.

Par exemple, pour rendre les métriques du planificateur et du gestionnaire de contrôleur accessibles, vous devrez peut-être ajouter l' indicateur --authorization-always-allow-paths , permettant /metrics ou --authentication-kubeconfig et --authorization-kubeconfig d'activer l'authentification jeton.

En supposant que chaque composant soit accessible sur le port spécifié, la configuration suivante monitorera le serveur API, le planificateur et le gestionnaire de contrôleur :

controlPlane:
  kind: DaemonSet
  config:
    scheduler:
      enabled: true
      staticEndpoint:
        url: https://localhost:10259
        insecureSkipVerify: true
        auth:
          type: bearer
    controllerManager:
      enabled: true
      staticEndpoint:
        url: https://localhost:10257
        insecureSkipVerify: true
        auth:
          type: bearer
    apiServer:
      enabled: true
      staticEndpoint:
        url: https://localhost:6443
        insecureSkipVerify: true
        auth:
          type: bearer

Dans cet exemple, l'intégration doit s'exécuter sur le même nœud de chaque composant control plane dont l'option hostNetwork est définie sur true, car elle se connecte localement à chaque staticEndpoint. Par conséquent, controlPlane.kind doit être conservé comme DaemonSet. De plus, le DaemonSet a besoin de règles d'affinité, de nodeSelector et de tolérances configurées afin que toutes les instances s'exécutent sur tous les nœuds control plane que vous souhaitez monitorer.

Vous pouvez reconnaître les nœuds control plane en vérifiant l’étiquette node-role.kubernetes.io/controlplane. Ce label est déjà pris en compte par les règles d'affinité par défaut de l'intégration.

Si vous utilisez la version 2 de l'intégration, consultez Monitoring control plane avec la version 2 de l'intégration.

Configuration d'OpenShift

La version 3 de l'intégration Kubernetes inclut des paramètres par défaut qui détecteront automatiquement les composants control plane dans le cluster OpenShift. Elle devrait donc fonctionner immédiatement pour tous les composants, à l'exception d'etcd.

Etcd n’est pas pris en charge par défaut, car le point de terminaison des métriques est configuré pour exiger l’authentification mTLS dans les environnements OpenShift. Notre intégration prend en charge l’authentification mTLS pour récupérer les métriques etcd dans cette configuration, cependant vous devrez créer manuellement le certificat mTLS requis. Cela est nécessaire pour éviter d’accorder de larges autorisations à notre intégration sans l’approbation explicite de l’utilisateur.

Pour créer un secret mTLS, veuillez suivre les étapes de cette section ci-dessous, puis configurez l'intégration pour utiliser le secret nouvellement créé comme décrit dans la section mtls.

Si vous utilisez la version 2 de l'intégration, configuration OpenShift sur la version 2 de l'intégration.

Configurer mTLS pour etcd dans OpenShift

Suivez ces instructions pour configurer l’authentification TLS mutuelle pour etcd dans OpenShift 4.x :

1. Exportez les certificats clients etcd du cluster vers un secret opaque. Dans un cluster OpenShift géré par défaut, le secret est nommé kube-etcd-client-certs et il est stocké dans l'espace de nommage openshift-monitoring.

   bash

   Copier

   $
   kubectl get secret etcd-client -n openshift-etcd -o yaml > etcd-secret.yaml

   Le contenu du fichier etcd-secret.yaml ressemblerait à ce qui suit.

   apiVersion: v1
    data:
      tls.crt: <CERT VALUE>
      tls.key: <KEY VALUE>
    kind: Secret
    metadata:
      creationTimestamp: "2023-03-23T23:19:17Z"
      name: etcd-client
      namespace: openshift-etcd
      resourceVersion: 
      uid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
    type: kubernetes.io/tls

   Copier

2. Vous pouvez éventuellement modifier le nom secret et l'espace de nommage par quelque chose de significatif. Les étapes suivantes supposent que le nom secret et l'espace de nommage sont respectivement modifiés en mysecret et newrelic .

3. Supprimez ces clés inutiles dans la section métadonnées :

   • creationTimestamp
   • resourceVersion
   • uid

4. Installer le manifeste avec son nouveau nom et espace de nommage :

   bash

   Copier

   $
   kubectl apply -n newrelic -f etcd-secret.yaml

5. Configurez l'intégration pour utiliser le secret nouvellement créé comme décrit dans la section mtls. Cela peut être fait en ajoutant la configuration suivante dans le values.yaml si vous installez l'intégration via le graphique nri-bundle .

   newrelic-infrastructure:
    controlPlane:
      enabled: true
      config:
        etcd:
          enabled: true
          autodiscover:
            - selector: "app=etcd,etcd=true,k8s-app=etcd"
              namespace: openshift-etcd
              matchNode: true
              endpoints:
                - url: https://<ETCD_ENDPOINT>:<PORT>
                  insecureSkipVerify: true
                  auth:
                    type: mTLS
                    mtls:
                      secretName: mysecret
                      secretNamespace: newrelic

   Copier

Consultez vos données

Si l'intégration est correctement configurée, vous verrez une vue avec tous les composants control plane et leurs statuts dans une section dédiée, comme indiqué ci-dessous.

Vous pouvez également vérifier les données control plane avec cette requête NRQL :

SELECT latest(timestamp) 
FROM K8sApiServerSample, K8sEtcdSample, K8sSchedulerSample, K8sControllerManagerSample FACET entityName 
WHERE clusterName = '_MY_CLUSTER_NAME_'