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