Сиз барган сайын көбүрөөк Kubernetes кызматтарын түзө баштаганыңызда, башында жөнөкөй болгон тапшырмалар татаалдашып баштайт. Мисалы, иштеп чыгуу топтору бир эле ат менен кызматтарды же жайылтууларды түзө албайт. Эгер сизде миңдеген поддондор болсо, аларды жөн гана тизмелөө, аларды туура башкаруу мындай турсун, көп убакытты талап кылат. Ал эми бул айсбергдин чети гана.
Келгиле, аттар мейкиндиги Kubernetes ресурстарын башкарууну кантип жеңилдеткенин карап көрөлү. Ошентип, ысым мейкиндиги деген эмне? Ат мейкиндигин Kubernetes кластериңиздин ичиндеги виртуалдык кластер катары кароого болот. Бир Kubernetes кластеринин ичинде бири-биринен обочолонгон бир нече аттар мейкиндигине ээ боло аласыз. Алар сизге жана сиздин командаларыңызга уюштуруу, коопсуздук жана атүгүл тутумдун иштеши боюнча чындап жардам бере алат.
Көпчүлүк Kubernetes дистрибуцияларында кластер "демейки" деп аталган аттар мейкиндиги менен кутудан чыгат. Чындыгында Kubernetes иштеген үч аттар мейкиндиги бар: демейки, kube-системасы жана kube-public. Учурда Kube-public көп колдонулбайт.
Kube аталыш мейкиндигин жалгыз калтыруу жакшы идея, айрыкча Google Kubernetes Engine сыяктуу башкарылуучу тутумда. Ал сиздин кызматтарыңыз жана тиркемелериңиз түзүлгөн жер катары "демейки" аттар мейкиндигин колдонот. Бул жөнүндө эч кандай өзгөчө эч нерсе жок, бирок Kubernetes аны колдонуу үчүн кутудан тышкары конфигурацияланган жана аны өчүрө албайсыз. Бул баштоо үчүн эң сонун жана өндүрүмдүүлүгү төмөн системалар, бирок мен чоң өндүрүш системаларында демейки аттар мейкиндигин колдонууну сунуштабайт элем. Акыркы учурда, бир иштеп чыгуу тобу башка бирөөнүн кодун оңой эле кайра жазып, башка команданын ишин байкабай эле бузуп коюшу мүмкүн.
Ошондуктан, сиз бир нече аталыш мейкиндигин түзүп, аларды кызматтарыңызды башкарылуучу бирдиктерге бөлүү үчүн колдонушуңуз керек. Ат мейкиндигин бир буйрук менен түзсө болот. Эгер сиз тест деп аталган аттар мейкиндигин түзгүңүз келсе, анда $ kubectl аттар мейкиндигин түзүү сынагы буйругун колдонуңуз же жөн гана YAML файлын түзүп, аны башка Kubernetes ресурсу сыяктуу колдонуңуз.
Сиз $ kubectl get namespace буйругун колдонуп, бардык аттар мейкиндигин көрө аласыз.
Ал бүткөндөн кийин, сиз үч камтылган аттар мейкиндигин жана "сынак" деп аталган жаңы аттар мейкиндигин көрөсүз. Подгон түзүү үчүн жөнөкөй YAML файлын карап көрөлү. Сиз аттар мейкиндиги жөнүндө эч кандай сөз жок экенин байкайсыз.
Бул файлды иштетүү үчүн kubectl колдонсоңуз, ал учурда активдүү аттар мейкиндигинде mypod модулун түзөт. Бул сиз аны өзгөртмөйүнчө демейки аттар мейкиндиги болот. Kubernetesке ресурсуңузду кайсы аттар мейкиндигинде түзгүңүз келгенин айтуунун 2 жолу бар. Биринчи жол - бул ресурсту түзүүдө ат мейкиндигинин желегин колдонуу.
Экинчи жол - YAML декларациясында аттар мейкиндигин көрсөтүү.
YAMLде аттар мейкиндигин көрсөтсөңүз, ресурс дайыма ошол аттар мейкиндигинде түзүлөт. Эгерде сиз аттар мейкиндигинин желегин колдонуп жатканда башка мейкиндикти колдонууга аракет кылсаңыз, буйрук аткарылбай калат. Эми сиз өзүңүздүн капчыгыңызды табууга аракет кылсаңыз, аны таба албайсыз.
Бул бардык буйруктар учурдагы активдүү аттар мейкиндигинен тышкары аткарылгандыктан пайда болот. Подгонуңузду табуу үчүн, сиз аттар мейкиндигинин желегин колдонушуңуз керек, бирок бул тез тажатат, өзгөчө, эгер сиз өз аттар мейкиндигин колдонгон команданын иштеп чыгуучусу болсоңуз жана ал желекти ар бир буйрук үчүн колдонгуңуз келбесе. Келгиле, муну кантип оңдой аларыбызды карап көрөлү.
Сиздин активдүү аттар мейкиндигиңиз демейки деп аталат. YAML ресурсунда аттар мейкиндигин көрсөтпөсөңүз, анда бардык Kubernetes буйруктары бул активдүү демейки аттар мейкиндигин колдонот. Тилекке каршы, kubectl аркылуу активдүү аттар мейкиндигин башкаруу аракети ишке ашпай калышы мүмкүн. Бирок, бул процессти бир топ жеңилдеткен Kubens деген абдан жакшы курал бар. Сиз kubens буйругун иштеткенде, активдүү аттар мейкиндиги белгиленген бардык аттар мейкиндигин көрөсүз.
Активдүү аттар мейкиндигин тесттик аттар мейкиндигине которуу үчүн, сиз жөн гана $kubens сыноо буйругун иштетиңиз. Эгер сиз $kubens буйругун кайра иштетсеңиз, жаңы активдүү аттар мейкиндиги бөлүнгөнүн көрөсүз - тест.
Бул сыноо аттар мейкиндигинде подкастты көрүү үчүн ат мейкиндигинин желеги керек эмес дегенди билдирет.
Ошентип, аттар мейкиндиктери бири-биринен жашырылат, бирок бири-биринен обочолонбойт. Бир аттар мейкиндигиндеги кызмат башка аттар мейкиндигиндеги кызмат менен оңой байланыша алат, бул көбүнчө абдан пайдалуу. Ар кандай аттар мейкиндигинде баарлашуу мүмкүнчүлүгү сиздин иштеп чыгуучулардын кызматы башка аттар мейкиндигинде башка иштеп чыгуучулар тобунун кызматы менен байланыша алат дегенди билдирет.
Адатта, колдонмоңуз Kubernetes кызматына киргиси келгенде, сиз орнотулган DNS табуу кызматын колдоносуз жана жөн гана колдонмоңузга кызматтын атын бересиз. Бирок, муну менен сиз бир нече аттар мейкиндигинде бир эле ат менен кызмат түзө аласыз, бул кабыл алынбайт.
Бактыга жараша, бул DNS дарегин кеңейтилген түрүн колдонуу менен айланып өтүү үчүн жеңил болот. Kubernetes кызматтары жалпы DNS шаблону аркылуу акыркы чекиттерин ачыкка чыгарышат. Бул мындай көрүнөт:
Адатта, сизге жөн гана кызматтын аталышы керек жана DNS толук даректи автоматтык түрдө аныктайт.
Бирок, эгер сизге башка аттар мейкиндигиндеги кызматка кирүү керек болсо, жөн гана кызматтын атын жана аттар мейкиндигинин атын колдонуңуз:
Мисалы, эгер сиз тесттик аттар мейкиндигинде кызмат көрсөтүүлөр базасына туташууну кааласаңыз, анда дарек базасы database.test колдоно аласыз.
Эгерде сиз прод аттар мейкиндигинде кызмат маалымат базасына туташууну кааласаңыз, анда database.prod колдоносуз.
Эгер сиз чындап эле аттар мейкиндигине кирүү мүмкүнчүлүгүн обочолонтуп, чектөөнү кааласаңыз, Kubernetes муну Kubernetes Network Policies аркылуу жасоого мүмкүндүк берет. Бул тууралуу кийинки бөлүмдө айтам.
Мага көп суроо берилет, мен канча аталыш мейкиндигин түзүшүм керек жана кандай максаттар үчүн? Башкарылуучу маалымат деген эмне?
Эгер сиз өтө көп аттар мейкиндигин түзсөңүз, алар жөн эле жолуңузга тоскоол болот. Алардын саны өтө аз болсо, мындай чечимдин бардык артыкчылыктарын жоготосуз. Менимче, ар бир компания өзүнүн уюштуруу түзүмүн түзүүдө төрт негизги этаптан өтөт. Долбооруңуз же компанияңыз иштеп жаткан өнүгүү стадиясына жараша, сиз тиешелүү аталыш мейкиндигинин стратегиясын кабыл алгыңыз келиши мүмкүн.
Сиз 5-10 микросервистерди иштеп чыгуунун үстүндө иштеп жаткан чакан топтун мүчөсү экениңизди элестетиңиз жана бардык иштеп чыгуучуларды бир бөлмөгө оңой чогулта аласыз. Бул жагдайда, демейки аттар мейкиндигинде бардык прод кызматтарын иштетүү мааниси бар. Албетте, көбүрөөк ийкемдүүлүк үчүн, сиз 2 аталыш мейкиндигин колдоно аласыз - прод жана иштеп чыгуу үчүн өзүнчө. Балким, сиз Minikube сыяктуу нерсени колдонуп, жергиликтүү компьютериңизде иштеп чыгууңузду сынайсыз.
Келгиле, нерселер өзгөрдү дейли жана сизде азыр бир эле учурда 10дон ашык микросервистерде иштеген тездик менен өсүп жаткан командаңыз бар. Прод жана иштеп чыгуу үчүн өзүнчө бир нече кластерлерди же аттар мейкиндигин колдонуу зарыл болгон учур келет. Ар биринин өзүнүн микросервистерине ээ болушу үчүн жана бул командалардын ар бири программалык камсыздоону иштеп чыгуу жана чыгаруу процессин башкаруу процессин жеңилдетүү үчүн өзүнүн аталыш мейкиндигин тандап алышы үчүн, сиз команданы бир нече суб-командаларга бөлсөңүз болот.
Ар бир команда мүчөсү тутумдун кантип иштээрин түшүнгөн сайын, ар бир өзгөрүүнү башка иштеп чыгуучулар менен координациялоо барган сайын кыйындай баштайт. Жергиликтүү машинаңызда толук стекти айлантууга аракет кылуу күн сайын кыйындап баратат.
Ири компанияларда иштеп чыгуучулар көбүнчө ким эмненин үстүндө иштеп жатканын билишпейт. Командалар кызматтык контракттарды колдонуу менен байланышат же Istio конфигурациялоо куралы сыяктуу тармак аркылуу абстракция катмарын кошо турган кызматтык тор технологиясын колдонушат. Толук стекти жергиликтүү түрдө иштетүү мүмкүн эмес. Мен Kubernetesтеги Spinnaker сыяктуу үзгүлтүксүз жеткирүү (CD) платформасын колдонууну сунуштайм. Ошентип, ар бир буйрук сөзсүз түрдө өзүнүн аталыш мейкиндигине муктаж болгон учур келет. Ар бир команда иштеп чыгуучу чөйрө жана өндүрүш чөйрөсү үчүн бир нече аталыш мейкиндигин тандай алат.
Акыр-аягы, иштеп чыгуучулардын бир тобу башка топтордун бар экендигин билбеген ири ишкердик компаниялары бар. Мындай компания жалпысынан аны менен жакшы документтештирилген API аркылуу өз ара аракеттенген үчүнчү тараптын иштеп чыгуучуларын жалдай алат. Ар бир мындай топ бир нече командаларды жана бир нече микросервистерди камтыйт. Бул учурда, мен мурда айткан бардык куралдарды колдонуу керек.
Программисттер кызматтарды кол менен жайгаштырбашы керек жана аларга тиешеси жок аттар мейкиндигине кирүү мүмкүнчүлүгү болбошу керек. Бул этапта начар конфигурацияланган тиркемелердин “жардыруу радиусун” азайтуу, эсеп коюу процесстерин жана ресурстарды башкарууну жөнөкөйлөтүү үчүн бир нече кластерлердин болушу максатка ылайыктуу.
Ошентип, уюмуңуз тарабынан аттар мейкиндиктерин туура колдонуу Kubernetes'ти башкара алгыдай, башкарылуучу, коопсуз жана ийкемдүү кылууга мүмкүндүк берет.
Кээ бир жарнамалар 🙂
Биз менен болгонуңуз үчүн рахмат. Биздин макалалар сизге жагабы? Көбүрөөк кызыктуу мазмунду көргүңүз келеби? Буйрутма берүү же досторуңузга сунуштоо менен бизди колдоңуз, , биз сиз үчүн ойлоп тапкан баштапкы деңгээлдеги серверлердин уникалдуу аналогу: (RAID1 жана RAID10 менен жеткиликтүү, 24 өзөккө чейин жана 40 ГБ DDR4 чейин).
Dell R730xd Амстердамдагы Equinix Tier IV маалымат борборунда 2 эсе арзанбы? Бул жерде гана Нидерландыда! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 доллардан! Жөнүндө окуу
Source: www.habr.com
