Куб върху куб, метаклъстери, пчелни пити, разпределение на ресурси

Ориз. 1. Екосистема Kubernetes на Alibaba Cloud

От 2015 г. Alibaba Cloud Container Service за Kubernetes (ACK) е една от най-бързо развиващите се облачни услуги в Alibaba Cloud. Той обслужва множество клиенти и също така поддържа вътрешната инфраструктура на Alibaba и другите облачни услуги на компанията.

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

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

Влизане

Kubernetes се превърна в де факто стандарт за различни работни натоварвания в облака. Както е показано на фиг. 1 по-горе, все повече и повече приложения на Alibaba Cloud вече работят на клъстери на Kubernetes: приложения със състояние и без състояние, както и мениджъри на приложения. Управлението на Kubernetes винаги е било интересна и сериозна тема за дискусия за инженерите, които изграждат и поддържат инфраструктура. Когато става дума за облачни доставчици като Alibaba Cloud, проблемът с мащабирането излиза на преден план. Как да управлявате Kubernetes клъстери в този мащаб? Вече разгледахме най-добрите практики за управление на огромни клъстери Kubernetes с 10 000 възела. Разбира се, това е интересен проблем за мащабиране. Но има и друга скала: количеството самите клъстери.

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

Ориз. 2. Проблеми с управлението на огромен брой Kubernetes клъстери

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

• Разнородност

ACK трябва да поддържа различни видове клъстери, включително стандартни, без сървър, Edge, Windows и няколко други. Различните клъстери изискват различни опции, компоненти и хостинг модели. Някои клиенти се нуждаят от помощ при персонализиране за техните специфични случаи.

• Различни размери на клъстери

Клъстерите варират по размер: от няколко възли с няколко подове до десетки хиляди възли с хиляди подове. Изискванията за ресурси също варират значително. Неправилното разпределение на ресурсите може да повлияе на производителността или дори да причини неуспех.

• Различни версии

Kubernetes се развива много бързо. Нови версии се пускат на всеки няколко месеца. Клиентите винаги са готови да изпробват нови функции. Така че те искат да поставят тестовото натоварване върху новите версии на Kubernetes и производственото натоварване върху стабилните. За да изпълни това изискване, ACK трябва непрекъснато да доставя нови версии на Kubernetes на клиентите, като същевременно поддържа стабилни версии.

• Съответствие със сигурността

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

Платформата ACK е проектирана да решава повечето от горните проблеми. В момента той надеждно и стабилно управлява повече от 10 хиляди клъстера Kubernetes по целия свят. Нека да разгледаме как е постигнато това, включително чрез няколко ключови принципа на дизайн/архитектура.

Дизайн

Куб на куб и пчелна пита

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

Всеки регион в облака Alibaba се състои от няколко зони (AZ) и обикновено съответства на конкретен център за данни. В голям регион (напр. Huangzhou) често има хиляди клиентски клъстери на Kubernetes, изпълняващи ACK.

ACK управлява тези Kubernetes клъстери, използвайки самия Kubernetes, което означава, че имаме Kubernetes метаклъстер, работещ за управление на клиентските Kubernetes клъстери. Тази архитектура се нарича още „kube-on-kube“ (KoK). Архитектурата KoK опростява управлението на клиентските клъстери, тъй като внедряването на клъстери е просто и детерминистично. По-важното е, че можем да използваме повторно собствените функции на Kubernetes. Например, управление на API сървъри чрез внедряване, използване на оператора etcd за управление на множество etcd. Такава рекурсия винаги носи особено удоволствие.

Няколко метакластъра на Kubernetes се разполагат в рамките на един регион, в зависимост от броя на клиентите. Ние наричаме тези метакластери клетки. За да защити срещу повреда на цяла зона, ACK поддържа мултиактивни внедрявания в един регион: метаклъстерът разпределя главните компоненти на клиентския клъстер на Kubernetes в множество зони и ги изпълнява едновременно, тоест в мултиактивен режим. За да гарантира надеждността и ефективността на главния, ACK оптимизира разположението на компонентите и гарантира, че API сървърът и etcd са близо един до друг.

Този модел ви позволява да управлявате Kubernetes ефективно, гъвкаво и надеждно.

Метаклъстерно планиране на ресурсите

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

Да вземем например мрежовите ресурси. В архитектурата KoK компонентите на Kubernetes от клиентски клъстери се разполагат като подове в метаклъстер. Ние използваме Теруей (Фиг. 3) е високоефективен плъгин, разработен от Alibaba Cloud за управление на контейнерна мрежа. Той предоставя богат набор от политики за сигурност и ви позволява да се свързвате с виртуални частни облаци (VPC) на клиентите чрез Alibaba Cloud Elastic Networking Interface (ENI). За да разпределим ефективно мрежовите ресурси между възли, подове и услуги в метаклъстер, трябва внимателно да наблюдаваме тяхното използване в метаклъстера на виртуални частни облаци. Когато мрежовите ресурси свършат, се създава нова клетка.

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

Ориз. 3. Мрежова архитектура на Terway

Компоненти на съветника за мащабиране в клиентски клъстери

Компонентите на съветника имат различни нужди от ресурси. Те зависят от броя на възлите и подовете в клъстера, броя на нестандартните контролери/оператори, взаимодействащи с APIServer.

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

За да намери фин компромис между надеждност и цена, ACK използва система от типове. А именно, ние дефинираме три вида клъстери: малки, средни и големи. Всеки тип има отделен профил за разпределение на ресурси. Типът се определя въз основа на натоварването на компонентите на съветника, броя на възлите и други фактори. Типът клъстер може да се промени с времето. ACK непрекъснато следи тези фактори и може да въвежда съответно нагоре/надолу. След като типът на клъстера бъде променен, разпределението на ресурсите се актуализира автоматично с минимална намеса на потребителя.

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

Ориз. 4. Интелигентно многостепенно превключване на типа

Еволюция на клиентските клъстери в мащаб

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

Kubernetes е „Linux“ на облачния свят. Той непрекъснато се актуализира и става по-модулен. Ние трябва постоянно да доставяме нови версии на нашите клиенти, да коригираме уязвимостите и да актуализираме съществуващите клъстери, както и да управляваме голям брой свързани компоненти (CSI, CNI, Device Plugin, Scheduler Plugin и много други).

Нека вземем за пример управление на компоненти на Kubernetes. Като начало разработихме централизирана система за регистриране и управление на всички тези свързани компоненти.

Ориз. 5. Гъвкави и щепселни компоненти

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

Ориз. 6. Предварителна проверка на компонентите на клъстера

За бързо и надеждно актуализиране на тези компоненти работи система за непрекъснато внедряване с поддръжка за частично напредване (скали на сивото), паузи и други функции. Стандартните контролери Kubernetes не са много подходящи за този случай на употреба. Ето защо, за да управляваме компонентите на клъстера, ние разработихме набор от специализирани контролери, включително плъгин и допълнителен контролен модул (управление на странични коли).

Например, контролерът BroadcastJob е проектиран да актуализира компоненти на всяка работна машина или да проверява възли на всяка машина. Заданието за излъчване изпълнява под на всеки възел в клъстера, като DaemonSet. Въпреки това, DaemonSet винаги поддържа пода работещ за дълго време, докато BroadcastJob го свива. Контролерът за излъчване също стартира подове на новосъединени възли и инициализира възлите с необходимите компоненти. През юни 2019 г. отворихме изходния код на двигателя за автоматизация OpenKruise, който ние самите използваме в рамките на компанията.

Ориз. 7. OpenKurise организира изпълнението на Broadcast задачата на всички възли

За да помогнем на клиентите да изберат правилните конфигурации на клъстера, ние също предоставяме набор от предварително дефинирани профили, включително профили без сървър, Edge, Windows и Bare Metal. Тъй като пейзажът се разширява и нуждите на нашите клиенти нарастват, ние ще добавим повече профили, за да опростим досадния процес на настройка.

Ориз. 8. Разширени и гъвкави клъстерни профили за различни сценарии

Глобална наблюдаемост в центровете за данни

Както е показано на фиг. 9, облачната услуга Alibaba Cloud Container е внедрена в двадесет региона по света. Като се има предвид този мащаб, една от ключовите цели на ACK е лесно да наблюдава състоянието на работещите клъстери, така че ако клиентски клъстер срещне проблем, да можем бързо да реагираме на ситуацията. С други думи, трябва да излезете с решение, което ще ви позволи ефективно и сигурно да събирате статистически данни в реално време от клиентски клъстери във всички региони - и визуално да представяте резултатите.

Ориз. 9. Глобално внедряване на услугата Alibaba Cloud Container в двадесет региона

Подобно на много системи за наблюдение Kubernetes, ние използваме Prometheus като наш основен инструмент. За всеки метаклъстер агентите на Prometheus събират следните показатели:

• Показатели на ОС, като ресурси на хоста (CPU, памет, диск и т.н.) и честотна лента на мрежата.
• Метрики за системата за управление на метаклъстер и клиентски клъстер, като kube-apiserver, kube-controller-manager и kube-scheduler.
• Метрики от kubernetes-state-metrics и cadvisor.
• etcd показатели като време за запис на диска, размер на база данни, пропускателна способност на връзки между възли и др.

Глобалните статистически данни се събират с помощта на типичен многослоен модел на агрегиране. Данните за наблюдение от всеки метаклъстер първо се агрегират във всеки регион и след това се изпращат до централен сървър, който показва цялостната картина. Всичко работи чрез механизма на федерацията. Сървър на Prometheus във всеки център за данни събира показатели от този център за данни, а централният сървър на Prometheus е отговорен за агрегирането на данни за наблюдение. AlertManager се свързва с централния Prometheus и изпраща предупреждения, ако е необходимо чрез DingTalk, имейл, SMS и т.н. Визуализация - Използване на Grafana.

На фигура 10 системата за мониторинг може да бъде разделена на три нива:

• Гранично ниво

Най-отдалеченият от центъра слой. Prometheus Edge Server работи във всеки метаклъстер, събирайки показатели от мета и клиентски клъстери в рамките на един и същи мрежов домейн.

• Каскадно ниво

Функцията на каскадния слой Prometheus е да събира данни за наблюдение от множество региони. Тези сървъри работят на ниво по-големи географски единици като Китай, Азия, Европа и Америка. С нарастването на клъстерите регионът може да бъде разделен и след това Prometheus сървър на каскадно ниво ще се появи във всеки нов голям регион. С тази стратегия можете плавно да мащабирате според нуждите.

• Централно ниво

Централният Prometheus сървър се свързва с всички каскадни сървъри и извършва окончателното агрегиране на данни. За надеждност две централни инстанции на Prometheus бяха повдигнати в различни зони, свързани към едни и същи каскадни сървъри.

Ориз. 10. Глобална многостепенна мониторингова архитектура, базирана на механизма за обединяване на Prometheus

Обобщение

Базираните на Kubernetes облачни решения продължават да трансформират нашата индустрия. Облачната контейнерна услуга на Alibaba предоставя сигурен, надежден и високопроизводителен хостинг - това е един от най-добрите облачни хостинги на Kubernetes. Екипът на Alibaba Cloud силно вярва в принципите на Open Source и общността с отворен код. Определено ще продължим да споделяме знанията си в областта на оперирането и управлението на облачни технологии.

Източник: www.habr.com