23 вересня 20.00 МСК Сергій Бондарєв проведе безкоштовний вебінар «», де розповість, як готують kubespray, щоб вийшло швидко, ефективно та відмово стійко.
Сергій Бондарєв розповість відмінність оригінальної версії та нашого форку:
Відмінність оригінальної версії та нашого форку.
Ті, хто з кубспреєм вже стикався, напевно зараз дивуються, чому я kubeadm протиставляю кубспрею, адже кубспрей для створення кластера якраз і викликає кубадм і на перший погляд виглядає як скрипт установки пакетів та автоматизованого запуску.
Але так було не завжди, спочатку кубспрей встановлював усі компоненти самостійно:
- збирав кластер, etcd;
- встановлював кублети, генерував сертифікати, конфіги та токени доступу для статик подів контролплейну та інших службових компонентів;
- створював сервіс акаунти для робочих вузлів та підключав їх до кластера.
Та позаминулого року вони цей функціонал випилили, залишивши лише кубадм. Котрий на той час був не дуже. Мені стало прикро і я зробив свій форк, у якому зберіг класичний режим установки, і власне тепер підтримую цей форк у актуальному стані, чері-пікаючи комміти з оригінального кубспрею до себе. Принагідно допилюючи класичний режим під нові зміни.
У результаті різниця між кластерами, створеними моїм форком та оригінальним – це kube-proxy та терміни дії сертифікатів.
У моєму форку все залишилося, як було раніше — куб-проксі запускається, як статик під сертифікати виписуються на 100 років.
У Kubeadm куб-проксі запускається, як daemonset, а сертифікати виписуються на 1 рік, і їх треба періодично продовжувати. kubeadm нарешті навчився це робити однією командою.
Різниця невелика, і на сьогодні ми використовуємо обидва варіанти.
Особливості (недоліки) при промисловій експлуатації:
Сценарій універсальний, тож не дуже швидкий. Власний можна значно прискорити, викинувши перевірки, запускаючись із готового образу.
Сценарій складний, є нелогічні місця, важка спадщина легації. Встановлення дод. контролерів та софту через кубспрей - хороша для навчання та тестів. У пром. експлуатації залежати від кубспрею не дуже здорова ідея, плюс оновлення софту реалізовано методом "убив-зробив новий" - означає перерву в обслуговуванні.
Може додавати лише робочі вузли, з майстрами є деякі нюанси із сертифікатами, і сценарій не відпрацьовує всіх можливих проблем, які можуть виникнути.
Наприклад, у мене була проблема з кубадмом, коли він падав у момент додавання другого і третього майстра, і після цього кубспрей робив kubeadm reset на вузлі, і пробував додати майстер ще раз.
Ось тільки проблема була в тому, що до моменту збою другий інстанс etcd вже встигав зареєструватися, і так як він теж видалявся після ресета, то отримували кошмар кластер etcd з двох вузлів, один з яких видалили, а другий більше не приймає клієнтів. У результаті кластер помер, не народившись.
Opensource як він є.
Все це і багато іншого на безкоштовному вебінарі23 вересня 20.00 МСК.
Приєднуйтесь!
Джерело: habr.com