Schaalopties voor toepassingen in Azure Kubernetes Service (AKS)

Wanneer u toepassingen uitvoert in Azure Kubernetes Service (AKS), moet u mogelijk de hoeveelheid rekenresources verhogen of verlagen. Wanneer u het aantal toepassingsexemplaren wijzigt, moet u mogelijk het aantal onderliggende Kubernetes-knooppunten wijzigen. Mogelijk moet u ook een groot aantal andere toepassingsexemplaren inrichten.

In dit artikel worden de belangrijkste concepten voor het schalen van AKS-toepassingen geïntroduceerd, waaronder het handmatig schalen van pods of knooppunten, met behulp van de horizontale automatische schaalaanpassing van pods, met behulp van de automatische schaalaanpassing van clusters en integratie met Azure Container Instances (ACI).

Pods of knooppunten handmatig schalen

U kunt replica's of pods handmatig schalen en knooppunten om te testen hoe uw toepassing reageert op een wijziging in beschikbare resources en status. Door resources handmatig te schalen, kunt u een vaste hoeveelheid resources definiëren die moet worden gebruikt voor het onderhouden van vaste kosten, zoals het aantal knooppunten. Als u handmatig wilt schalen, definieert u het aantal replica's of knooppunten. De Kubernetes-API plant vervolgens het maken van meer pods of het leegmaken van knooppunten op basis van die replica of het aantal knooppunten.

Wanneer u knooppunten omlaag schaalt, roept de Kubernetes-API de relevante Azure Compute-API aan die is gekoppeld aan het rekentype dat door uw cluster wordt gebruikt. Voor clusters die zijn gebouwd op virtuele-machineschaalsets, bepaalt de API voor virtuele-machineschaalsets bijvoorbeeld welke knooppunten moeten worden verwijderd. Zie de veelgestelde vragen over virtuele-machineschaalsets voor meer informatie over hoe knooppunten worden geselecteerd voor verwijdering op schaal omlaag.

Zie Knooppunten handmatig schalen in een AKS-cluster om aan de slag te gaan met het handmatig schalen van knooppunten. Als u het aantal pods handmatig wilt schalen, raadpleegt u de kubectl-schaalopdracht.

Horizontale automatische schaalaanpassing van pods

Kubernetes maakt gebruik van de horizontale automatische schaalaanpassing van pods (HPA) om de vraag naar resources te bewaken en het aantal pods automatisch te schalen. Standaard controleert de HPA elke 15 seconden de API voor metrische gegevens op alle vereiste wijzigingen in het aantal replica's en haalt de Api voor metrische gegevens elke 60 seconden gegevens op uit de Kubelet. De HPA wordt dus elke 60 seconden bijgewerkt. Wanneer er wijzigingen vereist zijn, wordt het aantal replica's dienovereenkomstig verhoogd of verlaagd. HPA werkt met AKS-clusters die de Metrics Server voor Kubernetes versie 1.8 en hoger hebben geïmplementeerd.

Automatische schaalaanpassing van Kubernetes-pods

Wanneer u de HPA configureert voor een bepaalde implementatie, definieert u het minimum- en maximum aantal replica's dat kan worden uitgevoerd. U definieert ook de metrische gegevens voor het bewaken en baseren van eventuele schaalbeslissingen op, zoals CPU-gebruik.

Zie Pods in AKS automatisch schalen om aan de slag te gaan met de horizontale automatische schaalaanpassing van pods in AKS.

Afkoeling van schaalgebeurtenissen

Omdat de HPA elke 60 seconden effectief wordt bijgewerkt, zijn eerdere schaalevenementen mogelijk niet voltooid voordat een andere controle wordt uitgevoerd. Dit gedrag kan ertoe leiden dat de HPA het aantal replica's wijzigt voordat de vorige schaal gebeurtenis toepassingsworkload kan ontvangen en dat de resourcevereisten dienovereenkomstig moeten worden aangepast.

Om race-gebeurtenissen te minimaliseren, wordt een vertragingswaarde ingesteld. Deze waarde bepaalt hoe lang de HPA moet wachten na een schaalgebeurtenis voordat een andere schaalgebeurtenis kan worden geactiveerd. Met dit gedrag kan het aantal nieuwe replica's van kracht worden en kan de API voor metrische gegevens overeenkomen met de gedistribueerde workload. Er is geen vertraging voor omhoog schalen vanaf Kubernetes 1.12, maar de standaardvertraging voor omlaag schalen is vijf minuten.

Automatische schaalaanpassing van clusters

Als u wilt reageren op veranderende podvereisten, past de automatische schaalaanpassing van kubernetes-clusters het aantal knooppunten aan op basis van de aangevraagde rekenresources in de knooppuntgroep. De automatische schaalaanpassing van clusters controleert standaard elke 10 seconden op de API-server voor metrische gegevens voor alle vereiste wijzigingen in het aantal knooppunten. Als de automatische schaalaanpassing van clusters bepaalt dat een wijziging is vereist, wordt het aantal knooppunten in uw AKS-cluster dienovereenkomstig verhoogd of verlaagd. De automatische schaalaanpassing van clusters werkt met Kubernetes RBAC-clusters met Kubernetes 1.10.x of hoger.

Automatische schaalaanpassing van Kubernetes-clusters

De automatische schaalaanpassing van clusters wordt doorgaans gebruikt naast de horizontale automatische schaalaanpassing van pods. Wanneer de horizontale schaalaanpassing van pods wordt gecombineerd, neemt het aantal pods toe of verlaagt het aantal pods op basis van de toepassingsvraag en past de automatische schaalaanpassing van clusters het aantal knooppunten aan om meer pods uit te voeren.

Zie Automatische schaalaanpassing van clusters in AKS om aan de slag te gaan met de automatische schaalaanpassing van clusters in AKS.

Gebeurtenissen uitschalen

Als een knooppunt niet over voldoende rekenresources beschikt om een aangevraagde pod uit te voeren, kan die pod niet doorgaan met het planningsproces. De pod kan alleen worden gestart als er meer rekenresources beschikbaar zijn in de knooppuntgroep.

Wanneer in de automatische schaalaanpassing van clusters pods worden opgemerkt die niet kunnen worden gepland vanwege resourcebeperkingen voor knooppuntgroepen, wordt het aantal knooppunten in de knooppuntgroep verhoogd om extra rekenresources te bieden. Wanneer de knooppunten zijn geïmplementeerd en beschikbaar zijn voor gebruik in de knooppuntgroep, worden de pods vervolgens gepland om erop te worden uitgevoerd.

Als uw toepassing snel moet worden geschaald, blijven sommige pods mogelijk in een status die moet worden gepland totdat meer knooppunten die door de automatische schaalaanpassing van het cluster zijn geïmplementeerd, de geplande pods kunnen accepteren. Voor toepassingen met hoge piekvereisten kunt u schalen met virtuele knooppunten en Azure Container Instances.

Inschalen van gebeurtenissen

De automatische schaalaanpassing van clusters bewaakt ook de status van de podplanning voor knooppunten die niet onlangs nieuwe planningsaanvragen hebben ontvangen. In dit scenario wordt aangegeven dat de knooppuntgroep meer rekenresources heeft dan vereist en het aantal knooppunten kan worden verminderd. Standaard worden knooppunten die een drempelwaarde doorgeven voor 10 minuten niet meer nodig, gepland voor verwijdering. Wanneer deze situatie zich voordoet, worden pods gepland om te worden uitgevoerd op andere knooppunten in de knooppuntgroep en vermindert de automatische schaalaanpassing van clusters het aantal knooppunten.

Uw toepassingen kunnen enige onderbreking ondervinden omdat pods op verschillende knooppunten worden gepland wanneer de automatische schaalaanpassing van clusters het aantal knooppunten verlaagt. Vermijd toepassingen die gebruikmaken van één podexemplaren om onderbrekingen te minimaliseren.

Kubernetes Gebeurtenisgestuurde Automatische schaalaanpassing (KEDA)

Kubernetes Gebeurtenisgestuurde Automatische schaalaanpassing (KEDA) is een opensource-onderdeel voor het automatisch schalen van workloads op basis van gebeurtenissen. Hiermee worden workloads dynamisch geschaald op basis van het aantal ontvangen gebeurtenissen. KEDA breidt Kubernetes uit met een aangepaste resourcedefinitie (CRD), aangeduid als scaledObject, om te beschrijven hoe toepassingen moeten worden geschaald als reactie op specifiek verkeer.

KEDA-schaalaanpassing is handig in scenario's waarin workloads bursts van verkeer ontvangen of grote hoeveelheden gegevens verwerken. Het verschilt van horizontale automatische schaalaanpassing van pods, omdat KEDA gebeurtenisgestuurd is en schaalt op basis van het aantal gebeurtenissen, terwijl HPA metrische gegevens is gebaseerd op het resourcegebruik (bijvoorbeeld CPU en geheugen).

Zie het KEDA-overzicht om aan de slag te gaan met de KEDA-invoegtoepassing in AKS.

Burst naar Azure Container Instances (ACI)

Als u uw AKS-cluster snel wilt schalen, kunt u integreren met Azure Container Instances (ACI). Kubernetes heeft ingebouwde onderdelen om het aantal replica's en knooppunten te schalen. Als uw toepassing echter snel moet schalen, kan de horizontale schaalaanpassing van pods meer pods plannen dan kan worden geleverd door de bestaande rekenresources in de knooppuntgroep. Als dit scenario is geconfigureerd, wordt de automatische schaalaanpassing van clusters geactiveerd om meer knooppunten in de knooppuntgroep te implementeren, maar het kan enkele minuten duren voordat deze knooppunten zijn ingericht en de Kubernetes-scheduler toestaan om pods op deze knooppunten uit te voeren.

Kubernetes burst schalen naar ACI

Met ACI kunt u snel containerinstanties implementeren zonder extra infrastructuuroverhead. Wanneer u verbinding maakt met AKS, wordt ACI een beveiligde, logische uitbreiding van uw AKS-cluster. Het onderdeel virtuele knooppunten , dat is gebaseerd op virtuele Kubelet, wordt geïnstalleerd in uw AKS-cluster dat ACI als een virtueel Kubernetes-knooppunt presenteert. Kubernetes kan vervolgens pods plannen die als ACI-exemplaren worden uitgevoerd via virtuele knooppunten, niet als pods op VM-knooppunten rechtstreeks in uw AKS-cluster.

Uw toepassing vereist geen wijzigingen voor het gebruik van virtuele knooppunten. Uw implementaties kunnen worden geschaald in AKS en ACI en zonder vertraging wanneer de automatische schaalaanpassing van clusters nieuwe knooppunten in uw AKS-cluster implementeert.

Virtuele knooppunten worden geïmplementeerd in een ander subnet in hetzelfde virtuele netwerk als uw AKS-cluster. Deze configuratie van het virtuele netwerk beveiligt het verkeer tussen ACI en AKS. Net als een AKS-cluster is een ACI-exemplaar een beveiligde, logische rekenresource die is geïsoleerd van andere gebruikers.

Volgende stappen

Zie de volgende bronnen om aan de slag te gaan met het schalen van toepassingen:

Zie de volgende artikelen voor meer informatie over de belangrijkste Kubernetes- en AKS-concepten: