Kubernetes API
Vue d'ensemble​
Kubernetes est un système d'orchestration de conteneurs open source pour l'automatisation de déploiement, la mise à l'échelle et la gestion d'applications.
Ce Pack vise Ă superviser Ă la fois la couche d'infrastructure (noeuds) et les services du cluster (deployments, daemonsets, etc).
Contenu du Pack​
Le Pack Kubernetes API offre plusieurs choix concernant la façon dont vous pouvez organiser la supervision du cluster.
Il existe principalement trois façons :
- Rassemblez toutes les métriques sur un seul hôte Centreon avec un service par unité Kubernetes (i.e. deployments, daemonsets, etc) - appliquer la procédure création manuelle,
- Rassemblez toutes les métriques sur un seul hôte Centreon avec un service pour chaque instances de chaque unité Kubernetes - appliquer les procédures création manuelle et découverte de service,
- Collectez les métriques d'infrastructure (noeuds maître et noeuds de travail) avec un hôte Centreon par noeud Kubernetes et conserver les métriques d'orchestration / d'application sur un hôte unique (en utilisant l'un des 2 scénarii précédents) - appliquer la procédure découverte d'hôte.
Pour tous ces scénarii, la découverte et les modèles classiques seront utilisées.
Il vous suffit de choisir la méthode qui vous plaît le plus : communiquer avec
l'API Rest exposée par le cluster Kubernetes, ou à l'aide de l'outil CLI
kubectl
pour communiquer avec le noeud ayant le rĂ´le control plane.
Découverte​
Le Pack Kubernetes API est fourni avec plusieurs règles de découverte.
Voici la liste des providers Host Discovery :
Provider | Description |
---|---|
Kubernetes Nodes (RestAPI) | Découvrez les noeuds Kubernetes en interrogeant l'API Rest Kubernetes |
Kubernetes Nodes (Kubectl) | Découvrez les noeuds Kubernetes en interrogeant le cluster Kubernetes avec kubectl |
Les deux providers rechercheront les noeuds Kubernetes et les lieront à un modèle d'hôte minimaliste pour superviser l'utilisation des noeuds en termes d'allocation de pods, de processeur et de demandes / limites de mémoire.
Parallèlement à cette découverte, des services unitaires peuvent être créés grâce aux règles de Service Discovery :
Règle | Description |
---|---|
Cloud-Kubernetes-Api-CronJobs-Status | Découvrez les CronJobs Kubernetes pour superviser leur statut |
Cloud-Kubernetes-Api-Daemonsets-Status | Découvrez les DaemonSets Kubernetes pour superviser leur statut |
Cloud-Kubernetes-Api-Deployments-Status | Découvrez les Deployments Kubernetes pour superviser leur statut |
Cloud-Kubernetes-Api-Nodes-Status | Découvrez les Nodes Kubernetes pour superviser leur statut |
Cloud-Kubernetes-Api-Nodes-Usage | Découvrez les Nodes Kubernetes pour superviser leur utilisation |
Cloud-Kubernetes-Api-PersistentVolumes-Status | Découvrez les PersistentVolumes Kubernetes pour superviser leur statut |
Cloud-Kubernetes-Api-Pods-Status | Découvrez les Pods Kubernetes pour superviser leur statut |
Cloud-Kubernetes-Api-ReplicaSets-Status | Découvrez les ReplicaSets Kubernetes pour superviser leur statut |
Cloud-Kubernetes-Api-ReplicationControllers-Status | Découvrez les ReplicationControllers Kubernetes pour superviser leur statut |
Cloud-Kubernetes-Api-StatefulSets-Status | Découvrez les StatefulSets Kubernetes pour superviser leur statut |
Modèles​
Le Pack Kubernetes API apporte 2 modèles d'hôte différents à utiliser en fonction des scénarios mentionnés précédemment :
Modèle d'hôte tout en un qui rassemblera les contrôles et les métriques avec un service par unité Kubernetes :
Cloud-Kubernetes-Api Cluster Events CronJob Status DaemonSet Status Deployment Status Node Status Node Usage PersistentVolume Status Pod Status ReplicatSet Status ReplicationController Status StatefulSet Status Un modèle d'hôte minimal qui ne collectera que des métriques pour les noeuds Kubernetes :
Cloud-Kubernetes-Node-Api Node Usage Node Status
Métriques et indicateurs supervisés​
Evénements du cluster​
Cet indicateur permet de superviser le nombre d'événements se produisant sur
le cluster, comme le kubectl get events
peut fournir :
NAMESPACE LAST SEEN TYPE REASON OBJECT MESSAGE
graphite 26m Warning Unhealthy pod/graphite-0 Liveness probe failed: Get "http://10.244.2.10:8080/": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
La sortie résultante dans Centreon pourrait ressembler à :
Event 'Warning' for object 'Pod/graphite-0' with message 'Liveness probe failed: Get "http://10.244.2.10:8080/": context deadline exceeded (Client.Timeout exceeded while awaiting headers)', Count: 1, First seen: 26m 21s ago (2021-03-11T12:26:23Z), Last seen: 26m 21s ago (2021-03-11T12:26:23Z)
Les métriques collectées seront :
Métrique |
---|
events.type.warning.count |
events.type.normal.count |
Il est alors possible de placer des seuils à l'aide des variables spéciales suivantes :
%{type}
%{object}
%{message}
%{count}
%{first_seen}
%{last_seen}
%{name}
%{namespace}
Les valeurs par défaut sont les suivantes :
Seuil | Valeur | Description |
---|---|---|
Warning | %{type} =~ /warning/i | Déclenchera une alerte s'il y a des événements warning |
Critical | %{type} =~ /error/i | Déclenchera une alerte critique s'il y a des événements error |
Référez vous à la documentation officielle pour plus d'informations sur les métriques collectées et comment affiner vos seuils.
Statut des CronJobs​
Cet indicateur permet de vérifier que les CronJobs sont exécutés comme ils
le devraient, comme le kubectl get cronjobs
peut fournir :
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
hello */1 * * * * False 1 6s 2d1h
La sortie résultante dans Centreon pourrait ressembler à :
CronJob 'hello' Jobs Active: 1, Last schedule time: 6s ago (2021-03-11T12:31:00Z)
La métrique collectée pour chaque CronJobs sera :
Métrique | Métrique Kubernetes |
---|---|
cronjob.jobs.active.count | active |
Si le service collecte des métriques de plusieurs CronJobs (selon le scénario choisi), le nom du CronJob sera ajouté au nom de la métrique :
Métrique |
---|
hello#cronjob.jobs.active.count |
Il est alors possible de placer des seuils à l'aide des variables spéciales suivantes :
%{active}
%{last_schedule}
%{name}
%{namespace}
Il n'y a pas de seuils par défaut. Un exemple intéressant pourrait être le
suivant: % {last_schedule}> x
oĂą x
en secondes est la durée au-delà de
laquelle le CronJob est considéré comme ne fonctionnant pas comme prévu.
Référez vous à la documentation officielle pour plus d'informations sur les métriques collectées et comment affiner vos seuils.
Statut des DaemonSets​
Cet indicateur garantira que les DaemonSets sont dans des limites définies
en regardant le nombre de Pods disponibles et/ou Ă jour par rapport au
nombre souhaité, comme le kubectl get daemonsets
peut fournir :
NAMESPACE NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
kube-system kube-flannel-ds-amd64 3 3 3 3 3 beta.kubernetes.io/arch=amd64 624d
kube-system kube-proxy 3 3 3 3 3 kubernetes.io/os=linux 624d
La sortie résultante dans Centreon pourrait ressembler à :
Daemonset 'kube-flannel-ds-amd64' Pods Desired: 3, Current: 3, Available: 3, Up-to-date: 3, Ready: 3, Misscheduled: 0
Daemonset 'kube-proxy' Pods Desired: 3, Current: 3, Available: 3, Up-to-date: 3, Ready: 3, Misscheduled: 0
Les métriques collectées pour chaque Daemonsets sera :
Métrique | Métrique Kubernetes |
---|---|
daemonset.pods.desired.count | desiredNumberScheduled |
daemonset.pods.current.count | currentNumberScheduled |
daemonset.pods.available.count | numberAvailable |
daemonset.pods.uptodate.count | updatedNumberScheduled |
daemonset.pods.ready.count | numberReady |
daemonset.pods.misscheduled.count | numberMisscheduled |
Si le service collecte des métriques de plusieurs DaemonSets (selon le scénario choisi), le nom du DaemonSet sera ajouté au nom de la métrique :
Métrique |
---|
kube-proxy#daemonset.pods.desired.count |
Il est alors possible de placer des seuils à l'aide des variables spéciales suivantes :
%{desired}
%{current}
%{available}
%{up_to_date}
%{ready}
%{misscheduled}
%{name}
%{namespace}
Les valeurs par défaut sont les suivantes :
Sueil | Valeur | Description |
---|---|---|
Warning | %{up_to_date} < %{desired} | Déclenchera une alerte si le nombre de Pods à jour est inférieur au nombre désiré |
Critical | %{available} < %{desired} | Déclenchera une alerte critique si le nombre de Pods disponible est inférieur au nombre désiré |
Référez vous à la documentation officielle pour plus d'informations sur les métriques collectées et comment affiner vos seuils.
Statut des Deployments​
Cet indicateur garantira que les Deployments sont dans des limites définies
en examinant le nombre de répliques disponibles et/ou à jour par rapport au
nombre souhaité, comme le kubectl get deployments
peut fournir :
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE
kube-system coredns 2/2 2 2 624d
kube-system tiller-deploy 1/1 1 1 624d
kubernetes-dashboard dashboard-metrics-scraper 1/1 1 1 37d
kubernetes-dashboard kubernetes-dashboard 1/1 1 1 37d
La sortie résultante dans Centreon pourrait ressembler à :
Deployment 'coredns' Replicas Desired: 2, Current: 2, Available: 2, Ready: 2, Up-to-date: 2
Deployment 'tiller-deploy' Replicas Desired: 1, Current: 1, Available: 1, Ready: 1, Up-to-date: 1
Deployment 'dashboard-metrics-scraper' Replicas Desired: 1, Current: 1, Available: 1, Ready: 1, Up-to-date: 1
Deployment 'kubernetes-dashboard' Replicas Desired: 1, Current: 1, Available: 1, Ready: 1, Up-to-date: 1
Les métriques collectées pour chaque Deployments sera :
Métrique | Métrique Kubernetes |
---|---|
deployment.replicas.desired.count | replicas (dans l'entrée spec ) |
deployment.replicas.current.count | replicas (dans l'entrée status ) |
deployment.replicas.available.count | availableReplicas |
deployment.replicas.ready.count | readyReplicas |
deployment.replicas.uptodate.count | updatedReplicas |
Si le service collecte des métriques de plusieurs Deployments (selon le scénario choisi), le nom du Deployment sera ajouté au nom de la métrique :
Métrique |
---|
tiller-deploy#deployment.replicas.desired.count |
Il est alors possible de placer des seuils à l'aide des variables spéciales suivantes :
%{desired}
%{current}
%{available}
%{ready}
%{up_to_date}
%{name}
%{namespace}
Les valeurs par défaut sont les suivantes :
Seuil | Valeur | Description |
---|---|---|
Warning | %{up_to_date} < %{desired} | Déclenchera une alerte si le nombre de replicas à jour est inférieur au nombre désiré |
Critical | %{available} < %{desired} | Déclenchera une alerte critique si le nombre de replicas disponible est inférieur au nombre désiré |
Référez vous à la documentation officielle pour plus d'informations sur les métriques collectées et comment affiner vos seuils.
Statut des Nodes​
Cet indicateur garantira que les noeuds fonctionnent bien en regardant
les statuts des conditions, comme le kubectl describe nodes
peut lister :
Conditions:
Type Status LastHeartbeatTime LastTransitionTime Reason Message
---- ------ ----------------- ------------------ ------ -------
MemoryPressure False Thu, 11 Mar 2021 14:20:25 +0100 Tue, 26 Jan 2021 09:38:11 +0100 KubeletHasSufficientMemory kubelet has sufficient memory available
DiskPressure False Thu, 11 Mar 2021 14:20:25 +0100 Wed, 17 Feb 2021 09:37:40 +0100 KubeletHasNoDiskPressure kubelet has no disk pressure
PIDPressure False Thu, 11 Mar 2021 14:20:25 +0100 Tue, 26 Jan 2021 09:38:11 +0100 KubeletHasSufficientPID kubelet has sufficient PID available
Ready True Thu, 11 Mar 2021 14:20:25 +0100 Tue, 26 Jan 2021 17:26:36 +0100 KubeletReady kubelet is posting ready status
La sortie résultante dans Centreon pourrait ressembler à :
Condition 'DiskPressure' Status is 'False', Reason: 'KubeletHasNoDiskPressure', Message: 'kubelet has no disk pressure'
Condition 'MemoryPressure' Status is 'False', Reason: 'KubeletHasSufficientMemory', Message: 'kubelet has sufficient memory available'
Condition 'PIDPressure' Status is 'False', Reason: 'KubeletHasSufficientPID', Message: 'kubelet has sufficient PID available'
Condition 'Ready' Status is 'True', Reason: 'KubeletReady', Message: 'kubelet is posting ready status'
Aucune métrique n'est collectée.
Il est possible de placer des seuils en utilisant les variables spéciales suivantes:
%{type}
%{status}
%{reason}
%{message}
Les valeurs par défaut sont les suivantes :
Seuil | Valeur | Description |
---|---|---|
Critical | (%{type} =~ /Ready/i && %{status} !~ /True/i) || (%{type} =~ /.*Pressure/i && %{status} !~ /False/i) | Déclenchera une alerte critique si le status de la condition Ready n'est pas True ou si le statut des conditions Pressure n'est pas False |
Référez vous à la documentation officielle pour plus d'informations sur les status et comment affiner vos seuils.
Utilisation des Nodes​
Cet indicateur rassemblera des métriques sur l'utilisation des noeuds comme l'allocation des Pods, les demandes de CPU et de mémoire faites par ces Pods, et les limites de CPU et de mémoire autorisées pour ces mêmes Pods.
En utilisant l'outil de ligne de commande Kubernetes, cela pourrait ressembler Ă ce qui suit :
Capacité des noeuds :
kubectl get nodes -o=custom-columns="NODE:.metadata.name,PODS ALLOCATABLE:.status.allocatable.pods,CPU ALLOCATABLE:.status.allocatable.cpu,MEMORY ALLOCATABLE:.status.allocatable.memory"
NODE PODS ALLOCATABLE CPU ALLOCATABLE MEMORY ALLOCATABLE
master-node 110 2 3778172Ki
worker-node 110 2 3778184KiPods en cours d'exécution :
kubectl get pods -o=custom-columns="NODE:.spec.nodeName,POD:.metadata.name,CPU REQUESTS:.spec.containers[*].resources.requests.cpu,CPU LIMITS:.spec.containers[*].resources.limits.cpu,MEMORY REQUESTS:.spec.containers[*].resources.requests.memory,MEMORY LIMITS:.spec.containers[*].resources.limits.memory"
NODE POD CPU REQUESTS CPU LIMITS MEMORY REQUESTS MEMORY LIMITS
worker-node coredns-74ff55c5b-g4hmt 100m <none> 70Mi 170Mi
master-node etcd-master-node 100m <none> 100Mi <none>
master-node kube-apiserver-master-node 250m <none> <none> <none>
master-node kube-controller-manager-master-node 200m <none> <none> <none>
master-node kube-flannel-ds-amd64-fk59g 100m 100m 50Mi 50Mi
worker-node kube-flannel-ds-amd64-jwzms 100m 100m 50Mi 50Mi
master-node kube-proxy-kkwmb <none> <none> <none> <none>
worker-node kube-proxy-vprs8 <none> <none> <none> <none>
master-node kube-scheduler-master-node 100m <none> <none> <none>
master-node kubernetes-dashboard-7d75c474bb-7zc5j <none> <none> <none> <none>
Depuis le tableau de bord Kubernetes, les métriques se trouvent dans le
menu Cluster > Nodes
:
Liste depuis
Cluser > Nodes
:Détail de l'allocation pour un noeud :
La sortie résultante dans Centreon pourrait ressembler à :
Node 'master-node' CPU requests: 37.50% (0.75/2), CPU limits: 5.00% (0.1/2), Memory requests: 3.96% (150.00MB/3.70GB), Memory limits: 1.32% (50.00MB/3.70GB), Pods allocation: 7.27% (8/110)
Node 'worker-node' CPU requests: 35.00% (0.7/2), CPU limits: 115.00% (2.3/2), Memory requests: 31.51% (1.17GB/3.70GB), Memory limits: 115.21% (4.26GB/3.70GB), Pods allocation: 9.09% (10/110)
Les métriques collectées pour chaque nœud seront :
Métrique |
---|
cpu.requests.percentage |
cpu.limits.percentage |
memory.requests.percentage |
memory.limits.percentage |
pods.allocation.percentage |
Si le service collecte des métriques de plusieurs Nodes (selon le scénario choisi), le nom du Node sera ajouté au nom de la métrique:
Métrique |
---|
worker-node#pods.allocation.percentage |
Des seuils exprimés en pourcentage peuvent être définis pour toutes les métriques, pour les alertes et les alertes critiques.
Statut des PersistentVolumes​
Cet indicateur garantira que les PersistentVolumes fonctionnent correctement
en regardant la phase dans laquelle ils se trouvent, comme le
kubectl get pv
peut fournir :
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv-nfs-kubestorage-001 5Gi RWO Retain Available 630d
pv-nfs-kubestorage-002 5Gi RWO Retain Bound tick/data-influxdb 630d
pv-nfs-kubestorage-003 5Gi RWO Retain Released graphite/graphite-pvc 630d
La sortie résultante dans Centreon pourrait ressembler à :
Persistent Volume 'pv-nfs-kubestorage-001' Phase is 'Available'
Persistent Volume 'pv-nfs-kubestorage-002' Phase is 'Bound'
Persistent Volume 'pv-nfs-kubestorage-003' Phase is 'Released'
Aucune métrique n'est collectée.
Il est possible de placer des seuils en utilisant les variables spéciales suivantes :
%{phase}
%{name}
Les valeurs par défaut sont les suivantes :
Seuil | Valeur | Description |
---|---|---|
Critical | `%{phase} !~ /Bound | Available |
Référez vous à la documentation officielle pour plus d'informations sur les status et comment affiner vos seuils.
Statut des Pods​
Cet indicateur garantira que les Pods et leurs conteneurs sont dans des
limites définies en regardant le nombre de conteneurs prêts par rapport au
nombre souhaité, comme le kubectl get pods
peut fournir :
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system kube-proxy-65zhn 1/1 Running 0 37d
kube-system kube-proxy-kkwmb 1/1 Running 0 37d
kube-system kube-proxy-vprs8 1/1 Running 0 37d
kube-system tiller-deploy-7bf78cdbf7-z5n24 1/1 Running 5 550d
kubernetes-dashboard dashboard-metrics-scraper-79c5968bdc-vncxc 1/1 Running 0 37d
kubernetes-dashboard kubernetes-dashboard-7448ffc97b-42rps 1/1 Running 0 37d
La sortie résultante dans Centreon pourrait ressembler à :
Checking pod 'kube-proxy-65zhn'
Containers Ready: 1/1 (100.00%), Status is 'Running', Restarts: 0
Container 'kube-proxy' Status is 'running', State is 'ready', Restarts: 0
Checking pod 'kube-proxy-kkwmb'
Containers Ready: 1/1 (100.00%), Status is 'Running', Restarts: 0
Container 'kube-proxy' Status is 'running', State is 'ready', Restarts: 0
Checking pod 'kube-proxy-vprs8'
Containers Ready: 1/1 (100.00%), Status is 'Running', Restarts: 0
Container 'kube-proxy' Status is 'running', State is 'ready', Restarts: 0
Checking pod 'tiller-deploy-7bf78cdbf7-z5n24'
Containers Ready: 1/1 (100.00%), Status is 'Running', Restarts: 5
Container 'tiller' Status is 'running', State is 'ready', Restarts: 5
Checking pod 'dashboard-metrics-scraper-79c5968bdc-vncxc'
Containers Ready: 1/1 (100.00%), Status is 'Running', Restarts: 0
Container 'dashboard-metrics-scraper' Status is 'running', State is 'ready', Restarts: 0
Checking pod 'kubernetes-dashboard-7448ffc97b-42rps'
Containers Ready: 1/1 (100.00%), Status is 'Running', Restarts: 0
Container 'kubernetes-dashboard' Status is 'running', State is 'ready', Restarts: 0
Les métriques collectées pour chaque Pods seront :
Métrique |
---|
containers.ready.count |
restarts.total.count |
containers.restarts.count |
Si le service collecte des métriques de plusieurs Pods (en fonction du scénario choisi), le nom du Pod et le nom du conteneur seront ajoutés au nom de la métrique :
Métrique |
---|
coredns-74ff55c5b-g4hmt#containers.ready.count |
coredns-74ff55c5b-g4hmt#restarts.total.count |
coredns-74ff55c5b-g4hmt_coredns#containers.restarts.count |
Il est alors possible de placer des seuils à l'aide des variables spéciales suivantes :
%{name}
%{status}
%{state}
(containers seulement)%{name}
%{namespace}
(Pods seulement)
Les valeurs par défaut sont les suivantes :
Seuil | Valeur | Description |
---|---|---|
Critical (Pod) | %{status} !~ /running/i | Déclenchera une alerte critique si un Pod n'est pas en statut running |
Critical (conteneur) | %{status} !~ /running/i || %{state} !~ /^ready$/ | Déclenchera une alerte critique si un conteneur n'est pas en statut running ou en état ready |
Référez vous à la documentation officielle pour plus d'informations sur les métriques collectées et comment affiner vos seuils.
Statut des ReplicaSets​
Cet indicateur garantira que les ReplicaSets sont dans les limites définies
en regardant le nombre de répliques prêtes par rapport au nombre souhaité,
comme le kubectl get replicasets
peut fournir :
NAMESPACE NAME DESIRED CURRENT READY AGE
kube-system coredns-74ff55c5b 2 2 2 44d
kube-system tiller-deploy-7bf78cdbf7 1 1 1 630d
kubernetes-dashboard dashboard-metrics-scraper-79c5968bdc 1 1 1 44d
kubernetes-dashboard kubernetes-dashboard-7448ffc97b 1 1 1 44d
La sortie résultante dans Centreon pourrait ressembler à :
ReplicaSet 'coredns-74ff55c5b' Replicas Desired: 2, Current: 2, Ready: 2
ReplicaSet 'tiller-deploy-7bf78cdbf7' Replicas Desired: 1, Current: 1, Ready: 1
ReplicaSet 'dashboard-metrics-scraper-79c5968bdc' Replicas Desired: 1, Current: 1, Ready: 1
ReplicaSet 'kubernetes-dashboard-7448ffc97b' Replicas Desired: 1, Current: 1, Ready: 1
Les métriques collectées pour chaque ReplicaSets seront :
Métrique | Métrique Kubernetes |
---|---|
replicaset.replicas.desired.count | replicas (dans l'entrée spec ) |
replicaset.replicas.current.count | replicas (dans l'entrée status ) |
replicaset.replicas.ready.count | readyReplicas |
Si le service collecte des métriques de plusieurs ReplicaSets (selon le scénario choisi), le nom du ReplicaSet sera ajouté au nom de la métrique :
Métrique |
---|
tiller-deploy-7bf78cdbf7#replicaset.replicas.desired.count |
Il est alors possible de placer des seuils à l'aide des variables spéciales suivantes :
%{desired}
%{current}
%{ready}
%{name}
%{namespace}
Les valeurs par défaut sont les suivantes :
Seuil | Valeur | Description |
---|---|---|
Critical | %{ready} < %{desired} | Déclenchera une alerte critique si le nombre de réplique en status ready est inférieur au nombre souhaité |
Référez vous à la documentation officielle pour plus d'informations sur les métriques collectées et comment affiner vos seuils.
Statut des ReplicationControllers​
Cet indicateur garantira que les ReplicationControllers sont dans les limites
définies en regardant le nombre de répliques prêtes par rapport au nombre
souhaité, comme le kubectl get rc
peut fournir :
NAMESPACE NAME DESIRED CURRENT READY AGE
elk nginx 3 3 3 2d19h
La sortie résultante dans Centreon pourrait ressembler à :
ReplicationController 'nginx' Replicas Desired: 3, Current: 3, Ready: 3
Les métriques collectées pour chaque ReplicaSets seront :
Métrique | Métrique Kubernetes |
---|---|
replicationcontroller.replicas.desired.count | replicas (dans l'entrée spec ) |
replicationcontroller.replicas.current.count | replicas (dans l'entrée status ) |
replicationcontroller.replicas.ready.count | readyReplicas |
Si le service collecte des métriques de plusieurs ReplicationControllers (selon le scénario choisi), le nom du ReplicationController sera ajouté au nom de la métrique :
Métrique |
---|
nginx#replicationcontroller.replicas.desired.count |
Il est alors possible de placer des seuils à l'aide des variables spéciales suivantes :
%{desired}
%{current}
%{ready}
%{name}
%{namespace}
Les valeurs par défaut sont les suivantes :
Seuil | Valeur | Description |
---|---|---|
Critical | %{ready} < %{desired} | Déclenchera une alerte critique si le nombre de réplique en status ready est inférieur au nombre souhaité |
Référez vous à la documentation officielle pour plus d'informations sur les métriques collectées et comment affiner vos seuils.
Statut des StatefulSets​
Cet indicateur garantira que les StatefulSets sont dans des limites définies
en regardant le nombre de répliques prêtes / à jour par rapport au nombre
souhaité, comme le kubectl get statefulsets
peut fournir :
NAMESPACE NAME READY AGE
elk elasticsearch-master 2/2 44d
graphite graphite 1/1 3d
prometheus prometheus-prometheus-operator-prometheus 1/1 619d
La sortie résultante dans Centreon pourrait ressembler à :
StatefulSet 'elasticsearch-master' Replicas Desired: 2, Current: 2, Up-to-date: 2, Ready: 2
StatefulSet 'graphite' Replicas Desired: 1, Current: 1, Up-to-date: 1, Ready: 1
StatefulSet 'prometheus-prometheus-operator-prometheus' Replicas Desired: 1, Current: 1, Up-to-date: 1, Ready: 1
Les métriques collectées pour chaque StatefulSets seront :
Métrique | Métrique Kubernetes |
---|---|
statefulset.replicas.desired.count | replicas (dans l'entrée spec ) |
statefulset.replicas.current.count | currentReplicas |
statefulset.replicas.ready.count | readyReplicas |
statefulset.replicas.uptodate.count | updatedReplicas |
Si le service collecte des métriques de plusieurs StatefulSets (selon le scénario choisi), le nom du StatefulSet sera ajouté au nom de la métrique :
Métrique |
---|
graphite#statefulset.replicas.desired.count |
Il est alors possible de placer des seuils à l'aide des variables spéciales suivantes :
%{desired}
%{current}
%{ready}
%{up_to_date}
%{name}
%{namespace}
Les valeurs par défaut sont les suivantes :
Seuil | Valeur | Description |
---|---|---|
Warning | %{up_to_date} < %{desired} | Déclenchera une alerte si le nombre de réplique à jour est inférieur au nombre souhaité |
Critical | %{ready} < %{desired} | Déclenchera une alerte critique si le nombre de réplique en status ready est inférieur au nombre souhaité |
Référez vous à la documentation officielle pour plus d'informations sur les métriques collectées et comment affiner vos seuils.
Prérequis​
Centreon Plugin​
Installez ce plugin sur chaque Poller nécessaire :
yum install centreon-plugin-Cloud-Kubernetes-Api
Kubernetes​
Comme mentionné dans l'introduction, deux modes de communication sont disponibles:
- l'API Rest exposée par le cluster Kubernetes,
- l'outil CLI kubectl pour communiquer avec le control plane du cluster.
Pour de meilleures performances, nous vous recommandons d'utiliser l'API Rest.
Créer un compte de service​
Les deux versions peuvent utiliser un compte de service avec des droits suffisants pour accéder à l'API Kubernetes.
Créez un compte de service dédié centreon-service-account
dans l'espace de
noms kube-system
pour accéder à l'API:
kubectl create serviceaccount centreon-service-account --namespace kube-system
Créez un rôle de cluster api-access
avec les privilèges nécessaires pour le
Plugin et liez-le au compte de service nouvellement créé :
cat <<EOF | kubectl create -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: api-access
rules:
- apiGroups:
- ""
- apps
- batch
resources:
- cronjobs
- daemonsets
- deployments
- events
- namespaces
- nodes
- persistentvolumes
- pods
- replicasets
- replicationcontrollers
- statefulsets
verbs:
- get
- list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: api-access
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: api-access
subjects:
- kind: ServiceAccount
name: centreon-service-account
namespace: kube-system
EOF
Se référer à la documentation officielle pour la création de compte de service ou pour des informations sur le concept de secret.
Utilisation de l'API Rest​
Si vous avez choisi de communiquer avec l'API Rest de votre plate-forme Kubernetes, les conditions préalables suivantes doivent être remplies :
- Exposez l'API avec TLS,
- Récupérez le jeton du compte de service.
Exposez l'API​
Comme l'API utilise HTTPS, vous aurez besoin d'un certificat.
Vous pouvez créer un couple clé / certificat signé automatiquement avec la commande suivante :
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/kubernetesapi.key -out /etc/ssl/certs/kubernetesapi.crt
Puis chargez-le en tant que api-certificate
dans le cluster, Ă partir du
noeud maître :
kubectl create secret tls api-certificate --key /etc/ssl/private/kubernetesapi.key --cert /etc/ssl/certs/kubernetesapi.crt
L'entrée peut maintenant être créée :
cat <<EOF | kubectl create -f -
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: kubernetesapi-ingress
namespace: default
annotations:
kubernetes.io/ingress.class: "nginx"
nginx.ingress.kubernetes.io/backend-protocol: HTTPS
spec:
tls:
- hosts:
- kubernetesapi.local.domain
secretName: api-certificate
rules:
- host: kubernetesapi.local.domain
http:
paths:
- backend:
serviceName: kubernetes
servicePort: 443
path: /
EOF
Adaptez les entrées host à vos besoins.
Se référer à la documentation officielle pour la gestion des ingress.
Récupérer le jeton du compte de service​
Récupérez le secret du compte de service précédemment créé :
kubectl get serviceaccount centreon-service-account --namespace kube-system --output jsonpath='{.secrets[].name}'
Récupérez ensuite le jeton du secret du compte de service :
kubectl get secrets centreon-service-account-token-xqw7m --namespace kube-system --output jsonpath='{.data.token}' | base64 --decode
Ce jeton sera utilisé ultérieurement pour la configuration de l'hôte Centreon.
Utilisation de kubectl​
Si vous avez choisi de communiquer avec le control plane du cluster avec kubectl, les conditions préalables suivantes doivent être remplies:
- Installez l'outil kubectl,
- Créez une configuration kubectl.
Ces actions sont nécessaires sur tous les Pollers qui effectueront la surveillance de Kubernetes.
Installer kubectl​
Téléchargez la dernière version avec la commande suivante :
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
Assurez-vous de télécharger une version avec une différence d'au maximum une version mineure de votre cluster. Pour télécharger une version spécifique, changez le curl intégrée par la version comme
v1.20.0
.
Installez l'outil dans le répertoire des binaires :
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
Référez vous à la documentation officielle pour plus de détails.
Créer une configuration kubectl​
Pour accéder au cluster, kubectl a besoin d'un fichier de configuration contenant toutes les informations nécessaires.
Voici un exemple de création de fichier de configuration basé sur un compte de service (créé au chapitre précédent).
Vous devrez remplir les informations suivantes et exécuter les commandes sur le noeud maître:
ip=<master node ip>
port=<api port>
account=centreon-service-account
namespace=kube-system
clustername=my-kube-cluster
context=my-kube-cluster
secret=$(kubectl get serviceaccount $account --namespace $namespace --output jsonpath='{.secrets[].name}')
ca=$(kubectl get secret $secret --namespace $namespace --output jsonpath='{.data.ca\.crt}')
token=$(kubectl get secret $secret --namespace $namespace --output jsonpath='{.data.token}' | base64 --decode)
Le nom du compte et l'espace de noms doivent correspondre au compte créé précédemment. Toutes les autres informations doivent être adaptées.
Exécutez ensuite cette commande pour générer le fichier de configuration :
cat <<EOF >> config
apiVersion: v1
kind: Config
clusters:
- name: ${clustername}
cluster:
certificate-authority-data: ${ca}
server: https://${ip}:${port}
contexts:
- name: ${context}
context:
cluster: ${clustername}
namespace: ${namespace}
user: ${account}
current-context: ${context}
users:
- name: ${account}
user: ${token}
EOF
Cela créera un fichier config
. Ce fichier doit être copié dans le répertoire
racine de l'utilisateur de l'Engine du Poller, généralement dans un répertoire
.kube
(c'est-Ă -dire /var/lib/centreon-engine/.kube/config
).
Ce chemin sera utilisé ultérieurement dans la configuration de l'hôte Centreon.
Vous pouvez également copier la configuration dans le répertoire de l'utilisateur Gorgone si vous utilisez Host Discovery.
Référez vous à la documentation officielle pour plus de détails.
Configuration de la supervision​
Création manuelle​
Ajoutez un hĂ´te Ă partir du menu Configuration> Hosts
et choisissez un
modèle entre Cloud-Kubernetes-Api
(surveillance globale, scénarios 1 et 2)
et Cloud-Kubernetes-Node-Api
(surveillance unitaire, scénario 3) dans la
liste.
Dans les deux cas, remplissez les champs suivants :
Champ | Description |
---|---|
Host name | Nom de l'hĂ´te |
Alias | Description de l'hĂ´te |
IP | Adresse IP de l'hĂ´te |
Monitored from | Poller Ă utiliser |
L'adresse IP peut être soit l'adresse IP de Kubernetes (noeud maître), soit l'adresse IP de chaque noeud si vous choisissez le modèle
Cloud-Kubernetes-Node-Api
.
Ensuite, définissez les valeurs pour chaque macros nécessaire :
Si vous utiliser l'API Rest :
Macro Description Exemple KUBERNETESAPICUSTOMMODE
Mode custom du plugin api
KUBERNETESAPIHOSTNAME
Nom d'hĂ´te ou adresse IP du service d'API du clister kubenetesapi.local.domain
KUBERNETESAPIPORT
Port de l'API 443
KUBERNETESAPIPROTO
Protocole utilisé par l'API https
KUBERNETESAPITOKEN
Jeton récupéré lié au compte de service eyJhbG...KEw
Si vous utiliser kubectl :
Macro Description Exemple KUBERNETESAPICUSTOMMODE
Mode custom du plugin kubectl
KUBECTLCONFIGFILE
Chemin vers le fichier de configuration ~/.kube/config
Ensuite, définissez les valeurs pour chaque macros nécessaire :
Macro | Description | Valeur par défaut |
---|---|---|
PROXYURL | URL du proxy (si nécessaire) | aucune |
TIMEOUT | Temps en secondes avant l'expiration de la requĂŞte | 10 |
EXTRAOPTIONS | Options supplémentaires (si nécessaire) | aucune |
KUBERNETESAPINAMESPACE | Filtre namespace | aucune |
Si vous choisissez Cloud-Kubernetes-Api
, l'hôte sera ajouté avec tous les
services pour vérifier chaque unité Kubernetes (scénario 1).
Cliquez sur le bouton Enregistrer et vous ĂŞtes prĂŞt Ă pousser la configuration vers les Engines.
Découverte automatique​
Découverte d'hôte​
Ajoutez une tâche dans le menu Configuration > Découverte
et choisissez
un provider entre Kubernetes Nodes (RestAPI)
et
Kubernetes Nodes (Kubectl)
dans la liste.
Définissez les informations d'identification pour accéder à l'API Kubernetes en fonction de la méthode choisie:
- Si vous utilisez l'API Rest: définissez le jeton récupérer plus tôt à partir du compte de service,
- Si vous utilisez kubectl: définissez le chemin vers le
fichier de configuration créé
(préférez utiliser le chemin relatif pour le faire fonctionner à la fois
pour la découverte et la supervision, c'est-à -dire
~/.kube/config
).
Pour l'API Rest: le nom d'hôte / l'adresse, le port et le protocole sont nécessaires pour accéder à l'API Kubernetes.
Par défaut, la découverte ajoutera des hôtes avec un modèle d'hôte minimal
qui ne collectera que des métriques pour l'utilisation des noeuds Kubernetes.
Il ajoutera ensuite une macro spéciale KUBERNETESNODENAME
avec le nom du
noeud comme valeur (scénario 3).
S'il est planifié, la tâche ajoutera automatiquement les nouveaux noeuds ajoutés au cluster.
Découverte de service​
En plus de la création manuelle, il est possible d'ajouter un service pour chaque instance de chaque unité Kubernetes (scénario 2). Il est alors recommandé de désactiver les services précédemment créés lors de l'ajout d'hôte.
Lancez une analyse sur l'hôte ajouté à partir du menu
Configuration > Service > Manuelle
et ajoutez tous les services souhaités.
Si elle est activée, la règle de découverte de service ajoutera automatiquement les nouvelles instances créées dans le cluster.
Dépannage​
Voici quelques erreurs courantes et leur description. Vous voudrez souvent
utiliser l'option --debug
pour obtenir l'erreur exacte.
Erreur | Description |
---|---|
UNKNOWN: Cannot decode json response: Can't connect to <hostname>:<port> (certificate verify failed) | This error may appear if the TLS cetificate in self-signed. Use the option --ssl-opt="SSL_verify_mode => SSL_VERIFY_NONE" to omit the certificate validity. |
UNKNOWN: API return error code '401' (add --debug option for detailed message) | If adding --debug option, API response message says Unauthorized . It generally means that the provided token is not valid. |
UNKNOWN: API return error code '403' (add --debug option for detailed message) | If adding --debug option, API response message says nodes is forbidden: User "system:serviceaccount:<namespace>:<account>" cannot list resource "nodes" in API group "" at the cluster scope . It means that the cluster role RBAC bound to the service account does not have the necessary privileges |
UNKNOWN: CLI return error code '1' (add --debug option for detailed message) | If adding --debug option, CLI response message says error: stat ~/.kube/config:: no such file or directory . The provided configuration file cannot be found. |
UNKNOWN: CLI return error code '1' (add --debug option for detailed message) | If adding --debug option, CLI response message says error: error loading config file "/root/.kube/config": open /root/.kube/config: permission denied . The provided configuration file cannot be read by current user. |
UNKNOWN: CLI return error code '1' (add --debug option for detailed message) | If adding --debug option, CLI response message says error: error loading config file "/root/.kube/config": v1.Config.AuthInfos: []v1.NamedAuthInfo: v1.NamedAuthInfo.AuthInfo: v1.AuthInfo.ClientKeyData: decode base64: illegal base64... . The provided configuration file is not valid. |
UNKNOWN: CLI return error code '1' (add --debug option for detailed message) | If adding --debug option, CLI response message says The connection to the server <hostname>:<port> was refused - did you specify the right host or port? . The provided configuration file is not valid. |