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 :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 | type PodLifecycleHandler interface {
CreatePod(ctx context.Context, pod *corev1.Pod) error
UpdatePod(ctx context.Context, pod *corev1.Pod) error
DeletePod(ctx context.Context, pod *corev1.Pod) error
GetPod(ctx context.Context, namespace, name string) (*corev1.Pod, error)
GetPodStatus(ctx context.Context, namespace, name string) (*corev1.PodStatus, error)
GetPods(context.Context) ([]*corev1.Pod, error)
} |
Cette interface est facile à mettre en correspondance avec l'API Fly Machines. Par exemple :
| Code : | Sélectionner tout |
1 2 | CreatePod -> POST /apps/{app_name}/machines
UpdatePod -> POST /apps/{app_name}/machines/{machine_id} |
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, persistance SQLite et Virtual Kubelet.
Au final, l'équipe a obtenu quelque chose de beaucoup plus simple que K3s, ce qui n'est pas peu dire.
Fly Kubernetes a quelques avantages par rapport à flyctl et fly.toml :
- Votre déploiement est plus déclaratif qu'avec le fichier fly.toml. Vous déclarez l'état exact de tout, jusqu'au nombre de répliques, aux règles d'autoscaling, aux définitions de volume, etc.
- Lorsque vous déployez avec Fly Kubernetes, Kubernetes fait automatiquement correspondre vos définitions à l'état du monde. Des machines tombent en panne ? Kubernetes les remettra en ligne.
Il s'agit d'une façon différente de faire de l'orchestration et de l'ordonnancement sur Fly.io. Ce n'est pas ce que tout le monde va vouloir. Mais si vous le voulez, et que vous le voulez vraiment, Fly.io est ravi de vous l'offrir : Les fonctionnalités de la plateforme Fly.io, avec Kubernetes gérant la configuration et conduisant votre système à l'état désiré.
L'équipe a tenu à ce que les choses restent simples pour commencer. Il y a des cas d'utilisation de K8s pour lesquels Fly.io est parfaitement adapté aujourd'hui, et d'autres pour lesquels des améliorations seront apportées dans un avenir proche, au fur et à mesure que les utilisateurs de K8s feront progresser la plateforme sous-jacente (et en particulier le proxy).
Ce que tout cela signifie
Une chose évidente est que vous avez investi dans l'outillage Kubernetes, vous pouvez le conserver tout en exécutant des choses au-dessus de Fly.io. C'est donc très intéressant.
Mais l'histoire de l'informatique est également intéressante. Fly.io a parié sur une stratégie idiosyncrasique pour l'orchestration globale. Le consensus global, qui est le mode de fonctionnement de Borg, Kubernetes et Nomad, a été remplacé par un système basé sur le marché. Ce système était plus rapide et, surtout, plus bête que le système de consensus qu'il remplaçait.
Cela avait un coût ! Le consensus global de Nomad devait faire des quantités de travail vraiment héroïques pour s'assurer que les Fly Apps soient programmées quelque part, n'importe où. En bon capitaliste, Fly Machines vous dira en termes clairs combien de travail il est prêt à faire pour vous ("moins qu'un Nomad"
.Mais cela ne signifie pas que vous devez vous contenter des réponses que Fly Machines vous donne. Parce que Fly Machines est si simple, et essaie si fort d'être prévisible, l'équipe espère que vous serez capable de construire des schémas d'ordonnancement et d'orchestration plus sophistiqués au-dessus de lui. Et nous y voilà : L'ordonnancement Kubernetes, en tant que plugin de la plateforme.
D'autres nouveautés à venir ! L'équipe de Fly.io a hâte de voir combien de façons différentes ce pari pourrait être payant.
Source : "Introducing Fly Kubernetes" (Fly.io)
Et vous ?
Quel est votre avis sur le sujet ?Voir aussi
Fly.io lève 70 millions de dollars pour accélérer le déploiement d'apps sur son propre cloud public, l'entreprise veut accompagner la création d'apps qui s'exécutent rapidement dans le monde entier K3s : une distribution Kubernetes légère et facile à installer, avec un binaire de moins de 100 Mo et des dépendances externes réduites au minimum