Intégration Kubernetes : compatibilité et exigences

L'intégration Kubernetes est compatible avec de nombreuses plateformes différentes, notamment GKE, EKS, AKS, OpenShift, etc. Chacun a une compatibilité différente avec notre intégration. Vous trouverez plus d'informations sur cette page.

Exigences

L'intégration New Relic Kubernetes nécessite un compte New Relic. Si vous ne l'avez pas déjà fait, créez votre compte New Relic gratuit ci-dessous pour commencer monitoring vos données dès aujourd'hui.

Vous aurez également besoin d'une distribution Linux compatible avec l'agent New Relic Infrastructure.

Compatibilité et exigences pour Helm

• Assurez-vous que Helm est installé et que la version minimale prise en charge est la v3. La version 3 de l'intégration Kubernetes nécessite Helm version 3.

• Choisissez un nom d’affichage pour votre cluster. Par exemple, vous pouvez utiliser cette sortie :

  bash

  Copier

  $
  kubectl config current-context

Compatibilité et exigences pour Manifest

Si des manifestes personnalisés ont été utilisés à la place de Helm, vous devrez d'abord supprimer l'ancienne installation à l'aide de kubectl delete -f previous-manifest-file.yml, puis suivre à nouveau le programme d'installation guidé. Cela générera un ensemble mis à jour de manifestes qui peuvent être déployés à l'aide de kubectl apply -f manifest-file.yml.

Exécution du conteneur

Notre intégration Kubernetes est indépendante du CRI . Il a été spécifiquement testé pour être compatible avec Containerd. Notez que Dockershim a été supprimé du projet Kubernetes à partir de la sortie 1.24. Lisez la FAQ sur la suppression de Dockershim pour plus de détails.

Compatibilité

Notre intégration est compatible et testée en continu sur les versions de Kubernetes suivantes :

Saveurs de Kubernetes

L'intégration de Kubernetes est compatible avec différentes versions. Nous avons testé l'intégration avec les éléments suivants :

Selon la méthode d'installation, la n'est pas disponible ou peut control plane monitoring nécessiter configuration supplémentaire.

Par exemple:

• Seules les métriques du serveur API sont récupérables et disponibles pour intrumenter du cluster géré par (GKE, EKS, AKS), control plane car aucun point de terminaison n'expose les métriques nécessaires pour etcd, le planificateur et le gestionnaire de contrôleur.
• Pour intrumenter control plane Rancher, étant donné que les composants /metrics ne sont pas toujours accessibles par défaut et ne peuvent pas être détectés automatiquement, une configuration supplémentaire est nécessaire.

Besoins en ressources

Lors du déploiement de l'intégration de New Relic Kubernetes , il est important d'allouer des ressources appropriées pour garantir que les composants monitoring fonctionnent efficacement.

Voici les requests et limites de ressources minimales recommandées pour chacun des composants déployés par le graphique d'infrastructure .

Composant Kubelet

Les conteneurs suivants sont inclus dans le pod du composant Kubelet déployé dans chaque nœud.

Conteneur Kubelet

• Processeur:

  • Demande: 100m

• Mémoire:

  • Demande: 150M
  • Limite: 300M

Agent conteneur

• Processeur:

  • Demande: 100m

• Mémoire:

  • Demande: 150M
  • Limite: 300M

Composant métrique de l'état de Kube

Conteneur KSM

• Processeur:

  • Demande: 100m

• Mémoire:

  • Demande: 150M
  • Limite: 850M

Conteneur transitaire

• Processeur:

  • Demande: 100m

• Mémoire:

  • Demande: 150M
  • Limite: 850M

composant du plan de contrôle

• Processeur:

  • Demande: 100m

• Mémoire:

  • Demande: 150M
  • Limite: 300M

Agent conteneur

• Processeur:

  • Demande: 100m

• Mémoire:

  • Demande: 150M
  • Limite: 300M

Voici les requests de ressources recommandées et les limites requises par d'autres composants déployés dans le cadre du nri-bundle

injectionméta

• Processeur:

  • Demande: 100m

• Mémoire:

  • Demande: 30M
  • Limite: 80M

Enregistrement

Les conteneurs suivants sont inclus dans le pod de logging New Relic déployé dans chaque nœud.

• Processeur:

  • Demande: 250m
  • Limite: 500m

• Mémoire:

  • Demande: 64M
  • Limite: 128M

Considérations

• Taille de Cluster : ces recommandations de ressources concernent les tailles cluster typiques. Un cluster plus grand avec plus de nœuds et de pods peut nécessiter des allocations de ressources accrues pour gérer le volume de données supplémentaire.

• Configuration personnalisée: si vous activez une fonctionnalité supplémentaire ou une configuration personnalisée, pensez à ajuster les ressources en conséquence.

• Monitoring et ajustement: Après le déploiement, monitorez l'utilisation des ressources de ces pods et ajustez les requests et les limites en fonction de l'utilisation réelle pour optimiser les performances et les coûts.

Ces spécifications de ressources peuvent être ajustées dans le fichier values.yaml du graphique Helm utilisé pour déployer l'intégration New Relic Kubernetes. En garantissant que ces exigences en matière de ressources sont satisfaites, vous pouvez maintenir monitoring efficace et efficiente de votre cluster Kubernetes avec New Relic.