Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Wanneer u toepassingen uitvoert in Azure Kubernetes Service (AKS), moet u mogelijk de hoeveelheid rekenresources in uw cluster actief 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, zoals het aantal knooppunten, om een vaste kosten te handhaven. Als u handmatig wilt schalen, definieert u een replica of aantal 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 vereiste wijzigingen in het aantal replica's, terwijl de Api voor metrische gegevens elke 60 seconden gegevens ophaalt uit de Kubelet. Als gevolg hiervan wordt HPA elke 60 seconden bijgewerkt. Wanneer er wijzigingen zijn vereist, wordt het aantal replica's dienovereenkomstig geschaald. HPA werkt met AKS-clusters die Metrics Server hebben geïmplementeerd voor Kubernetes versie 1.8 en hoger.
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 schaalbeslissingen op, zoals CPU-gebruik.
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 het opschalen van gebeurtenissen vanaf Kubernetes 1.12. De standaardvertraging voor omlaag schaal gebeurtenissen is echter 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.
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.
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 de status wachten om te worden gepland totdat meer knooppunten die door de automatische schaalaanpassing van het cluster worden 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 drempel van 10 minuten waarin ze niet nodig zijn overschrijden, 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 een 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. KEDA verschilt van de Horizontal Pod Autoscaler (HPA), omdat KEDA gebeurtenisgestuurd is en schaalt op basis van het aantal gebeurtenissen, terwijl HPA op metrische gegevens wordt gebaseerd, zoals het gebruik van resources (bijvoorbeeld CPU en geheugen).
Zie het KEDA-overzicht om aan de slag te gaan met de KEDA-invoegtoepassing in AKS.
Automatisch inrichten van knooppunten
Node-autoprovisioning (preview) maakt gebruik van het open-source Karpenter-project dat Karpenter automatisch implementeert, configureert en beheert op uw AKS-cluster. NAP voorziet dynamisch in knooppunten op basis van de actuele resourcevereisten voor pods; automatisch wordt de optimale SKU en hoeveelheid virtuele machines (VM) geselecteerd om aan de directe vraag te voldoen.
NAP maakt gebruik van een vooraf gedefinieerde lijst met VM-SKU's als uitgangspunt om te bepalen welke SKU het meest geschikt is voor workloads die in behandeling zijn. Voor een nauwkeurigere controle kunnen gebruikers de bovengrens definiëren van resources die worden gebruikt door een knooppuntgroep en voorkeuren van waar workloads moeten worden gepland als er meerdere knooppuntgroepen zijn.
Schaalaanpassing en beveiliging van controlevlak
Kubernetes heeft een multidimensionale schaalvelop met elk resourcetype dat een dimensie vertegenwoordigt. Niet alle middelen zijn hetzelfde. Horloges zijn bijvoorbeeld vaak ingesteld op geheimen, wat resulteert in lijstoproepen naar de kube-apiserver die kosten toevoegen en een onevenredig hogere belasting op het besturingsvlak in vergelijking met resources zonder horloges.
Het besturingsvlak beheert alle schaalaanpassing van resources in het cluster, dus hoe meer u het cluster in een bepaalde dimensie schaalt, hoe minder u binnen andere dimensies kunt schalen. Het uitvoeren van honderdduizenden pods in een AKS-cluster heeft bijvoorbeeld invloed op het aantal podverlooppercentages (podmutaties per seconde) dat het besturingsvlak kan ondersteunen. Raadpleeg de aanbevolen procedures.
AKS schaalt automatisch onderdelen van het besturingsvlak op basis van belangrijke signalen, zoals het totale aantal kernen in het cluster en cpu of geheugendruk op de onderdelen van het besturingsvlak.
Als u wilt controleren of het besturingsvlak omhoog is geschaald, controleert u de configuratiemap met de naam 'large-cluster-control-plane-scaling-status'
kubectl describe configmap large-cluster-control-plane-scaling-status -n kube-system
Beveiliging van controlevlak
Als het automatisch schalen van de API-server niet wordt gestabiliseerd onder scenario's met hoge belasting, implementeert AKS een beheerde API-serverbeveiliging. Deze beveiliging fungeert als laatste redmiddel om de API-server te beveiligen door aanvragen van niet-systeemclients te beperken en te voorkomen dat het besturingsvlak volledig niet meer reageert. Systeemkritieke aanroepen naar API-server van onderdelen zoals kubelet blijven normaal functioneren.
Als u wilt controleren of de beheerde API-serverbeveiliging is toegepast, controleert u op de aanwezigheid van FlowSchema en PriorityLevelConfiguration voor 'aks-managed-apiserver-guard '.
kubectl get flowschemas
kubectl get prioritylevelconfigurations
Raadpleeg de handleiding voor probleemoplossing voor de API-server en etcd als de "aks-managed-apiserver-guard" FlowSchema en PriorityLevelConfiguration zijn toegepast op het cluster voor snelle mitigatie.
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 automatische schaalaanpassing van pods meer pods plannen dan de bestaande rekenresources in de knooppuntgroep kunnen ondersteunen. 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.
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:
- Pods of knooppunten handmatig schalen
- De horizontale automatische schaalaanpassing van pods gebruiken
- Automatische schaalaanpassing van clusters gebruiken
- De invoegtoepassing Kubernetes Event-driven Autoscaling (KEDA) gebruiken
Zie de volgende artikelen voor meer informatie over de belangrijkste Kubernetes- en AKS-concepten: