Kubus-op-kubus, metaclusters, honingraten, distributie van hulpbronnen

Rijst. 1. Kubernetes-ecosysteem op Alibaba Cloud

Sinds 2015 is Alibaba Cloud Container Service for Kubernetes (ACK) een van de snelst groeiende clouddiensten in Alibaba Cloud. Het bedient talloze klanten en ondersteunt ook de interne infrastructuur van Alibaba en de andere clouddiensten van het bedrijf.

Net als bij vergelijkbare containerdiensten van cloudproviders van wereldklasse zijn betrouwbaarheid en beschikbaarheid onze topprioriteiten. Daarom is er een schaalbaar en wereldwijd toegankelijk platform gecreëerd voor tienduizenden Kubernetes-clusters.

In dit artikel delen we onze ervaringen met het beheren van een groot aantal Kubernetes-clusters op cloudinfrastructuur, evenals de architectuur van het onderliggende platform.

Toegang

Kubernetes is de de facto standaard geworden voor een verscheidenheid aan workloads in de cloud. Zoals weergegeven in afb. 1 hierboven draaien steeds meer Alibaba Cloud-applicaties op Kubernetes-clusters: stateful en stateless applicaties, maar ook applicatiebeheerders. Kubernetes-beheer is altijd een interessant en serieus gespreksonderwerp geweest voor ingenieurs die infrastructuur bouwen en onderhouden. Als het gaat om cloudproviders zoals Alibaba Cloud, komt de kwestie van schaalvergroting naar voren. Hoe beheer je Kubernetes-clusters op deze schaal? We hebben al best practices besproken voor het beheren van enorme Kubernetes-clusters met 10 knooppunten. Dit is natuurlijk een interessant schaalprobleem. Maar er is nog een andere schaal: kwantiteit de clusters zelf.

We hebben dit onderwerp met veel ACK-gebruikers besproken. De meesten van hen kiezen ervoor om tientallen, zo niet honderden, kleine of middelgrote Kubernetes-clusters te beheren. Daar zijn goede redenen voor: het beperken van potentiële schade, het scheiden van clusters voor verschillende teams, het creëren van virtuele clusters om te testen. Als ACK met dit gebruiksmodel een wereldwijd publiek wil bedienen, moet het op betrouwbare en efficiënte wijze een groot aantal clusters in meer dan twintig regio's beheren.

Rijst. 2. Problemen bij het beheren van een groot aantal Kubernetes-clusters

Wat zijn de belangrijkste uitdagingen bij het beheren van clusters op deze schaal? Zoals u in de figuur kunt zien, zijn er vier problemen waarmee u rekening moet houden:

• Heterogeniteit

ACK zou verschillende soorten clusters moeten ondersteunen, waaronder standaard, serverloos, Edge, Windows en verschillende andere. Verschillende clusters vereisen verschillende opties, componenten en hostingmodellen. Sommige klanten hebben hulp nodig bij het aanpassen van hun specifieke gevallen.

• Diverse clustergroottes

Clusters variëren in grootte, van een paar knooppunten met een paar peulen tot tienduizenden knooppunten met duizenden peulen. De vereisten voor middelen variëren ook sterk. Onjuiste toewijzing van middelen kan de prestaties beïnvloeden of zelfs storingen veroorzaken.

• Verschillende versies

Kubernetes evolueert zeer snel. Elke paar maanden worden er nieuwe versies uitgebracht. Klanten zijn altijd bereid om nieuwe functies uit te proberen. Ze willen dus de testbelasting op de nieuwe versies van Kubernetes plaatsen en de productiebelasting op de stabiele versies. Om aan deze eis te voldoen, moet ACK voortdurend nieuwe versies van Kubernetes aan klanten leveren, terwijl stabiele versies behouden blijven.

• Beveiligingsnaleving

Clusters zijn verspreid over verschillende regio’s. Ze moeten daarom voldoen aan verschillende veiligheidseisen en officiële voorschriften. Een cluster in Europa moet bijvoorbeeld voldoen aan de AVG, terwijl een financiële cloud in China over extra beschermingslagen moet beschikken. Deze vereisten zijn verplicht en het is onaanvaardbaar om ze te negeren, omdat dit enorme risico's met zich meebrengt voor klanten van het cloudplatform.

Het ACK-platform is ontworpen om de meeste van de bovenstaande problemen op te lossen. Het beheert momenteel betrouwbaar en stabiel meer dan 10 Kubernetes-clusters over de hele wereld. Laten we eens kijken hoe dit werd bereikt, onder meer via verschillende belangrijke ontwerp-/architectuurprincipes.

ontwerp

Kubus-op-kubus en honingraat

In tegenstelling tot een gecentraliseerde hiërarchie wordt celgebaseerde architectuur doorgaans gebruikt om een ​​platform verder te schalen dan één enkel datacenter of om de reikwijdte van noodherstel uit te breiden.

Elke regio in de Alibaba Cloud bestaat uit verschillende zones (AZ) en komt meestal overeen met een specifiek datacenter. In een grote regio (bijvoorbeeld Huangzhou) zijn er vaak duizenden Kubernetes-clientclusters waarop ACK wordt uitgevoerd.

ACK beheert deze Kubernetes-clusters met behulp van Kubernetes zelf, wat betekent dat we een Kubernetes-metacluster hebben draaien om de client-Kubernetes-clusters te beheren. Deze architectuur wordt ook wel “kube-on-kube” (KoK) genoemd. De KoK-architectuur vereenvoudigt het beheer van clientclusters omdat clusterimplementatie eenvoudig en deterministisch is. Belangrijker nog is dat we native Kubernetes-functies kunnen hergebruiken. Bijvoorbeeld het beheren van API-servers via implementatie, waarbij de etcd-operator wordt gebruikt om meerdere etcds te beheren. Een dergelijke recursie brengt altijd bijzonder plezier.

Binnen één regio worden meerdere Kubernetes-metaclusters ingezet, afhankelijk van het aantal clients. Deze metaclusters noemen we cellen. Om te beschermen tegen het falen van een hele zone, ondersteunt ACK multi-actieve implementaties in één regio: de metacluster distribueert Kubernetes-clientclustermastercomponenten over meerdere zones en voert deze tegelijkertijd uit, dat wil zeggen in multi-actieve modus. Om de betrouwbaarheid en efficiëntie van de master te garanderen, optimaliseert ACK de plaatsing van componenten en zorgt ervoor dat de API-server en etcd dicht bij elkaar staan.

Met dit model kunt u Kubernetes efficiënt, flexibel en betrouwbaar beheren.

Metacluster resourceplanning

Zoals we al vermeldden, hangt het aantal metaclusters in elke regio af van het aantal klanten. Maar op welk punt moet een nieuwe metacluster worden toegevoegd? Dit is een typisch probleem met resourceplanning. In de regel is het gebruikelijk om een ​​nieuwe te creëren wanneer bestaande metaclusters al hun bronnen hebben uitgeput.

Laten we bijvoorbeeld netwerkbronnen nemen. In de KoK-architectuur worden Kubernetes-componenten van clientclusters als pods in een metacluster ingezet. We gebruiken Terway (Fig. 3) is een krachtige plug-in ontwikkeld door Alibaba Cloud voor containernetwerkbeheer. Het biedt een uitgebreide reeks beveiligingsbeleidsregels en stelt u in staat verbinding te maken met de virtuele privéclouds (VPC's) van klanten via de Alibaba Cloud Elastic Networking Interface (ENI). Om netwerkbronnen effectief te verdelen over knooppunten, pods en services in een metacluster, moeten we hun gebruik binnen de metacluster van virtuele privéclouds zorgvuldig monitoren. Wanneer de netwerkbronnen opraken, wordt er een nieuwe cel gemaakt.

Om het optimale aantal klantclusters in elke metacluster te bepalen, houden we ook rekening met onze kosten, dichtheidsvereisten, resourcequota, betrouwbaarheidsvereisten en statistieken. De beslissing om een ​​nieuw metacluster te creëren wordt genomen op basis van al deze informatie. Houd er rekening mee dat kleine clusters in de toekomst enorm kunnen uitbreiden, waardoor het verbruik van hulpbronnen toeneemt, zelfs als het aantal clusters onveranderd blijft. Meestal laten we voor elk cluster voldoende vrije ruimte over om te groeien.

Rijst. 3. Terway-netwerkarchitectuur

Wizardcomponenten schalen over clientclusters

Wizardcomponenten hebben verschillende resourcebehoeften. Ze zijn afhankelijk van het aantal knooppunten en pods in het cluster en het aantal niet-standaardcontrollers/operators die interactie hebben met APIServer.

In ACK verschilt elk Kubernetes-clientcluster qua grootte en runtime-vereisten. Er bestaat geen universele configuratie voor het plaatsen van wizardcomponenten. Als we per ongeluk een lage resourcelimiet instellen voor een grote klant, kan het cluster de belasting niet aan. Als u een conservatief hoge limiet instelt voor alle clusters, gaan er bronnen verloren.

Om een ​​subtiele afweging te vinden tussen betrouwbaarheid en kosten, gebruikt ACK een typesysteem. We definiëren namelijk drie soorten clusters: klein, middelgroot en groot. Elk type heeft een afzonderlijk resourcetoewijzingsprofiel. Het type wordt bepaald op basis van de belasting van wizardcomponenten, het aantal knooppunten en andere factoren. Het clustertype kan in de loop van de tijd veranderen. ACK houdt deze factoren voortdurend in de gaten en kan dienovereenkomstig omhoog/omlaag typen. Zodra het clustertype is gewijzigd, wordt de toewijzing van bronnen automatisch bijgewerkt met minimale tussenkomst van de gebruiker.

We werken eraan dit systeem te verbeteren met fijnmazige schaling en nauwkeurigere type-updates, zodat deze wijzigingen soepeler plaatsvinden en economisch zinvoller zijn.

Rijst. 4. Intelligente meertrapstypeschakeling

Evolutie van klantclusters op schaal

In de voorgaande secties zijn enkele aspecten van het beheer van grote aantallen Kubernetes-clusters besproken. Er is echter nog een ander probleem dat moet worden opgelost: de evolutie van clusters.

Kubernetes is de “Linux” van de cloudwereld. Het wordt voortdurend bijgewerkt en wordt modulairer. We moeten voortdurend nieuwe versies aan onze klanten leveren, kwetsbaarheden oplossen en bestaande clusters updaten, en een groot aantal gerelateerde componenten beheren (CSI, CNI, Device Plugin, Scheduler Plugin en vele andere).

Laten we Kubernetes-componentbeheer als voorbeeld nemen. Om te beginnen hebben we een centraal systeem ontwikkeld voor het registreren en beheren van al deze aangesloten componenten.

Rijst. 5. Flexibele en insteekbare componenten

Voordat u verder gaat, moet u ervoor zorgen dat de update succesvol is geweest. Hiervoor hebben wij een systeem ontwikkeld om de functionaliteit van componenten te controleren. De controle wordt vóór en na de update uitgevoerd.

Rijst. 6. Voorafgaande controle van clustercomponenten

Om deze componenten snel en betrouwbaar te updaten, werkt een continu implementatiesysteem met ondersteuning voor gedeeltelijke voortgang (grijswaarden), pauzes en andere functies. Standaard Kubernetes-controllers zijn niet goed geschikt voor deze use case. Om clustercomponenten te beheren, hebben we daarom een ​​set gespecialiseerde controllers ontwikkeld, inclusief een plug-in en een extra besturingsmodule (zijspanbeheer).

De BroadcastJob-controller is bijvoorbeeld ontworpen om componenten op elke werkmachine bij te werken of knooppunten op elke machine te controleren. De Broadcast-taak voert een pod uit op elk knooppunt in het cluster, zoals een DaemonSet. DaemonSet zorgt er echter voor dat de pod altijd lange tijd actief blijft, terwijl BroadcastJob deze samenvouwt. De Broadcast-controller lanceert ook pods op nieuw aangesloten knooppunten en initialiseert de knooppunten met de benodigde componenten. In juni 2019 openden we de broncode van de automatiseringsengine OpenKruise, die we zelf binnen het bedrijf gebruiken.

Rijst. 7. OpenKurise organiseert de uitvoering van de Broadcast-taak op alle knooppunten

Om klanten te helpen bij het selecteren van de juiste clusterconfiguraties, bieden we ook een reeks vooraf gedefinieerde profielen, waaronder Serverless-, Edge-, Windows- en Bare Metal-profielen. Naarmate het landschap zich uitbreidt en de behoeften van onze klanten groeien, zullen we meer profielen toevoegen om het vervelende installatieproces te vereenvoudigen.

Rijst. 8. Geavanceerde en flexibele clusterprofielen voor verschillende scenario's

Wereldwijde waarneembaarheid in datacenters

Zoals weergegeven in onderstaande afb. Op 9 september is de Alibaba Cloud Container-cloudservice geïmplementeerd in twintig regio’s over de hele wereld. Gezien deze schaal is een van de belangrijkste doelstellingen van ACK het eenvoudig monitoren van de status van actieve clusters, zodat we snel op de situatie kunnen reageren als een clientcluster een probleem tegenkomt. Met andere woorden, u moet een oplossing bedenken waarmee u efficiënt en veilig in realtime statistieken kunt verzamelen van klantclusters in alle regio's - en de resultaten visueel kunt presenteren.

Rijst. 9. Wereldwijde inzet van Alibaba Cloud Container-service in twintig regio’s

Zoals veel Kubernetes-monitoringsystemen gebruiken we Prometheus als ons belangrijkste hulpmiddel. Voor elke metacluster verzamelen Prometheus-agenten de volgende statistieken:

• Besturingssysteemstatistieken zoals hostbronnen (CPU, geheugen, schijf, enz.) en netwerkbandbreedte.
• Metrische gegevens voor het metacluster- en clientclusterbeheersysteem, zoals kube-apiserver, kube-controller-manager en kube-scheduler.
• Statistieken van kubernetes-state-metrics en cadvisor.
• etcd-statistieken zoals schijfschrijftijd, databasegrootte, doorvoer van verbindingen tussen knooppunten, enz.

Mondiale statistieken worden verzameld met behulp van een typisch meerlaags aggregatiemodel. Monitoringgegevens van elke metacluster worden eerst in elke regio verzameld en vervolgens naar een centrale server gestuurd die het totaalbeeld toont. Alles werkt via het federatiemechanisme. Een Prometheus-server in elk datacenter verzamelt statistieken van dat datacenter, en de centrale Prometheus-server is verantwoordelijk voor het aggregeren van monitoringgegevens. AlertManager maakt verbinding met centrale Prometheus en stuurt indien nodig waarschuwingen via DingTalk, e-mail, SMS, etc. Visualisatie - met behulp van Grafana.

In Figuur 10 kan het monitoringsysteem in drie niveaus worden verdeeld:

• Grens niveau

De laag die het verst van het centrum verwijderd is. De Prometheus Edge Server draait in elke metacluster en verzamelt statistieken van meta- en clientclusters binnen hetzelfde netwerkdomein.

• Cascadeniveau

De functie van de Prometheus-cascadelaag is het verzamelen van monitoringgegevens uit meerdere regio's. Deze servers opereren op het niveau van grotere geografische eenheden zoals China, Azië, Europa en Amerika. Naarmate clusters groeien, kan de regio worden verdeeld, waarna in elke nieuwe grote regio een Prometheus-server op cascadeniveau zal verschijnen. Met deze strategie kunt u soepel opschalen als dat nodig is.

• Centraal niveau

De centrale Prometheus-server maakt verbinding met alle cascadeservers en voert de uiteindelijke gegevensaggregatie uit. Voor de betrouwbaarheid zijn er twee centrale Prometheus-instanties in verschillende zones opgezet, verbonden met dezelfde cascadeservers.

Rijst. 10. Mondiale monitoringarchitectuur op meerdere niveaus, gebaseerd op het Prometheus-federatiemechanisme

Beknopt

Op Kubernetes gebaseerde cloudoplossingen blijven onze sector transformeren. Alibaba Cloud-containerservice biedt veilige, betrouwbare en krachtige hosting - het is een van de beste Kubernetes-cloudhosting. Het Alibaba Cloud-team gelooft sterk in de principes van Open Source en de open source-gemeenschap. Wij zullen onze kennis op het gebied van het bedienen en beheren van cloudtechnologieën zeker blijven delen.

Bron: www.habr.com