Monitorer les nœuds Windows

L'intégration New Relic Kubernetes prend nativement en charge le monitoring des nœuds Windows aux côtés des nœuds Linux dans le même cluster — vous n'avez pas besoin d'un graphique Helm ou d'une installation séparée.

Découvrez comment activer et configurer le monitoring des nœuds Windows. Pour plus de détails sur le modèle d'exécution privilégié vs non privilégié et les considérations de sécurité, consultez Mode privilégié vs non privilégié. Pour les limitations de métriques spécifiques à Windows, consultez Limitations et dépannage pour Windows.

Prérequis

Avant d'activer le monitoring Windows, assurez-vous que votre cluster répond aux exigences suivantes :

• Compatibilité et exigences pour les nœuds Windows
• Windows Server LTSC 2019 (build 10.0.17763) ou LTSC 2022 (build 10.0.20348).
• La version de l'image de conteneur doit correspondre exactement à la version de l'OS hôte Windows. Windows ne prend en charge que l’isolation des processus, et non l’isolation Hyper-V.
• Les nœuds Windows s'exécutant dans les clusters Red Hat OpenShift ne sont pas pris en charge.

Vérifiez votre version de nœud Windows

Si vous n'êtes pas sûr de la version Windows exécutée par vos nœuds, effectuez directement une requête sur les étiquettes des nœuds :

$
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.labels.node\.kubernetes\.io/windows-build}{"\n"}{end}'

Ceci affiche la valeur du label node.kubernetes.io/windows-build pour chaque nœud, à laquelle correspond le DaemonSet nodeSelector de l'intégration. Vous pouvez également exécuter systeminfo sur le nœud lui-même et faire correspondre le numéro de build :

Activer le monitoring de Windows

Pour activer le monitoring Windows, définissez enableWindows: true dans votre values.yaml. Lors d'un déploiement via nri-bundle, passez ceci sous la clé newrelic-infrastructure :

newrelic-infrastructure:
  enableWindows: true

Appliquez la modification avec un helm upgrade:

$
helm upgrade newrelic-bundle newrelic/nri-bundle \
>
  --namespace newrelic \
>
  --reuse-values \
>
  --set newrelic-infrastructure.enableWindows=true

Par défaut, l'activation de Windows crée des DaemonSets pour LTSC 2019 et LTSC 2022. Consultez Configurer pour des versions spécifiques de Windows pour restreindre cela.

Configurer pour des versions spécifiques de Windows

La clé windowsOsList contrôle quelles versions de Windows reçoivent les DaemonSets. Par défaut, il inclut les deux versions prises en charge. Pour restreindre le monitoring uniquement aux versions Windows réellement présentes dans votre cluster, surchargez-le dans votre values.yaml:

newrelic-infrastructure:
  enableWindows: true
  windowsOsList:
    - version: ltsc2022
      imageTagSuffix: ltsc2022
      buildNumber: 10.0.20348

Chaque entrée génère un DaemonSet séparé. Les pods sont uniquement planifiés sur les nœuds dont le label node.kubernetes.io/windows-build correspond au champ buildNumber. Cela empêche les DaemonSets vides d'apparaître dans votre cluster.

Clusters mixtes Linux et Windows

Dans la v3, les nœuds Windows et Linux sont monitorés à l’aide du même graphique newrelic-infrastructure — vous n’avez pas besoin d’une installation de graphique séparée comme vous le faisiez dans la v2. Le graphique crée automatiquement :

• Un DaemonSet Linux avec nodeSelector: kubernetes.io/os: linux
• Un DaemonSet Windows par entrée dans windowsOsList, chacun avec nodeSelector: kubernetes.io/os: windows et un sélecteur de numéro de build correspondant

Un values.yaml minimal pour un cluster hybride :

global:
  licenseKey: YOUR_NEW_RELIC_LICENSE_KEY
  cluster: YOUR_CLUSTER_NAME

newrelic-infrastructure:
  enableWindows: true
  windowsOsList:
    - version: ltsc2022
      imageTagSuffix: ltsc2022
      buildNumber: 10.0.20348

Installer ou mettre à jour avec :

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

Mode privilégié

Le monitoring Windows s’exécute par défaut en mode privilégié, qui utilise les conteneurs Windows HostProcess pour collecter des métriques complètes au niveau du nœud, y compris le processeur, la mémoire, le disque et le réseau. Ceci est requis pour recevoir les données SystemSample, StorageSample et NetworkSample des nœuds Windows.

Pour exécuter en mode non privilégié à la place :

newrelic-infrastructure:
  enableWindows: true
  windows:
    privileged: false

Le mode non privilégié désactive les métriques au niveau de l’hôte mais peut être requis par les politiques de sécurité du cluster. Pour obtenir le détail complet des données affectées, consultez Mode privilégié vs non privilégié.

Vérifier l'installation

Après l'installation ou la mise à jour, vérifiez que les DaemonSets ont été créés :

$
kubectl -n newrelic get daemonsets

Vous devriez voir un DaemonSet pour chaque version Windows que vous avez configurée aux côtés du DaemonSet Linux :

$
NAME                                                DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR
$
newrelic-bundle-nrk8s-kubelet                       2         2         2       2            2           kubernetes.io/os=linux
$
newrelic-bundle-nrk8s-kubelet-windows-ltsc2019      0         0         0       0            0           kubernetes.io/os=windows,node.kubernetes.io/windows-build=10.0.17763
$
newrelic-bundle-nrk8s-kubelet-windows-ltsc2022      1         1         1       1            1           kubernetes.io/os=windows,node.kubernetes.io/windows-build=10.0.20348

Un nombre DESIRED de 0 pour une version Windows signifie qu'aucun nœud avec ce numéro de build n'existe dans le cluster — c'est le comportement attendu, pas une erreur.

Pour confirmer que les pods Windows s'exécutent sur leurs nœuds :

$
kubectl -n newrelic get pods -o wide | grep windows

Configuration supplémentaire

Ajouter des sélecteurs de nœuds

Par défaut, les DaemonSets Windows sélectionnent les nœuds à l'aide de kubernetes.io/os: windows. Vous pouvez ajouter des sélecteurs supplémentaires pour restreindre le monitoring à un sous-ensemble spécifique de nœuds Windows :

kubelet:
  windowsNodeSelector:
    kubernetes.io/os: windows
    node.kubernetes.io/windows-build: "10.0.20348"
    newrelic.com/monitoring-allowed: "true"  # custom label you control

Utilisez un registre de conteneurs privé

Pour récupérer des images Windows depuis un registre privé au lieu de celui par défaut :

images:
  windowsIntegration:
    registry: your-registry.example.com
    pullPolicy: Always
  windowsAgent:
    registry: your-registry.example.com
    pullPolicy: Always
  pullSecrets:
    - name: registry-credentials

Définir les limites de ressources

Les conteneurs HostProcess sont en concurrence pour les ressources directement sur le nœud Windows. Le chart définit une limite de mémoire par défaut. Vous pouvez l'ajuster, ou définir une limite de CPU. Pour plus d’informations, consultez Exigences de ressources.

kubelet:
  resources:
    requests:
      cpu: 50m
      memory: 150Mi
    limits:
      memory: 300Mi

Aucune limite de CPU n'est définie par défaut — un plafond de CPU strict risque de manquer des intervalles de scrape en cas de charge du nœud. Si la politique de votre cluster en exige un, évaluez ce compromis avant de le définir.

Prochaines étapes