Etude d'impact de l'upgrade Kubernetes sur l'outillage Monitoring Caascad#

Ce document décrit la procédure pour faire une étude de compatibilité entre les outils de monitoring et une version de Kubernetes donnée.

Avant l'upgrade du cluster#

Noter la liste des différentes apiservices et leurs versions.

kubectl get apiservices.apiregistration.k8s.io

2. Vérifier le système d'alerting

Créer une alerte et regarder dans Karma pour vérifier que le système d'alerting est fonctionnel.

Vérifier la présence des métriques dans Grafana
Faire un tableau récapitulatif

statut	node exporter	docker-exporter	kube-state-metrics	prometheus	prometheus-operator	promtail
déployé ?	oui	oui	oui	oui	oui	oui
running ?	oui	oui	oui	oui	oui	oui
erreur log?	non	non	PDB et Cronjob deprecated	non	non	oui
vérification dans Grafana	Oui	Oui	Oui	Oui	Oui	oui

Faire l'étude des changelog de Kubernetes#

Parcourir les différents changelog de Kubernetes et relever les changements les plus impactants.
Confirmer la présence des nouvelles métriques depuis Grafana.
Faire un tableau récapitulatif des métriques en identifiant les nouvelles, celles qui sont dépréciées, celles qui sont supprimées et celles qui ont subi un changement différent.

Exemple

metrics name	new metrics	deprecated	deleted	new label	other
apiserver_admission_* metrics	no	no	no	namespace	no
apiserver_flowcontrol_request_concurrency_in_use	yes	no	no	no	no
apiserver_flowcontrol_current_r	yes	no	no	priority_level	no
apiserver_flowcontrol_dispatch_r	yes	no	no	priority_level	no
apiserver_flowcontrol_latest_s	yes	no	no	priority_level	no
apiserver_flowcontrol_next_s_bounds	yes	no	no	priority_level	no

Identifier les rules et les dashboards impactés#

Pour cela, il faut d'abord télécharger van_halen et ripgrep.

van_halen update --clone
sudo apt install ripgrep

Ensuite aller dans le répertoire contenant les dépots Git et faire une recherche récursive des métriques qui sont supprimées ou renommées.

Exemple avec la métrique storage_operation_errors_total:

cd ~/git/caascad
rg storage_operation_errors_total

Vérifier la compatibilité des autres applications dans le cluster#

Coredns Faire une étude comparative des différents release CoreDns pour voir s'il y a des impacts au niveau des métriques et des rules.
Kube-state-metrics

Pour Kube-state-metrics, il faut récupérer directement la matrice de compatibilité depuis le dépot

Après l'upgrade du cluster#

Faire une vérification visuelle dans Karma.
Vérifier les logs des différents composants.

Vérifier le système d'alerting en déployant une prometheusrules.

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
labels:
    cloudservicesfactory.com/monitoring: "1"
name: test.alert
spec:
groups:
- name: TestAlert
    rules:
    - alert: TestAlert
    expr: vector(1)
    labels:
        severity: info