Not. werger.: Nivîskarên vê gotarê endezyarên ji pargîdaniyek piçûk a Czech, pipetail in. Wan karî navnîşek ecêb a [carinan banal, lê dîsa jî] pirsgirêk û têgînên xelet ên têkildarî xebata komên Kubernetes berhev bikin.
Di salên bikaranîna Kubernetes de, me bi hejmareke mezin a koman re xebitî (hem bi rêve kirin û hem jî nerêveber - li ser GCP, AWS û Azure). Bi demê re, me dest pê kir ku hin xeletî bi berdewamî têne dubare kirin. Lêbelê, di vê yekê de şerm tune: me piraniya wan bixwe kiriye!
Di gotarê de xeletiyên herî gelemperî hene û her weha behsa çawaniya rastkirina wan jî dike.
1. Çavkanî: daxwaz û sînor
Ev tişt bê guman bala herî nêzîk û cîhê yekem di navnîşê de heq dike.
Daxwaza CPU bi gelemperî yan qet nehatiye diyarkirin yan jî nirxeke wê pir kêm e (ji bo ku bi qasî ku pêkan be li ser her girêkek bi qasî kulîlkan bi cîh bikin). Bi vî rengî, girêk zêde bar dibin. Di demên bargiraniya zêde de, hêza pêvajoyê ya girêkê bi tevahî tê bikar anîn û karek taybetî tenê tiştê ku ji hêla "daxwaz" ve distîne. Kêmkirina CPU. Ev dibe sedema zêdekirina derengiya serîlêdanê, dem û encamên din ên ne xweş. (Li ser vê yekê di wergera meya dawî ya din de bêtir bixwînin: "" - nêzîkî. werger.)
BestEffort (herî zêde ne pêşniyar kirin):
resources: {}Daxwaza CPU ya pir kêm (zehf ne pêşniyar kirin):
resources:
Requests:
cpu: "1m"Ji hêla din ve, hebûna sînorek CPU-yê dikare bibe sedema paşvekişandina bêaqil a çerxên demjimêrê ji hêla podan ve, hetta ku pêvajoya girêkê bi tevahî ne barkirî ye. Dîsa, ev dikare bibe sedema zêdebûna dereng. Nakokî li dora parametreyê berdewam dike kotaya CPU CFS di kernelê Linux û CPU-yê de li gorî tixûbên destnîşankirî veqetandin, û hem jî betalkirina kotaya CFS-ê... Mixabin, sînorên CPU-yê ji yên ku dikarin çareser bikin zêdetir dibe sedema pirsgirêkan. Agahiyên bêtir li ser vê yekê dikarin li ser lînka jêrîn bibînin.
Hilbijartina zêde (zêde kirin) pirsgirêkên bîra dikare bibe sedema pirsgirêkên mezintir. Gihîştina sînorê CPU bi paşketina çerxên demjimêrê vedihewîne, dema ku gihîştina sînorê bîranînê bi "kuştina" podê re vedigire. Ma we qet çavdêrî kiriye OOMkill? Erê, ew e ku em li ser dipeyivin.
Ma hûn dixwazin îhtîmala vê yekê kêm bikin? Bîrê zêde veneqetînin û QoS Garantî (Qalîteya Karûbar) bi kar bînin bi danîna daxwaza bîranînê li ser sînor (wek mînaka jêrîn). Di derbarê vê de bêtir bixwînin (Endezyarê sereke li Zalando).
Burstable (şansê bilind ê kuştina OOM):
resources:
requests:
memory: "128Mi"
cpu: "500m"
limits:
memory: "256Mi"
cpu: 2Guaranteed:
resources:
requests:
memory: "128Mi"
cpu: 2
limits:
memory: "128Mi"
cpu: 2Di sazkirina çavkaniyan de dê çi bibe alîkar?
Bi alîkariya alîkariya metrics-server hûn dikarin vexwarina çavkaniya CPU ya heyî û karanîna bîranînê ji hêla pods (û konteynerên hundurê wan) ve bibînin. Bi îhtîmaleke mezin, hûn berê wê bikar tînin. Tenê emrên jêrîn bimeşînin:
kubectl top pods
kubectl top pods --containers
kubectl top nodesLêbelê, ew tenê karanîna heyî nîşan didin. Ew dikare di derheqê rêza mezinahiyê de ramanek berbiçav bide we, lê di dawiyê de hûn ê hewce bibin dîroka guhertinên di metrics bi demê re (ji bo bersivdana pirsên wekî: "Berkêşana herî zêde ya CPU çi bû?", "Duh sibehê çi bû?", hwd.). Ji bo vê yekê hûn dikarin bikar bînin Prometheus, DataDog û amûrên din. Ew bi tenê metrîkan ji metrics-server distînin û wan hilînin, û bikarhêner dikare li wan bipirse û li gorî wan xêz bike.
Ev rê dide otomatîkkirin vê pêvajoyê. Ew dîroka karanîna CPU û bîranînê dişopîne û li gorî vê agahiyê daxwaz û sînorên nû saz dike.
Bikaranîna hêza hesabkirinê bi bandor ne karekî hêsan e. Mîna ku her dem Tetris dilîzin. Ger hûn ji bo hêza hesabkirinê ya bi xerckirina navînî ya kêm (bibêjin ~ 10%) pir zêde didin, em pêşniyar dikin ku li hilberên li ser bingeha AWS Fargate an Kubelet Virtual binêrin. Ew li ser modelek fatûreya bê server/pay-per-karsaziyê hatine çêkirin, ku dibe ku di şert û mercên weha de erzantir bibe.
2. Lêpirsînên zindîbûn û amadebûnê
Ji hêla xwerû ve, kontrolên zindîbûn û amadebûnê di Kubernetes de ne çalak in. Û carinan ew ji bîr dikin ku wan vekin ...
Lê wekî din hûn dikarin di bûyerek xeletiyek kujer de karûbarek ji nû ve bidin destpêkirin? Û çawa balansa barkirinê dizane ku pod amade ye ku seyrûseferê qebûl bike? An ku ew dikare bêtir seyrûseferê bike?
Van testan bi gelemperî bi hevûdu re têne şaş kirin:
- Zindî - Kontrola "serbixwebûnê", ya ku podê ji nû ve dest pê dike heke têk biçe;
- Amadekirin - Kontrola amadebûnê, heke ew têk neçe, ew pod ji karûbarê Kubernetes veqetîne (ev dikare bi karanîna ve were kontrol kirin
kubectl get endpoints) û seyrûsefer nagihîje wê heya ku kontrolê din bi serfirazî neqede.
Ev herdu kontrol DI DEMA TEVÎ XIVÎYA JIYANÊ YA PODÊ DE TÊ KIRIN. Pir girîng e.
Nerazîbûnek hevpar ev e ku sondajên amadehiyê tenê di destpêkê de têne xebitandin da ku balansek zanibe ku pod amade ye (Ready) û dikare dest bi seyrûseferê bike. Lêbelê, ev tenê yek ji vebijarkên ji bo karanîna wan e.
Din jî îhtîmala dîtina ku seyrûsefera li ser pod zêde ye û wê zêde bar dike (an jî pod hesabên çavkaniyê-dijwar pêk tîne). Di vê rewşê de, kontrolkirina amadebûnê dibe alîkar barkirina li ser pod kêm bikin û wê "sar" bikin. Di pêşerojê de qedandina serketî ya kontrolek amadebûnê destûrê dide barkirina li ser pod dîsa zêde bike. Di vê rewşê de (heke ceribandina amadebûnê têk biçe), têkçûna ceribandina zindîbûnê dê pir berevajî be. Çima podek ku saxlem e û dijwar dixebite ji nû ve bidin destpêkirin?
Ji ber vê yekê, di hin rewşan de, çu kontrol ji çalakkirina wan bi parametreyên nerast vesazkirî çêtir e. Wekî ku li jor hate gotin, heke kontrolkirina jîngehê kontrolkirina amadebûnê kopî dike, hingê hûn di tengahiyek mezin de ne. Vebijêrkek gengaz e ku mîheng bike û bihêle.
Dema ku girêdanên hevpar têk diçin divê her du cûreyên kontrolê têk neçin, wekî din ev ê bibe sedema têkçûnek kaskadî (mîna berfê) ya hemî podan. Bi gotineke din, .
3. LoadBalancer ji bo her xizmeta HTTP
Bi îhtîmalek mezin, we di koma we de karûbarên HTTP hene ku hûn dixwazin ji cîhana derve re bişînin.
Ger hûn xizmetê wekî vekin type: LoadBalancer, kontrolkerê wê (li gorî peydakerê karûbarê ve girêdayî ye) dê LoadBalancerek derveyî peyda bike û danûstandinê bike (ne hewce ye ku li ser L7, lê li ser L4-ê jî tê xebitandin), û ev dibe ku bandorê li lêçûnê bike (navnîşana IPv4 ya statîk a derve, hêza hesabkirinê, fatûreya serê çirkeyê ) ji ber hewcedariya afirandina hejmareke mezin ji çavkaniyên weha.
Di vê rewşê de, pir maqûltir e ku meriv yek balansek barkirinê ya derveyî bikar bîne, vekirina karûbarên wekî type: NodePort. An jî çêtir e, tiştek wekî berfireh bikin nginx-ingress-kontroller (an jî traefik), kî dê tenê yek be NodePort xala dawîyê bi hevsengek barkirina derveyî ve girêdayî ye û dê seyrûsefera komê bi kar bîne rê ketin-Çavkaniyên Kubernetes.
Karûbarên din ên hundurîn (mîkro) ku bi hevûdu re têkilî daynin dikarin bi karanîna karûbarên mîna ClusterIP û mekanîzmayek vedîtina karûbarê bi navgîniya DNS-ê ve hatî çêkirin. Tenê DNS / IP-ya wan a gelemperî bikar neynin, ji ber ku ev dikare bandorê li derengiyê bike û lêçûna karûbarên cloudê zêde bike.
4. Xweserkirina komek bêyî ku taybetmendiyên wê bêne hesibandin
Dema ku girêkan li komekê zêde bikin û wan ji komekê derxînin, divê hûn xwe bispêrin hin metrîkên bingehîn ên mîna karanîna CPU-yê li ser wan girêkan. Plansazkirina Pod divê gelek kesan bihesibîne sînorkirin, wek girêdana pods / girêkan, nerîn û tolerans, daxwazên çavkaniyê, QoS, hwd. Bikaranîna otoscalerek derveyî ku van nuwazeyan li ber çavan nagire, dikare bibe sedema pirsgirêkan.
Bifikirin ku divê hin podek were plansaz kirin, lê hemî hêza CPU ya berdest tê xwestin/jihevdexistin û pod di nav dewletekê de asê dibe Pending. Otoscalerkerê derveyî navînî barkirina CPU ya heyî (ne ya tê xwestin) dibîne û berfirehbûnê dest pê nake (pîvazkirin) - nodek din lê zêde nake. Wekî encamek, ev pod dê neyê plansaz kirin.
Di vê rewşê de, pîvana berevajî (pîvek-li) - rakirina girêkek ji komekê her gav pêkanîna dijwartir e. Bifikirin ku we podek dewletdar heye (bi hilanîna domdar ve girêdayî ye). cildên Persistent bi gelemperî girêdayî ye herêma hebûna taybetî û li herêmê nayên dubarekirin. Bi vî rengî, heke otoscalerek derveyî girêkek bi vê podê re jêbibe, wê hingê plansaz dê nikaribe vê podê li ser girêkek din destnîşan bike, ji ber ku ev tenê dikare li devera peydabûnê ya ku depoya domdar lê ye were kirin. Pod dê di dewletê de bimîne Pending.
Di civata Kubernetes de pir populer . Ew li ser komekê dimeşîne, API-yên ji pêşkêşkerên sereke yên ewr piştgirî dike, hemî qedexeyan dihesibîne û dikare di rewşên jorîn de pîvan bike. Di heman demê de di heman demê de ku hemî sînorên destnîşankirî diparêze, di heman demê de dikare pîvaz bike, bi vî rengî drav (ku wekî din dê li ser kapasîteya neyê bikar anîn were xerc kirin).
5. Îhmalkirina kapasîteyên IAM/RBAC
Hay ji karanîna bikarhênerên IAM-ê yên bi razên domdar ji bo makîne û sepanên. Bi karanîna rol û hesabên karûbarê gihîştina demkî organîze bikin (hesabên karûbar).
Em gelek caran rastî wê yekê tên ku bişkokên gihîştinê (û nehênî) di veavakirina serîlêdanê de kodkirî ne, û her weha guh nadin zivirandina nehêniyan tevî ku gihîştina Cloud IAM-ê. Li cîhê ku guncan be li şûna bikarhêneran rol û hesabên karûbarê IAM bikar bînin.
Kube2iam ji bîr bikin û rasterast biçin rolên IAM-ê ji bo hesabên karûbarê (wekî ku di nav de hatî destnîşan kirin Štěpán Vraný):
apiVersion: v1
kind: ServiceAccount
metadata:
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
name: my-serviceaccount
namespace: defaultYek annotation. Ne ew qas dijwar, rast?
Di heman demê de, hesabên karûbar û profîlên mînakî îmtiyazên nedin admin и cluster-admineger ew ne hewce ne. Pêkanîna vê yekê hinekî dijwartir e, nemaze di RBAC K8 de, lê bê guman hêjayî hewildanê ye.
6. Pişta xwe nedin ser dij-hevalîtîya otomatîkî ya ji bo podan
Bifikirin ku we sê kopiyên hin bicîhkirinê li ser nodek heye. Girêk dikeve, û bi wê re hemî replica. Rewşa ne xweş, rast? Lê çima hemî replica li ser heman nodê bûn? Ma ne hewce ye ku Kubernetes hebûna bilind (HA) peyda bike?!
Mixabin, plansazkerê Kubernetes, bi însiyatîfa xwe, bi qaîdeyên hebûna cihêreng tevnagere (dij-hevalîtî) ji bo piyan. Divê ew bi eşkereyî bêne gotin:
// опущено для краткости
labels:
app: zk
// опущено для краткости
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: "app"
operator: In
values:
- zk
topologyKey: "kubernetes.io/hostname"
Navê pêger. Naha dê pod li ser girêkên cihêreng werin plansaz kirin (ev rewş tenê di dema plansaziyê de tê kontrol kirin, lê ne di dema xebata wan de - ji ber vê yekê requiredDuringSchedulingIgnoredDuringExecution).
Li vir em li ser dipeyivin podAntiAffinity li ser girêkên cûda: topologyKey: "kubernetes.io/hostname", - û ne li ser deverên cûda yên hebûna. Ji bo pêkanîna HA-ya bêkêmasî, hûn ê neçar bin ku di vê mijarê de kûrtir bikolin.
7. Paguhkirina PodDisruptionBudgets
Bifikirin ku we bargiraniyek hilberînê li ser komek Kubernetes heye. Bi periyodîk, girêk û kom bi xwe pêdivî ye ku bêne nûve kirin (an jêbirin). PodDisruptionBudget (PDB) tiştek mîna peymanek garantiya karûbarê di navbera rêveberên komê û bikarhêneran de ye.
PDB dihêle hûn ji qutbûna karûbarê ku ji ber kêmbûna girêk çêdibin dûr bixin:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: zk-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: zookeeperDi vê nimûneyê de, hûn, wekî bikarhênerek komê, ji rêveberan re dibêjin: "Hey, min karûbarek zookparêz heye, û hûn çi bikin jî, ez dixwazim bi kêmî ve 2 kopiyên vê karûbarê her dem hebin."
Hûn dikarin li ser vê yekê bêtir bixwînin .
8. Pir bikarhêner an jîngeh di komek hevpar de
Cihên navên Kubernetes (cihên navan) îzolasyoneke xurt nadin.
Nerazîbûnek hevpar ev e ku heke hûn barek ne-prod di nav cîhek navekî de û barek prod li cîhek din bicîh bikin, wê hingê ew dê bi tu awayî bandorê li hev nekin... Lêbelê, astek diyarkirî ya veqetandinê bi karanîna daxwazên çavkaniyê/sînorkirin, danîna kotayan, û danîna dersên pêşîn dikare were bidestxistin. Hin îzolekirina "fizîkî" ya di plana daneyê de ji hêla girêdan, tolerasyon, gemaran (an helbijarkeran) ve tê peyda kirin, lê veqetandinek wusa pir e. zehmet e bicîanîn.
Yên ku hewce ne ku her du celeb bargiraniyên xebatê di heman komê de bihev bikin dê neçar bin ku bi tevliheviyê re mijûl bibin. Ger hewcedariyek wusa tune, û hûn dikarin yek hebe komeke din (bibêjin, di ewrek gelemperî de), wê hingê çêtir e ku meriv wiya bike. Ev ê bigihîje astek pir bilind a însulasyonê.
9. DerveyîTrafficPolicy: Cluster
Pir caran em dibînin ku hemî seyrûsefera li hundurê komê bi karûbarek mîna NodePort ve tê, ku ji bo wê polîtîkaya xwerû hatî danîn externalTrafficPolicy: Cluster... Ew tê wê wateyê NodePort li ser her girêkek di komê de vekirî ye, û hûn dikarin her yek ji wan bikar bînin da ku bi karûbarê xwestinê re têkilî daynin (komek pods).
Di heman demê de, podên rastîn ên ku bi karûbarê NodePort-a jorîn ve girêdayî ne bi gelemperî tenê li ser hindek peyda dibin. binkoma van girêkan. Bi gotinek din, heke ez bi girêkek ku xwedan poda pêwîst tune ve girêbidim, ew ê seyrûseferê bigihîne nodek din, hop zêde kirin û zêdekirina derengiyê (eger girêk li deverên cûda yên hebûna / navendên daneyê bi cih bibin, dereng dikare pir zêde be; ji bilî vê, lêçûnên seyrûsefera derketinê dê zêde bibe).
Ji hêla din ve, ger hin karûbarek Kubernetes xwedan siyasetek e externalTrafficPolicy: Local, wê hingê NodePort tenê li ser wan girêkan vedike ku pêlên pêwîst bi rastî lê dixebitin. Dema ku balansek barkirinê ya derveyî bikar tîne ku dewletê kontrol dike (kontrolkirina tenduristiyê) xalên dawîn (çawa dike AWS ELB), Ew dê trafîkê tenê ji girêkên pêwîst re bişîne, ya ku dê bandorek bikêr li ser dereng, hewcedariyên hesabkirinê, fatûreyên derketinê bike (û aqilê hevpar heman ferman dike).
Îhtîmalek mezin heye ku hûn berê tiştek mîna bikar tînin traefik an nginx-ingress-kontroller wekî xala dawiya NodePort (an LoadBalancer, ku di heman demê de NodePort jî bikar tîne) ji bo rêgirtina seyrûsefera têketina HTTP-ê, û danîna vê vebijarkê dikare derengiya daxwazên weha bi girîngî kêm bike.
В Hûn dikarin li ser DerveyîTrafficPolicy, awantaj û dezawantajên wê bêtir fêr bibin.
10. Bi koman ve girêdayî nebin û balafira kontrolê xerab nekin
Berê, adet bû ku meriv serveran bi navên xwerû bang bike: , HAL9000 û Colossus... Îro li şûna wan nasnameyên bi korfelaqî hatine çêkirin hatine guhertin. Lêbelê, adet ma, û naha navên xwerû diçin koman.
Çîrokek tîpîk (li ser bingeha bûyerên rastîn): her tişt bi delîlek têgehê dest pê kir, ji ber vê yekê komê navek serbilind bû. testkirina… Sal derbas bûn û HÎN di hilberînê de tê bikar anîn, û her kes ditirse ku dest bavêje wê.
Tiştek xweş tune ku komikên ku bibin heywanên heywanan, ji ber vê yekê em pêşniyar dikin ku di dema pratîkê de wan dem bi dem ji holê rakin vegerandina karesatê (ev ê alîkariyê bike - nêzîkî. werger.). Digel vê yekê, ew ê zirarê nede ku meriv li ser qata kontrolê bixebite (balafira kontrolê). Ditirsin ku dest bidin wî ne nîşanek baş e. hwd. mirî? Hevalno, hûn bi rastî di tengasiyê de ne!
Ji aliyê din ve, divê hûn bi manîpulekirina wê neçin. Bi demê re dibe ku qata kontrolê hêdî bibe. Bi îhtimaleke mezin, ev ji ber hejmareke mezin a tiştan e ku bêyî zivirîna wan têne afirandin (rewşek hevpar dema ku Helm bi mîhengên xwerû bikar tînin, ji ber vê yekê rewşa wê di mîhengan/veşartan de nayê nûve kirin - di encamê de, bi hezaran tişt di nav de kom dibin. qata kontrolê) an bi guherandina domdar a tiştên kube-api (ji bo pîvandina otomatîk, ji bo CI/CD, ji bo şopandin, têketinên bûyeran, kontrolker, hwd.).
Digel vê yekê, em pêşniyar dikin ku peymanên SLA/SLO bi peydakiroxê Kubernetes-ê re bi rêve bibin û bala xwe bidin garantiyan. Firoşkar dikare garantî bike hebûna qatê kontrolê (an pêkhateyên wê), lê ne derengiya p99 ya daxwazên ku hûn jê re dişînin. Bi gotineke din, hûn dikarin têkevin kubectl get nodes, û tenê piştî 10 hûrdeman bersivek bistînin, û ev ê nebe binpêkirina şertên peymana karûbarê.
11. Bonus: bikaranîna tagê herî dawî
Lê ev jixwe klasîkek e. Di van demên dawî de em kêm caran rastî vê teknîkê tên, ji ber ku gelekan, ku ji ezmûna tal fêr bûne, dev ji karanîna tagê berdane. :latest û dest bi pînekirina guhertoyan kir. Hooray!
ECR ; Em pêşniyar dikin ku hûn xwe bi vê taybetmendiya berbiçav nas bikin.
Nîqaş
Li bendê nebin ku her tişt di şevekê de bixebite: Kubernetes ne dermanek e. Serlêdana xirab (û dibe ku ew ê xirabtir bibe). Xemgînî dê bibe sedema tevliheviya zêde, xebata hêdî û stresê ya qata kontrolê. Wekî din, hûn xeternak in ku hûn bêyî stratejiyek başkirina karesatê bimînin. Li bendê nebin ku Kubernetes ji qutiyê veqetandin û hebûna bilind peyda bike. Hin dem derbas bikin ku serîlêdana xwe bi rastî xwecî cloudê bikin.
Hûn dikarin bi serpêhatiyên neserkeftî yên tîmên cûrbecûr re bibin nas ji hêla Henning Jacobs ve.
Kesên ku dixwazin li navnîşa xeletiyên ku di vê gotarê de hatine dayîn zêde bikin, dikarin li ser Twitterê bi me re têkilî daynin (, ).
PS ji wergêr
Li ser bloga me jî bixwînin:
- «»;
- «»;
- «"(nirxandin û raporta vîdyoyê);
- «".
Source: www.habr.com