Aron hingpit nga ma-master ang Kubernetes, kinahanglan nimo mahibal-an ang lainlaing mga paagi sa pag-scale sa mga kapanguhaan sa cluster: pinaagi sa , usa kini sa mga nag-unang buluhaton sa Kubernetes. Naghatag kami usa ka taas nga lebel nga kinatibuk-ang panan-aw sa pinahigda ug bertikal nga autoscaling ug mga mekanismo sa pagbag-o sa cluster, ingon man mga rekomendasyon kung giunsa kini magamit nga epektibo.
Artikulo gihubad sa team nga nagpatuman sa autoscaling sa .
Ngano nga hinungdanon nga maghunahuna bahin sa pag-scale
- usa ka himan alang sa pagdumala sa kahinguhaan ug orkestra. Siyempre, nindot nga mag-usik sa mga cool nga bahin sa pag-deploy, pag-monitor, ug pagdumala sa mga pod (ang pod usa ka grupo sa mga sudlanan nga gilunsad agig tubag sa usa ka hangyo).
Bisan pa, kinahanglan nimo usab nga hunahunaon ang mosunod nga mga pangutana:
- Giunsa ang pag-scale sa mga module ug aplikasyon?
- Sa unsa nga paagi sa pagpadayon sa mga sudlanan nga magamit ug episyente?
- Giunsa pagtubag ang kanunay nga pagbag-o sa code ug mga workloads gikan sa mga tiggamit?
Ang pag-configure sa mga cluster sa Kubernetes aron mabalanse ang mga kahinguhaan ug performance mahimong mahagiton ug magkinahanglan og kahibalo sa eksperto sa sulod nga mga buhat sa Kubernetes. Ang workload sa imong aplikasyon o mga serbisyo mahimong mag-usab-usab sa tibuok adlaw o bisan sa dagan sa usa ka oras, mao nga ang pagbalanse labing maayo nga isipon isip usa ka nagpadayon nga proseso.
Mga lebel sa autoscaling sa Kubernetes
Ang epektibo nga autoscaling nanginahanglan koordinasyon tali sa duha nga lebel:
- Ang lebel sa pod, lakip ang pinahigda (Horizontal Pod Autoscaler, HPA) ug vertical nga autoscaler (Vertical Pod Autoscaler, VPA). Kini mao ang pag-scale sa anaa nga mga kapanguhaan alang sa imong mga sudlanan.
- Ang lebel sa kumpol, nga gidumala sa Cluster Autoscaler (CA), nga nagdugang o nagpamenos sa gidaghanon sa mga node sulod sa cluster.
Horizontal Autoscaler (HPA) module
Sama sa gisugyot sa ngalan, ang HPA nagtimbang sa gidaghanon sa pod nga mga replika. Kadaghanan sa mga devop naggamit sa CPU ug memory load isip mga trigger sa pag-usab sa gidaghanon sa mga replika. Bisan pa, posible nga i-scale ang sistema base sa , sila o bisan pa .
Taas nga lebel sa HPA operating diagram:
- Ang HPA padayon nga nagsusi sa metric values ββββnga gipiho sa panahon sa pag-instalar sa default interval nga 30 segundos.
- Ang HPA mosulay sa pagdugang sa gidaghanon sa mga modules kung ang gitakda nga threshold maabot.
- Ang HPA nag-update sa gidaghanon sa mga replika sulod sa deployment/replication controller.
- Ang deployment/replication controller unya nag-deploy sa bisan unsa nga gikinahanglan nga dugang nga mga module.
Gisugdan sa HPA ang proseso sa pag-deploy sa module kung maabot na ang metric threshold
Sa paggamit sa HPA, hunahunaa ang mosunod:
- Ang default nga HPA check interval kay 30 segundos. Gibutang kini sa bandila horizontal-pod-autoscaler-sync-period sa controller manager.
- Ang default nga paryente nga sayup mao ang 10%.
- Pagkahuman sa katapusan nga pagtaas sa gidaghanon sa mga module, gipaabut sa HPA nga ang mga sukatan mo-stabilize sa sulod sa tulo ka minuto. Kini nga agwat gitakda sa bandila horizontal-pod-autoscaler-upscale-delay.
- Human sa katapusang pagkunhod sa gidaghanon sa mga modules, ang HPA maghulat ug lima ka minuto aron ma-stabilize. Kini nga agwat gitakda sa bandila horizontal-pod-autoscaler-downscale-delay.
- Ang HPA labing maayo nga nagtrabaho sa mga butang nga gi-deploy kaysa mga tigkontrol sa pagkopya. Ang horizontal autoscaling dili uyon sa rolling update, nga direktang nagmaniobra sa replication controllers. Sa deployment, ang gidaghanon sa mga replika nagdepende direkta sa deployment nga mga butang.
Vertical autoscaling sa mga pod
Vertical autoscaling (VPA) naggahin ug mas daghan (o mas gamay) nga oras sa CPU o memorya sa mga naa na pod. Angayan alang sa stateful o stateless pods, apan nag-una nga gituyo alang sa stateful nga mga serbisyo. Bisan pa, mahimo usab nimo gamiton ang VPA alang sa mga walaβy estado nga module kung kinahanglan nimo nga awtomatiko nga i-adjust ang kantidad sa una nga gigahin nga mga kapanguhaan.
Nagtubag usab ang VPA sa mga panghitabo sa OOM (wala na sa panumduman). Ang pagbag-o sa oras ug memorya sa CPU nanginahanglan pag-restart sa mga pod. Kung gi-restart, girespeto sa VPA ang badyet sa alokasyon () aron magarantiya ang minimum nga gikinahanglan nga gidaghanon sa mga modules.
Mahimo nimong itakda ang minimum ug maximum nga mga kapanguhaan alang sa matag module. Sa ingon, mahimo nimong limitahan ang labing kadaghan nga gigahin nga memorya sa 8 GB. Mapuslanon kini kung ang mga karon nga node siguradong dili makagahin labaw pa sa 8 GB nga memorya matag sudlanan. Ang detalyado nga mga detalye ug mekanismo sa operasyon gihulagway sa .
Dugang pa, ang VPA adunay usa ka makapaikag nga function sa rekomendasyon (VPA Recommender). Gibantayan niini ang paggamit sa kapanguhaan ug mga panghitabo sa OOM sa tanan nga mga module aron isugyot ang bag-ong memorya ug mga kantidad sa oras sa CPU base sa usa ka intelihenteng algorithm base sa mga sukatan sa kasaysayan. Adunay usab usa ka API nga nagkuha usa ka pod nga gunitanan ug gibalik ang gisugyot nga mga kantidad sa kapanguhaan.
Angay nga hinumdoman nga ang VPA Recommender wala magsubay sa "limitasyon" sa kapanguhaan. Mahimong moresulta kini sa pagmonopolyo sa module sa mga kapanguhaan sulod sa mga node. Mas maayo nga ibutang ang limitasyon sa lebel sa namespace aron malikayan ang dako nga memorya o konsumo sa CPU.
Taas nga lebel nga pamaagi sa operasyon sa VPA:
- Ang VPA padayon nga nagsusi sa metric values ββnga gipiho sa panahon sa pag-instalar sa default interval nga 10 segundos.
- Kung ang gitakda nga threshold maabot, ang VPA mosulay sa pag-usab sa gigahin nga kantidad sa mga kapanguhaan.
- Ang VPA nag-update sa gidaghanon sa mga kapanguhaan sulod sa deployment/replication controller.
- Kung ang mga module gi-restart, ang tanan nga mga bag-ong kapanguhaan magamit sa mga nahimo nga mga higayon.
Gidugang sa VPA ang gikinahanglan nga kantidad sa mga kapanguhaan
Palihug hinumdomi ang mosunod nga mga punto kung mogamit sa VPA:
- Ang scaling nanginahanglan usa ka mandatory restart sa pod. Kini mao ang gikinahanglan aron sa paglikay sa dili lig-on nga operasyon human sa paghimo sa mga kausaban. Alang sa kasaligan, ang mga module gi-restart ug giapod-apod sa mga node base sa bag-ong gigahin nga mga kapanguhaan.
- Ang VPA ug HPA dili pa compatible sa usag usa ug dili makadagan sa samang pods. Kung gigamit nimo ang duha nga mga mekanismo sa pag-scale sa parehas nga cluster, siguruha nga ang imong mga setting nagpugong niini nga ma-aktibo sa parehas nga mga butang.
- Gitun-an sa VPA ang mga hangyo sa sudlanan alang sa mga kapanguhaan base lamang sa nangagi ug karon nga paggamit. Wala kini magbutang ug mga limitasyon sa paggamit sa kahinguhaan. Mahimong adunay mga problema sa mga aplikasyon nga dili molihok sa husto ug nagsugod sa pagkuha sa dugang ug dugang nga mga kapanguhaan, kini modala ngadto sa Kubernetes sa pagpalong niini nga pod.
- Ang VPA anaa pa sa sayo nga yugto sa pag-uswag. Pag-andam nga ang sistema mahimong moagi sa pipila ka mga pagbag-o sa umaabot nga umaabot. Makabasa ka bahin sa ΠΈ . Sa ingon, adunay mga plano nga ipatuman ang hiniusang operasyon sa VPA ug HPA, ingon man ang pag-deploy sa mga module kauban ang usa ka bertikal nga polisiya sa autoscaling alang kanila (pananglitan, usa ka espesyal nga label 'nagkinahanglan VPA').
Autoscaling sa usa ka Kubernetes cluster
Ang Cluster Autoscaler (CA) nagbag-o sa gidaghanon sa mga node base sa gidaghanon sa naghulat nga mga pod. Ang sistema matag karon ug unya nagsusi alang sa pending nga mga module - ug nagdugang sa gidak-on sa cluster kung gikinahanglan ang dugang nga mga kapanguhaan ug kung ang cluster dili molapas sa natukod nga mga limitasyon. Ang CA nakigkomunikar sa cloud service provider, nangayo og dugang nga mga node gikan niini, o nagpagawas sa mga walay pulos. Ang una nga kasagarang magamit nga bersyon sa CA gipaila sa Kubernetes 1.8.
Taas nga lebel nga laraw sa operasyon sa SA:
- Gisusi sa CA ang pending nga mga module sa default interval nga 10 segundos.
- Kung ang usa o daghan pa nga mga pod naa sa standby nga estado tungod kay ang cluster walay igong magamit nga mga kapanguhaan sa paggahin niini, kini mosulay sa paghatag og usa o daghan pa nga mga node.
- Sa diha nga ang cloud service provider mogahin sa gikinahanglan nga node, kini moapil sa cluster ug andam sa pag-alagad sa mga pods.
- Ang Kubernetes scheduler nag-apod-apod sa mga pending pod sa bag-ong node. Kung pagkahuman niini ang pipila ka mga module nagpabilin nga naghulat nga kahimtang, ang proseso gisubli ug ang mga bag-ong node idugang sa cluster.
Awtomatikong paghatag sa mga cluster node sa panganod
Tagda ang mosunod kon gamiton ang CA:
- Gisiguro sa CA nga ang tanan nga mga pod sa cluster adunay lugar nga magamit, bisan unsa pa ang load sa CPU. Gisulayan usab niini nga masiguro nga walaβy wala kinahanglana nga mga node sa cluster.
- Girehistro sa CA ang panginahanglan sa pag-scale pagkahuman sa gibana-bana nga 30 segundos.
- Sa higayon nga ang usa ka node dili na kinahanglan, ang CA default sa paghulat sa 10 minutos sa dili pa scaling ang sistema.
- Ang sistema sa autoscaling adunay konsepto sa mga expander. Lainlain kini nga mga estratehiya sa pagpili sa usa ka grupo sa mga node diin ang mga bag-ong node idugang.
- Gamita ang opsyon nga responsable cluster-autoscaler.kubernetes.io/safe-to-evict (tinuod). Kung mag-install ka daghang mga pod, o kung daghan niini nagkatag sa tanan nga mga node, labi ka mawad-an ka sa abilidad sa pag-scale sa cluster.
- Paggamit aron mapugngan ang mga pod nga matangtang, nga mahimong hinungdan nga ang mga bahin sa imong aplikasyon hingpit nga maguba.
Giunsa ang mga autoscaler sa Kubernetes makig-uban sa usag usa
Para sa hingpit nga panag-uyon, ang autoscaling kinahanglang i-apply sa pod level (HPA/VPA) ug cluster level. Sila nakig-uban sa usag usa medyo yano:
- Ang mga HPA o VPA nag-update pod sa mga replika o mga kahinguhaan nga gigahin sa kasamtangan nga mga pod.
- Kung walay igo nga mga node alang sa giplano nga scaling, ang CA nakamatikod sa presensya sa mga pod sa usa ka naghulat nga kahimtang.
- Ang CA naggahin ug bag-ong mga node.
- Ang mga module giapod-apod sa bag-ong mga node.
Kolaborasyon nga Kubernetes scale-out nga sistema
Kasagarang mga sayop sa Kubernetes autoscaling
Adunay ubay-ubay nga kasagarang mga problema nga mahitabo kung mosulay sa pagpatuman sa autoscaling.
Ang HPA ug VPA nagdepende sa mga sukatan ug pipila ka makasaysayanong datos. Kung dili igo nga mga kapanguhaan ang gigahin, ang mga module maminusan ug dili makahimo og mga sukatan. Sa kini nga kaso, ang autoscaling dili mahitabo.
Ang scaling operation mismo sensitibo sa oras. Gusto namon nga ang mga module ug cluster dali nga modako - sa dili pa mamatikdan sa mga tiggamit ang bisan unsang mga problema o kapakyasan. Busa, ang kasagaran nga oras alang sa pag-scaling sa mga pod ug ang cluster kinahanglan nga tagdon.
Maayo nga senaryo - 4 ka minuto:
- 30 segundos. I-update ang target metrics: 30β60 segundos.
- 30 segundos. Gisusi sa HPA ang metric values: 30 segundos.
- Wala pay 2 segundos. Gibuhat ang mga pod ug naa sa kahimtang sa paghulat: 1 segundo.
- Wala pay 2 segundos. Nakita sa CA ang naghulat nga mga module ug nagpadala sa mga tawag sa mga provision node: 1 segundo.
- 3 minutos. Ang cloud provider naggahin og mga node. Ang mga K8 naghulat hangtod nga sila andam: hangtod sa 10 minuto (depende sa daghang mga hinungdan).
Ang pinakagrabe nga kaso (mas realistiko) nga senaryo - 12 ka minuto:
- 30 segundos. I-update ang target metrics.
- 30 segundos. Gisusi sa HPA ang metric values.
- Wala pay 2 segundos. Ang mga pod gihimo ug mosulod sa standby state.
- Wala pay 2 segundos. Nakita sa CA ang naghulat nga mga module ug nagtawag aron mahatagan ang mga node.
- 10 minutos. Ang cloud provider naggahin og mga node. Naghulat ang K8 hangtod andam na sila. Ang oras sa paghulat nagdepende sa daghang mga hinungdan, sama sa paglangan sa vendor, paglangan sa OS, ug mga himan sa pagsuporta.
Ayaw libuga ang mga mekanismo sa pag-scale sa mga cloud provider sa among CA. Ang naulahi midagan sulod sa usa ka Kubernetes cluster, samtang ang cloud provider engine naglihok sa node distribution basis. Wala kini nahibal-an kung unsa ang nahitabo sa imong mga pod o aplikasyon. Kini nga mga sistema naglihok nga managsama.
Giunsa pagdumala ang scaling sa Kubernetes
- Ang Kubernetes usa ka himan sa pagdumala sa kahinguhaan ug orkestra. Ang mga operasyon alang sa pagdumala sa mga pod ug mga kahinguhaan sa cluster usa ka mahinungdanong milestone sa pag-master sa Kubernetes.
- Sabta ang lohika sa pod scalability nga gikonsiderar ang HPA ug VPA.
- Ang CA kinahanglan nga gamiton lamang kung ikaw adunay maayo nga pagsabut sa mga panginahanglan sa imong mga pod ug mga sudlanan.
- Aron labing maayo nga ma-configure ang usa ka cluster, kinahanglan nimo nga masabtan kung giunsa ang lainlaing mga sistema sa pag-scale nagtinabangay.
- Kung gibanabana ang oras sa pag-scale, ibutang sa hunahuna ang labing daotan nga kaso ug labing maayo nga mga senaryo.
Source: www.habr.com