Kuutio kuutiolla, metaklusterit, hunajakennot, resurssien jakelu

Riisi. 1. Kubernetes-ekosysteemi Alibaba Cloudissa

С 2015 года Alibaba Cloud Container Service for Kubernetes (ACK) является одним из самых быстрорастущих облачных сервисов в Alibaba Cloud. Он обслуживает многочисленных клиентов, а также поддерживает внутреннюю инфраструктуру Alibaba и другие облачные сервисы компании.

Kuten maailmanluokan pilvipalveluntarjoajien vastaavien konttipalveluiden kohdalla, tärkein prioriteettimme ovat luotettavuus ja saatavuus. Siksi kymmenille tuhansille Kubernetes-klustereille on luotu skaalautuva ja maailmanlaajuisesti saavutettava alusta.

Tässä artikkelissa jaamme kokemuksemme lukuisten Kubernetes-klustereiden hallinnasta pilviinfrastruktuurissa sekä taustalla olevan alustan arkkitehtuurista.

Merkintä

Kubernetesista on tullut de facto standardi erilaisille pilvityökuormille. Kuten kuvassa näkyy. Kuvassa 1, yhä useammat Alibaba Cloud -sovellukset ovat nyt käynnissä Kubernetes-klustereissa: tilallisia ja tilattomia sovelluksia sekä sovellusten hallintaohjelmia. Kubernetes-hallinta on aina ollut mielenkiintoinen ja vakava keskustelunaihe infrastruktuuria rakentaville ja ylläpitäville insinööreille. Mitä tulee pilvipalveluntarjoajiin, kuten Alibaba Cloud, skaalauskysymys tulee esiin. Kuinka hallita Kubernetes-klustereita tässä mittakaavassa? Olemme jo käsitelleet parhaita käytäntöjä valtavien 10 000 solmun Kubernetes-klusterien hallintaan. Tämä on tietysti mielenkiintoinen skaalausongelma. Mutta on toinenkin asteikko: määrä itse klusterit.

Мы обсуждали эту тему со многими пользователями ACK. Большинство из них предпочитают запускать десятки, если не сотни, небольших или средних кластеров Kubernetes. На это есть разумные причины: ограничение потенциального ущерба, разделение кластеров для разных команд, создание виртуальных кластеров для тестирования. Если ACK стремится обслуживать глобальную аудиторию по такой модели использования, то должна надёжно и эффективно управлять большим количеством кластеров в более чем 20 регионах.

Riisi. 2. Valtavan Kubernetes-klustereiden hallinnan ongelmat

Mitkä ovat tämän mittakaavan klusterien hallinnan suurimmat haasteet? Kuten kuvasta näkyy, on käsiteltävä neljä asiaa:

• Heterogeenisuus

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

• Erilaisia ​​klusterin kokoja

Klusterit vaihtelevat kooltaan: muutamasta solmusta, joissa on useita tyynyjä, kymmeniin tuhansiin solmuihin, joissa on tuhansia paloja. Myös resurssivaatimukset vaihtelevat suuresti. Väärä resurssien allokointi voi vaikuttaa suorituskykyyn tai jopa aiheuttaa epäonnistumisen.

• Eri versiot

Kubernetes очень быстро развивается. Новые версии выходят каждые несколько месяцев. Клиенты всегда готовы пробовать новые функции. Таким образом, они хотят разместить тестовую нагрузку на новых версиях Kubernetes, а рабочую нагрузку — на стабильных. Чтобы удовлетворить это требование, ACK должна постоянно поставлять клиентам новые версии Kubernetes, в то же время поддерживая стабильные версии.

• Turvallisuusvaatimustenmukaisuus

Klusterit ovat jakautuneet eri alueille. Sellaisenaan niiden tulee täyttää erilaisia ​​turvallisuusvaatimuksia ja viranomaismääräyksiä. Esimerkiksi Euroopan klusterin on oltava GDPR-yhteensopiva, kun taas Kiinan talouspilvessä on oltava lisäsuojakerroksia. Nämä vaatimukset ovat pakollisia, eikä niitä voida hyväksyä, koska se aiheuttaa valtavia riskejä pilvialustan asiakkaille.

ACK-alusta on suunniteltu ratkaisemaan useimmat yllä mainituista ongelmista. Tällä hetkellä se hallitsee luotettavasti ja vakaasti yli 10 tuhatta Kubernetes-klusteria ympäri maailmaa. Katsotaanpa, kuinka tämä saavutettiin, mukaan lukien useiden suunnittelun/arkkitehtuurin keskeisten periaatteiden avulla.

Suunnittelu

Kuutio kuutiolla ja hunajakenno

Toisin kuin keskitetty hierarkia, solupohjaista arkkitehtuuria käytetään tyypillisesti alustan skaalaamiseen yhden datakeskuksen ulkopuolelle tai katastrofipalautuksen laajentamiseen.

Jokainen Alibaba Cloudin alue koostuu useista vyöhykkeistä (AZ) ja vastaa yleensä tiettyä datakeskusta. Suurella alueella (esim. Huangzhou) on usein tuhansia Kubernetes-asiakasklustereita, joissa on käytössä ACK.

ACK управляет этими кластерами Kubernetes с помощью самого Kubernetes, то есть у нас работает метакластер Kubernetes для управления клиентскими кластерами Kubernetes. Такая архитектура также называется «куб-на-кубе» (kube-on-kube, KoK). Архитектура KoK упрощает управление клиентскими кластерами, поскольку развёртывание кластера становится простым и детерминированным. Что ещё важнее, мы можем повторно использовать функции нативного Kubernetes. Например, управление API-серверами через деплой, использование оператора etcd для управления несколькими etcd. Такая рекурсия всегда приносит особое удовольствие.

Yhdellä alueella on käytössä useita Kubernetes-metaklustereita asiakkaiden lukumäärästä riippuen. Kutsumme näitä metaklustereita soluiksi. Suojatakseen koko vyöhykkeen epäonnistumiselta ACK tukee moniaktiivisia käyttöönottoja yhdellä alueella: metaklusteri jakaa Kubernetes-asiakasklusterin pääkomponentit useille vyöhykkeille ja suorittaa ne samanaikaisesti, eli moniaktiivisessa tilassa. Isäntäkoneen luotettavuuden ja tehokkuuden varmistamiseksi ACK optimoi komponenttien sijoittelun ja varmistaa, että API-palvelin ja etcd ovat lähellä toisiaan.

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

Metacluster-resurssisuunnittelu

Kuten jo mainitsimme, metaklusterien määrä kullakin alueella riippuu asiakkaiden määrästä. Mutta missä vaiheessa uusi metaklusteri lisätään? Tämä on tyypillinen resurssisuunnittelun ongelma. Yleensä on tapana luoda uusi, kun olemassa olevat metaklusterit ovat käyttäneet kaikki resurssinsa.

Otetaan esimerkiksi verkkoresurssit. KoK-arkkitehtuurissa asiakasklusterien Kubernetes-komponentit otetaan käyttöön podeina metaklusterissa. Käytämme Terway (Kuva 3) on Alibaba Cloudin kehittämä korkean suorituskyvyn laajennus konttiverkon hallintaan. Se tarjoaa runsaasti suojauskäytäntöjä ja mahdollistaa yhteyden muodostamisen asiakkaiden virtuaalisiin yksityispilviin (VPC) Alibaba Cloud Elastic Networking Interfacen (ENI) kautta. Jotta verkkoresurssit voidaan jakaa tehokkaasti metaklusterin solmuille, podille ja palveluille, meidän on tarkkailtava tarkasti niiden käyttöä virtuaalisten yksityispilvien metaklusterissa. Kun verkkoresurssit loppuvat, luodaan uusi solu.

Määrittääksemme optimaalisen asiakasklusterien määrän kussakin metaklusterissa, otamme huomioon myös kustannukset, tiheysvaatimukset, resurssikiintiöt, luotettavuusvaatimukset ja tilastot. Päätös uuden metaklusterin luomisesta tehdään kaiken tämän tiedon perusteella. Huomioi, että pienet klusterit voivat laajentua tulevaisuudessa suuresti, joten resurssien kulutus kasvaa, vaikka klusterien määrä pysyisi ennallaan. Jätämme yleensä tarpeeksi vapaata tilaa kullekin klusterille kasvaa.

Riisi. 3. Terway-verkkoarkkitehtuuri

Масштабирование компонентов мастера в клиентских кластерах

Ohjatun toiminnon komponenteilla on erilaiset resurssitarpeet. Ne riippuvat klusterin solmujen ja podien määrästä sekä APIServerin kanssa vuorovaikutuksessa olevien ei-standardien ohjaimien/operaattoreiden määrästä.

ACK:ssa jokainen Kubernetes-asiakasklusteri eroaa kooltaan ja ajonaikavaatimuksiltaan. Ohjatun toiminnon osien sijoittamiseen ei ole yleistä konfiguraatiota. Jos asetamme vahingossa pienen resurssirajan suurelle asiakkaalle, sen klusteri ei kestä kuormitusta. Jos asetat konservatiivisesti korkean rajan kaikille klusteille, resurssit menevät hukkaan.

Чтобы найти тонкий компромисс между надёжностью и стоимостью, ACK использует систему типов. А именно, мы определяем три типа кластеров: малый, средний и большой. У каждого типа отдельный профиль распределения ресурсов. Тип определяется на основе загрузки компонентов мастера, количества узлов и других факторов. Тип кластера может изменяться с течением времени. ACK постоянно отслеживает эти факторы и может соответствующим образом повышать/понижать тип. После изменения типа кластера распределение ресурсов обновляется автоматически при минимальном вмешательстве пользователя.

Мы работаем над улучшением этой системы в части более мелкозернистого масштабирования и более точного обновления типов, чтобы эти изменения происходили плавнее и имели больше экономического смысла.

Riisi. 4. Älykäs monivaiheinen tyypin vaihto

Asiakasklustereiden kehitys mittakaavassa

Edellisissä osissa käsiteltiin joitain näkökohtia suurten Kubernetes-klustereiden hallinnassa. On kuitenkin toinen ongelma, joka on ratkaistava: klusterien kehitys.

Kubernetes on pilvimaailman "Linux". Sitä päivitetään jatkuvasti ja siitä tulee modulaarisempi. Meidän on jatkuvasti toimitettava uusia versioita asiakkaillemme, korjattava haavoittuvuuksia ja päivitettävä olemassa olevia klustereita sekä hallittava suurta määrää asiaan liittyviä komponentteja (CSI, CNI, Device Plugin, Scheduler Plugin ja monet muut).

Otetaan esimerkiksi Kubernetes-komponenttien hallinta. Aluksi kehitimme keskitetyn järjestelmän kaikkien näiden yhdistettyjen komponenttien rekisteröintiä ja hallintaa varten.

Riisi. 5. Joustavat ja kytkettävät komponentit

Прежде чем двигаться дальше, нужно убедиться в успешности обновления. Для этого мы разработали систему проверки работоспособности компонентов. Проверка выполняется до и после обновления.

Рис. 6. Предварительная проверка компонентов кластера

Näiden komponenttien päivittämiseksi nopeasti ja luotettavasti jatkuvan käyttöönoton järjestelmä tukee osittaista edistymistä (harmaasävyt), taukoja ja muita toimintoja. Vakiokubernetes-ohjaimet eivät sovellu hyvin tähän käyttötapaukseen. Siksi olemme kehittäneet klusterin komponenttien hallintaa varten joukon erikoisohjaimia, mukaan lukien laajennuksen ja apuohjausmoduulin (sivuvaunun hallinta).

Esimerkiksi BroadcastJob-ohjain on suunniteltu päivittämään komponentit jokaisessa työntekijäkoneessa tai tarkistamaan kunkin koneen solmut. Broadcast-työ suorittaa podin jokaisessa klusterin solmussa, kuten DaemonSet. DaemonSet kuitenkin pitää podin aina käynnissä pitkän aikaa, kun taas BroadcastJob tiivistää sen. Broadcast-ohjain käynnistää myös podeja vastaliitetyissä solmuissa ja alustaa solmut tarvittavilla komponenteilla. Kesäkuussa 2019 avasimme OpenKruise-automaatiomoottorin lähdekoodin, jota itse käytämme yrityksessä.

Riisi. 7. OpenKurise järjestää Broadcast-tehtävän suorittamisen kaikissa solmuissa

Чтобы помочь клиентам в выборе правильных конфигураций кластеров, мы также предоставляем набор предопределённых профилей, включая профили Serverless, Edge, Windows и Bare Metal. Поскольку ландшафт расширяется, а потребности наших клиентов растут, мы добавим больше профилей, чтобы упростить утомительный процесс настройки.

Riisi. 8. Kehittyneet ja joustavat klusteriprofiilit erilaisiin skenaarioihin

Глобальная наблюдаемость по дата-центрам

Kuten alla olevasta kuvasta näkyy. 9, Alibaba Cloud Container -pilvipalvelu on otettu käyttöön kahdellakymmenellä alueella ympäri maailmaa. Tässä mittakaavassa yksi ACK:n keskeisistä tavoitteista on valvoa helposti käynnissä olevien klusterien tilaa, jotta voimme reagoida tilanteeseen nopeasti, jos asiakasklusteri kohtaa ongelman. Toisin sanoen sinun on keksittävä ratkaisu, jonka avulla voit tehokkaasti ja turvallisesti kerätä tilastoja reaaliajassa asiakasklustereista kaikilla alueilla - ja esittää tulokset visuaalisesti.

Riisi. 9. Alibaba Cloud Container -palvelun maailmanlaajuinen käyttöönotto kahdellakymmenellä alueella

Kuten monet Kubernetes-valvontajärjestelmät, käytämme Prometheusta päätyökalumme. Prometheus-agentit keräävät jokaisesta metaklusterista seuraavat tiedot:

• Käyttöjärjestelmän tiedot, kuten isäntäresurssit (CPU, muisti, levy jne.) ja verkon kaistanleveys.
• Метрики для системы управления метакластерами и клиентскими кластерами, такие как kube-apiserver, kube-controller-manager и kube-scheduler.
• Метрики от kubernetes-state-metrics и cadvisor.
• Метрики etcd, такие как время записи на диск, размер БД, пропускная способность связей между узлами и т. д.

Globaalit tilastot kerätään käyttämällä tyypillistä monikerroksista aggregointimallia. Jokaisen metaklusterin seurantatiedot kootaan ensin kullakin alueella ja lähetetään sitten keskuspalvelimelle, joka näyttää kokonaiskuvan. Kaikki toimii liittoutumismekanismin kautta. Jokaisessa palvelinkeskuksessa oleva Prometheus-palvelin kerää mittareita kyseisestä palvelinkeskuksesta, ja Prometheus-keskuspalvelin on vastuussa seurantatietojen yhdistämisestä. AlertManager muodostaa yhteyden Prometheuksen keskusyksikköön ja lähettää tarvittaessa hälytyksiä DingTalkin, sähköpostin, tekstiviestien jne. kautta. Visualisointi - Grafanan avulla.

Kuvassa 10 valvontajärjestelmä voidaan jakaa kolmeen tasoon:

• Rajataso

Keskustasta kauimpana oleva kerros. Prometheus Edge Server toimii jokaisessa metaklusterissa ja kerää mittareita saman verkkoalueen meta- ja asiakasklustereista.

• Каскадный уровень

Prometheus-kaskadikerroksen tehtävänä on kerätä seurantatietoja useilta alueilta. Nämä palvelimet toimivat suurempien maantieteellisten yksiköiden, kuten Kiinan, Aasian, Euroopan ja Amerikan, tasolla. Klusterien kasvaessa alue voidaan jakaa, jolloin jokaiselle uudelle suurelle alueelle ilmestyy kaskaditason Prometheus-palvelin. Tällä strategialla voit skaalata sujuvasti tarpeen mukaan.

• Keskitaso

Keskitetty Prometheus-palvelin muodostaa yhteyden kaikkiin kaskadipalvelimiin ja suorittaa lopullisen datan yhdistämisen. Luotettavuuden vuoksi kaksi Prometheus-instanssia nostettiin eri vyöhykkeille yhdistettynä samoihin kaskadipalvelimiin.

Рис. 10. Глобальная многоуровневая архитектура мониторинга на базе механизма федерации Prometheus

Yhteenveto

Kubernetes-pohjaiset pilviratkaisut muuttavat edelleen toimialaamme. Alibaba Cloud -konttipalvelu tarjoaa turvallisen, luotettavan ja tehokkaan isännöinnin - se on yksi parhaista Kubernetes-pilvipalveluista. Alibaba Cloud -tiimi uskoo vahvasti avoimen lähdekoodin ja avoimen lähdekoodin yhteisön periaatteisiin. Jatkamme varmasti jatkossakin osaamisemme jakamista pilviteknologioiden toiminnassa ja hallinnassa.

Lähde: will.com