Kubernetes - опитомяване на облака

Когато искате да използвате Linux за предоставяне на услуги на бизнес, тези услуги ще трябва да бъдат сигурни, устойчиви и мащабируеми. Хубави думи, но какво имаме предвид под тях?

„Защитен“ означава, че потребителите могат да имат достъп до данните, които се изискват, било то достъп само за четене или достъп за запис. В същото време няма данни, изложени на никоя страна, която не е упълномощена да ги види. Сигурността е измамна: можете да мислите, че имате всичко защитено, само за да разберете по-късно, че има дупки. Проектирането в защита от началото на проекта е далеч по-лесно, отколкото да се опитвате да го модернизирате по-късно.

„Устойчив“ означава, че вашите услуги толерират откази в инфраструктурата. Неуспех може да бъде дисковият контролер на сървъра, който вече няма достъп до дискове, което прави данните недостъпни. Или повредата може да е мрежов превключвател, който вече не позволява на две или повече системи да комуникират. В този контекст „единична точка на отказ“ или SPOF е отказ, който се отразява неблагоприятно на наличността на услугата. Еластичната инфраструктура е тази без SPOF.

„Scalable“ описва способността на системите да се справят грациозно с пиковете на търсенето. Той също така диктува колко лесно могат да се правят промени в системите. Например добавяне на нов потребител, увеличаване на капацитета за съхранение или преместване на инфраструктура от Amazon Web Services в Google Cloud - или дори преместване вътрешно.

Веднага след като вашата инфраструктура се разшири отвъд един сървър, има много възможности за увеличаване на сигурността, устойчивостта и мащабируемостта. Ще разгледаме как тези проблеми се решават традиционно и какви нови технологии са на разположение, които променят облика на големите компютърни приложения.

Вземете повече Linux!

Наслаждаваш се на това, което четеш? Искате повече Linux и отворен код? Можем да доставим буквално! Абонирайте се за Linux Format днес на изгодна цена. Можете да получите издания за печат, дигитални издания или защо не и двете? Доставяме до Вашата врата по целия свят за проста годишна такса. Затова направете живота си по-добър и по-лесен, абонирайте се сега!

За да разберете какво е възможно днес, е полезно да разгледате как традиционно се изпълняват технологични проекти. Навремето - т.е. преди повече от 10 години - предприятията щяха да купуват или дават под наем хардуер, за да изпълняват всички компоненти на своите приложения. Дори относително прости приложения, като уебсайт на WordPress, имат множество компоненти. В случая на WordPress е необходима база данни MySQL заедно с уеб сървър, като Apache, и начин за работа с PHP код. Така че те щяха да създадат сървър, да настроят Apache, PHP и MySQL, да инсталират WordPress и да тръгнат.

Като цяло това работи. Работи достатъчно добре, че все още има огромен брой сървъри, конфигурирани точно по този начин днес. Но не беше перфектно и два от най-големите проблеми бяха устойчивостта и мащабируемостта.

Липсата на устойчивост означава, че всеки съществен проблем на сървъра ще доведе до загуба на услуга. Очевидно катастрофалният провал би означавал липса на уебсайт, но също така нямаше място за извършване на планова поддръжка, без да се повлияе на уебсайта. Дори инсталирането и активирането на рутинна актуализация на защитата за Apache ще изисква прекъсване на уебсайта за няколко секунди.

Проблемът с устойчивостта беше решен до голяма степен чрез изграждането на „клъстери с висока наличност“. Принципът беше да има два сървъра, работещи с уебсайта, конфигурирани така, че отказът на единия да не доведе до спиране на уебсайта. Предоставяната услуга е била устойчива, дори ако отделните сървъри не са били.

Абстрактни облаци

Част от силата на Kubernetes е абстракцията, която предлага. От гледна точка на разработчика те разработват приложението, което да се изпълнява в контейнер на Docker. Docker не се интересува дали работи под Windows, Linux или друга операционна система. Същият контейнер на Docker може да бъде взет от MacBook на разработчика и да се изпълнява под Kubernetes без никакви модификации.

Самата инсталация на Kubernetes може да бъде една машина. Разбира се, много от предимствата на Kubernetes няма да бъдат достъпни: няма да има автоматично мащабиране; има очевидна единична точка на провал и т.н. Като доказателство за концепцията в тестова среда обаче тя работи.

След като сте готови за производство, можете да стартирате вътрешно или на доставчик на облак, като AWS или Google Cloud. Облачните доставчици имат някои вградени услуги, които подпомагат стартирането на Kubernetes, но нито едно от тях не е строго изискване. Ако искате да се придвижите между Google, Amazon и вашата собствена инфраструктура, настройте Kubernetes и преминете. Нито едно от вашите приложения не трябва да се променя по никакъв начин.

А къде е Linux? Kubernetes работи под Linux, но операционната система е невидима за приложенията. Това е важна стъпка в зрелостта и използваемостта на ИТ инфраструктурите.

Ефектът на Slashdot

Проблемът с мащабируемостта е малко по-сложен. Да приемем, че вашият WordPress сайт получава 1000 посетители месечно. Един ден вашият бизнес се споменава по радио 4 или телевизия за закуска. Изведнъж получавате посетители за повече от месец за 20 минути. Всички сме чували истории за „сривове“ на уебсайтове и ето защо обикновено: липса на мащабируемост.

Двата сървъра, които помогнаха за устойчивостта, можеха да управляват по-голямо натоварване, отколкото само един сървър, но това все още е ограничено. Ще платите за два сървъра 100 процента от времето и през повечето време и двамата работеха перфектно. Вероятно само един може да управлява вашия сайт. Тогава Джон Хъмфрис споменава бизнеса ви в Днес и ще ви трябват 10 сървъра, за да се справите с товара - но само за няколко часа.

По-доброто решение както за устойчивостта, така и за проблема с мащабируемостта бяха изчисленията в облак. Настройте един или два екземпляра на сървъра - малките сървъри, които изпълняват вашите приложения - на Amazon Web Services (AWS) или Google Cloud и ако един от екземплярите не успее по някаква причина, той автоматично ще бъде рестартиран. Настройте правилно автоматично мащабиране и когато г-н Humphrys предизвика бързо нарастване на натоварването на вашите екземпляри на вашия уеб сървър, автоматично стартират допълнителни екземпляри на сървъра, за да споделят натоварването. По-късно, когато лихвите намаляват, тези допълнителни случаи се спират и вие плащате само за това, което използвате. Перфектно … или е така?

Докато облачното решение е много по-гъвкаво от традиционния самостоятелен сървър, все още има проблеми. Актуализирането на всички работещи екземпляри в облака не е лесно. Разработването за облака също има предизвикателства: лаптопът, който вашите разработчици използват, може да е подобен на облачния екземпляр, но не е същият. Ако се ангажирате с AWS, мигрирането към Google Cloud е сложно начинание. И да предположим, че по каквато и да е причина просто не искате да предавате компютрите си на Amazon, Google или Microsoft?

Контейнерите се появиха като средство за увиване на приложения с всичките им зависимости в един пакет, който може да се изпълнява навсякъде. Контейнери, като Docker, могат да работят на лаптопите на вашите разработчици по същия начин, както те работят на вашите облачни екземпляри, но управлението на флота от контейнери става все по-голямо предизвикателство, тъй като броят на контейнерите нараства.

Отговорът е оркестрация на контейнери. Това е значителна промяна във фокуса. Преди се уверихме, че разполагаме с достатъчно сървъри, били те физически или виртуални, за да гарантираме, че можем да обслужваме натоварването. Използването на автоматично мащабиране на доставчиците на облак помогна, но все още се занимавахме с екземпляри. Трябваше да конфигурираме балансьори на натоварване, защитни стени, съхранение на данни и много други ръчно. С оркестрацията на контейнери се полагат грижи за всичко това (и много повече). Ние посочваме резултатите, които се изискват, и нашите инструменти за оркестрация на контейнери отговарят на нашите изисквания. Ние уточняваме какво искаме да направим, а не как го искаме.

Непрекъснатата интеграция и непрекъснатото внедряване могат да работят добре с Kubernetes. Ето преглед на Jenkins, който се използва за изграждане и внедряване на Java приложение

Станете Kubernete

Kubernetes (ku-ber-net-eez) е водещият инструмент за оркестрация на контейнери днес и идва от Google. Ако някой знае как да управлява огромни ИТ инфраструктури, Google го знае. Произходът на Kubernetes е Borg, вътрешен проект на Google, който все още се използва за стартиране на повечето приложения на Google, включително неговата търсачка, Gmail, Google Maps и др. Борг беше тайна, докато Google публикува статия за това през 2015 г., но от хартията стана ясно, че Борг е основното вдъхновение зад Kubernetes.

Borg е система, която управлява изчислителните ресурси в центровете за данни на Google и поддържа приложенията на Google, както производствени, така и други, да работят въпреки хардуерна повреда, изтощение на ресурси или други възникващи проблеми, които иначе биха могли да причинят прекъсване. Това се прави чрез внимателно наблюдение на хилядите възли, които изграждат „клетка” на Borg и работещите върху тях контейнери, и стартиране или спиране на контейнери, както се изисква в отговор на проблеми или колебания в товара.

Самата Kubernetes е родена от инициативата на Google GIFEE („Инфраструктурата на Google за всички останали“) на Google и е проектирана да бъде по-приятелска версия на Borg, която може да бъде полезна извън Google. Той е дарен на Linux Foundation през 2015 г. чрез създаването на Cloud Native Computing Foundation (CNCF).

Kubernetes предоставя система, чрез която вие „декларирате“ вашите контейнерирани приложения и услуги и гарантира, че вашите приложения работят в съответствие с тези декларации. Ако вашите програми изискват външни ресурси, като например балансиращи устройства за съхранение или натоварване, Kubernetes може да ги осигури автоматично. Той може да мащабира вашите приложения нагоре или надолу, за да е в крак с промените в натоварването, и дори може да мащабира целия ви клъстер, когато е необходимо. Компонентите на вашата програма дори не трябва да знаят къде работят: Kubernetes предоставя услуги за вътрешно именуване на приложения, за да могат да се свържат с „wp_mysql“ и да бъдат автоматично свързани с правилния ресурс. “

Крайният резултат е платформа, която може да се използва за стартиране на вашите приложения на всяка инфраструктура, от една машина през локална система от системи до облачни бази от виртуални машини, работещи на който и да е основен доставчик в облака, като всички използват едни и същи контейнери и конфигурация. Kubernetes е агностик на доставчика: стартирайте го, където искате.

Kubernetes е мощен инструмент и задължително е сложен. Преди да влезем в общ преглед, трябва да представим някои термини, използвани в Kubernetes. Контейнерите изпълняват единични приложения, както беше обсъдено по-горе, и са групирани в под. Под е група от тясно свързани контейнери, които са разположени заедно на един и същ хост и споделят някои ресурси. Контейнерите в подсистемата работят в екип: те ще изпълняват свързани функции, като контейнер за приложения и контейнер за регистриране със специфични настройки за приложението.

Преглед на Kubernetes, показващ главното устройство, изпълняващо ключовите компоненти и два възела. Имайте предвид, че на практика главните компоненти могат да бъдат разделени на множество системи

Четири ключови компонента на Kubernetes са API Server, Scheduler, Controller Manager и разпределена база данни за конфигурация, наречена etcd. API сървърът е в основата на Kubernetes и действа като основна крайна точка за всички заявки за управление. Те могат да бъдат генерирани от различни източници, включително други компоненти на Kubernetes, като планировчик, администратори чрез команден ред или уеб-базирани табла за управление и самите контейнерирани приложения. Той проверява заявките и актуализира данните, съхранявани в etcd.

Планировщикът определя на кои възли ще работят различните подси, като взема предвид ограничения като изисквания за ресурси, всякакви хардуерни или софтуерни ограничения, натоварване, срокове и други.

Диспечерът на контролерите следи състоянието на клъстера и ще се опита да стартира или спре подси, както е необходимо, чрез API сървъра, за да доведе клъстера до желаното състояние. Той също така управлява някои вътрешни връзки и функции за сигурност.

Всеки възел изпълнява Kubelet процес, който комуникира със API сървъра и управлява контейнери - обикновено с помощта на Docker - и Kube-Proxy, който обработва мрежово проксиране и балансиране на натоварването в рамките на клъстера.

Системата за разпределена база данни etcd получава името си от / и т.н. папка на Linux системи, която се използва за съхраняване на информация за конфигурацията на системата, плюс наставката „d“, често използвана за обозначаване на демон процес. Целите на etcd са да съхранява данни ключ-стойност по разпределен, последователен и устойчив на грешки начин.

API сървърът съхранява всичките си данни за състоянието в etcd и може да изпълнява много екземпляри едновременно. Планировчикът и диспечерът на контролера могат да имат само един активен екземпляр, но използва система за лизинг, за да определи кой работещ екземпляр е главният. Всичко това означава, че Kubernetes може да работи като високодостъпна система без единични точки на повреда.

Събирайки всичко

И така, как да използваме тези компоненти на практика? Следва пример за настройка на уебсайт на WordPress с помощта на Kubernetes. Ако искате да направите това реално, вероятно ще използвате предварително дефинирана рецепта, наречена кормилна карта. Те са достъпни за редица често срещани приложения, но тук ще разгледаме някои от стъпките, необходими за създаване и работа на сайт на WordPress на Kubernetes.

Първата задача е да се определи парола за MySQL:

 kubectl създайте тайна обща mysql-pass --from-literal = парола = YOUR_PASSWORD

kubectl ще разговаря с API сървъра, който ще провери командата и след това ще съхрани паролата в etcd. Нашите услуги са дефинирани в YAML файлове и сега се нуждаем от постоянно съхранение за базата данни MySQL.

 apiVersion: v1 вид: PersistentVolumeClaim метаданни: name: mysql-pv-label labels: app: wordpress spec: accessModes: - ReadWriteOnce ресурси: заявки: съхранение: 20Gi

Спецификацията трябва да бъде самообяснима. Полетата за име и етикети се използват за препратка към това хранилище от други части на Kubernetes, в този случай нашия WordPress контейнер.

След като дефинираме хранилището, можем да дефинираме екземпляр на MySQL, насочвайки го към предварително дефинираното хранилище. Това е последвано от дефиниране на самата база данни. Ние даваме на тази база данни име и етикет за лесна справка в Kubernetes.

Сега се нуждаем от друг контейнер за стартиране на WordPress. Част от спецификацията за разполагане на контейнера е:

 вид: Метаданни за внедряване: име: wordpress етикети: приложение: wordpress спецификация: стратегия: тип: Пресъздаване

Типът стратегия „Пресъздаване“ означава, че ако някой от кода, съдържащ приложението се промени, изпълняващите се екземпляри ще бъдат изтрити и пресъздадени. Другите опции включват възможност за цикъл на нови екземпляри и премахване на съществуващи екземпляри, един по един, което позволява на услугата да продължи да работи по време на разполагането на актуализация. И накрая, декларираме услуга за самия WordPress, включваща PHP кода и Apache. Част от YAML файла, деклариращ това е:

 метаданни: име: wordpress етикети: app: wordpress spec: ports: - port: 80 селектор: app: wordpress tier: frontend type: LoadBalancer

Обърнете внимание на последния ред, дефинирайки типа услуга като LoadBalancer. Това инструктира Kubernetes да направи услугата достъпна извън Kubernetes. Без тази линия това би било само вътрешна услуга „Само Kubernetes“. И това е. Kubernetes сега ще използва тези YAML файлове като декларация за това, което се изисква, и ще настрои подсистеми, връзки, съхранение и така нататък, както е необходимо, за да вкара клъстера в „желаното“ състояние.

Използвайте изгледа на таблото, за да получите накратко обобщение на Kubernetes в действие

Това непременно е само обзор на високо ниво на Kubernetes и много подробности и характеристики на системата са пропуснати. Прегледахме автоматично мащабиране (както под, така и възлите, които съставляват клъстер), cron задания (стартиране на контейнери по график), Ingress (HTTP балансиране на натоварването, пренаписване и SSL разтоварване), RBAC (контрол на достъпа на базата на роли) , мрежови политики (защитна стена) и много други. Kubernetes е изключително гъвкав и изключително мощен: за всяка нова ИТ инфраструктура той трябва да бъде сериозен претендент.

Ресурси

Ако не сте запознати с Docker, започнете от тук: https://docs.docker.com/get-started.

Тук има интерактивен урок за внедряване и мащабиране на приложение: https://kubernetes.io/docs/tutorials/kubernetes-basics.

И вижте https://kubernetes.io/docs/setup/scratch за това как да изградите клъстер.

Можете да играете с безплатен клъстер Kubernetes на https://tryk8s.com.

И накрая, можете да разгледате дълга техническа книга с отличен преглед на използването на Borg от Google и как това е повлияло на дизайна на Kubernetes тук: https://storage.googleapis.com/pub-tools-public-publication-data/ pdf / 43438.pdf.

Научете повече за Tiger Computing.