Le cloud native en bref : microservices, observabilité, écosystème CNCF

Vous savez maintenant lancer et organiser des pods. Prenons un peu de hauteur : pourquoi tout le monde parle de Kubernetes, de microservices, de « cloud native » ? Ces mots recouvrent une façon de concevoir et d'exploiter les applications, née chez les géants du web et devenue la norme. La comprendre vous évitera de voir Kubernetes comme une simple collection de commandes, et c'est un domaine à part entière de la certification KCNA.

Ce que vous saurez à la fin : expliquer ce qu'est une application cloud native, les avantages et les coûts des microservices, les trois piliers de l'observabilité, ce qu'est la CNCF et comment lire son écosystème.

1. Cloud native, c'est quoi ?

La définition de la CNCF (Cloud Native Computing Foundation), en résumé : les technologies cloud native permettent de construire et d'exploiter des applications évolutives dans des environnements dynamiques (clouds publics, privés, hybrides). Conteneurs, microservices, infrastructure immuable et API déclaratives en sont les exemples typiques.

Ce n'est donc pas « héberger dans le cloud ». Une application monolithique copiée telle quelle sur une machine virtuelle chez un fournisseur cloud n'est pas cloud native. Une application conçue pour être découpée, répliquée, remplacée et mise à jour en continu peut l'être, même sur vos propres serveurs.

Les propriétés recherchées :

• Résilience : la panne d'un composant ne fait pas tomber l'ensemble ; on se répare automatiquement.
• Élasticité : on ajoute ou retire des copies selon la charge.
• Livraison fréquente : on met à jour plusieurs fois par jour sans couper le service.
• Observabilité : on comprend ce qui se passe à l'intérieur sans s'y connecter à la main.
• Automatisation : tout ce qui se répète est décrit dans du code et exécuté par des machines.

2. Monolithe et microservices

Le monolithe : toute l'application (catalogue, panier, paiement, comptes) dans un seul programme, déployé d'un bloc.

Les microservices : chaque fonction est un petit service indépendant, avec sa propre équipe, son propre rythme de livraison et souvent sa propre base de données. Ils communiquent par le réseau (HTTP, gRPC, files de messages).

	Monolithe	Microservices
Déploiement	tout ou rien	chaque service séparément
Mise à l'échelle	toute l'application	seulement le service chargé
Panne	peut tout emporter	reste souvent limitée à un service
Complexité	dans le code	dans le réseau et l'exploitation
Équipes	toutes sur le même code	une équipe par service

Les microservices ne sont pas gratuits : appels réseau qui échouent, données réparties, déploiements à coordonner, diagnostic plus difficile. Beaucoup d'équipes gagnent à commencer par un monolithe bien structuré. Kubernetes n'impose pas les microservices, mais il les rend exploitables : chaque service devient un Deployment et un Service, avec ses copies, ses mises à jour et sa découverte par DNS.

3. Les principes d'une application bien conçue

Une application est facile à exploiter sur Kubernetes si elle respecte quelques règles (inspirées de la méthode des 12 facteurs) :

• Sans état (stateless) : elle ne garde rien d'important en mémoire ou sur son disque local. L'état vit dans une base de données ou un stockage dédié. On peut ainsi tuer une copie et en lancer une autre à tout moment.
• Configuration externe : rien n'est codé en dur. Adresses, options et secrets arrivent par des variables d'environnement ou des fichiers (les ConfigMaps et Secrets du Parcours 2). La même image tourne en test et en production.
• Journaux sur la sortie standard : l'application écrit ses logs sur stdout, et la plateforme se charge de les collecter. C'est ce que lit kubectl logs.
• Démarrage rapide, arrêt propre : elle démarre en quelques secondes et termine proprement ses requêtes en cours quand on lui demande de s'arrêter.
• Santé exposée : elle indique si elle est vivante et prête (les sondes).

Et côté infrastructure, le principe d'immuabilité : on ne modifie pas un conteneur qui tourne. On construit une nouvelle image et on remplace. Fini les serveurs « bricolés à la main » dont plus personne ne connaît la configuration.

4. L'observabilité : comprendre ce qui se passe

Avec des dizaines de services qui se parlent, « se connecter sur le serveur pour regarder » n'a plus de sens. On instrumente les applications pour qu'elles racontent ce qu'elles font. Trois types de signaux, les trois piliers :

Pilier	Question à laquelle il répond	Exemple	Outils courants
Journaux (logs)	que s'est-il passé, en détail ?	ERROR paiement refusé, commande 4512	Fluent Bit, Loki, Elasticsearch
Métriques	combien, à quelle vitesse, avec quelle tendance ?	230 requêtes/s, 2 % d'erreurs, 450 Mo de mémoire	Prometheus, Grafana
Traces	par où est passée une requête, et où a-t-elle perdu du temps ?	40 ms dans le panier, 800 ms dans le paiement	Jaeger, Tempo

OpenTelemetry est le standard ouvert qui unifie la production de ces trois signaux, quel que soit l'outil qui les stocke.

On distingue souvent la surveillance (monitoring, être alerté quand une valeur connue dépasse un seuil) de l'observabilité (pouvoir répondre à des questions qu'on n'avait pas prévues).

5. Les rôles autour de la plateforme

• DevOps : une culture qui rapproche développement et exploitation, avec des livraisons fréquentes et automatisées.
• SRE (Site Reliability Engineering) : l'exploitation traitée comme un problème d'ingénierie, avec des objectifs de fiabilité mesurés (SLO : « 99,9 % des requêtes réussies sur 30 jours »).
• Platform engineering : une équipe construit une plateforme interne (souvent sur Kubernetes) que les équipes de développement utilisent en libre-service.

6. Comment on livre : CI/CD et GitOps

• CI (intégration continue) : à chaque modification du code, des tests et la construction d'une image se lancent automatiquement.
• CD (livraison continue) : la nouvelle version est déployée automatiquement ou en un clic.
• GitOps : l'état voulu du cluster est décrit dans un dépôt Git, et un outil (Argo CD, Flux) l'applique en continu. Pour changer la production, on change Git, avec relecture et historique. C'est la boucle de réconciliation de Kubernetes, étendue à toute la chaîne.

7. Au-delà des conteneurs : serverless

Avec le serverless, on ne gère même plus de serveurs ni de conteneurs qui tournent en permanence : on fournit du code (une fonction), et la plateforme le lance à la demande, en facturant à l'usage. Sur Kubernetes, des projets comme Knative proposent ce modèle, avec la possibilité de descendre à zéro copie quand personne n'utilise le service.

8. La CNCF et son écosystème

La CNCF est une fondation, partie de la Linux Foundation, qui héberge des projets open source neutres : Kubernetes en premier lieu, mais aussi Prometheus, containerd, CoreDNS, Helm, Envoy, etcd, OpenTelemetry, Argo, Flux…

Chaque projet a un niveau de maturité :

Niveau	Signification
Sandbox	expérimental, prometteur
Incubating	utilisé en production par plusieurs organisations, en progression
Graduated	mature, largement adopté, gouvernance solide (Kubernetes, Prometheus, etcd, containerd…)

Le CNCF Landscape cartographie des centaines de projets et produits par catégorie : runtime, orchestration, observabilité, sécurité, stockage, réseau… Il est volontairement exhaustif : ce n'est pas une liste de choses à installer, mais une carte pour savoir quelles familles d'outils existent.

Enfin, l'écosystème repose sur des standards ouverts, qui évitent de dépendre d'un seul éditeur :

• OCI : format des images et des runtimes de conteneurs ;
• CRI : interface entre Kubernetes et le runtime de conteneurs ;
• CNI : interface pour le réseau des pods ;
• CSI : interface pour le stockage.

À retenir

• Cloud native = applications résilientes, élastiques, livrées souvent, observables et automatisées, pas « hébergées dans le cloud ».
• Les microservices apportent de l'indépendance, au prix d'une complexité d'exploitation.
• Une bonne application pour Kubernetes est sans état, configurée de l'extérieur, écrit ses journaux sur stdout, démarre vite et s'arrête proprement.
• Observabilité : journaux, métriques, traces, unifiés par OpenTelemetry.
• La CNCF héberge les projets, classés sandbox, incubating, graduated ; l'écosystème tient sur des standards (OCI, CRI, CNI, CSI).