Begrepp om skalbarhet

  • 5 minuter

Innan du hittar en skalningslösning måste du förstå vad skalbarhet är och hur den gäller för Kubernetes-program.

I den här lektionen går vi igenom några skalbarhetsbegrepp.

Skalbarhet

Skalbarhet beskriver ett programs eller systemets förmåga att hantera allt mer arbete genom att lägga till fler resurser i det.

I vårt exempelscenario är mängden arbete som upplever en ökning antalet kundförfrågningar. Mängden tillagda resurser kan representeras på två sätt: vertikal skalbarhet och horisontell skalbarhet.

Lodrät skalbarhet

Lodrät skalbarhet, eller uppskalning, syftar på att skala ett system genom att lägga till fler fysiska resurser, till exempel minne eller PROCESSORkraft. Om företagets webbplats till exempel förbrukar för mycket minne kan du uppdatera den virtuella datorinstansen så att den innehåller mer minne samtidigt som du behåller samma underliggande program.

Vertical scaling diagram.

Sammanfattningsvis innebär skalning lodrätt att öka storleken på den virtuella datorn samtidigt som antalet program bibehålls på samma sätt. Den här metoden är värdefull om du har monolitiska program som kräver mycket beräkningskraft men som är för kostsamma för att delas upp i mindre delar. Dessa program finns främst i virtuella datorer i stället för distribuerade system.

Trots en mer hanterbar kostnad kan mycket stora virtuella datorer bli mycket dyra. Kostnaden för att lägga till mer beräkningskraft är högre än kostnaden för att duplicera små virtuella datorer. Det finns en övre gräns för hur många resurser du kan lägga till i en enskild virtuell dator, vilket innebär att du så småningom måste duplicera den virtuella datorn när du når den övre gränsen.

Horisontell skalbarhet

Horisontell skalbarhet, eller utskalning, syftar på att skala ett system genom att duplicera programmet och balansera belastningen mellan programinstanserna.

Horizontal scaling diagram.

Horisontell skalning är värdefullt för distribuerade program, till exempel de som distribueras i AKS och tillståndslösa system eftersom du kan starta flera containrar med samma program på en enda virtuell dator. Genom att skala ut kan du extrahera de flesta resurser medan du betalar för en enskild virtuell dator.

I vårt exempelscenario är företagswebbplatsen tillståndslös. Det innebär att utskalning är den bästa åtgärden. Kubernetes tillhandahåller en resurs med namnet HorizontalPodAutoscaler (HPA) som gör att du kan skala ut dina distributioner.

Manuell skalbarhet på Kubernetes

Innan vi går igenom HPA ska vi gå igenom hur du skalar ett Kubernetes-program manuellt.

Varje distribution är bunden till en annan resurs som kallas replicaSet. En ReplicaSet ansvarar för att upprätthålla ett "önskat repliktillstånd" och skala det verkliga programmet in eller ut för att behålla önskat tillstånd på samma sätt som det verkliga tillståndet. Du kan styra antalet repliker i en distribution via spec.replicas nyckeln i distributionsspecifikationen. Den här nyckeln anger antalet önskade repliker i den underliggande Replikuppsättningen och tvingar replikeringsstyrenheten att behålla det här antalet repliker vid en viss tidpunkt.

Du kan också styra antalet repliker i en distribution med kubectl scale deploy/contoso-website --replicas <number> kommandot . Det här kommandot ändrar dynamiskt antalet önskade repliker i en distribution och skalar programmet in eller ut.

HorizontalPodAutoscaler (HPA)

HPA är den interna Kubernetes 1.8+-resursen som ger horisontell skalbarhet för poddar i klustret. Den övervakar mått-API:et var 30:e sekund för eventuella ändringar i önskat replikantal. Om det önskade antalet repliker skiljer sig från det aktuella antalet repliker skalar kontrollanthanteraren, som hanterar HPA-objekt, distributionen in eller ut.

HorizontalPodAutoscaling design diagram.

HPA:er arbetar med autoscaling API-gruppen i Kubernetes. Det finns två versioner av den här API-gruppen: v1 och v2. Med v1 versionen kan distributionen endast skalas baserat på CPU-mått. Versionen v2 tillåter intern övervakning av både CPU och minne. I den här modulen v2 använder vi versionen.

Varje HPA är kopplad till en skalningsreferens, som definieras i nyckeln för spec.scaleTargetRef HPA-manifestet. Den här skalningsreferensen måste ha underliggande poddar som ska skalas, annars fungerar inte HPA eftersom det inte går att tillämpa skalning på objekt som inte kan skalas, till exempel DaemonSets.

Det är viktigt att varje podd har en resursbegäran inställd i sin specifikation. HPA-algoritmen kan inte beräkna måtten korrekt och fastställa resursanvändningen utan den här inställningen. Du kan ange den här begränsningen spec.template.spec.containers[].resources via nyckeln i distributionsmanifestet, som du ser i följande exempel:

spec:
  template:
    spec:
      containers:
        - resources:
            requests:
              cpu: 250m
              memory: 256M
            limits:
              cpu: 500m
              memory: 512M

Exempel på HPA-manifest

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

Testa dina kunskaper

1.

Vad är horisontell skalning?

2.

Varför är det viktigt att ha en resursbegäran inställd på poddar som är bundna till en HPA?

3.

Varför rekommenderas vertikal skalning mindre för tillståndslösa program?