Эй Хабр!
Біз Exness платформасының командасын ұсынамыз. Бұл туралы бұрын әріптестеріміз мақала жазған болатын . Бүгін біз Kubernetes-ке көшіру қызметтері тәжірибемізбен бөліскіміз келеді.
Алдымен, не талқыланатынын жақсы түсіну үшін сізге бірнеше сандарды ұсынамыз:
- Біздің әзірлеу бөлімі 100+ адамнан тұрады, оның ішінде өзін-өзі қамтамасыз ететін QA, DevOps және Scrum процестері бар 10-нан астам әртүрлі командалар. Әзірлеу стегі - Python, PHP, C++, Java және Golang.
- Сынақ және өндірістік орталардың көлемі әрқайсысы шамамен 2000 контейнерді құрайды. Олар Rancher v1.6 нұсқасын өздерінің виртуализациясында және VMware астында іске қосуда.
Мотивация
Олар айтқандай, ештеңе мәңгілікке созылмайды және Rancher 1.6 нұсқасын қолдаудың аяқталғанын бұрыннан хабарлады. Иә, үш жылдан астам уақыт ішінде біз оны қалай дайындауды және туындаған мәселелерді шешуді үйрендік, бірақ бізде ешқашан түзетілмейтін мәселелер жиі кездеседі. Rancher 1.6-да құқықтарды берудің сүйектендірілген жүйесі бар, онда сіз бәрін дерлік жасай аласыз немесе ештеңе жасай аласыз.
Меншікті виртуалдандыру деректерді сақтау мен оның қауіпсіздігіне үлкен бақылауды қамтамасыз еткенімен, ол компанияның тұрақты өсуін, жобалардың санын және оларға қойылатын талаптарды ескере отырып, қабылдау қиын болатын операциялық шығындарды жүктеді.
Біз IaC стандарттарын ұстанғымыз келді және қажет болған жағдайда қуаттылықты кез келген географиялық жерде және жеткізуші құлпысыз тез алуды, сондай-ақ одан тез бас тартуды қалаймыз.
алғашқы қадамдар
Ең алдымен, біз командаларға жылдамырақ даму цикліне ие болуға және қуат беретін платформамен өзара әрекеттесу үшін операциялық шығындарды азайтуға мүмкіндік беретін заманауи технологиялар мен шешімдерге сенгіміз келді.
Әрине, бірінші ойымызға Кубернетес келді, бірақ біз қуанбадық және оның дұрыс таңдау екенін білу үшін аздап зерттедік. Біз тек ашық бастапқы шешімдерді бағаладық және әділетсіз шайқаста Кубернетес сөзсіз жеңді.
Келесі кезекте кластерлерді құру құралын таңдау мәселесі туындады. Біз ең танымал шешімдерді салыстырдық: kops, kubespray, kubeadm.
Бастау үшін, kubeadm бізге «велосипедті» ойлап табушы сияқты тым күрделі жол болып көрінді, ал копстердің икемділігі жеткіліксіз болды.
Ал жеңімпаз:
Біз өз виртуализациямызбен және AWS-пен тәжірибе жасай бастадық, барлығы бірдей «кластерді» бөлісетін бұрынғы ресурстарды басқару үлгісіне шамамен ұқсас нәрсені қайта жасауға тырыстық. Енді бізде 10 шағын виртуалды машинадан тұратын бірінші кластер бар, олардың бірнешеуі AWS-де орналасқан. Біз командаларды сонда көшіруге тырыстық, бәрі «жақсы» болып көрінді және оқиға аяқталуы мүмкін, бірақ...
Бірінші мәселелер
Ansible - kubespray негізінде құрылған, ол IaC-ді орындауға мүмкіндік беретін құрал емес: түйіндерді іске қосу/пайдаланудан шығару кезінде үнемі бірдеңе дұрыс болмады және қандай да бір араласу қажет болды, ал әр түрлі операциялық жүйелерді пайдаланған кезде ойын кітабы басқаша әрекет етті. . Кластердегі командалар мен түйіндер саны көбейген сайын біз ойын кітапшасының аяқталуы ұзағырақ және ұзағырақ болатынын байқай бастадық, нәтижесінде біздің рекордымыз 3,5 сағат болды, сіздікі ше? 🙂
Және kubespray жай ғана Ansible сияқты көрінеді, және бәрі бір қарағанда түсінікті, бірақ:
Саяхаттың басында қуаттарды тек AWS және виртуализацияда іске қосу міндеті тұрды, бірақ содан кейін жиі болатындай талаптар өзгерді.
Осыны ескере отырып, біздің ресурстарды бір оркестрлік жүйеге біріктірудің ескі үлгісі сәйкес келмейтіні белгілі болды - кластерлер өте алыс және әртүрлі провайдерлер басқаратын жағдайда.
Әрі қарай. Барлық командалар бір кластер ішінде жұмыс істегенде, дұрыс орнатылмаған NodeSelectors әртүрлі қызметтер басқа команданың «бөтен» хостына ұшып, сол жерде ресурстарды пайдалана алады, ал егер ластану орнатылған болса, сол немесе басқа қызмет жұмыс істемейді деген тұрақты сұраулар болды, адам факторына байланысты дұрыс бөлінбеген. Тағы бір мәселе, әсіресе қызметтерді түйіндер бойынша таратудағы проблемаларды ескере отырып, шығындарды есептеу болды.
Қызметкерлерге құқық беру туралы бөлек әңгіме болды: әр команда кластердің «басшысы» болғысы келді және оны толығымен басқарғысы келді, бұл толық күйреуге әкелуі мүмкін, өйткені командалар негізінен бір-бірінен тәуелсіз.
Не істесем екен?
Жоғарыда айтылғандарды және командалардың неғұрлым тәуелсіз болу тілектерін ескере отырып, біз қарапайым қорытынды жасадық: бір команда - бір кластер.
Сонымен бізде екіншісі бар:
Содан кейін үшінші кластер:
Содан кейін біз ойлана бастадық: бір жылдан кейін біздің командаларда бірнеше кластер болады делік? Әртүрлі географиялық аймақтарда, мысалы, немесе әртүрлі провайдерлердің бақылауында ма? Олардың кейбіреулері кейбір сынақтар үшін уақытша кластерді жылдам орналастыруды қалайды.
Толық Кубернетес келеді! Бұл MultiKubernetes-тің бір түрі, белгілі болды.
Сонымен бірге, бәрімізге қандай да бір түрде осы кластерлердің барлығын сақтау, оларға қол жеткізуді оңай басқару, сондай-ақ қолмен араласусыз жаңаларын құру және ескілерін жою қажет болады.
Кубернетес әлеміндегі саяхатымыздың басынан бері біраз уақыт өтті және біз қол жетімді шешімдерді қайта қарауды шештік. Ол нарықта бұрыннан бар екені белгілі болды - Rancher 2.2.
Зерттеуіміздің бірінші кезеңінде Rancher Labs 2-нұсқаның алғашқы шығарылымын жасап қойған болатын, бірақ оны бірнеше параметрлері бар сыртқы тәуелділіксіз контейнерді іске қосу немесе ресми HELM диаграммасын пайдалану арқылы өте тез көтеруге болатын болса да, бұл өрескел болып көрінді. бізге, және біз бұл шешімге сене алатынымызды білмедік, ол әзірленеді ме, әлде тез бас тартылады ма. UI-дегі кластер = кликтер парадигмасы да бізге сәйкес келмеді және біз RKE-ге қосылғымыз келмеді, өйткені бұл өте тар бағытталған құрал.
Rancher 2.2 нұсқасы әлдеқашан жұмыс істейтін көрініске ие болды және алдыңғыларымен бірге көптеген сыртқы провайдерлермен интеграция, құқықтарды таратудың бір нүктесі және kubeconfig файлдары, kubectl іске қосу сияқты көптеген қызықты мүмкіндіктерге ие болды. пайдаланушы интерфейсіндегі құқықтарыңыз бар кескін, кірістірілген аттар кеңістігі, яғни жобалар.
Сондай-ақ Rancher 2 айналасында қауымдастық құрылды және оны басқару үшін HashiCorp Terraform деп аталатын провайдер құрылды, бұл бізге бәрін біріктіруге көмектесті.
Не болды
Нәтижесінде, біз Rancher іске қосатын бір шағын кластерге қол жеткіздік, оған барлық басқа кластерлерге, сондай-ақ оған қосылған көптеген кластерлерге қол жеткізуге болады, олардың кез келгеніне қол жеткізу ldap каталогына пайдаланушыны қосу сияқты ғана рұқсат етілуі мүмкін. ол қай жерде орналасқан және қандай провайдердің ресурстарын пайдаланады.
gitlab-ci және Terraform көмегімен бұлттық провайдерлерде немесе жеке инфрақұрылымымызда кез келген конфигурацияның кластерін жасауға және оларды Rancher-ге қосуға мүмкіндік беретін жүйе жасалды. Мұның бәрі IaC стилінде жасалады, мұнда әрбір кластер репозиториймен сипатталады және оның күйі нұсқаланады. Сонымен қатар, модульдердің көпшілігі сыртқы репозитарийлерден қосылған, осылайша айнымалы мәндерді беру немесе даналар үшін теңшелетін конфигурацияңызды сипаттау ғана қалады, бұл код қайталану пайызын азайтуға көмектеседі.
Әрине, біздің саяхатымыз аяқталуға жақын және әлі де көптеген қызықты міндеттер бар, мысалы, кез келген кластерлердің журналдарымен және метрикасымен жұмыс істеудің бір нүктесі, сервистік тор, мультикластерде жүктемелерді басқаруға арналған гитоптар және т.б. Біздің тәжірибеміз сізге қызықты болады деп үміттенеміз!
Мақаланы А.Антипов, А.Гануш, платформа инженерлері жазған.
Ақпарат көзі: www.habr.com