Čau Habr!
Zastupujeme tým platformy Exness. Již dříve naši kolegové napsali článek o . Dnes se chceme podělit o naše zkušenosti s migrací služeb na Kubernetes.
Pro začátek vám nabízíme několik čísel pro lepší pochopení toho, o čem bude řeč:
- Naše vývojové oddělení se skládá z více než 100 lidí, včetně více než 10 různých týmů se soběstačnými procesy QA, DevOps a Scrum. Vývojový zásobník - Python, PHP, C++, Java a Golang.
- Velikost testovacího a produkčního prostředí je přibližně 2000 kontejnerů. Používají Rancher v1.6 na vlastní virtualizaci a pod VMware.
Motivace
Jak se říká, nic netrvá věčně a Rancher oznámil konec podpory verze 1.6 už docela dávno. Ano, za více než tři roky jsme se ho naučili připravovat a řešit vzniklé problémy, ale stále častěji se potýkáme s problémy, které se nikdy nenapraví. Rancher 1.6 má také zkostnatělý systém vydávání práv, kde buď můžete dělat téměř vše, nebo nic.
Proprietární virtualizace sice poskytovala větší kontrolu nad datovým úložištěm a jejich bezpečností, ale vyžadovala provozní náklady, které bylo obtížné akceptovat s ohledem na neustálý růst společnosti, množství projektů a požadavků na ně.
Chtěli jsme dodržovat standardy IaC a v případě potřeby získat kapacitu rychle, v jakékoli geografické lokalitě a bez uzamčení dodavatele, a také být schopni ji rychle opustit.
První kroky
V první řadě jsme se chtěli spolehnout na moderní technologie a řešení, které by týmům umožnily rychlejší vývojový cyklus a minimalizovaly provozní náklady na interakci s platformou, která poskytuje napájení.
Samozřejmě, první věc, která nás napadla, byl Kubernetes, ale nebyli jsme nadšení a provedli jsme malý průzkum, abychom zjistili, zda je to správná volba. Hodnotili jsme pouze opensource řešení a v neférové bitvě Kubernetes bezpodmínečně zvítězil.
Následovala otázka výběru nástroje pro vytváření clusterů. Porovnali jsme nejoblíbenější řešení: kops, kubespray, kubeadm.
Pro začátek se nám zdálo, že kubeadm je příliš komplikovaná cesta, spíše jako jakýsi vynálezce „kola“ a kops neměl dostatečnou flexibilitu.
A vítězem se stal:
Začali jsme experimentovat s naší vlastní virtualizací a AWS a snažili jsme se znovu vytvořit něco zhruba podobného našemu předchozímu vzoru správy zdrojů, kde všichni sdíleli stejný „shluk“. A nyní máme náš první cluster 10 malých virtuálních strojů, z nichž několik je umístěno v AWS. Začali jsme tam zkoušet migrovat týmy, vše se zdálo být „dobré“ a příběh mohl být dokončen, ale...
První problémy
Ansible je to, na čem je kubespray postaven, není to nástroj, který vám umožní sledovat IaC: při zprovozňování/vyřazování uzlů se neustále něco pokazilo a byl vyžadován nějaký zásah a při použití různých OS se playbook choval jinak. . Jak počet týmů a uzlů v clusteru rostl, začali jsme si všímat, že dokončení playbooku trvalo déle a déle, a v důsledku toho byl náš rekord 3,5 hodiny, co váš? 🙂
A zdá se, že kubespray je jen Ansible a vše je na první pohled jasné, ale:
Na začátku cesty bylo úkolem spouštět kapacity pouze v AWS a na virtualizaci, ale pak, jak se často stává, se požadavky změnily.
Ve světle toho se ukázalo, že náš starý model spojování zdrojů do jednoho orchestračního systému nebyl vhodný – v případě, kdy jsou clustery velmi vzdálené a jsou spravovány různými poskytovateli.
Dále více. Když všechny týmy pracují ve stejném clusteru, různé služby s nesprávně nainstalovanými NodeSelectors by mohly létat na „cizího“ hostitele jiného týmu a využívat tam zdroje, a pokud bylo nastaveno poskvrnění, neustále se objevovaly požadavky, že ta či ona služba nefunguje. není správně distribuován kvůli lidskému faktoru. Dalším problémem byl výpočet nákladů, zejména s ohledem na problémy s distribucí služeb mezi uzly.
Samostatným příběhem bylo vydávání práv zaměstnancům: každý tým chtěl být „v čele“ klastru a kompletně jej řídit, což by mohlo způsobit úplný kolaps, protože týmy jsou na sobě v podstatě nezávislé.
Co dělat?
S přihlédnutím k výše uvedenému a přání týmů být nezávislejší jsme učinili jednoduchý závěr: jeden tým – jeden cluster.
Takže máme druhý:
A pak třetí shluk:
Pak jsme začali přemýšlet: řekněme, že za rok budou mít naše týmy více než jeden cluster? Například v různých geografických oblastech nebo pod kontrolou různých poskytovatelů? A někteří z nich budou chtít mít možnost rychle nasadit dočasný cluster pro některé testy.
Přišel by plný Kubernetes! Ukázalo se, že jde o nějaký druh MultiKubernetes.
Všechny tyto clustery přitom budeme muset všichni nějak udržovat, umět k nim snadno spravovat přístupy, stejně jako vytvářet nové a vyřazovat staré bez ručního zásahu.
Od začátku naší cesty světem Kubernetes uplynul nějaký čas a my jsme se rozhodli znovu prozkoumat dostupná řešení. Ukázalo se, že na trhu již existuje - Rancher 2.2.
V první fázi našeho výzkumu Rancher Labs již provedly první vydání verze 2, ale ačkoli to bylo možné velmi rychle zvýšit spuštěním kontejneru bez externích závislostí s několika parametry nebo použitím oficiálního diagramu HELM, zdálo se to hrubé. k nám a nevěděli jsme, zda se na toto rozhodnutí můžeme spolehnout, zda bude rozvíjeno nebo rychle opuštěno. Paradigma cluster = clicks v samotném uživatelském rozhraní nám také nevyhovovalo a nechtěli jsme se vázat na RKE, protože jde o poměrně úzce zaměřený nástroj.
Verze Rancher 2.2 již měla funkčnější vzhled a spolu s předchozími měla hned z krabice spoustu zajímavých funkcí, jako je integrace s mnoha externími poskytovateli, jednotné místo distribuce práv a souborů kubeconfig, spuštění kubectl obrázek s vašimi právy v uživatelském rozhraní, vnořené jmenné prostory aka projekty.
Kolem Ranchera 2 už také vznikla komunita a pro její správu byl vytvořen poskytovatel HashiCorp Terraform, který nám pomohl dát vše dohromady.
Co se stalo
Výsledkem bylo, že jsme skončili s jedním malým clusterem se systémem Rancher, který je přístupný všem ostatním clusterům a také mnoha clusterům, které jsou k němu připojeny, přičemž přístup ke kterémukoli z nich lze udělit stejně jednoduše jako přidání uživatele do adresáře ldap, bez ohledu na kde se nachází a jaké zdroje poskytovatele využívá.
Pomocí gitlab-ci a Terraform byl vytvořen systém, který umožňuje vytvořit cluster libovolné konfigurace u cloudových poskytovatelů nebo vlastní infrastruktury a připojit je k Rancheru. To vše se děje ve stylu IaC, kde je každý cluster popsán úložištěm a jeho stav je verzován. Zároveň je většina modulů připojena z externích úložišť, takže zbývá pouze předat proměnné nebo popsat vaši vlastní konfiguraci pro instance, což pomáhá snížit procento opakování kódu.
Naše cesta samozřejmě zdaleka nekončí a stále je před námi mnoho zajímavých úkolů, jako je jeden pracovní bod s logy a metrikami libovolných clusterů, servisní síť, gitopy pro správu zátěží v multiclusteru a mnoho dalšího. Doufáme, že vás naše zkušenost zaujme!
Článek napsali A. Antipov, A. Ganush, Platform Engineers.
Zdroj: www.habr.com