Kubernetes: отворен код наспроти специфични за продавачите

Здраво, јас се викам Дмитриј Краснов. Повеќе од пет години управувам со кластерите на Kubernetes и градам сложени микросервисни архитектури. На почетокот на оваа година лансиравме услуга за управување со кластерите на Кубернетес базирани на Containerum. Искористувајќи ја оваа можност, ќе ви кажам што е Kubernetes и како интеграцијата со продавачот се разликува од софтверот со отворен код.

За почеток, што е Кубернети. Ова е систем за управување со контејнери на голем број домаќини. Од грчки, патем, тоа е преведено како „пилот“ или „коламен“. Првично развиен од Google, а потоа дониран како технолошки придонес на Cloud Native Computing Foundation, меѓународна непрофитна организација која ги обединува водечките светски програмери, крајни корисници и даватели на технологија за контејнери.

Управувајте со голем број контејнери

Сега да откриеме какви се овие контејнери. Ова е апликација со целата своја околина - главно библиотеките од кои зависи програмата. Сето ова е спакувано во архиви и претставено во форма на слика што може да се извршува без разлика на оперативниот систем, тестирано и многу повеќе. Но, постои проблем - управувањето со контејнери на голем број домаќини е многу тешко. Затоа е создаден Kubernetes.

Сликата на контејнер претставува апликација плус нејзините зависности. Апликацијата, нејзините зависности и сликата на датотечниот систем на ОС се наоѓаат во различни делови од сликата, таканаречени слоеви. Слоевите може повторно да се користат за различни контејнери. На пример, сите апликации во една компанија може да го користат основниот слој на Ubuntu. Кога работат контејнери, нема потреба да се складираат повеќе копии од еден основен слој на домаќинот. Ова ви овозможува да го оптимизирате складирањето и испораката на слики.

Кога сакаме да извршиме апликација од контејнер, потребните слоеви се надредени еден на друг и се формира преклопен датотечен систем. Одозгора се поставува слој за снимање, кој се отстранува кога контејнерот ќе застане. Ова осигурува дека кога ќе работи контејнерот, апликацијата секогаш ќе ја има истата средина, која не може да се промени. Ова гарантира репродуктивност на околината на различни оперативни системи домаќини. Без разлика дали се работи за Ubuntu или CentOS, околината секогаш ќе биде иста. Покрај тоа, контејнерот е изолиран од домаќинот користејќи механизми вградени во кернелот Линукс. Апликациите во контејнер не ги гледаат датотеките, процесите на домаќинот и соседните контејнери. Оваа изолација на апликациите од оперативниот систем домаќин обезбедува дополнителен слој на безбедност.

Има многу достапни алатки за управување со контејнери на домаќин. Најпопуларниот од нив е Докер. Тоа ви овозможува да го обезбедите целосниот животен циклус на контејнерите. Сепак, работи само на еден домаќин. Ако треба да управувате со контејнери низ повеќе домаќини, Docker може да им го направи животот пекол на инженерите. Затоа е создаден Kubernetes.

Побарувачката за Kubernetes се должи токму на можноста за управување со групи контејнери на повеќе домаќини како некој вид на единствен ентитет. Популарноста на системот дава можност за изградба на DevOps или развојни операции, во кои Kubernetes се користи за извршување на процесите на овој DevOps.

Слика 1. Шематски приказ за тоа како функционира Kubernetes

Целосна автоматизација

DevOps во основа е автоматизација на процесот на развој. Грубо кажано, програмерите пишуваат код што се поставува во складиштето. Тогаш овој код може автоматски да се собере веднаш во контејнер со сите библиотеки, да се тестира и да се „префрли“ во следната фаза - Станирање, а потоа веднаш во Производство.

Заедно со Kubernetes, DevOps ви овозможува да го автоматизирате овој процес, така што тој се случува практично без учество од самите програмери. Поради ова, изградбата е значително побрза, бидејќи развивачот не мора да го прави тоа на неговиот компјутер - тој едноставно пишува парче код, го турка кодот до складиштето, по што се стартува гасоводот, кој може да го вклучи процесот на градење, тестирање и воведување. И ова се случува со секое извршување, така што тестирањето се случува континуирано.

Во исто време, користењето на контејнер ви овозможува да бидете сигурни дека целата околина на оваа програма ќе биде пуштена во производство токму во формата во која е тестирана. Односно, нема да има проблеми како „имаше некои верзии на тестот, други во производство, но кога ги инсталиравме, сè падна“. И бидејќи денес имаме тренд кон микросервисна архитектура, кога наместо една огромна апликација има стотици мали, за да се администрираат рачно, ќе се бара огромен персонал од вработени. Затоа користиме Kubernetes.

Добрите, добрите, добрите

Ако зборуваме за предностите на Kubernetes како платформа, тогаш тој има значителни предности од гледна точка на управување со архитектура на микросервис.

• Управување со повеќе реплики. Најважната работа е управување со контејнери низ повеќе домаќини. Уште поважно, управувајте со повеќекратни реплики на апликации во контејнери како еден ентитет. Благодарение на ова, инженерите не мора да се грижат за секој поединечен контејнер. Ако еден од контејнерите се сруши, Кубернетес ќе го види ова и ќе го рестартира повторно.
• Кластерска мрежа. Кубернетес има и таканаречена кластерска мрежа со сопствен адресен простор. Благодарение на ова, секоја мешунка има своја адреса. Подпод се подразбира како минимална структурна единица на кластерот во кој контејнерите се директно лансирани. Покрај тоа, Kubernetes има функционалност која комбинира балансирач на оптоварување и Discovery на услуги. Ова ви овозможува да се ослободите од рачното управување со IP-адреси и да ја делегирате оваа задача на Kubernetes. И автоматските здравствени проверки ќе помогнат да се откријат проблеми и да се пренасочи сообраќајот кон работните подлоги.
• Управување со конфигурација. Кога управувате со голем број апликации, станува тешко да се управува со конфигурацијата на апликацијата. За таа цел, Kubernetes има специјални ресурси за ConfigMap. Тие ви дозволуваат централно да ги складирате конфигурациите и да ги изложувате на подлоги при извршување на апликации. Овој механизам ни овозможува да ја гарантираме конзистентноста на конфигурацијата во најмалку десет или стотина реплики на апликации.
• Постојани волумени. Контејнерите се инхерентно непроменливи и кога контејнерот е запрен, сите податоци запишани во датотечен систем ќе бидат уништени. Но, некои апликации складираат податоци директно на дискот. За да се реши овој проблем, Kubernetes има функционалност за управување со складирање на диск - Постојани томови. Овој механизам користи надворешно складирање за податоци и може да префрли постојано складирање, блок или датотека, во контејнери. Ова решение ви овозможува да складирате податоци одделно од работниците, што ги зачувува доколку истите работници се расипат.
• Баланс на оптоварување. Иако во Kubernetes управуваме со апстрактни ентитети како што се Deployment, StatefulSet итн., на крајот контејнерите работат на обични виртуелни машини или хардверски сервери. Тие не се совршени и можат да паднат во секое време. Kubernetes ќе го види ова и ќе го пренасочи внатрешниот сообраќај кон други реплики. Но, што да се прави со сообраќајот што доаѓа однадвор? Ако едноставно го насочите сообраќајот кон еден од работниците, ако се урне, услугата ќе стане недостапна. За да се реши овој проблем, Kubernetes има услуги како Load Balancer. Дизајнирани се автоматски да конфигурираат надворешен балансер на облак за сите работници во кластерот. Овој надворешен балансер го насочува надворешниот сообраќај кон работниците и самиот го следи нивниот статус. Ако еден или повеќе работници станат недостапни, сообраќајот се пренасочува кон други. Ова ви овозможува да креирате високо достапни услуги користејќи Kubernetes.

Kubernetes најдобро функционира кога работи микросервис архитектури. Можно е да се имплементира системот во класичната архитектура, но тоа е бесмислено. Ако апликацијата не може да работи на повеќе реплики, тогаш каква разлика има - во Kubernetes или не?

Кубернет со отворен код

Кубернет со отворен код е одлична работа: го инсталирав и работи. Можете да го распоредите на вашите сопствени хардверски сервери, на вашата сопствена инфраструктура, да инсталирате мајстори и работници на кои ќе работат сите апликации. И што е најважно, сето ова е бесплатно. Сепак, постојат нијанси.

• Првата е побарувачката за знаење и искуство од администратори и инженери кои ќе го распоредат и поддржат сето ова. Бидејќи клиентот добива целосна слобода на дејствување во кластерот, тој самиот е одговорен за извршувањето на кластерот. И многу е лесно да се скрши сè овде.
• Вториот е недостатокот на интеграции. Ако користите Kubernetes без популарна платформа за виртуелизација, нема да ги добиете сите придобивки од програмата. Како на пример користење на услуги за постојан волумен и оптоварување баланс.

Слика 2. архитектура k8s

Kubernetes од продавачот

Интеграцијата со провајдер на облак обезбедува две опции:

• Прво, едно лице може едноставно да кликнете на копчето „креирај кластер“ и да добие кластер веќе конфигуриран и подготвен за употреба.
• Второ, самиот продавач го инсталира кластерот и ја поставува интеграцијата со облакот.

Како се случува овде. Инженерот што го започнува кластерот одредува колку работници му требаат и со кои параметри (на пример, 5 работници, секој со 10 процесори, 16 GB RAM и, да речеме, 100 GB диск). По што добива пристап до веќе формираниот кластер. Во овој случај, работниците на кои се лансира товарот се целосно префрлени на клиентот, но целата рамнина за управување останува под одговорност на продавачот (ако услугата е обезбедена според моделот на управувана услуга).

Сепак, оваа шема има свои недостатоци. Поради фактот што рамнината за управување останува кај продавачот, продавачот не му дава целосен пристап на клиентот, а тоа ја намалува флексибилноста во работата со Kubernetes. Понекогаш се случува клиентот да сака да додаде одредена функционалност на Kubernetes, на пример, автентикација преку LDAP, но конфигурацијата на рамнината за управување не го дозволува тоа.

Слика 3. Пример за кластер Kubernetes од провајдер на облак

Што да изберете: отворен код или продавач

Значи, дали Kubernetes е специфичен со отворен код или продавач? Ако земеме Kubernetes со отворен код, тогаш корисникот прави што сака со него. Но, постои голема шанса да си пукате во стапалото. Со продавачот е потешко, бидејќи сè е обмислено и конфигурирано за компанијата. Најголемиот недостаток на Kubernetes со отворен код е барањето за специјалисти. Со опцијата продавач, компанијата е ослободена од оваа главоболка, но ќе треба да одлучи дали ќе плати на своите специјалисти или на продавачот.

Па, добрите се очигледни, лошите се исто така познати. Едно е константно: Kubernetes решава многу проблеми со автоматизирање на управувањето со многу контејнери. И кој да избере, софтвер со отворен код или продавач - секој носи своја одлука.

Статијата ја подготви Дмитриј Краснов, водечки архитект на услугата Containerum на провајдерот #CloudMTS

Извор: www.habr.com