5 articles tagués avec « eks »

« 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é.

Une mise à jour Kubernetes n'est jamais un simple changement de numéro de version. Il y a un drain de nœud, un échange de binaire, une migration de plan de contrôle, une séquence d'éviction de pods, et — si vous êtes en bare-metal — personne à appeler quand ça tourne mal.

Les fournisseurs Kubernetes managés gèrent l'essentiel de cela pour vous. Les clusters auto-gérés vous font tout posséder. Cet article documente les deux côtés concrètement : ce qu'EKS, GKE et AKS font réellement lors d'une mise à jour, et ce que j'ai construit pour automatiser le même processus sur mon cluster k3s de 5 nœuds tournant sur des ThinkPads.

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.