fabric

Zyvor Fabric est un plan de contrôle auto-hébergé pour les clouds privés, construit sur des serveurs Linux ordinaires avec KVM. Il regroupe l'API, l'authentification, le réseau, le stockage et la surveillance dans un seul démon Rust, zyvor-fabricd. Plutôt que d'implémenter lui-même l'exécution des VM, il se positionne comme la couche d'orchestration et d'UX au-dessus de deux projets compagnons : FluxVM (le moteur de VM, accessible via REST sur 127.0.0.1:7788) et GuestKit (inspection et personnalisation hors ligne du disque utilisées avant le premier démarrage). Interfaces et automatisation Le même démon alimente quatre interfaces de premier plan : l'outil en ligne de commande zyvorctl, une console web servie aux côtés de l'API (port par défaut 9095), un opérateur Kubernetes qui réconcilie les ressources personnalisées VirtualMachine avec une instance fabricd en cours d'exécution, et un fournisseur Terraform. Du contenu Ansible et un outil de pré-vol « Fabric Doctor » sont également inclus. Des définitions de VM déclaratives peuvent être appliquées avec zyvorctl apply -f, et la création de VM prend en charge un partitionnement optionnel par tenant. Le README indique que le démon expose plus de 480 points de terminaison REST ainsi que trois canaux WebSocket, et rapporte environ 48 crates Rust et environ 87 000 lignes de code en Rust et TypeScript. Sécurité et multi-tenancy L'authentification utilise JWT, avec des revendications de tenant limitant les opérations de liste, d'obtention et de mutation. Le projet liste des rôles RBAC, l'exportation d'audit et le chiffrement au repos, et documente l'intégration d'identité OIDC/SSO et SCIM, ainsi qu'une couche de compatibilité OpenStack avec du matériel tutoriel pour le client. Réseau Le README distingue deux plans de politique qui ne doivent pas être confondus : Fabric SDN (isolation des hôtes via nftables pilotée par des labels, gérée via /api/network-policies) et le dataplane Network Fabric VM-edge, qui attache des programmes TC/eBPF à l'interface côté hôte de chaque VM. Le dataplane edge prend en charge des listes d'autorisation CIDR IPv4/IPv6 par VM (cartes LPM), l'application de protocoles/ports L4, des limites de débit Mbps/PPS, ainsi que des statistiques par VM et des enregistrements de flux LRU, tous lisibles et modifiables via /api/vms/{name}/dataplane/{status,policy,stats,flows} et les sous-commandes zyvorctl dataplane correspondantes. Les mises à jour de politique sont décrites comme des réécritures de cartes BPF en place, avec une brève fenêtre de refus excessif documentée lors de la reconfiguration plutôt qu'une faille de type « tout autoriser ». Trois modes sont documentés : nftables seul (legacy), eBPF sur l'edge VM, et un mode de coexistence Cilium. Une couche Service Fabric distincte fournit l'équilibrage de charge VIP Maglev et des installations connexes. La politique durable réside dans /var/lib/fluxvm/network-policy, avec des programmes et des cartes épinglés sous /sys/fs/bpf/fluxvm. Le passthrough PCI/VFIO générique est exposé via l'API REST pour les GPU et dispositifs similaires. Déploiement Quatre voies documentées existent : bare metal via systemd ou binaire direct avec des scripts d'aide (incluant des flux « ship » en une commande), Docker/Podman Compose pour l'évaluation locale avec /dev/kvm et le réseau hôte, Kubernetes utilisant des DaemonSets hostNetwork privilégiés plus des charts Helm et un script de lab k3s distant, et un mode opérateur seul pour les flux GitOps contre un démon existant. Les exigences Kubernetes listées incluent /dev/kvm sur les nœuds, un niveau de sécurité de pod privilégié et un moteur de conteneurs rootful sur l'hôte de construction. Les identifiants d'administrateur sont générés lors du déploiement et récupérables sur le disque ou depuis le Secret Kubernetes zyvor-fabric-secrets, avec des variables d'environnement disponibles pour les définir ou les réinitialiser. Notes pour l'évaluation Le README contient du matériel comparatif soutenant que l'approche du projet concernant la politique VM-edge est en avance sur libvirt/nftables, le pare-feu via pont partagé, le NAT QEMU en mode utilisateur et les configurations microVM-plus-CNI typiques ; ce sont les affirmations des mainteneurs, et plusieurs chiffres de performance cités (tels que la latence de mise à jour des politiques) sont décrits comme des mesures de laboratoire. L'ensemble de la documentation principale du dépôt couvre le démarrage rapide, Kubernetes, Docker, l'architecture, le réseau, l'UX web, le cycle de vie de l'hôte, la gouvernance et la politique de sécurité. La licence est Apache-2.0.