Lien Un Kubernetes dans un Kubernetes dans un Kubernetes dans un Kubernetes dans un Kubernetes dans...

Posté par devnewton 🍺 (site web personnel) le 08 mars 2022 à 09:07.

Étiquettes :

mar.

2022

https://www.vcluster.com/

# Ca poutre

Posté par David Delassus (site web personnel) le 08 mars 2022 à 09:14. É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
- [^] # Re: Ca poutre
  
  Posté par Glandos le 08 mars 2022 à 10:52. Évalué à 3.
  
  Mais il est obligé de mettre son GROS micro dans le champ ? ;)
  - [^] # Re: Ca poutre
    
    Posté par devnewton 🍺 (site web personnel) le 09 mars 2022 à 09:55. Évalué à 7.
    
    Ce n'est pas un micro, c'est son crâne.
    
    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# toy ?

Posté par steph1978 le 08 mars 2022 à 14:22. É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 David Delassus (site web personnel) le 08 mars 2022 à 15:18. É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