10 articles tagués avec « bare-metal »

ArgoCD réconcilie tout ce qui est à l'intérieur de mon cluster : 95 applications, de Vault à la passerelle IA, toutes déclarées dans Git et synchronisées en continu. Mais ArgoCD ne peut pas formater un disque, installer open-iscsi ni corriger une route par défaut. Il existe une couche en dessous du GitOps — le système d'exploitation de chaque nœud bare-metal — et si cette couche n'est pas codifiée, « l'infrastructure reproductible » n'est qu'une demi-vérité.

Pour le système d'information ktayl-solution, cette couche appartient à un petit dépôt : minicloud-ansible. Environ 200 lignes de tâches réparties en quatre rôles, qui font une seule chose et la font bien : rendre les prérequis OS d'un cluster k3s à 6 nœuds reproductibles et auditables. Cet article explique comment je l'utilise pour exploiter la plateforme de l'organisation.

La plupart des tutoriels Kubernetes commencent par eksctl create cluster ou gcloud container clusters create. Un plan de contrôle managé, des groupes de nœuds à auto-scaling, des load balancers qui apparaissent avec une simple annotation. Le cloud abstrait entièrement le matériel.

Nous avons pris la direction opposée. Cinq machines physiques — quatre ThinkPads et un MacBook Pro de 2012 — exécutant k3s, avec chaque workload ordonnancé et exploité par nous. Pas de plan de contrôle managé. Pas de groupe de nœuds à auto-scaling. Pas de load balancer cloud. Juste Linux, containerd et Flannel sur du fer que l'on peut toucher.

Mais nous utilisons bien des services cloud. AWS achemine nos e-mails. Cloudflare se place devant chaque requête HTTP. Une instance Lightsail relaie le trafic UDP de nos appels vidéo. Tailscale nous connecte au cluster depuis n'importe où.

Cet article explique comment nous avons décidé ce qui va où, et pourquoi l'architecture résultante n'est pas un compromis — c'est une conception délibérée.

OpenShift Container Platform est une distribution Kubernetes d'entreprise avec des choix affirmés. Mon cluster minicloud est une pile k3s de 5 nœuds assemblée composant par composant à partir de projets CNCF. Après avoir traversé la construction complète — GitOps, observabilité, secrets, registre, OIDC, ingress, réplication de stockage, tests de chaos, correctifs de sécurité, mises à jour — je peux dire avec une certaine précision quelle est réellement la différence.

Ce n'est pas qu'OpenShift en fait plus. C'est qu'OpenShift a déjà fait chaque choix que vous auriez à faire vous-même, a empaqueté ces choix en une unité versionnée, testée et supportée, et les a imposés au niveau de l'architecture. Que ce soit un avantage ou une contrainte dépend entièrement de ce que vous cherchez à faire.

« Haute disponibilité » est l'un de ces termes dont tout le monde s'accorde à dire qu'il compte et que presque personne ne définit précisément. Sur un fournisseur Kubernetes managé, vous cochez une case pour le multi-AZ et vous passez à autre chose. Sur un cluster auto-géré, vous prenez six décisions d'architecture indépendantes, chacune avec son propre mode de défaillance, son compromis et son coût opérationnel.

Cet article documente chaque couche de HA sur minicloud — un cluster k3s de 5 nœuds sur des ThinkPads — explique le raisonnement derrière chaque compromis, et associe chaque couche à la façon dont EKS, GKE et AKS résolvent le même problème.

Chaque tutoriel Kubernetes mentionne etcd. Les schémas d'architecture montrent un cluster etcd à trois nœuds avec consensus Raft, élection de leader et réplication entre pairs. Si vous utilisez EKS, GKE ou AKS, ce cluster existe quelque part — vous ne pourrez simplement jamais le voir.

Si vous utilisez k3s, vous n'avez pas d'etcd du tout.

Cet article explique ce que k3s utilise réellement, ce que cela signifie de gérer soi-même les sauvegardes et la reprise, et où cela vous situe par rapport à un fournisseur managé.

Les fournisseurs Kubernetes managés font paraître le patch de sécurité simple. Vous activez l'auto-mise à jour sur GKE, vous cliquez « mettre à jour le groupe de nœuds » sur EKS, et la CVE disparaît. Ce qui se passe réellement, c'est que le fournisseur patche l'image OS, remplace le nœud, valide le binaire, et restaure vos workloads — le tout dans le temps qu'il faut pour rafraîchir la console AWS.

Sur un cluster auto-géré, rien de cela n'est automatique. Vous possédez l'OS. Vous possédez le runtime. Vous possédez les images de base. Vous possédez les versions de charts Helm. Et quand une CVE tombe, vous possédez la décision sur la couche où elle vit et le mécanisme qui la fermera.

Cet article documente les cinq couches de patching sur minicloud — un cluster k3s de 5 nœuds sur des ThinkPads bare-metal — ce qui est automatisé, ce qui requiert une PR, et où étaient les manques et comment ils ont été comblés.

La plupart des comparatifs Kubernetes sont écrits par des gens qui n'ont utilisé que des services managés. Celui-ci est écrit par quelqu'un qui a un ThinkPad nommé set-hog posé sur un bureau, en train de faire tourner le serveur d'API en ce moment même.

Voici à quoi ressemble vraiment l'auto-gestion d'un plan de contrôle Kubernetes — comparé ligne par ligne à EKS, GKE et AKS.

Un modèle 7B en FP32, c'est 28 Go de RAM. Mes ThinkPads en ont 16 à 32. Impossible de charger le modèle — sans parler de faire de l'inférence.

La quantization a résolu ce problème. Pas en sacrifiant la qualité — en changeant la façon dont les poids sont stockés.

Le matériel était provisionné. MAAS avait démarré quatre ThinkPads en PXE et cloud-init avait écrit les clés SSH et les noms d'hôte. La question suivante était : comment faire tourner concrètement Kubernetes sur cinq laptops ?

Il existe plus de façons d'installer Kubernetes qu'il n'y a de parcours de certification Kubernetes. J'ai fini avec k3s. Voici pourquoi — et exactement à quoi ressemblait l'installation.

La plupart des plateformes cloud vous cachent l'infrastructure. Provisioning MAAS, séquences de boot PXE, agrégation de cartes réseau, backends de stockage, chaînes de certificats — tout est abstrait derrière quelques flags CLI ou un tableau de bord. Cette abstraction a de la valeur en production, mais elle peut aussi tenir les ingénieurs à distance des systèmes qu'ils sont censés comprendre en profondeur.

Ce projet est né d'une question simple : qu'est-ce qu'il faut vraiment pour construire une plateforme Kubernetes de qualité production from scratch ?