TL;DR
Cette série construit progressivement une infrastructure cloud complète sur Infomaniak Public Cloud. Dans cet épisode, le sujet précis est: Kubernetes : monitoring de k8S + remote_write prometheus. Préciser la chaîne de monitoring Kubernetes: scrapes, ServiceMonitor, remote_write ou opérateur VictoriaMetrics selon le contenu de "Kubernetes : monitoring de k8S + remote_write prometheus".
La vidéo de référence
Vidéo: https://www.youtube.com/watch?v=UGiTqCRH_Ng
Playlist complète: https://www.youtube.com/playlist?list=PLn6POgpklwWpehxly1wOT6eB2NvZX9A-X
Le dépôt support est disponible ici: https://gitlab.com/xavki/infrastructure-cloud-infomaniak. Le chapitre correspondant est 103-kubernetes-monitoring-objectifs.
Objectif précis de l épisode
Préciser la chaîne de monitoring Kubernetes: scrapes, ServiceMonitor, remote_write ou opérateur VictoriaMetrics selon le contenu de "Kubernetes : monitoring de k8S + remote_write prometheus".
Concrètement, cet épisode sert à passer d une intention formulée dans le titre à une modification vérifiable dans l infrastructure. Le dépôt donne les fichiers, la vidéo donne l ordre de manipulation, et la vérification doit confirmer que la brique fonctionne vraiment.
Kubernetes : monitoring de k8S + remote_write prometheus: c est quoi exactement ?
Dans une infrastructure cloud réelle, chaque épisode ajoute une brique: réseau, compute, sécurité, automatisation, découverte de services, observabilité, sauvegardes ou orchestration. Ici, les outils détectés sont: openstack, consul, monitoring, traefik, postgresql, keycloak, gitlab, kubernetes, helm.
Dans cet épisode, il faut surtout regarder les éléments qui correspondent au titre: les ressources créées ou modifiées, les fichiers du chapitre, les services touchés et la preuve de fonctionnement. Les outils détectés donnent le contexte, mais le fil rouge reste Kubernetes : monitoring de k8S + remote_write prometheus.
Ce que la vidéo cherche à modifier
- brancher les métriques utiles
- adapter la configuration de collecte ou de stockage
- rendre le résultat visible dans Grafana ou dans les règles d alerte
- modifier les manifests, charts ou playbooks liés au cluster
- vérifier l interaction entre Kubernetes et OpenStack
- garder un chemin de diagnostic kubectl clair
Indices extraits des slides
- Kubernetes: Kubernetes monitoring & Objectifs
- Move to kubernetes ?
- keep Prometheus ?
- add the monitoring stack: progressive methode (remote write, Grafana chart in kube Prometheus stack)
- easier thanks to consul and its DNS
Notions et définitions des outils
- openstack: OpenStack est la couche cloud IaaS: instances, réseaux, routeurs, IP flottantes, groupes de sécurité, volumes et images. Chez Infomaniak Public Cloud, il sert de socle programmable via GUI, CLI, Terraform et API.
- consul: Consul apporte service discovery, DNS interne, health checks et catalogue de services. Il relie machines, proxy, monitoring et automatisation.
- monitoring: Le monitoring collecte métriques, alertes et dashboards. Node exporter, vmagent, VictoriaMetrics, VMAlert, Alertmanager, Karma et Grafana couvrent collecte, stockage, règles, notification et visualisation.
- traefik: Traefik est un reverse proxy dynamique. Il route HTTP/HTTPS vers des backends et peut se configurer via Consul ou annotations Kubernetes.
- postgresql: PostgreSQL est le SGBD relationnel de la plateforme. La série aborde installation, réplication, failover, utilisateurs, sauvegardes, PITR et monitoring.
- keycloak: Keycloak fournit SSO, realms, clients, rôles, mappings et protocoles OAuth2/OpenID Connect pour centraliser l authentification.
- gitlab: GitLab apporte forge Git, CI/CD, registry, sauvegardes et workflows d équipe pour industrialiser le code infrastructure et applicatif.
- kubernetes: Kubernetes orchestre des conteneurs sur un cluster: pods, deployments, services, CNI, kubeadm, Helm et intégration avec Terraform/Consul/monitoring.
- helm: Helm est le gestionnaire de packages de Kubernetes. Un chart regroupe templates, valeurs et dépendances; une release est une instance déployée de ce chart dans un cluster.
Ces définitions sont volontairement pratiques: elles expliquent à quoi sert l outil dans la chaîne, pas seulement ce qu il est sur le papier.
Points clés à retenir pour cet épisode
- Comprendre le rôle de Kubernetes : monitoring de k8S + remote_write prometheus dans la progression globale de l infrastructure.
- Identifier la couche concernée: cloud, automatisation, réseau, service, observabilité ou orchestration.
- Relier les fichiers du dépôt au résultat attendu sur les machines ou dans le cloud.
- Valider les objets Kubernetes créés et leur intégration avec le réseau et le monitoring.
- Conserver une preuve de fonctionnement via métriques, dashboards ou alertes.
Approfondissement spécifique
Pour Kubernetes : monitoring de k8S + remote_write prometheus, le sujet précis est le trajet de la métrique: exposition par un exporter ou un composant, découverte par le collecteur, stockage, requête PromQL puis visualisation ou alerte.
Un dashboard ne valide pas à lui seul l observabilité. Il faut remonter à la target, vérifier la fraîcheur des séries, tester une requête représentative et s assurer que l alerte repose sur un signal actionnable.
Dans Kubernetes : monitoring de k8S + remote_write prometheus, Kubernetes doit être relié au socle OpenStack et aux playbooks du dépôt. Le cluster n est pas isolé: réseau, routes, volumes, DNS et monitoring dépendent encore des choix faits autour de l infrastructure.
La lecture utile part des objets Kubernetes concernés, puis descend vers les events, les services, le CNI, les routes OpenStack ou les volumes Cinder selon le sujet de l épisode.
Le coeur de Kubernetes : monitoring de k8S + remote_write prometheus est la collecte Kubernetes: quelles cibles sont scrapées, par quel mécanisme, avec quels labels, et vers quel stockage métrique. C est cette chaîne qui décide si les métriques de cluster deviennent réellement exploitables.
Quand l épisode parle de scrapes, remote_write, ServiceMonitor ou opérateur, il faut vérifier la ressource de découverte, la target obtenue et une métrique concrète. Sinon on risque d avoir une configuration présente mais aucune série utile.
Exemple de code ou configuration du dépôt
Les exemples complets sont dans les répertoires du chapitre listés plus bas.
Chemin de diagnostic recommandé
- vérifier que les targets sont up
- contrôler une requête PromQL représentative
- ouvrir le dashboard ou l alerte concernée
- contrôler les pods, services et events
- vérifier les routes, CNI ou volumes si le sujet les touche
- tester la configuration depuis le cluster et depuis l extérieur
- Comparer l état attendu dans le dépôt et l état réel dans le cloud, la machine ou le cluster.
- Documenter la commande, l écran ou la métrique qui prouve que l étape est fonctionnelle.
Répertoires et commandes utiles
- Répertoire support: 103-kubernetes-monitoring-objectifs
- Répertoire support: 103-kubernetes-monitoring-objectifs/code/ansible
- Répertoire support: 103-kubernetes-monitoring-objectifs/code/terraform
Pièges fréquents
- déployer un exporter sans scrape
- créer un dashboard sans métrique stable
- alerter sur un signal trop bruité
- diagnostiquer Kubernetes sans regarder les events
- oublier le lien avec réseau OpenStack
- déployer un chart sans maîtriser les values
Liens utiles externes
- Dépôt Xavki infrastructure-cloud-infomaniak
- Playlist YouTube Infra de A à Z
- docs.infomaniak.cloud
- docs.infomaniak.cloud/getting_started/first_project
- docs.infomaniak.cloud/compute/instances
- docs.infomaniak.cloud/orchestration/terraform
- docs.infomaniak.cloud/network/networks
- docs.infomaniak.cloud/network/security_groups
Liens internes conseillés
- Parcours Kubernetes pour relier la partie cluster et orchestration.
- Prometheus, Grafana et observabilité pour approfondir métriques et dashboards.
- Kubernetes 003 – architecture pour revoir les composants du control plane.
- RabbitMQ et workloads stateful pour comparer stockage, redémarrage et état applicatif.
Pour continuer, lire Infra A à Z 105 – Kubernetes : monitoring – ajout des scrapes & destroy des routes.
FAQ
Pourquoi utiliser Terraform et Ansible ensemble ?
Terraform est adapté à la création et au cycle de vie des ressources cloud. Ansible est adapté à la configuration des machines et services. Les mélanger sans frontière claire rend les changements difficiles à relire.
Pourquoi Infomaniak/OpenStack dans cette série ?
Infomaniak Public Cloud expose des concepts OpenStack standards: compute, réseau, volumes, security groups, object storage, identity et orchestration. Cela permet d apprendre des notions transférables tout en travaillant sur un fournisseur concret.
Que faut-il sécuriser en premier ?
Les accès: credentials cloud, state Terraform, SSH, VPN, dashboards, secrets Ansible, tokens GitLab, consoles d administration et ports exposés publiquement. Une infrastructure automatisée amplifie aussi les erreurs de sécurité.
Comment savoir si une étape est terminée ?
Chaque étape doit produire une preuve: une ressource visible, un service joignable, une métrique collectée, un backup restaurable, une requête qui répond ou un déploiement qui converge.
Conclusion
L épisode 104 s inscrit dans une progression complète: construire, automatiser, sécuriser, observer et exploiter une infrastructure cloud. Le dépôt Xavki donne les exemples concrets, la documentation Infomaniak/OpenStack donne le cadre fournisseur, et le deep dive permet de comprendre le rôle des outils au lieu de seulement rejouer des commandes.