Эскертүү. котормо.: бул материал билим берүү долбоорунан алынган Kubernetes негизиндеги инфраструктураны долбоорлоодо популярдуу суроого жооп. Ар бир варианттын жакшы жана жаман жактарынын кеңири сыпаттамалары сиздин долбооруңуз үчүн эң жакшы тандоого жардам берет деп үмүттөнөбүз.
TL; DR: бир эле иш жүктөмүнүн топтомун бир нече чоң кластерлерде (ар бир кластерде көп сандагы жумуш жүктөмдөрү болот) же көптөгөн кичинекейлерде (ар бир кластерде аз сандагы иш жүктөмдөрү менен) иштетүүгө болот.
Төмөндө ар бир ыкманын жакшы жана жаман жактарын баалаган таблица келтирилген:
Kubernetesти тиркемелерди иштетүү үчүн платформа катары колдонууда кластерлерди орнотуунун татаалдыктары жөнүндө бир нече негизги суроолор пайда болот:
- Мен канча кластер колдонушум керек?
- Мен аларды канчалык чоң кылышым керек?
- Ар бир кластер эмнени камтышы керек?
Бул макалада мен ар бир ыкманын жакшы жана жаман жактарын талдоо менен ушул суроолордун баарына жооп берүүгө аракет кылам.
Суроонун билдирүүсү
Программалык камсыздоону иштеп чыгуучу катары сиз бир эле учурда көптөгөн тиркемелерди иштеп чыгып, иштетесиз.
Мындан тышкары, бул колдонмолордун көптөгөн учурлары ар кандай чөйрөдө иштеши мүмкүн - мисалы, булар болушу мүмкүн ишт.ч., текшерүү и продукт.
Натыйжада колдонмолордун жана чөйрөлөрдүн бүтүндөй матрицасы:
Колдонмолор жана чөйрөлөр
Жогорудагы мисал 3 тиркемени жана 3 чөйрөнү билдирет, натыйжада жалпысынан 9 мүмкүн болгон вариант.
Ар бир колдонмо инстанциясы башкалардан көз карандысыз иштөөгө боло турган өз алдынча жайгаштыруу бирдиги.
деп белгилешет колдонмонун мисалы көптөн турушу мүмкүн компоненттери, мисалы, frontend, backend, базасы ж.б. Микросервис тиркемеси болгон учурда, инстанция бардык микросервистерди камтыйт.
Натыйжада, Kubernetes колдонуучуларынын бир нече суроолору бар:
- Колдонмонун бардык инстанциялары бир кластерге жайгаштырылышы керекпи?
- Ар бир колдонмо инстанциясы үчүн өзүнчө кластерге ээ болуу керекпи?
- Же балким, жогоруда айтылган ыкмалардын айкалышы колдонулушу керекпи?
Бул варианттардын бардыгы абдан ыңгайлуу, анткени Kubernetes колдонуучунун мүмкүнчүлүктөрүн чектебеген ийкемдүү система.
Бул жерде мүмкүн болгон кээ бир жолдор:
- бир чоң жалпы кластер;
- көптөгөн чакан жогорку адистештирилген кластерлер;
- өтүнмө боюнча бир кластер;
- ар бир чөйрөгө бир кластер.
Төмөндө көрсөтүлгөндөй, биринчи эки ыкма варианттардын масштабынын карама-каршы жагында:
Бир нече чоң кластерлерден (солдо) көптөгөн кичинекейлерге (оңдо)
Жалпысынан алганда, бир кластер башкасына караганда "чоң" деп эсептелет, эгерде ал түйүндөрдүн жана кабыкчалардын көбүрөөк суммасына ээ болсо. Мисалы, 10 түйүн жана 100 уячалуу кластер 1 түйүн жана 10 уячалуу кластерге караганда чоңураак.
Мейли, баштайлы!
1. Бир чоң жалпы кластер
Биринчи вариант - бардык жүктөрдү бир кластерге жайгаштыруу:
Бир чоң кластер
Бул ыкманын алкагында кластер универсалдуу катары колдонулат инфраструктуралык платформа - сиз жөн гана бар болгон Kubernetes кластеринде керектүү нерселердин бардыгын орнотосуз.
Kubernetes кластердин бөлүктөрүн бири-биринен логикалык жактан ажыратууга мүмкүндүк берет, андыктан ар бир тиркеме инстанциясынын өзүнүн аттар мейкиндиги болушу мүмкүн.
Келгиле, бул ыкманын жакшы жана жаман жактарын карап көрөлү.
+ Ресурстарды эффективдүү пайдалануу
Жалгыз кластер менен сизге Kubernetes кластерин иштетүү жана башкаруу үчүн зарыл болгон бардык ресурстардын бир гана көчүрмөсү керек.
Мисалы, бул башкы түйүндөр үчүн чыныгы. Адатта, ар бир Kubernetes кластеринде 3 башкы түйүн бар, ошондуктан бир кластер үчүн алардын саны ошол бойдон калат (салыштыруу үчүн 10 кластерге 30 башкы түйүн керек болот).
Жогорудагы кылдаттык бүткүл кластер боюнча иштеген башка кызматтарга да тиешелүү, мисалы, жүк баланстоочулар, Ingress контроллерлору, аутентификация, каттоо жана мониторинг системалары.
Бир кластерде бул кызматтардын бардыгын бир эле учурда бардык жүктөмдөр үчүн колдонсо болот (бир нече кластердегидей алардын көчүрмөлөрүн түзүүнүн кереги жок).
+ Арзан
Жогоруда айтылгандардын натыйжасы катары, азыраак кластерлер, адатта, арзаныраак болот, анткени кошумча чыгымдар жок.
Бул өзгөчө мастер түйүндөргө тиешелүү, алар кандайча жайгаштырылып жатканына карабастан (жерлерде же булуттарда) олуттуу сумманы талап кылышы мүмкүн.
Кээ бир башкарган Kubernetes кызматтары, мисалы же , башкаруу катмарын акысыз камсыз кылуу. Бул учурда нарк маселеси анча курч эмес.
Ошондой эле ар бир Kubernetes кластеринин иштеши үчүн белгиленген төлөм талап кылган башкарылуучу кызматтар бар (мисалы, ).
+ Натыйжалуу башкаруу
Бир кластерди башкаруу бир нече башкарууга караганда оңой.
Администрация төмөнкү милдеттерди камтышы мүмкүн:
- Kubernetes версиясын жаңыртуу;
- CI/CD түтүгүн орнотуу;
- CNI плагинди орнотуу;
- колдонуучунун аутентификация системасын түзүү;
- кирүү контроллерин орнотуу;
жана башкалар…
Бир кластер болсо, мунун баарын бир гана жолу жасоого туура келет.
Көптөгөн кластерлер үчүн операциялар көп жолу кайталанууга туура келет, бул процесстин ырааттуулугун жана ырааттуулугун камсыз кылуу үчүн процесстерди жана инструменттерди бир аз автоматташтырууну талап кылат.
Ал эми азыр терс жактары жөнүндө бир нече сөз.
− Бир эле катачылык
баш тарткан учурда гана кластер дароо иштебей калат бардык жумуш жүктөрү!
Бир нерсе туура эмес болушунун көптөгөн жолдору бар:
- Kubernetesти жаңылоо күтүлбөгөн терс таасирлерге алып келет;
- Кластердик компонент (мисалы, CNI плагини) күтүлгөндөй иштебей баштайт;
- кластердин компоненттеринин бири туура конфигурацияланган эмес;
- негизги инфраструктуранын бузулушу.
Мындай окуялардын бири жалпы кластерде жайгаштырылган бардык жүктөргө олуттуу зыян келтириши мүмкүн.
− Катуу изоляция жок
Бөлүшүлгөн кластерде иштөө колдонмолордун аппараттык жабдыктарды, тармактык мүмкүнчүлүктөрдү жана кластер түйүндөрүндө иштөө тутумун бөлүшө тургандыгын билдирет.
Кандайдыр бир мааниде, бир түйүндө иштеген эки башка тиркемелери бар эки контейнер бир эле OS ядросун башкарган бир эле машинада иштеген эки процесске окшош.
Linux контейнерлери изоляциянын кандайдыр бир түрүн камсыз кылат, бирок ал виртуалдык машиналар менен камсыздалгандай күчтүү эмес. Чындыгында, контейнердеги процесс - бул хост операциялык тутумунда иштеген процесс.
Бул коопсуздук маселеси болушу мүмкүн: бул түзүлүш теориялык жактан байланышы жок тиркемелерге бири-бири менен байланышууга мүмкүндүк берет (атайылап же кокустан).
Кошумчалай кетсек, Kubernetes кластериндеги бардык жүктөмөлөр кластердик кызматтарды бөлүшөт, мисалы - бул колдонмолорго кластердеги башка колдонмолордун Кызматтарын табууга мүмкүндүк берет.
Жогорудагы пункттардын баары колдонмонун коопсуздук талаптарына жараша ар кандай мааниге ээ болушу мүмкүн.
Kubernetes сыяктуу коопсуздук маселелерин алдын алуу үчүн ар кандай куралдар менен камсыз кылат и . Бирок, аларды туура орнотуу кээ бир тажрыйбаны талап кылат, андан тышкары, алар таптакыр бардык коопсуздук тешиктерин жаба албайт.
Kubernetes башында иштелип чыкканын эстен чыгарбоо маанилүү бөлүшүү, үчүн эмес изоляция жана коопсуздук.
− Катуу көп квартиранын жоктугу
Kubernetes кластериндеги жалпы ресурстардын көптүгүн эске алуу менен, ар кандай тиркемелер бири-биринин манжаларын басуунун көптөгөн жолдору бар.
Мисалы, колдонмо жалпы ресурсту (мисалы, CPU же эстутум) монополиялап, бир эле түйүндө иштеген башка тиркемелерди ага жетүү мүмкүнчүлүгүнөн баш тартышы мүмкүн.
Kubernetes бул жүрүм-турумду көзөмөлдөө үчүн ар кандай механизмдерди камсыз кылат, мисалы (Ошондой эле макаланы карагыла ""- болжол менен. котормо.), и . Бирок, коопсуздук жагынан алганда, алардын конфигурациясы анча маанилүү эмес жана алар күтүлбөгөн терс таасирлердин баарын алдын ала албайт.
− Колдонуучулардын көптүгү
Бир кластер болсо, ага көптөгөн адамдарга мүмкүнчүлүк ачуу керек. Жана алардын саны канчалык көп болсо, алар бир нерсени "сындырып" алуу коркунучу ошончолук жогору болот.
Кластердин ичинде сиз ким эмнени колдоно алаарын көзөмөлдөй аласыз ("макаланы караңыз""- болжол менен. котормо.). Бирок, бул колдонуучулардын жоопкерчилик чөйрөсүндөгү бир нерсени "сындыруусуна" тоскоол болбойт.
− Кластерлер чексиз өсө албайт
Бардык жүктөөлөр үчүн колдонулган кластер, кыязы, бир топ чоң болушу мүмкүн (түйүндөрдүн жана поддондордун саны боюнча).
Бирок бул жерде дагы бир көйгөй туулат: Кубернетестеги кластерлер чексиз өсө албайт.
Кластердин өлчөмү боюнча теориялык чектөө бар. Kubernetes бул болжол менен .
Бирок, чыныгы жашоодо көйгөйлөр бир топ эрте башталышы мүмкүн - мисалы, жөн гана .
Чындыгында, чоң кластерлер Kubernetes башкаруу катмарына чоң жүк түшүрөт. Башка сөз менен айтканда, кластердин үзгүлтүксүз иштеши үчүн кылдат тууралоо керек.
Бул маселе "деп аталган оригиналдуу блогдогу тиешелүү макалада изилденген.«.
Бирок карама-каршы мамилени карап көрөлү: көптөгөн чакан кластерлер.
2. Көптөгөн чакан, адистештирилген кластерлер
Бул ыкма менен сиз жайгаштырган ар бир элемент үчүн өзүнчө кластер колдоносуз:
Көптөгөн майда кластерлер
Ушул берененин максаттары үчүн, астында жайгаштырылган элемент колдонмонун инстанциясын билдирет - мисалы, өзүнчө тиркеменин иштеп чыгуучу версиясы.
Бул стратегия Kubernetesти адистештирилген стратегия катары колдонот иштөө убактысы жеке колдонуу учурлары үчүн.
Келгиле, бул ыкманын жакшы жана жаман жактарын карап көрөлү.
+ Чектелген "жардыруу радиусу"
Кластер иштебей калганда, терс кесепеттер ошол кластерде орнотулган жумуш жүгү менен гана чектелет. Калган жумуштардын бардыгы тең тийбейт.
+ Изоляция
Жеке кластерлерде жайгаштырылган жумуш жүктөрү процессор, эстутум, операциялык система, тармак же башка кызматтар сыяктуу ресурстарды бөлүшпөйт.
Натыйжада, алардын коопсуздугу үчүн пайдалуу болушу мүмкүн болгон байланышы жок тиркемелердин ортосунда катуу изоляция болуп саналат.
+ Колдонуучулардын саны аз
Ар бир кластерде иш жүктөмүнүн чектелген гана топтомун камтыганын эске алсак, ага кирүү мүмкүнчүлүгү бар колдонуучулардын саны кыскарат.
Кластерге канчалык аз адамдар кирсе, бир нерсенин “сындыруу” коркунучу ошончолук аз болот.
Келгиле, терс жактарын карап көрөлү.
− ресурстарды натыйжасыз пайдалануу
Мурда айтылгандай, ар бир Kubernetes кластери башкаруу ресурстарынын белгилүү бир топтомун талап кылат: башкы түйүндөр, башкаруу катмарынын компоненттери, мониторинг жана каттоо чечимдери.
Чакан кластерлердин саны көп болгон учурда башкарууга ресурстардын көбүрөөк үлүшү бөлүнүшү керек.
− Кымбат
Ресурстарды натыйжасыз пайдалануу автоматтык түрдө чоң чыгымдарды алып келет.
Мисалы, бир эле эсептөө кубаттуулугу менен үч эмес, 30 башкы түйүндөрдү тейлөө чыгымдарга сөзсүз түрдө таасирин тийгизет.
− башкаруудагы кыйынчылыктар
Бир нече Kubernetes кластерлерин башкаруу бир эле башкарууга караганда алда канча кыйын.
Мисалы, ар бир кластер үчүн аутентификацияны жана авторизацияны конфигурациялашыңыз керек болот. Kubernetes версиясы да бир нече жолу жаңыртылышы керек болот.
Бул иштердин бардыгын натыйжалуураак кылуу үчүн сизге автоматташтыруу керек болот.
Эми азыраак экстремалдуу сценарийлерди карап көрөлү.
3. Ар бир өтүнмө боюнча бир кластер
Бул ыкмада сиз белгилүү бир колдонмонун бардык инстанциялары үчүн өзүнчө кластер түзөсүз:
Ар бир колдонмо үчүн кластер
Бул жол принциптин жалпылоосу катары каралышы мүмкүн "ар бир команда үчүн өзүнчө кластер", анткени, адатта, инженерлер тобу бир же бир нече тиркемелерди иштеп чыгууда.
Келгиле, бул ыкманын жакшы жана жаман жактарын карап көрөлү.
+ Кластерди колдонмого тууралоого болот
Колдонмонун өзгөчө муктаждыктары бар болсо, алар башка кластерлерге таасирин тийгизбестен кластерде ишке ашырылышы мүмкүн.
Мындай муктаждыктар GPU жумушчуларын, белгилүү CNI плагиндерин, тейлөө тармагын же башка кызматтарды камтышы мүмкүн.
Ар бир кластер керек болгон нерсени гана камтышы үчүн, анда иштеген тиркемеге ылайыкташтырылышы мүмкүн.
− Бир кластерде ар кандай чөйрөлөр
Бул ыкманын кемчилиги ар түрдүү чөйрөлөрдөгү тиркеме инстанциялары бир кластерде чогуу жашашында.
Мисалы, колдонмонун проддук версиясы иштеп чыгуучу версиясы менен бир кластерде иштейт. Бул ошондой эле иштеп чыгуучулар тиркеменин өндүрүштүк версиясы иштетилген кластерде иштешет дегенди билдирет.
Эгерде иштеп чыгуучулардын аракеттеринен же иштеп чыгуучу версиядагы мүчүлүштүктөрдөн улам кластерде мүчүлүштүктөр пайда болсо, анда прод версиясы да жабыркашы мүмкүн - бул ыкманын чоң кемчилиги.
Акыр-аягы, биздин тизмедеги акыркы сценарий.
4. Ар бир чөйрөгө бир кластер
Бул сценарий ар бир чөйрө үчүн өзүнчө кластер бөлүүнү камтыйт:
Ар бир чөйрөгө бир кластер
Мисалы, сизде кластерлер болушу мүмкүн ишт.ч., текшерүү и продукт, анда сиз белгилүү бир чөйрөгө арналган колдонмонун бардык нускаларын иштетесиз.
Бул жерде бул ыкманын жакшы жана жаман жактары бар.
+ Өндүрүш чөйрөсүн изоляциялоо
Бул ыкманын алкагында бардык чөйрөлөр бири-биринен обочолонгон. Бирок, иш жүзүндө бул өндүрүш чөйрөсүндө өзгөчө маанилүү.
Колдонмонун өндүрүштүк версиялары эми башка кластерлерде жана чөйрөлөрдө болуп жаткан нерселерден көз каранды эмес.
Ошентип, эгер иштеп чыгуучу кластерде күтүлбөгөн жерден көйгөй пайда болсо, тиркемелердин проддук версиялары эч нерсе болбогондой иштей берет.
+ Кластерди айлана-чөйрөгө ылайыкташтырууга болот
Ар бир кластер чөйрөсүнө ылайыкташтырылышы мүмкүн. Мисалы, сиз:
- dev кластеринде иштеп чыгуу жана мүчүлүштүктөрдү оңдоо үчүн куралдарды орнотуу;
- кластерге тест алкактарын жана куралдарын орнотуу текшерүү;
- кластерде күчтүүрөөк аппараттык жана тармактык каналдарды колдонуңуз продукт.
Бул тиркемени иштеп чыгуунун жана иштетүүнүн натыйжалуулугун жогорулатууга мүмкүндүк берет.
+ Өндүрүш кластерине кирүү мүмкүнчүлүгүн чектөө
Продукт кластери менен түздөн-түз иштөө зарылдыгы чанда гана пайда болот, андыктан ага кирүү мүмкүнчүлүгү бар адамдардын чөйрөсүн олуттуу чектей аласыз.
Сиз андан да ары барып, адамдардын бул кластерге кирүүсүнө таптакыр тыюу салып, автоматташтырылган CI/CD куралы аркылуу бардык жайылтууларды аткара аласыз. Мындай мамиле адам каталарынын коркунучун эң керектүү жерде азайтат.
Ал эми азыр терс жактары жөнүндө бир нече сөз.
− Колдонмолордун ортосунда изоляция жок
Бул ыкманын негизги кемчилиги тиркемелер арасында аппараттык жана ресурстук изоляциянын жоктугу болуп саналат.
Байланбаган тиркемелер кластердик ресурстарды бөлүшөт: системанын өзөгү, процессор, эс тутум жана башка кызматтар.
Жогоруда айтылгандай, бул коркунучтуу болушу мүмкүн.
− Колдонмолордун көз карандылыктарын локалдаштыруу мүмкүн эмес
Колдонмонун атайын талаптары бар болсо, анда алар бардык кластерлерде канааттандырылышы керек.
Мисалы, эгер тиркеме GPUну талап кылса, анда ар бир кластер GPU менен жок дегенде бир жумушчуну камтышы керек (ал ошол колдонмо тарабынан гана колдонулса да).
Натыйжада, биз чыгымдардын жогорулоосуна жана ресурстарды натыйжасыз пайдалануу тобокелдигине дуушар болобуз.
жыйынтыктоо
Эгер сизде белгилүү бир тиркемелер топтому бар болсо, аларды бир нече чоң кластерлерге же көптөгөн кичинекейлерге жайгаштырууга болот.
Макалада бир глобалдык кластерден бир нече чакан жана жогорку адистештирилгенге чейинки ар кандай ыкмалардын жакшы жана жаман жактары талкууланат:
- бир чоң жалпы кластер;
- көптөгөн чакан жогорку адистештирилген кластерлер;
- өтүнмө боюнча бир кластер;
- ар бир чөйрөгө бир кластер.
Демек, сиз кандай мамиле кылышыңыз керек?
Адаттагыдай эле, жооп колдонуу шартына жараша болот: ар кандай ыкмалардын жакшы жана жаман жактарын таразалап, эң оптималдуу вариантты тандоо керек.
Бирок, тандоо жогорудагы мисалдар менен эле чектелбейт - сиз алардын каалаган айкалышын колдоно аласыз!
Мисалы, сиз ар бир команда үчүн бир нече кластерлерди уюштура аласыз: өнүктүрүү кластери (анын ичинде чөйрөлөр болот) ишт.ч. и текшерүү) жана кластер үчүн продукция (өндүрүш чөйрөсү кайда жайгашат).
Бул макаладагы маалыматтын негизинде, сиз белгилүү бир сценарий үчүн оң жана терс жактарын оптималдаштырсаңыз болот. Жолуңуз ачык болсун!
PS
Биздин блогдон дагы окуңуз:
- «";
- «";
- «";
- ««.
Source: www.habr.com