Когато искате да използвате Linux за предоставяне на услуги на бизнес, тези услуги трябва да бъдат сигурни, устойчиви и мащабируеми. Хубави думи, но какво имаме предвид под тях?
‘Secure’ означава, че потребителите могат да имат достъп до необходимите им данни, независимо дали имат достъп само за четене или запис. В същото време никаква страна не излага данни’не е упълномощен да го вижда. Сигурността е измамна: можете да мислите, че имате всичко защитено, само за да разберете по-късно, че има дупки. Проектирането в сигурност от началото на проекта е много по-лесно, отколкото да се опитате да го преоборудвате по-късно.
‘гъвкав’ означава, че вашите услуги търпят повреди в инфраструктурата. Провал може да е сървър на дисковия контролер, който вече не може да има достъп до никакви дискове, което прави данните недостъпни. Или отказът може да е мрежов превключвател, който вече не позволява на две или повече системи да комуникират. В този контекст a “единична точка на отказ” или SPOF е повреда, която се отразява неблагоприятно на достъпността на услугата. Устойчивата инфраструктура е такава, без SPOF.
‘Scalable’ описва способността на системите да се справят с шипове на търсенето грациозно. Той също така диктува колко лесно могат да се правят промени в системите. Например, добавяне на нов потребител, увеличаване на капацитета за съхранение или преместване на инфраструктура от Amazon Web Services в Google Cloud – или дори преместването му вътрешно.
Веднага щом вашата инфраструктура се разшири отвъд един сървър, има много възможности за повишаване на сигурността, устойчивостта и мащабируемостта. ние’Ще разгледаме как тези проблеми се решават традиционно и какви нови технологии са налични, които променят лицето на големите компютърни приложения.
За да разбера какво’е възможно днес, то’е полезно да разгледаме как традиционно се изпълняват технологичните проекти. В миналото – тоест преди повече от 10 години – предприятията ще купуват или отдават под наем хардуер, за да изпълняват всички компоненти на своите приложения. Дори сравнително прости приложения, като уебсайт на WordPress, имат множество компоненти. В случая на WordPress е необходима MySQL база данни заедно с уеб сървър, като Apache, и начин за работа с PHP код. Така че те’d изграждане на сървър, настройване на Apache, PHP и MySQL, инсталиране на WordPress и изключване от тях’ще отида.
Като цяло, това работеше. Работи достатъчно добре, че все още има огромен брой сървъри, конфигурирани точно по този начин днес. Но не беше’t перфектен, а два от по-големите проблеми бяха устойчивостта и мащабируемостта.
Липсата на устойчивост означаваше, че всеки съществен проблем на сървъра би довел до загуба на услуга. Очевидно катастрофална повреда ще означава, че няма уебсайт, но също така нямаше място за извършване на планирана поддръжка, без да се отрази на уебсайта. Дори инсталирането и активирането на рутинна актуализация на сигурността за Apache ще изисква няколко секунди’ прекъсване на уебсайта.
Проблемът с устойчивостта до голяма степен беше решен чрез изграждане ‘групи с висока наличност’. Принципът беше да има два сървъра, работещи с уебсайта, конфигурирани така, че да се провали нито един’да доведе до отпадане на уебсайта. Предоставяната услуга беше устойчива, дори ако отделните сървъри не бяха.
Абстрактни облаци
Част от силата на Кубернети е абстракцията, която предлага. От разработчик’от гледна точка, те разработват приложението, за да стартират в Docker контейнер. Докер не знае’не ми пука дали’работи на Windows, Linux или друга операционна система. Същият Docker контейнер може да бъде взет от програмиста’s MacBook и работи под Kubernetes без никакви изменения.
Самата инсталация на Kubernetes може да бъде една машина. Разбира се, много от предимствата на спечелените Кубернети’t да бъдат налични: няма да има автоматично мащабиране; там’s очевидна единична точка на провал и т.н. Като доказателство за концепция в тестова среда обаче работи.
Веднъж ти’готови за производство, можете да стартирате вътрешно или от доставчик на облак като AWS или Google Cloud. Облачните доставчици имат някои вградени услуги, които помагат за стартирането на Kubernetes, но нито едно от тях не е трудни изисквания. Ако искате да се движите между Google, Amazon и вашата собствена инфраструктура, вие настройвате Kubernetes и се движите навътре. Нито едно от вашите приложения не трябва да се променя по никакъв начин.
И къде е Linux? Kubernetes работи на Linux, но операционната система е невидима за приложенията. Това е значителна стъпка към зрелостта и използваемостта на ИТ инфраструктурите.
Ефектът Slashdot
Проблемът с мащабируемостта е малко по-сложен. Позволявам’Кажете, че вашият WordPress сайт получава 1000 посетители на месец. Един ден вашият бизнес се споменава по радио 4 или закуска за телевизия. Изведнъж получавате повече от месец’струва посетители за 20 минути. ние’всички чух истории на уебсайтове ‘трясък’, и това’s обикновено защо: липса на мащабируемост.
Двата сървъра, които помогнаха за устойчивост, можеха да управляват по-голямо натоварване, отколкото един сървър сам, но това’е все още ограничен. Ти’бих плащал за два сървъра 100 на сто от времето и през повечето време и двата работеха перфектно. То’е вероятно един човек да може да управлява вашия сайт. Тогава Джон Хъмфрис споменава вашия бизнес на Днес и вие’трябва 10 сървъра, за да се справят с товара, но само за няколко часа.
По-доброто решение както на проблема с устойчивостта, така и на мащабируемостта бяха облачните изчисления. Настройте сървър или два екземпляра – малките сървъри, които стартират вашите приложения – в Amazon Web Services (AWS) или Google Cloud и ако някой от случаите се провали по някаква причина, той автоматично ще бъде рестартиран. Настройте правилно автоматичното мащабиране и когато г-н Humphrys причини натоварването на инстанциите на вашия уеб сървър бързо да нараства, допълнителните сървърни копия автоматично започват да споделят натовареността. По-късно, с намаляването на лихвите, тези допълнителни инстанции се спират и плащате само за това, което използвате. съвършен… или е така?
Въпреки че облачното решение е много по-гъвкаво от традиционния самостоятелен сървър, все още има проблеми. Актуализиране на всички работещи екземпляри в облак не е’t направо. Разработката за облака също има предизвикателства: лаптопът, който вашите разработчици използват, може да е подобен на облачния екземпляр, но това е така’не е същото. Ако се ангажирате с AWS, мигрирането към Google Cloud е сложно начинание. И да предположим, по каквато и да е причина, просто нямате’не искате да предадете вашите изчисления на Amazon, Google или Microsoft?
Контейнерите се появиха като средство за опаковане на приложения с всичките им зависимости в един пакет, който може да се изпълнява навсякъде. Контейнери, като Docker, могат да работят на вашите разработчици’ лаптопи по същия начин, както те се изпълняват в облачните ви случаи, но управлението на флота от контейнери става все по-трудно, тъй като броят на контейнерите расте.
Отговорът е оркестрация на контейнери. Това е значително изместване на фокуса. Преди се уверихме, че имаме достатъчно сървъри, били те физически или виртуални, за да гарантираме, че можем да обслужваме натовареността. Използване на облачните доставчици’ автоматичното скалиране помогна, но ние все още се занимавахме с случаи. Трябваше да конфигурираме ръчно балансиращи устройства, защитни стени, съхранение на данни и други. С контейнерната оркестрация се грижи всичко това (и много повече). Ние уточняваме необходимите резултати и нашите инструменти за оркестрация на контейнери изпълняват нашите изисквания. Ние уточняваме какво искаме да бъде направено, а не как искаме да е направено.
Непрекъснатата интеграция и непрекъснатото внедряване могат да работят добре с Kubernetes. Тук’s преглед на Jenkins, който се използва за изграждане и внедряване на Java приложение
(Графичен кредит: Бъдеще)
Станете кубернета
Kubernetes (ku-ber-net-eez) е водещият инструмент за оркестриране на контейнери днес и той идва от Google. Ако някой знае как да управлява огромни ИТ инфраструктури, Google прави. Произходът на Kubernetes е Borg, вътрешен проект на Google, който’все още се използва за управление на повечето от Google’s приложения, включително неговата търсачка, Gmail, Google Maps и други. Борг беше тайна, докато Google не публикува статия за това през 2015 г., но от вестника стана ясно, че Борг е главното вдъхновение зад Kubernetes.
Borg е система, която управлява изчислителните ресурси в Google’s центрове за данни и поддържа Google’s приложения, както производствени, така и по друг начин, работещи въпреки повреда в хардуера, изтощение на ресурси или други възникващи проблеми, които в противен случай биха могли да причинят прекъсване. Това прави, като внимателно наблюдава хилядите възли, които съставят Борг “клетка” и контейнерите, работещи върху тях, и пускане или спиране на контейнери, както се изисква в отговор на проблеми или колебания в товара.
Самата Kubernetes се роди извън Google’s ПОДАРЪК (‘Google’s Инфраструктура за всички останали’) инициатива и е проектиран да бъде по-приятелска версия на Borg, която може да бъде полезна извън Google. Той бе дарен на Фондация Linux през 2015 г. чрез създаването на Фондация за облачни изчислителни технологии в облака (CNCF).
Kubernetes предоставя система, чрез която вие “декларират” вашите контейнерни приложения и услуги и той гарантира, че приложенията ви работят в съответствие с тези декларации. Ако вашите програми изискват външни ресурси, като например балансиращи устройства за съхранение или зареждане, Kubernetes могат да ги предоставят автоматично. Той може да мащабира приложенията ви нагоре или надолу, за да бъдете в крак с промените в натоварването и дори може да мащабира целия си клъстер, когато е необходимо. Вашата програма’s компоненти don’дори трябва да знам къде са’отново работи: Kubernetes предоставя вътрешни услуги за именуване на приложения, така че те да могат да се свързват “wp_mysql” и да бъде автоматично свързан с правилния ресурс.’
Крайният резултат е платформа, която може да се използва за стартиране на вашите приложения във всяка инфраструктура, от една машина през локален стелаж от системи до облачни бази от виртуални машини, работещи на всеки основен доставчик на облак, като всички използват същите контейнери и конфигурация. Kubernetes е доставчик-агностик: стартирайте го където искате.
Kubernetes е мощен инструмент и задължително е сложен. Преди да преминем към преглед, трябва да въведем някои термини, използвани в Kubernetes. Контейнерите изпълняват единични приложения, както беше обсъдено по-горе, и са групирани в шушулки. Под е група от тясно свързани контейнери, които са разположени заедно на един и същ хост и споделят някои ресурси. Контейнерите в рамките на шушулка работят като екип: те’Ще изпълнявам свързани функции, като контейнер за приложения и контейнер за регистриране със специфични настройки за приложението.
Преглед на Kubernetes, показващ главния управляващ ключовите компоненти и два възла. Обърнете внимание, че на практика главните компоненти могат да бъдат разделени на множество системи
(Графичен кредит: Бъдеще)
Четири ключови компонента на Kubernetes са API Server, Scheduler, Controller Manager и разпределена база данни за конфигурация, наречена etcd. API сървърът е в основата на Kubernetes и действа като основна крайна точка за всички заявки за управление. Те могат да бъдат генерирани от различни източници, включително други компоненти на Kubernetes, като планиращия, администраторите чрез командния ред или уеб-базирани табла за управление и самите приложения за контейнери. Той потвърждава заявките и актуализира данните, съхранявани в etcd.
Графикът определя на кои възли ще се изпълняват различните шушулки, като се вземат предвид ограниченията като изисквания към ресурсите, всякакви хардуерни или софтуерни ограничения, работно натоварване, срокове и други.
Мениджърът на контролера следи състоянието на клъстера и ще се опита да стартира или спира pods, както е необходимо, чрез API сървъра, за да приведе клъстера до желаното състояние. Той също така управлява някои вътрешни връзки и функции за защита.
Всеки възел изпълнява процес на Kubelet, който комуникира с API сървъра и управлява контейнери – обикновено използвайки Docker – и Kube-Proxy, който обработва мрежата, проксимираща и зареждаща балансиране в рамките на клъстера.
Системата за разпределена база данни etcd получава името си от / и т.н. папка на Linux системи, която се използва за съхраняване на информация за системната конфигурация, плюс наставката ‘д’, често се използва за означаване на процес на демон. Целите на etcd са да съхраняват данни от ключова стойност по разпределен, последователен и устойчив на неизправности начин.
API сървърът съхранява всички данни за състоянието си в etcd и може да изпълнява много случаи едновременно. Мениджърът за планиране и контролер може да има само един активен екземпляр, но използва система за лизинг, за да определи кой работещ екземпляр е главният. Всичко това означава, че Kubernetes може да работи като високодостъпна система без единични точки на повреда.
Поставяме всичко заедно
И така, как да използваме тези компоненти на практика? Това, което следва, е пример за настройка на уебсайт на WordPress с помощта на Kubernetes. Ако сте искали да направите това за истински, тогава вие’d вероятно използвам предварително дефинирана рецепта, наречена диаграма на кормилото. Те са достъпни за редица често срещани приложения, но тук ние’Ще разгледаме някои от стъпките, необходими за стартиране и работа на WordPress сайт в Kubernetes.
Първата задача е да определите парола за MySQL:
kubectl създаване на секретен общ mysql-pass – от-literal = парола = YOUR_PASSWORD
kubectl ще говори с API сървъра, който ще валидира командата и след това ще съхранява паролата в etcd. Услугите ни са дефинирани в YAML файлове и сега се нуждаем от постоянно устойчиво съхранение за MySQL базата данни.
apiVersion: v1kind: PersistentVolumeClaimmetadata: име: mysql-pv-вземане на етикети: приложение: wordpressspec: accessModes: – ReadWriteOnceresources: искания: съхранение: 20Gi
Спецификацията трябва да бъде най-вече самостоятелна. Полетата за име и етикети се използват за обозначаване на това хранилище от други части на Kubernetes, в случая нашия контейнер WordPress.
Веднъж ние’като дефинирахме съхранението, можем да определим MySQL екземпляр, насочвайки го към предварително дефинираното съхранение. Че’s, последвано от дефиниране на самата база данни. Ние даваме име и етикет на тази база данни за лесна справка в Kubernetes.
Сега имаме нужда от друг контейнер, за да стартираме WordPress. Част от спецификацията за разполагане на контейнера е:
вид: Deploymentmetadata: име: wordpresslabels: приложение: wordpressspec: стратегия: тип: Пресъздайте
Тип на стратегията “Recreate” означава, че ако някой от кода, съдържащ приложението, се променя, тогава работещите екземпляри ще бъдат изтрити и пресъздадени. Други опции включват възможност за циклиране на нови инстанции във и премахване на съществуващи екземпляри, една по една, което позволява на услугата да продължи да се изпълнява по време на разгръщане на актуализация. И накрая, ние декларираме услуга за самия WordPress, състоящ се от PHP код и Apache. Част от YAML файла, деклариращ това е:
метаданни: име: wordpresslabels: приложение: wordpressspec: пристанища: – порт: 80selector: приложение: wordpresstier: frontendtype: LoadBalancer
Забележете последния ред, определящ типа услуга като LoadBalancer. Това инструктира Kubernetes да направи услугата достъпна извън Kubernetes. Без тази линия това би било просто вътрешно “Само Кубернети” обслужване. И това’е то. Kubernetes вече ще използва тези YAML файлове като декларация за това, което се изисква и ще настрои шушулки, връзки, съхранение и така нататък, както е необходимо, за да вкара клъстера в “желания” състояние.
Използвайте изгледа на таблото, за да получите накратко обобщение на Kubernetes в действие
(Кредит за изображение: Ditching)
Това непременно е било само преглед на високо ниво на Kubernetes и много подробности и характеристики на системата бяха пропуснати. ние’озаглавен за автоматично мащабиране (както шушулки, така и възлите, които съставляват клъстер), cron задания (стартиране на контейнери според график), Ingress (HTTP балансиране на зареждане, пренаписване и разтоварване на SSL), RBAC (ролеви контрол на достъпа), мрежа политики (защитна стена) и много други. Kubernetes е изключително гъвкав и изключително мощен: за всяка нова ИТ инфраструктура той трябва да бъде сериозен конкурент.
ресурси
Ако ти’не сте запознати с Docker започнете от тук: https://docs.docker.com/get-started.
Там’s интерактивен урок за разгръщане и мащабиране на приложение тук: https://kubernetes.io/docs/tutorials/kubernetes-basics.
И вижте https://kubernetes.io/docs/setup/scratch как да създадете клъстер.
Можете да играете с безплатен клъстер Kubernetes на https://tryk8s.com.
И накрая, можете да пореете върху дълга, техническа хартия с отличен преглед на Google’използването на Borg и как това повлия на дизайна на Kubernetes тук: https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43438.pdf.
Научете повече за Tiger Computing.
- Най-добро съхранение в облак на 2019 г. онлайн: безплатни, платени и бизнес опции
