September 2026 • Product

„Automatinis masteliavimas“ Kubernetes aplinkoje reiškia tris skirtingus mechanizmus, o jų painiojimas yra dažniausia priežastis, kodėl klasteris, kuris turėtų prisitaikyti, to nedaro. Podai masteliuojami su HorizontalPodAutoscaler, mazgai — pagal worker telkinių ribas, o valdymo plokštuma — pagal API apkrovą. Šiame straipsnyje paaiškiname kiekvieną iš jų, tada žingsnis po žingsnio aprašome tikrą bandymą, kurį atlikome Kube-DC valdomame klasteryje, su manifestais, kad galėtumėte jį pakartoti.

Trys dalykai gali masteliuotis

Sluoksnis Kas masteliuojama Kube-DC valdomame klasteryje
Podai Deployment ar StatefulSet replikų skaičius, valdomas tokia metrika kaip CPU Standartinis HorizontalPodAutoscaler, su jau įdiegtu metrics-server. Išbandyta šiame straipsnyje
Mazgai Worker mašinų, prieinamų tiems podams paleisti, skaičius Worker telkiniai su mažiausia ir didžiausia riba kiekvienam telkiniui, kaip dokumentuota platformai. Nebuvo mūsų bandymo dalis
Valdymo plokštuma API serverio ir etcd ištekliai augant klasterio apkrovai Abiejų vertikalusis automatinis masteliavimas, įjungtas pagal numatytuosius nustatymus ir sukonfigūruotose ribose, kaip dokumentuota. Nebuvo mūsų bandymo dalis

Kiekvieną sluoksnį žymime tuo, ką išbandėme ir ką žinome tik iš dokumentacijos, nes planuojant galią šis skirtumas svarbus.

Ką iš tikrųjų daro HorizontalPodAutoscaler

HorizontalPodAutoscaler (HPA) yra valdymo ciklas, veikiantis Kubernetes valdymo plokštumos viduje. Pagal numatytuosius nustatymus jis pabunda kas 15 sekundžių, nuskaito taikinių podų metrikas ir koreguoja Deployment replikų skaičių. Keturios smulkmenos paaiškina beveik visus netikėtumus:

  • Panaudojimas yra santykinis užklausai. 50 % CPU tikslas reiškia 50 % CPU, kurio užklausė podo konteineriai, o ne 50 % mazgo. Jei konteineris neturi CPU užklausos, panaudojimas neapibrėžtas ir autoscaler šiai metrikai nieko nedaro.
  • Jam reikia metrikų API. metrics.k8s.io API paprastai teikia Metrics Server papildinys, kurį savarankiškai valdomame klasteryje reikia įdiegti atskirai.
  • Aritmetika yra santykis. Norimas replikų skaičius lygus dabartiniam replikų skaičiui, padaugintam iš dabartinės metrikos ir tikslo santykio, suapvalintam į viršų. Jei santykis nuo 1,0 skiriasi mažiau nei 0,1 (numatytoji tolerancija), nieko nevyksta.
  • Mažinimas sąmoningai lėtas. Valdiklis prisimena neseniai pateiktas rekomendacijas ir vykdo didžiausią iš jų lange, kuris pagal numatytuosius nustatymus yra penkios minutės, o tai išlygina svyruojančias metrikas ir apsaugo nuo svyravimų.

Pavyzdžiui, viena replika, veikianti 57 % CPU esant 50 % tikslui, duoda santykį 1,14, o suapvalinus į viršų 1 × 1,14 gaunamos 2 replikos. Būtent tokį pirmą žingsnį pastebėjome toliau aprašytame bandyme.

Bandymas: valdomo klasterio masteliavimas esant tikrai apkrovai

Mūsų 2026 m. rugpjūčio pilname bandyme sukūrėme valdomą klasterį pavadinimu test2 su dviem worker mazgais, kurių kiekvieno dydis 1 vCPU ir 2 GB atminties, kad tilptų į paketo kvotoje likusį rezervą. Klasterio API prieigos taškas pagal numatytuosius nustatymus yra privatus, todėl prie jo prisijungėme iš projekto integruoto Cloud Shell per vidinį klasterio paslaugos adresą, o ne iš interneto. Abu worker buvo Ready, o metrics-server jau buvo įdiegtas ir veikė, ko HPA ir reikia.

Įdiegėme nedidelę žiniatinklio programą su HPA, kurio tikslas 50 % CPU, o diapazonas nuo 1 iki 6 replikų. Tai pavyzdiniai manifestai tokios pat formos kaip bandyme; CPU užklausų reikšmės yra iliustracinės:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
      - name: hello
        image: nginxdemos/hello
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 100m
            memory: 64Mi
---
apiVersion: v1
kind: Service
metadata:
  name: hello
spec:
  selector:
    app: hello
  ports:
  - port: 80
    targetPort: 80
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: hello
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: hello
  minReplicas: 1
  maxReplicas: 6
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

Nuolatinei apkrovai sukurti paleidome kelis vienkartinius podus klasterio viduje, kurių kiekvienas ciklu siunčia HTTP užklausas į paslaugą. Pirmąją komandą paleiskite dviejuose ar trijuose terminaluose su skirtingais pavadinimais, o autoscaler stebėkite kitame:

kubectl run load-1 --image=busybox:1.36 --restart=Never -- /bin/sh -c "while true; do wget -q -O- http://hello > /dev/null; done"

kubectl get hpa hello --watch
Rezultatas: CPU pakilo iki 57 % esant apkrovai, HPA padidino deployment nuo 1 iki 2, o vėliau iki 3 replikų, o vidutinis CPU nusistovėjo apie 35 %. Pašalinus apkrovos generatorius, replikų skaičius sugrįžo į 1 be jokio rankinio veiksmo.

Dvi sąžiningos pastabos apie šį rezultatą. Nematavome mažinimo laiko, o numatytasis penkių minučių stabilizavimo langas paaiškina, kodėl jis atsilieka nuo didinimo. Be to, bandymas įrodo tik podų sluoksnį: jis parodo, kad HPA, metrikų API ir klasterio planavimas veikia kartu Kube-DC valdomame klasteryje, bet ne tai, kaip worker telkiniai elgiasi masteliuojant mazgų lygiu.

Baigę pašalinkite apkrovą su kubectl delete pod load-1 (ir kitais paleistais generatoriais), tada bandomąjį darbo krūvį su kubectl delete hpa,svc,deploy hello.

Ko podai vieni negali: galia

HPA prideda podus, o podams reikia vietos, kur veikti. Jei worker mazgai pilni, papildomos replikos lieka Pending, kol atsiranda galios, todėl HPA maxReplicas turi prasmę tik jei po juo esantis telkinys gali sutalpinti tiek podų. Padauginkite didžiausią replikų skaičių iš kiekvieno podo užklausų ir palyginkite rezultatą su laisva jūsų worker telkinio galia.

Kube-DC worker telkiniai apibrėžiami kiekvienam telkiniui atskirai (CPU, atmintis, diskas ir atvaizdas) su automatinio masteliavimo ribomis kiekvienam telkiniui, o telkinys naudoja jūsų paketo kvotą. Ta kvota bendra viskam, ką paleidžiate: konteineriai, virtualios mašinos ir valdomi klasteriai dalijasi tuo pačiu vCPU ir atminties limitu. Pasekmes matėme savo bandyme, kur esamas valdomas klasteris ir virtuali mašina naudojo maždaug 7,5 iš 8 vCPU Pro pakete ir neliko vietos GPU podui. Todėl bandomuosius worker mazgus nustatėme 1 vCPU ir 2 GB dydžio. Vertinkite savo paketą kaip kiekvieno masteliavimo sluoksnio lubas ir prieš didindami maksimumą patikrinkite likusį rezervą.

Valdymo plokštuma taip pat masteliuojasi

Klasteris su daugybe podų ir dažnu masteliavimu apkrauna API serverį ir etcd. Kube-DC dokumentacija nurodo, kad valdymo plokštumos ir etcd ištekliai automatiškai pritaikomi sukonfigūruotose ribose augant klasterio apkrovai, o vertikalusis automatinis masteliavimas įjungtas pagal numatytuosius nustatymus. Savarankiškai valdomame klasteryje tų komponentų dydžio parinkimas yra jūsų darbas, o etcd jautrus išteklių trūkumui, kaip aiškiname savo straipsnyje apie valdomą ir savarankiškai talpinamą Kubernetes.

Dažniausios klaidos

  • Nėra išteklių užklausų. Be CPU užklausos panaudojimo tikslo apskaičiuoti neįmanoma, ir HPA tai metrikai nieko nedaro.
  • Ignoruojamas paleidimo elgesys. Podas, kuris inicializuojantis sunaudoja daug CPU, gali sukelti papildomus didinimus. Kubernetes dokumentacija rekomenduoja paleidimo (startup) zondą arba pasirengimo (readiness) zondą, kuris praeina tik po šuolio, o valdiklis ignoruoja podo CPU mėginius jo inicializavimo laikotarpiu.
  • Masteliavimas pagal CPU, kai CPU nėra kliūtis. autoscaling/v2 API taip pat palaiko atminties ir pasirinktines metrikas, kurios geriau tinka eile valdomiems ar į I/O įsitraukusiems darbo krūviams.
  • Maksimumo nustatymas netikrinant galios. Kaip minėta aukščiau, replikos, viršijančios tai, ką telkinys gali sutalpinti, tiesiog laukia Pending būsenoje.
  • Viena replika produkcijoje. Minimumas vienas reiškia vieną podą, kol apkrova maža. Viskam, kas turi išgyventi mazgo praradimą, naudokite didesnį minimumą.

Šaltiniai

Susiję skaitiniai

Paleiskite šį bandymą savo klasteryje

Kiekvienas Kube-DC paketas apima įdėtuosius Kubernetes klasterius, sukuriamus iš jūsų projekto savitarnos portale, su paruoštu metrics-server ir matoma jūsų kvota, kad galėtumėte planuoti galią. Už jų slypi dedikuoti vCPU, Ceph pagrįsta NVMe saugykla, dedikuotas viešasis IPv4 ir su S3 suderinama objektų saugykla, su 24/7 pagalba el. paštu ir per užklausas bei 4 valandų sprendimo tikslu. Pakartokite aukščiau aprašytą vadovą ir savo akimis pamatykite, kaip juda replikos.

Susipažinkite su Kube-DC Kubernetes