À propos du projet
VirtFoundry est une couche IaaS déclarative et cloud-native qui transforme un cluster Kubernetes existant en cloud privé multi-tenant. Il s'appuie sur KubeVirt pour les machines virtuelles et sur Multus pour le réseau, et est distribué sous licence Apache 2.0.
Ce dépôt (virtfoundry/core) contient l'API REST et l'interface web. Les composants associés se trouvent dans des dépôts séparés : virtfoundry/operator fournit les CRD virtfoundry.io et l'opérateur Kubernetes ; virtfoundry/helm-charts contient les charts Helm, la documentation et les scripts de déploiement ; et virtfoundry/terraform-provider-virtfoundry fournit un provider Terraform.
Principales capacités décrites dans le README :
- Multi-tenant : namespaces isolés par tenant.
- Réseau : VPC, sous-réseaux privés, pool optionnel d'IP publiques et groupes de sécurité implémentés via NetworkPolicy.
- Calcul : machines virtuelles KubeVirt, templates, offerings, snapshots de VM et console noVNC.
- Stockage : volumes PVC et snapshots de volumes, avec la réserve qu'un provider CSI VolumeSnapshot est requis (local-path ne suffit pas).
- IAM : utilisateurs, rôles et clés API préfixées vfd_live_.
- Packaging : un chart Helm officiel.
L'installation se fait via Helm. Le quick start documenté installe d'abord le chart de l'opérateur (CRD plus opérateur), puis le chart principal pour l'API et l'UI, tous deux dans le namespace virtfoundry-system, avec le mot de passe root et le secret JWT fournis comme valeurs. Le README indique que le quick start suppose que le cluster dispose déjà de KubeVirt, Multus et CDI, et renvoie à un guide de démarrage rapide et à un guide d'installation pour l'ensemble des prérequis. Pour les snapshots de volumes, une classe de snapshot telle que longhorn doit être configurée.
Pour le développement, l'état de la plateforme peut être stocké soit dans Kubernetes via les CRD virtfoundry.io (store.driver=kubernetes, destiné à la production et à un usage homelab), soit dans un store en mémoire, qui est la valeur par défaut lors de l'exécution du serveur avec go run et ne nécessite aucun cluster. L'exécution contre un cluster nécessite KUBECONFIG pointant vers un cluster où les CRD sont installées. L'UI est développée séparément avec npm.
Le README documente également le modèle produit du projet : un cœur open source sous Apache 2.0 plus des composants entreprise optionnels de Thurler IT, avec un support entreprise couvrant la migration depuis CloudStack ou VMware, le SSO, la facturation et le support SLA. La gouvernance, les maintainers, les adoptants, la roadmap, les exigences CI, l'architecture, le catalogue de templates de VM et un brouillon de candidature au CNCF Sandbox sont tous référencés comme documents séparés dans le dépôt.
Comments
0 people shared their preference · Deer Point appears after 10 participants
Sign in to join the discussion.