• [^] # Re: toy ?

    Posté par (site web personnel) . En réponse au lien Un Kubernetes dans un Kubernetes dans un Kubernetes dans un Kubernetes dans un Kubernetes dans.... Évalué à 4.

    Pour moi on a pas le meilleur des deux comme promis mais le pire des deux.

    Je suis pas vraiment d'accord. L'intérêt d'un cluster dans un namespace c'est plusieurs choses :

    • pouvoir mettre des quotas sur l'utilisation d'un cluster (nombre de pods etc...)
    • pouvoir isoler 2 clients à qui tu fournis une plateforme pour déployer leurs workloads
    • pouvoir créer/supprimer/mettre à jour des clusters à la volée
    • pouvoir contrôler le coût de fonctionnement de ton infra plus précisément

    De plus : https://www.vcluster.com/docs/architecture/synced-resources#sync-other-resources

    Syncing other resources such as deployments, statefulsets and namespaces is usually not needed as those just control lower level resources and since those lower level resources are synced the cluster can function correctly.

    However, there might be cases though were custom syncing of resources might be needed or beneficial. In order to accomplish this, vcluster provides an SDK to develop your own resource syncers as plugins. To find out more, please take a look at the plugins documenation.

    Cela veut dire que tu peux créer un opérateur Kubernetes en mode SaaS :

    • tu installes l'opérateur sur le cluster hôte
    • tu ajoute tes CRDs au vcluster, ainsi que le plugin pour les synchroniser sur le cluster hôte
    • tu fournit un vcluster a tes clients, qui peuvent bénéficier de ton opérateur sans devoir gérer l'installation / la mise à jour / ...
    • derrière, tu scale le cluster hôte, ça scale tout le monde

    C'est d'autant plus intéressant car vcluster ce n'est pas de la virtualisation (c'est pas KinD - Kubernetes in Docker), c'est juste un niveau d'abstraction supplémentaire pour découper proprement les choses.

    https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg