Kubernetes n’est pas obligatoire : la stack « pas k8s »

Il y a un truc qu’on n’ose pas toujours dire en réunion, surtout quand tout le monde parle « platform engineering », « SRE », « GitOps » et compagnie.

Kubernetes, c’est puissant. Oui. Mais Kubernetes n’est pas obligatoire.

Et si tu gères une petite équipe, un SaaS naissant, une appli interne, un site à trafic correct mais pas délirant, ou même une agence qui déploie plein de projets similaires… tu peux très bien vivre sans k8s. Longtemps. Parfois pour toujours.

Je vois encore des stacks partir sur k8s parce que « c’est standard ». Puis derrière, ça galère sur les basiques. Observabilité bricolée. Déploiements stressants. Coûts cloud qui gonflent. Et surtout… personne ne comprend vraiment ce qui se passe quand ça casse.

Ici, je te propose une stack « pas k8s ». Un truc simple, solide, maintenable. Pas sexy sur LinkedIn. Mais efficace.

Le vrai besoin : déployer, scaler, dormir

Avant de parler outils, on doit être honnête sur le besoin.

Tu veux quoi, en pratique ?

• déployer sans couper le service
• revenir en arrière rapidement si ça foire
• scaler quand ça monte
• avoir des logs lisibles, des métriques, des alertes
• sécuriser un minimum, avec des secrets propres
• payer un coût acceptable, en temps et en argent

Kubernetes coche tout ça, mais il te fait payer une taxe mentale. Et une taxe opérationnelle.

La stack « pas k8s », c’est juste l’idée suivante : prendre 80 % des bénéfices, sans le labyrinthe.

Les briques de la stack « pas k8s »

Je te donne une version très concrète. Ensuite tu adaptes selon ton contexte.

1) Conteneurs : Docker (ou Podman) + Compose

Oui, Docker Compose. Celui que certains considèrent comme « pour jouer ». En réalité, pour énormément de cas, c’est suffisant.

• un fichier compose.yml clair
• des services versionnés
• des réseaux internes
• des volumes pour la data
• des healthchecks
• une reproductibilité propre

Et surtout, tu peux lire le fichier et comprendre. Ça change tout.

2) Reverse proxy : Traefik ou Caddy

Tu veux du HTTPS automatique, du routage propre, du renouvellement de certificats sans douleur.

• Traefik si tu aimes les labels Docker et un écosystème riche
• Caddy si tu veux un truc ultra simple, souvent magique, et une conf lisible

Les deux font très bien le job.

Un point important : tu remplaces une grosse partie de l’expérience « Ingress » de k8s par quelque chose de plus direct.

3) Déploiement : SSH + CI/CD simple (ou Ansible)

La vérité : déployer sur 1 à 5 VPS, tu peux le faire proprement avec un pipeline CI qui :

• build les images
• push dans un registry (GitHub Container Registry, GitLab, etc.)
• se connecte en SSH sur le serveur
• fait un docker compose pull puis docker compose up -d
• purge les vieilles images si besoin

Et si tu veux industrialiser : Ansible.

Pas besoin de réinventer le monde.

4) Scaling : vertical + quelques serveurs, et basta

Le scaling horizontal façon k8s, c’est génial. Mais souvent, tu n’en as pas besoin au début.

Approche réaliste :

• tu scales verticalement (plus de CPU, plus de RAM)
• tu sépares les rôles (web sur un VPS, base de données sur un autre)
• tu ajoutes un second serveur web si nécessaire
• tu mets un load balancer simple (HAProxy, ou un LB managé chez ton cloud)

C’est moins « auto », mais c’est prévisible.

5) Observabilité : Uptime Kuma + Grafana + Loki (ou simple journalisation)

Tu n’as pas besoin d’un monstre.

• Uptime Kuma pour vérifier que ça répond, et alerter vite
• Prometheus + Grafana pour les métriques si tu veux creuser
• Loki pour des logs centralisés sans devenir fou
• ou juste journald + rotation + un accès propre, au début

Le but, c’est d’avoir un signal clair quand ça part en vrille.

6) Secrets : .env chiffré, ou SOPS, ou Vault léger

Ne mets pas tes secrets en clair dans le repo.

Options simples :

• .env non commité, injecté par le serveur
• SOPS (avec clé age) si tu veux versionner de manière propre
• Vault, mais uniquement si tu en as une vraie raison

Là encore, pas besoin de singer k8s pour faire bien.

7) Base de données : managée si possible

C’est le conseil qui fait gagner du temps.

Si tu peux : prends une base managée. Postgres managé. Redis managé. Backups inclus.

Si tu auto héberges : fais des backups automatisés, testés, restaurables. Testés, vraiment.

Exemple de stack complète (simple, réaliste)

Un setup que j’aime bien pour un produit web classique :

• 1 VPS « app » : Traefik + app(s) Docker + workers
• 1 VPS « data » : Postgres + Redis + backups
• Uptime Kuma sur le VPS app (ou ailleurs)
• CI/CD GitHub Actions ou GitLab CI
• Logs : Loki si besoin, sinon journalisation + rotation

C’est clair, tu sais où sont les choses, et tu peux expliquer ton infra en 3 minutes.

Quand k8s devient pertinent (et là, oui, vas y)

Je ne suis pas anti k8s. Je suis anti « k8s par défaut ».

Kubernetes devient pertinent quand :

• tu as beaucoup de services, beaucoup d’environnements
• tu as besoin d’un scheduling avancé, d’auto scaling fin, de multi zone
• tu as une équipe plateforme, ou au moins des gens qui veulent vraiment l’opérer
• tu veux standardiser à grande échelle

Sinon, tu risques surtout d’ajouter de la complexité à un système qui n’avait pas demandé ça.

En bref

La stack « pas k8s » n’est pas une régression. C’est souvent un choix adulte.

Tu prends Docker Compose, un reverse proxy solide, un déploiement CI propre, un peu d’observabilité, et tu avances. Tu construis le produit. Tu apprends. Tu itères. Et si un jour tu as vraiment besoin de k8s… tu y vas avec une raison, pas avec une mode.

Si tu aimes ce genre de contenus très terrain, j’en publie régulièrement sur Le Blog Tech Pro de Samyn-Antoy ABASSE ( https://monblog-sa-abasse.blogspot.com ) avec des guides Linux, admin système, IA, et des trucs concrets pour builder en ligne. Tu peux y passer et garder le lien sous la main, ça aide.

Questions fréquemment posées

Kubernetes est-il indispensable pour déployer une application SaaS ou un site web à trafic modéré ?

Non, Kubernetes n'est pas obligatoire. Pour une petite équipe, un SaaS naissant, une application interne ou un site avec un trafic correct mais pas excessif, il est tout à fait possible et souvent plus simple de déployer sans Kubernetes en utilisant des outils plus légers et compréhensibles.

Quels sont les principaux avantages d'une stack « pas k8s » pour le déploiement d'applications ?

La stack « pas k8s » permet de bénéficier de 80 % des avantages du déploiement moderne – comme le déploiement sans interruption, la possibilité de rollback rapide, le scaling, l'observabilité et la sécurité minimale – tout en évitant la complexité et la surcharge mentale associées à Kubernetes.

Quels outils composent une stack efficace sans Kubernetes ?

Une stack « pas k8s » typique inclut : 1) Docker ou Podman avec Docker Compose pour gérer les conteneurs ; 2) Traefik ou Caddy comme reverse proxy pour HTTPS automatique et routage ; 3) Un pipeline CI/CD simple avec SSH ou Ansible pour le déploiement ; 4) Scaling vertical avec quelques serveurs et load balancer simple ; 5) Observabilité via Uptime Kuma, Grafana, Loki ou simplement une bonne journalisation.

Comment gérer le déploiement continu sans Kubernetes sur plusieurs serveurs ?

Il est possible de mettre en place un pipeline CI/CD qui construit les images Docker, les pousse vers un registre (comme GitHub Container Registry), puis se connecte en SSH aux serveurs pour exécuter docker compose pull et docker compose up -d. Pour industrialiser ce processus, Ansible peut être utilisé sans complexifier inutilement.

Comment assurer la sécurité et la gestion des secrets dans une stack sans Kubernetes ?

Même sans Kubernetes, il est important de sécuriser les applications. La stack « pas k8s » recommande d'avoir une gestion propre des secrets, par exemple via des fichiers sécurisés ou des outils dédiés compatibles avec Docker Compose. Le reverse proxy (Traefik ou Caddy) gère aussi automatiquement les certificats HTTPS pour sécuriser les communications.

Est-il possible d'avoir une bonne observabilité et monitoring sans utiliser des solutions complexes comme celles intégrées à Kubernetes ?

Oui. Une observabilité efficace peut être obtenue avec des outils simples comme Uptime Kuma pour vérifier la disponibilité et alerter rapidement, Grafana associé à Prometheus pour les métriques détaillées, Loki pour centraliser les logs, ou même juste une bonne gestion des journaux système (journald) avec rotation et accès clair. L'objectif est d'avoir des signaux clairs quand quelque chose ne va pas.