Qu'est-ce que Kubernetes (K8s) ?

Kubernetes est une plateforme open-source qui automatise le déploiement, la mise à l’échelle et l’exploitation d’apps conteneurisées sur plusieurs machines. Son idée centrale est déclarative : vous énoncez l’état final désiré — trois répliques de ce conteneur, cette quantité de mémoire, joignable sur ce port — et le système travaille en continu pour que la réalité coïncide, redémarrant, replanifiant et mettant à l’échelle sans qu’on le lui demande.

Points clés

Le manifeste : comment vous parlez à Kubernetes

Tout est déclaration. Voici un Deployment minimal et réel — annoté en clair :

apiVersion: apps/v1
kind: Deployment              # "garde N copies de ceci en marche"
metadata:
  name: api
spec:
  replicas: 3                 # l'état désiré : trois pods
  selector:
    matchLabels: { app: api }
  template:                   # ce que contient chaque pod
    metadata:
      labels: { app: api }
    spec:
      containers:
        - name: api
          image: registry.example.com/api:1.4.2
          ports: [{ containerPort: 8080 }]
          resources:
            limits: { memory: "256Mi", cpu: "500m" }
# Appliquez-le, tuez un pod, regardez Kubernetes le ressusciter. C'est ça, le produit.

Par contraste — le même résultat (un backend déployé, mis à l’échelle, auto-réparant) consommé comme service, où le manifeste, le cluster et la réconciliation à 3 heures du matin sont le YAML de quelqu’un d’autre :

// JavaScript / Node.js — Back4app JS SDK
// The workload the manifest would have described — already running
const status = await Parse.Cloud.run('healthCheck');
console.log(status); // scheduling, scaling, restarts: the platform's job

// Flutter / Dart — Back4app Flutter SDK
final function = ParseCloudFunction('healthCheck');
final response = await function.execute();
if (response.success) {
  print(response.result); // no pods, no manifests, no cluster to run
}

// iOS / Swift — Back4app Swift SDK
ParseCloud.callFunction("healthCheck") { result in
  if case .success(let status) = result {
    print(status) // no pods, no manifests, no cluster to run
  }
}

// Android / Kotlin — Back4app Android SDK
ParseCloud.callFunctionInBackground<String>("healthCheck", hashMapOf()) { status, e ->
  if (e == null) Log.d("Health", status) // no pods, no manifests, no cluster
}

À l’intérieur d’un cluster

Le vocabulaire, une ligne chacun : un cluster est le système complet ; un nœud est une machine ; un pod est la plus petite unité déployable (un ou plusieurs conteneurs partageant réseau et stockage) ; un Deployment gère des pods répliqués avec rolling updates et rollbacks ; un Service donne aux pods éphémères une adresse stable ; un Ingress route le trafic externe vers l’intérieur ; les ConfigMaps et Secrets portent la configuration ; les namespaces partitionnent un cluster entre équipes. La vue d’ensemble officielle est l’étape suivante canonique.

Kubernetes vs. Docker

La confusion éternelle a une date : depuis la v1.24 (2022), Kubernetes a abandonné son shim de runtime spécifique à Docker et ne parle plus qu’à des runtimes de conteneurs standard. Rien ne s’est cassé — les images suivent le standard ouvert OCI — mais les rôles sont devenus nets : Docker est le chantier naval, Kubernetes est l’autorité portuaire. Le nom l’a toujours su : kubernetes signifie « timonier » en grec — le projet a été publié en open source en juin 2014, a atteint la 1.0 en 2015 et a donné naissance à la CNCF, distillant une décennie d’exploitation de conteneurs à l’échelle d’une flotte en un bien commun public.

Cas d’usage courants

• Flottes de microservices. Des dizaines de services avec mise à l’échelle et déploiements indépendants — la charge de travail qui a façonné Kubernetes.
• Équipes plateforme. Construire une plateforme interne sur un substrat qui s’exécute à l’identique sur n’importe quel cloud ou on-premises.
• Charges massives en pics. Jobs par lots, pipelines de données, entraînement de ML — bin-packés sur une capacité partagée.
• Stratégies multi-cloud et de portabilité. La couche de calcul d’une défense contre le vendor lock-in — avec la réserve que les services gérés alentour verrouillent encore.
• Parcs de production auto-réparants. Partout où « une machine est morte à 3 heures du matin » doit être un non-événement plutôt qu’une alerte qui réveille.

Devriez-vous exécuter Kubernetes ? Matrice de décision

Le consensus silencieux de l’industrie : la plupart des équipes qui exploitent Kubernetes sont en dessous de l’échelle où il se rentabilise. L’échelle des alternatives — un hôte avec un fichier compose, un service de conteneurs géré, un PaaS, un BaaS — couvre tout jusqu’aux vrais problèmes de flotte, et le Kubernetes géré couvre l’essentiel de ce qui reste.

Limites et trade-offs

• La courbe d’apprentissage est l’ombre du produit. Pods, services, ingress, RBAC, operators, Helm — la fluidité se mesure en mois, et le cluster n’attend pas.
• La surface opérationnelle. Mises à niveau, rotation des certificats, plugins réseau et santé du magasin d’état ne pardonnent pas ; c’est pourquoi les control planes gérés ont gagné.
• L’étalement de YAML. La configuration déclarative à l’échelle devient sa propre base de code, avec ses propres revues, ses bugs et sa dérive.
• Il orchestre des conteneurs, pas l’architecture. Un système mal délimité sur Kubernetes est le même système, désormais distribué — le cluster amplifie la conception, bonne ou mauvaise.
• Kubernetes n’est pas un PaaS. Par conception, il ne livre ni CI/CD, ni base de données par défaut, ni services applicatifs — la plateforme au-dessus est à vous d’assembler, ce qui est précisément le travail que les abstractions plus hautes revendent comme produit.

Kubernetes sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. La relation avec Kubernetes est une honnête division du travail : ce que la plupart des équipes applicatives attendent réellement d’un cluster — des services backend déployés, mis à l’échelle, auto-réparants — est exactement ce que la couche BaaS livre avec zéro manifeste à écrire. Et pour les charges qui sont réellement des conteneurs, Back4app Containers les exécute en service géré : poussez une image, obtenez l’orchestration, sans posséder le port.