• # Ca poutre

    Posté par  (site web personnel) . Évalué à 2. Dernière modification le 08 mars 2022 à 09:14.

    J'ai eu l'occasion de bosser avec pour mettre en place une infra multi-tennant. C'est une tuerie.

    Il manquait une seule chose à l'époque : la possibilité de sélectionner quelles ressources sont répliquées sur le cluster hôte.

    Cela permettrait de mutualiser des opérateurs comme TektonCD, ou même celui que he développe Kubirds.

    Faudra que j'aille zieuter si ça a changé.

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

    • [^] # Re: Ca poutre

      Posté par  . Évalué à 3.

      Mais il est obligé de mettre son GROS micro dans le champ ? ;)

      Micro

  • # toy ?

    Posté par  . Évalué à 3.

    L'intérêt d'un namespace est de ne pas avoir à exploiter un cluster K8s.
    L'intérêt d'un cluster K8s est de pouvoir faire ce qu'on veut dessus.
    L'intérêt d'un cluster dans un namespace …

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

    À la rigueur si 1000 clients veulent la simplicité d'un namespace et quelques uns veulent la liberté d'un cluster, cela peut faire sens de ne pas leur déployer un cluster chacun et de les virtualiser.

    Reste que le modèle opérationnel va être compliqué.

    • [^] # Re: toy ?

      Posté par  (site web personnel) . É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

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.