Ескерту. аударма: бұл материал білім беру жобасынан алынған Kubernetes негізіндегі инфрақұрылымды жобалау кезінде танымал сұраққа жауап болып табылады. Әрбір опцияның артықшылықтары мен кемшіліктерінің егжей-тегжейлі сипаттамасы жобаңыз үшін ең жақсы таңдау жасауға көмектеседі деп үміттенеміз.
TL; DR: жұмыс жүктемелерінің бірдей жинағын бірнеше үлкен кластерлерде (әр кластерде жұмыс жүктемелерінің үлкен саны болады) немесе көптеген шағында (әр кластерде жұмыс жүктемелерінің аз санымен) іске қосуға болады.
Төменде әрбір тәсілдің оң және теріс жақтарын бағалайтын кесте берілген:
Kubernetes қолданбасын іске қосу платформасы ретінде пайдаланған кезде кластерлерді орнатудың күрделілігі туралы бірнеше негізгі сұрақтар жиі туындайды:
- Мен қанша кластерді пайдалануым керек?
- Мен оларды қаншалықты үлкен етіп жасауым керек?
- Әрбір кластер нені қамтуы керек?
Бұл мақалада мен осы сұрақтардың бәріне жауап беруге тырысамын, бұл әр тәсілдің оң және теріс жақтарын талдау.
Сұрақтың қойылуы
Бағдарламалық жасақтаманы әзірлеуші ретінде сіз көптеген қолданбаларды бір уақытта жасап, басқара аласыз.
Бұған қоса, бұл қолданбалардың көптеген даналары әртүрлі орталарда іске қосылуы мүмкін - мысалы, олар болуы мүмкін Dev, сынақ и өнім.
Нәтиже қосымшалар мен орталардың тұтас матрицасы болып табылады:
Қолданбалар және орталар
Жоғарыдағы мысал 3 қолданбаны және 3 ортаны көрсетеді, нәтижесінде барлығы 9 ықтимал опция болады.
Әрбір қолданба данасы басқалардан тәуелсіз жұмыс істеуге болатын дербес орналастыру бірлігі болып табылады.
Осыған назар аударыңыз қолданбалы данасы көптен тұруы мүмкін компоненттері, мысалы, frontend, backend, дерекқор және т.б. Микросервис қолданбасы жағдайында дана барлық микросервистерді қамтиды.
Нәтижесінде Kubernetes пайдаланушыларында бірнеше сұрақтар туындайды:
- Барлық қолданба даналарын бір кластерге орналастыру керек пе?
- Әрбір қолданба данасы үшін бөлек кластер болуы керек пе?
- Немесе жоғарыда аталған тәсілдердің комбинациясы қолданылуы мүмкін бе?
Бұл опциялардың барлығы өміршең, өйткені Kubernetes - пайдаланушының мүмкіндіктерін шектемейтін икемді жүйе.
Міне, кейбір ықтимал жолдар:
- бір үлкен ортақ кластер;
- көптеген шағын жоғары мамандандырылған кластерлер;
- әр қолданбаға бір кластер;
- орта үшін бір кластер.
Төменде көрсетілгендей, алғашқы екі тәсіл опциялар масштабының қарама-қарсы жағында орналасқан:
Бірнеше үлкен кластерлерден (сол жақта) көптеген кішкентайларға дейін (оң жақта)
Тұтастай алғанда, бір кластер, егер оның түйіндері мен түйіндерінің сомасы көбірек болса, екіншісіне қарағанда «үлкен» болып саналады. Мысалы, 10 түйіні және 100 түйіні бар кластер 1 түйіні және 10 түйіні бар кластерден үлкенірек.
Ал, бастайық!
1. Бір үлкен ортақ кластер
Бірінші нұсқа - барлық жұмыс жүктемелерін бір кластерге орналастыру:
Бір үлкен кластер
Бұл тәсілдің шеңберінде кластер әмбебап ретінде пайдаланылады инфрақұрылымдық платформа — сіз жай ғана бар Kubernetes кластерінде қажет нәрсенің бәрін орналастырасыз.
Kubernetes кластердің бөліктерін бір-бірінен логикалық түрде бөлуге мүмкіндік береді, осылайша әрбір қолданба данасы өз аттар кеңістігіне ие болады.
Бұл тәсілдің оң және теріс жақтарын қарастырайық.
+ Ресурстарды тиімді пайдалану
Жалғыз кластермен сізге Kubernetes кластерін іске қосу және басқару үшін қажетті барлық ресурстардың бір ғана көшірмесі қажет.
Мысалы, бұл негізгі түйіндерге қатысты. Әдетте, әрбір Kubernetes кластерінде 3 негізгі түйін болады, сондықтан бір кластер үшін олардың саны сол күйінде қалады (салыстыру үшін 10 кластерге 30 негізгі түйін қажет болады).
Жоғарыда айтылған нәзіктік жүктеме баланстары, кіру контроллері, аутентификация, тіркеу және бақылау жүйелері сияқты бүкіл кластер бойынша жұмыс істейтін басқа қызметтерге де қатысты.
Бір кластерде барлық осы қызметтерді бірден барлық жұмыс жүктемелері үшін пайдалануға болады (бірнеше кластерлердегідей олардың көшірмелерін жасаудың қажеті жоқ).
+ Арзан
Жоғарыда айтылғандардың салдары ретінде, аз кластерлер әдетте арзанырақ болады, өйткені үстеме шығындар жоқ.
Бұл әсіресе негізгі түйіндерге қатысты, олар қалай орналастырылғанына қарамастан (жергілікті немесе бұлтта) айтарлықтай ақша жұмсауы мүмкін.
Кейбір басқарылатын Kubernetes қызметтері, мысалы немесе , басқару қабатын тегін қамтамасыз етіңіз. Бұл жағдайда шығын мәселесі аз өткір.
Әрбір Kubernetes кластерінің жұмысы үшін белгіленген ақы алатын басқарылатын қызметтер де бар (мысалы, ).
+ Тиімді басқару
Бір кластерді басқару бірнеше басқарудан оңайырақ.
Әкімшілік келесі міндеттерді қамтуы мүмкін:
- Kubernetes нұсқасын жаңарту;
- CI/CD құбырын орнату;
- CNI плагинін орнату;
- пайдаланушының аутентификация жүйесін орнату;
- қол жеткізу контроллерін орнату;
және басқа да көптеген…
Бір кластер жағдайында мұның барлығын бір рет орындауға тура келеді.
Көптеген кластерлер үшін операцияларды бірнеше рет қайталауға тура келеді, бұл процестегі жүйелілік пен жүйелілікті қамтамасыз ету үшін процестер мен құралдарды кейбір автоматтандыруды қажет етуі мүмкін.
Ал енді кемшіліктер туралы бірнеше сөз.
− Бір сәтсіздік нүктесі
Бас тартқан жағдайда жалғыз кластер бірден жұмысын тоқтатады барлық жұмыс жүктемелері!
Істің дұрыс болмауының көптеген жолдары бар:
- Kubernetes-ті жаңарту күтпеген жанама әсерлерге әкеледі;
- Кластерге қатысты құрамдас (мысалы, CNI плагині) күткендей жұмыс істемей бастайды;
- кластер құрамдастарының бірі дұрыс конфигурацияланбаған;
- негізгі инфрақұрылымдағы сәтсіздік.
Осындай оқиғалардың бірі ортақ кластерде орналастырылған барлық жұмыс жүктемелеріне елеулі зақым келтіруі мүмкін.
− Қатты оқшаулау жоқ
Ортақ кластерде іске қосу қолданбалардың аппараттық құралдарды, желілік мүмкіндіктерді және кластер түйіндеріндегі операциялық жүйені ортақ пайдалануын білдіреді.
Бір мағынада бір түйінде жұмыс істейтін екі түрлі қолданбасы бар екі контейнер бір операциялық жүйе ядросымен жұмыс істейтін бір машинада жұмыс істейтін екі процесс сияқты.
Linux контейнерлері оқшаулаудың қандай да бір түрін қамтамасыз етеді, бірақ ол виртуалды машиналармен қамтамасыз етілгендей күшті емес. Негізінде, контейнердегі процесс хост операциялық жүйесінде орындалатын процесс болып табылады.
Бұл қауіпсіздік мәселесі болуы мүмкін: бұл реттеу теориялық тұрғыдан байланысты емес қолданбалардың бір-бірімен байланысуына мүмкіндік береді (әдейі немесе кездейсоқ).
Сонымен қатар, Kubernetes кластеріндегі барлық жұмыс жүктемелері кейбір кластерлік қызметтерді ортақ пайдаланады, мысалы - бұл қолданбаларға кластердегі басқа қолданбалардың қызметтерін табуға мүмкіндік береді.
Жоғарыда аталған барлық тармақтар қолданбаның қауіпсіздік талаптарына байланысты әртүрлі мағынаға ие болуы мүмкін.
Kubernetes сияқты қауіпсіздік мәселелерін болдырмау үшін әртүрлі құралдарды ұсынады и . Дегенмен, оларды дұрыс орнату белгілі бір тәжірибені қажет етеді, сонымен қатар олар барлық қауіпсіздік саңылауларын жабуға қабілетті емес.
Kubernetes бастапқыда арнайы жасалғанын есте сақтау маңызды бөлісу, үшін емес оқшаулау және қауіпсіздік.
− Қатаң көп жалдау шартының жоқтығы
Kubernetes кластеріндегі ортақ ресурстардың көптігін ескере отырып, әртүрлі қолданбалар бір-бірінің саусақтарын басудың көптеген жолдары бар.
Мысалы, қолданба ортақ ресурсты монополиялауы мүмкін (мысалы, орталық процессор немесе жад) және бір түйінде жұмыс істейтін басқа қолданбаларға оған кіруге тыйым салуы мүмкін.
Кубернетес бұл әрекетті басқарудың әртүрлі механизмдерін ұсынады, мысалы («Сондай-ақ мақаланы қараңыз»" - шамамен. аудар.), и . Дегенмен, қауіпсіздік жағдайындағыдай, олардың конфигурациясы өте тривиальды емес және олар барлық күтпеген жанама әсерлердің алдын ала алмайды.
− Пайдаланушылардың үлкен саны
Бір кластер жағдайында оған көптеген адамдар үшін рұқсатты ашу керек. Олардың саны неғұрлым көп болса, олардың бірдеңені «сындыру» қаупі соғұрлым жоғары болады.
Кластер ішінде кім нені пайдалана алатынын басқара аласыз («бапты қараңыз»" - шамамен. аудар.). Дегенмен, бұл пайдаланушылардың жауапкершілік аймағының шекарасында бірдеңені «бұзуына» кедергі болмайды.
− Кластерлер шексіз өсе алмайды
Барлық жұмыс жүктемелері үшін пайдаланылатын кластер айтарлықтай үлкен болуы мүмкін (түйіндер мен түйіндер саны бойынша).
Бірақ бұл жерде тағы бір мәселе туындайды: Кубернетестегі кластерлер шексіз өсе алмайды.
Кластер өлшемі бойынша теориялық шектеу бар. Кубернетесте бұл шамамен .
Дегенмен, нақты өмірде проблемалар әлдеқайда ертерек басталуы мүмкін - мысалы, жай ғана .
Мәселе мынада, үлкен кластерлер Kubernetes басқару қабатына үлкен жүктеме түсіреді. Басқаша айтқанда, кластерді қосу және тиімді жұмыс істеу үшін мұқият баптау қажет.
Бұл мәселе түпнұсқа блогтағы «деп аталатын қатысты мақалада қарастырылған.«.
Бірақ қарама-қарсы көзқарасты қарастырайық: көптеген шағын кластерлер.
2. Көптеген шағын, мамандандырылған кластерлер
Бұл тәсілмен сіз орналастыратын әрбір элемент үшін бөлек кластерді пайдаланасыз:
Көптеген шағын кластерлер
Осы баптың мақсаттары үшін орналастыруға болатын элемент қолданбаның данасына сілтеме жасайды - мысалы, бөлек қолданбаның әзірлеуші нұсқасы.
Бұл стратегия Kubernetes-ті мамандандырылған ретінде пайдаланады орындау уақыты жеке қолдану даналары үшін.
Бұл тәсілдің оң және теріс жақтарын қарастырайық.
+ Шектеулі «жарылыс радиусы»
Кластер сәтсіз болғанда, теріс салдар тек сол кластерде орналастырылған жұмыс жүктемелерімен шектеледі. Барлық басқа жұмыс жүктемелері өзгеріссіз қалады.
+ Оқшаулау
Жеке кластерлерде орналастырылған жұмыс жүктемелері процессор, жад, операциялық жүйе, желі немесе басқа қызметтер сияқты ресурстарды ортақ пайдаланбайды.
Нәтиже - байланыссыз қолданбалар арасындағы тығыз оқшаулау, бұл олардың қауіпсіздігі үшін пайдалы болуы мүмкін.
+ Пайдаланушылар саны аз
Әрбір кластерде жұмыс жүктемелерінің шектеулі жиынтығы ғана бар екенін ескере отырып, оған кіру рұқсаты бар пайдаланушылар саны азаяды.
Кластерге неғұрлым аз адамдар қол жеткізе алса, бір нәрсенің «бұзылу» қаупі соғұрлым аз болады.
Кемшіліктерді қарастырайық.
− ресурстарды тиімсіз пайдалану
Жоғарыда айтылғандай, әрбір Kubernetes кластері басқару ресурстарының белгілі бір жинағын қажет етеді: негізгі түйіндер, басқару деңгейінің құрамдастары, бақылау және журналға тіркеу шешімдері.
Кішігірім кластерлер саны көп болған жағдайда, ресурстардың үлкен үлесі басшылыққа бөлінуі керек.
− Қымбат
Ресурстарды тиімсіз пайдалану автоматты түрде жоғары шығындарға әкеледі.
Мысалы, бірдей есептеу қуаты бар үшеуінің орнына 30 негізгі түйінді ұстау міндетті түрде шығындарға әсер етеді.
− Басқарудағы қиындықтар
Бірнеше Kubernetes кластерін басқару бір ғана басқарудан әлдеқайда қиын.
Мысалы, әрбір кластер үшін аутентификация мен авторизацияны конфигурациялау қажет болады. Kubernetes нұсқасы да бірнеше рет жаңартылуы керек.
Осы тапсырмалардың барлығын тиімдірек ету үшін сізге автоматтандыруды пайдалану қажет болуы мүмкін.
Енді азырақ экстремалды сценарийлерді қарастырайық.
3. Әр қолданбаға бір кластер
Бұл тәсілде сіз белгілі бір қолданбаның барлық даналары үшін бөлек кластер жасайсыз:
Әр қолданбаға кластер
Бұл жолды «қағидасының жалпылауы» деп санауға болады.әр командаға бөлек кластер», өйткені әдетте инженерлер тобы бір немесе бірнеше қосымшаларды әзірлейді.
Бұл тәсілдің оң және теріс жақтарын қарастырайық.
+ Кластерді қолданбаға реттеуге болады
Бағдарламаның арнайы қажеттіліктері болса, оларды басқа кластерлерге әсер етпестен кластерде іске асыруға болады.
Мұндай қажеттіліктерге GPU қызметкерлері, белгілі CNI плагиндері, қызмет көрсету торы немесе басқа қызмет кіруі мүмкін.
Әрбір кластерді онда жұмыс істейтін қолданбаға бейімдеуге болады, сонда ол тек қажет нәрсені қамтиды.
− Бір кластерде әртүрлі орталар
Бұл тәсілдің кемшілігі әртүрлі орталардағы қолданба даналарының бір кластерде бірге болуы болып табылады.
Мысалы, қолданбаның өнім нұсқасы әзірлеуші нұсқасы сияқты бір кластерде жұмыс істейді. Бұл сонымен қатар әзірлеушілер қолданбаның өндірістік нұсқасы жұмыс істейтін бір кластерде жұмыс істейтінін білдіреді.
Егер әзірлеушілердің әрекеттеріне немесе әзірлеуші нұсқасындағы ақауларға байланысты кластерде сәтсіздік орын алса, өнім нұсқасы да зардап шегуі мүмкін - бұл тәсілдің үлкен кемшілігі.
Ақырында, біздің тізімдегі соңғы сценарий.
4. Әр ортаға бір кластер
Бұл сценарий әрбір орта үшін бөлек кластерді бөлуді қамтиды:
Әр ортаға бір кластер
Мысалы, сізде кластерлер болуы мүмкін Dev, сынақ и өнім, онда сіз белгілі бір ортаға арналған қолданбаның барлық даналарын іске қосасыз.
Міне, осы тәсілдің оң және теріс жақтары.
+ Өндіріс ортасын оқшаулау
Бұл тәсілдің аясында барлық орталар бір-бірінен оқшауланған. Дегенмен, іс жүзінде бұл әсіресе өндірістік ортада маңызды.
Қолданбаның өндірістік нұсқалары енді басқа кластерлер мен орталарда болып жатқан жағдайға тәуелсіз.
Осылайша, әзірлеу кластерінде кенеттен мәселе туындаса, қолданбалардың шығарылған нұсқалары ештеңе болмағандай жұмысын жалғастырады.
+ Кластерді қоршаған ортаға реттеуге болады
Әрбір кластерді қоршаған ортаға реттеуге болады. Мысалы, сіз:
- әзірлеушілер кластерінде әзірлеу және жөндеу құралдарын орнату;
- кластерде сынақ құрылымдары мен құралдарын орнату сынақ;
- кластердегі қуаттырақ аппараттық құралдар мен желілік арналарды пайдаланыңыз өнім.
Бұл қолданбаларды әзірлеудің де, жұмыс істеудің де тиімділігін арттыруға мүмкіндік береді.
+ Өндірістік кластерге қол жеткізуді шектеу
Өнім кластерімен тікелей жұмыс істеу қажеттілігі сирек туындайды, сондықтан оған қол жеткізе алатын адамдар шеңберін айтарлықтай шектей аласыз.
Одан әрі қарай жүріп, адамдардың осы кластерге кіруіне мүлдем тыйым сала аласыз және автоматтандырылған CI/CD құралын пайдаланып барлық орналастыруларды орындай аласыз. Мұндай тәсіл адам қателерінің қаупін ең маңызды жерде барынша азайтады.
Ал енді кемшіліктер туралы бірнеше сөз.
− Қолданбалар арасында оқшаулану жоқ
Әдістің негізгі кемшілігі – қолданбалы бағдарламалар арасында аппараттық құралдар мен ресурстарды оқшаулаудың болмауы.
Байланысты емес қолданбалар кластер ресурстарын ортақ пайдаланады: жүйе өзегі, процессор, жад және кейбір басқа қызметтер.
Жоғарыда айтылғандай, бұл ықтимал қауіпті болуы мүмкін.
− Қолданбаға тәуелділіктерді локализациялау мүмкін емес
Қолданбаның арнайы талаптары болса, олар барлық кластерлерде қанағаттандырылуы керек.
Мысалы, егер қолданбаға GPU қажет болса, онда әрбір кластерде GPU бар кем дегенде бір жұмысшы болуы керек (тіпті оны тек сол қолданба пайдаланса да).
Нәтижесінде біз жоғары шығындар мен ресурстарды тиімсіз пайдалану қаупін тудырамыз.
қорытынды
Қолданбалардың белгілі бір жиынтығы болса, оларды бірнеше үлкен кластерлерге немесе көптеген шағын кластерге орналастыруға болады.
Мақалада бір жаһандық кластерден бірнеше шағын және жоғары мамандандырылғанға дейінгі әртүрлі тәсілдердің оң және теріс жақтары талқыланады:
- бір үлкен жалпы кластер;
- көптеген шағын жоғары мамандандырылған кластерлер;
- әр қолданбаға бір кластер;
- орта үшін бір кластер.
Сонымен, қандай тәсілді қолдану керек?
Әдеттегідей, жауап пайдалану жағдайына байланысты: әртүрлі тәсілдердің жақсы және жаман жақтарын өлшеп, ең оңтайлы нұсқаны таңдау керек.
Дегенмен, таңдау жоғарыда келтірілген мысалдармен шектелмейді - олардың кез келген комбинациясын пайдалануға болады!
Мысалы, әр топ үшін бірнеше кластер ұйымдастыруға болады: әзірлеу кластері (орталар болады). Dev и сынақ) және кластер үшін өнім (өндірістік орта қайда орналасатын болады).
Осы мақаладағы ақпаратқа сүйене отырып, белгілі бір сценарийге сәйкес артықшылықтар мен кемшіліктерді оңтайландыруға болады. Іске сәт!
PS
Біздің блогта да оқыңыз:
- ««;
- ««;
- ««;
- ««.
Ақпарат көзі: www.habr.com