Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • ansible ansible
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 2
    • Issues 2
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • Deployments
    • Deployments
    • Releases
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • ACIDES
  • Hepto
  • ansibleansible
  • Issues
  • #9
Closed
Open
Created Aug 21, 2021 by kaiyou@kaiyouOwner

Tester k3s embedded etcd

Les derniers tests en haute disponibilité sur k3s étaient sur rqlite et assez peu convainquants. Depuis la 1.19 il supporte un etcd embarqué, donc à assez faible overhead RAM a priori, il reste à tester deux choses sur le papier :

  • le fonctionnement de la synchronisation etcd avec des latences de l'ordre de 5-10ms (ce qu'on a entre les noeuds du cluster TeDomum)
  • l'overhead CPU et réseau associé

Dans tous les cas, si on opte pour la solution, il faudra accepter le choix qu'on ne sera plus vraiment compatible avec :

  • des liens à forte latence pour les masters d'un cluster ;
  • des clusters de moins de 3 noeuds ;
  • des clusters avec moins de 4Go de RAM par noeud (un master mange plutôt 600-1000Mo de RAM par rapport à 100-200Mo pour un noeud, on s'était donné maximum 20% d'overhead RAM pour la gestion de cluster et on s'approcherait plutôt de 50% d'overhead avec des masters à 2Go de RAM)

C'est peut-être un choix acceptable mais il faut le mettre sur la table et en discuter :)

Edited Aug 21, 2021 by kaiyou
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking