Fly Kubernetes, un nouveau cloud public pour l'exécution d'applications conteneurisées

Avec isolation de machine virtuelle sur le matériel propre de Fly.io dans le monde entier

Fly Kubernetes, un nouveau cloud public pour l'exécution d'applications conteneurisées, avec isolation de machine virtuelle sur le matériel propre de Fly.io dans le monde entier

Fly.io construit un nouveau cloud public qui exécute des applications conteneurisées avec isolation de machine virtuelle sur son propre matériel à travers le monde. Et cela sans aucun K8. Jusqu'à présent !

Kubernetes (communément appelé "K8s" est un système open source qui vise à fournir une "plate-forme permettant d'automatiser le déploiement, la montée en charge et la mise en œuvre de conteneurs d'application sur des grappes de serveurs". Fonctionnant avec toute une série de technologies de conteneurisation, et souvent utilisé avec Docker, Kubernetes a été conçu à l'origine par Google, puis offert à la Cloud Native Computing Foundation.

L'équipe de Fly.io reconnaît qu'elle a été sarcastique à l'égard de Kubernetes. "Nous sommes, dans l'âme, des geeks Unix de la vieille école. Nous sommes toujours scandalisés par systemd.". Pour compliquer un peu plus les choses, les problèmes sur lesquels Fly.io travaille ont beaucoup de points communs avec K8s, mais juste assez de décalage d'impédance pour qu'il (ou tout ce qui y ressemble) ne soit pas adapté à la plateforme Fly. L'équipe est consciente qu'elle est perçue comme n'ayant jamais pris K8s au sérieux. "K8s est difficile à utiliser pour nous, mais cela ne veut pas dire qu'il ne convient pas à ce que vous construisez. Nous avons toujours été clairs à ce sujet, n'est-ce pas ? Bien sûr !"

Eh bien, bonne nouvelle, tout le monde ! Si K8s est important pour votre projet, et que c'est tout ce qui vous retient d'essayer la plateforme, sachez que l'équipe de Fly.io a passé les derniers mois à construire quelque chose pour vous.


Fly.io pour les Kubernetiens

Fly.io fonctionne en transmogrifiant les conteneurs Docker en systèmes de fichiers pour des hyperviseurs légers, et en les exécutant sur des serveurs mis en rack dans des dizaines de régions à travers le monde.

Vous pouvez construire quelque chose comme Fly.io avec des outils d'orchestration "standard" tels que K8s. C'est d'ailleurs ce qui a été fait au départ. Pour garder les choses simples, Nomad a été utilisé, et au lieu des CNI de K8s, un proxy Anycast avec terminaison TLS basé sur Rust a été construit (et un système de réseau privé basé sur WireGuard/IPv6 et sur eBPF a été conçu). Mais les idées restent les mêmes.

Du point de vue de l'équipe, l'élément caractéristique d'un orchestrateur "standard" est le planificateur global : l'œil global dans le ciel qui suit les vacances sur les serveurs et le placement optimisé des nouvelles charges de travail. C'est le problème auquel l'équipe de Fly.io s'est heurtée. Plus de 200 000 applications sont exécutées sur tous les continents, à l'exception de l'Antarctique. La vitesse de la lumière (et un réseau mondial de backhoes) a son mot à dire sur le maintien d'une image globale parfaitement cohérente de centaines de milliers d'applications, et ce n'est pas agréable.

L'autre problème qui a été rencontré, c'est que le programmateur Nomad n'a cessé d'essayer d'être plus malin que l'équipe et, pire encore, que les clients. Il s'avère que les utilisateurs de Fly.io ont une idée assez précise de l'endroit où ils souhaitent que leurs applications soient exécutées. S'ils demandent São Paulo, ils veulent São Paulo, pas Rio. Mais les planificateurs mondiaux ont d'autres priorités, comme l'optimisation de la répartition des ressources, et il arrive que GIG leur paraisse tout aussi bon que GRU.

Pour échapper aux problèmes de mise à l'échelle et de DX qui se présentaient, l'orchestration a été repensée. Alors que les orchestrateurs comme K8s ont tendance à travailler par consensus distribué, la solution proposée maintient l'état au niveau local. Chaque serveur de la flotte est une source fiable d'informations sur les applications qui s'y exécutent et fournit une API à un "planificateur" de type marché qui fait des offres sur les ressources dans les régions. Ce système s'appelle l'API Fly Machines.

Un détail important à comprendre sur la façon dont tout cela fonctionne - la raison pour laquelle il n'a pas été possible de battre le théorème CAP en faisant cela - est que les appels API de Fly Machines peuvent échouer. Si Nomad ou K8s essaie de placer une charge de travail sur un serveur, pour finalement s'apercevoir qu'il est plein ou qu'il a coulé une bielle, il partira à la recherche d'un autre endroit pour la placer, comme un bon petit robot. L'API Machines ne fera pas cela. Elle ne répondra pas à la demande. En fait, elle s'efforce de faire échouer la demande rapidement, afin de fournir un retour d'information ; si l'équipe ne peut pas planifier le travail dans JNB pour l'instant, vous voudrez peut-être plutôt déployer rapidement dans BOM.

Orchestration pluggable et Fly Kubernetes (FKS)

En réalité, ce qui a été fait ici, c'est d'extraire une partie du problème de l'ordonnancement de l'orchestrateur, et de le confier à d'autres composants. Pour la plupart des utilisateurs, ce composant est flyctl, le CLI intrépide de Fly.

Mais Fly Machines est une API, et tout peut la piloter. Beaucoup d'utilisateurs veulent des réponses rapides aux demandes de programmation d'applications dans des régions spécifiques, et flyctl fait un excellent travail à cet égard. Mais il est tout à fait raisonnable de vouloir quelque chose qui fonctionne plus comme les bons petits robots à l'intérieur de K8s.

Vous pouvez créer votre propre orchestrateur avec l'API de Fly.io, mais si ce que vous recherchez est littéralement Kubernetes, cette peine vous sera épargnée. Il s'agit de Fly Kubernetes, ou FKS en abrégé.

FKS est une implémentation de Kubernetes qui fonctionne au-dessus de Fly.io. Vous le démarrez à l'aide de flyctl, en exécutant flyctl ext k8s create.

Sous le capot, FKS est une combinaison directe de deux projets Kubernetes bien connus : K3s, la distro légère K8s certifiée par la CNCF, et Virtual Kubelet.

Virtual Kubelet est intéressant. Au pays de K8s, un kubelet est un agent hôte ; c'est la chose qui s'exécute sur chaque serveur de votre flotte et qui sait comment exécuter un pod K8s. Virtual Kubelet n'est pas un agent hôte ; c'est un composant logiciel qui prétend être un hôte, s'enregistrant auprès de K8s comme s'il en était un, mais qui utilise sournoisement l'API Kubelet ailleurs.

Dans FKS, "ailleurs" correspond à Fly Machines. Tout ce qu'il reste à faire, c'est de satisfaire les différentes API que le kubelet virtuel expose. Par exemple, l'API pour le cycle de vie d'un pod :


Cette interface est facile à mettre en correspondance avec l'API Fly Machines. Par exemple :


K3s, quant à lui, est une implémentation dépouillée de tout K8s qui tient dans un seul binaire. K3s fait un tas de choses intelligentes pour être aussi rationalisé qu'il l'est, mais la plus notable d'entre elles est kine, une API shim qui remplace etcd par des bases de données comme SQLite. Grâce à kine, K3s peut gérer plusieurs serveurs, mais peut également fonctionner sur un seul serveur, sans état distribué.

C'est ce qui a été fait. Lorsque vous créez un cluster, Fly.io exécute K3s et le Virtual Kubelet sur un seul Fly Machine. La plateforme compile un kubeconfig, avec lequel vous pouvez parler à votre K3s via kubectl. L'ensemble est configuré pour exécuter des Pods sur des Fly Machines individuelles, de sorte que votre cluster s'étende directement en utilisant la plateforme, mais avec l'outillage de K8s.

Ce qui est intéressant dans cette conception, c'est qu'une grande partie du travail est déjà faite pour nous par la plateforme sous-jacente. Si vous êtes un adepte de K8s, prenez une seconde pour penser à tous les différents composants avec lesquels vous traitez : etcd, les nœuds provisionnés spécifiquement, le proxy kube, un binaire CNI et la configuration et son intégration avec le réseau hôte, containerd, les registres. Mais Fly.io fait déjà la plupart de ces choses. Ce projet a donc consisté à supprimer des composants jusqu'à ce que l'on se retrouve avec le strict minimum : CoreDNS,...