🥇10 ohiko akats Kubernetes erabiltzean

Ohar. itzul.: Artikulu honen egileak Txekiar enpresa txiki bateko ingeniariak dira, pipetail. Kubernetes klusterren funtzionamenduari lotutako arazo eta uste okerren [batzuetan hutsala, baina hala ere] zerrenda zoragarria osatzea lortu zuten.

Kubernetes erabiltzen urteetan zehar, kluster ugarirekin lan egin dugu (kudeatutako zein kudeatu gabeko - GCP, AWS eta Azure-n). Denborarekin, akats batzuk etengabe errepikatzen zirela ohartzen hasi ginen. Hala ere, honek ez du lotsarik: gehienak geuk egin ditugu!

Artikuluak akats ohikoenak jasotzen ditu eta horiek nola zuzendu ere aipatzen du.

1. Baliabideak: eskaerak eta mugak

Elementu honek, zalantzarik gabe, arretarik handiena eta zerrendako lehen postua merezi du.

CPU eskaera normalean edo batere zehaztu gabe edo oso balio baxua du (nodo bakoitzean ahalik eta lekak jartzeko). Horrela, nodoak gainkargatu egiten dira. Karga handiko garaietan, nodoaren prozesatzeko ahalmena guztiz erabiltzen da eta lan karga jakin batek "eskatu" duena baino ez du jasotzen. PUZaren murrizketa. Horrek aplikazioaren latentzia, denbora-muga eta beste ondorio desatseginak areagotzea dakar. (Irakurri honi buruz gehiago gure azken itzulpenean: "CPU mugak eta throttling oldarkorra Kubernetes-en"- gutxi gorabehera. itzul.)

BestEffort (izugarri ez gomendagarria):

resources: {}

CPU eskaera oso baxua (oso ez gomendagarria):

   resources:
      Requests:
        cpu: "1m"

Bestalde, PUZaren muga egoteak erloju-zikloak arrazoirik gabe saltea ekar dezake podek, nodo-prozesadorea guztiz kargatuta ez badago ere. Berriz ere, horrek atzerapenak areagotzea ekar dezake. Parametroaren inguruan eztabaidak jarraitzen du CPU CFS kuota Linux nukleoan eta CPU mugak ezarritako mugen arabera, baita CFS kuota desgaitu ere... Ai, CPU mugek ebatzi ditzaketen baino arazo gehiago sor ditzakete. Honi buruzko informazio gehiago beheko estekan aurki daiteke.

Gehiegizko hautaketa (gehiegizko konpromisoa) memoria arazoek arazo handiagoak ekar ditzakete. PUZaren mugara iristeak erloju-zikloak saltatzea dakar, eta memoria-mugara iristeak poda hiltzea dakar. Behatu al duzu inoiz OOMkill? Bai, horretaz ari gara hain zuzen.

Hori gertatzeko probabilitatea gutxitu nahi al duzu? Ez esleitu memoria gehiegi eta erabili Guaranteed QoS (Zerbitzuaren kalitatea) memoria eskaera mugara ezarriz (beheko adibidean bezala). Irakurri gehiago honi buruz Henning Jacobsen aurkezpenak (Zalandoko ingeniari nagusia).

Lehergarria (OOMhiltzeko aukera handiagoa):

   resources:
      requests:
        memory: "128Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: 2

Bermatuta:

   resources:
      requests:
        memory: "128Mi"
        cpu: 2
      limits:
        memory: "128Mi"
        cpu: 2

Zer lagunduko du baliabideak konfiguratzerakoan?

With metrika-zerbitzaria PUZaren egungo baliabideen kontsumoa eta memoriaren erabilera ikus ditzakezu pods (eta horien barruan dauden edukiontzien arabera). Seguruenik, dagoeneko erabiltzen ari zara. Exekutatu komando hauek:

kubectl top pods
kubectl top pods --containers
kubectl top nodes

Hala ere, egungo erabilera soilik erakusten dute. Magnitude ordenaren ideia gutxi gorabeheratsua eman diezazuke, baina azkenean beharko duzu denboran zehar metriketan izandako aldaketen historia (adibidez: “Zein izan zen CPU karga gorena?”, “Zein izan zen atzo goizean karga?”, etab. Horretarako erabil dezakezu Prometeo, DataDog eta beste tresna batzuk. metrics-server-tik neurketak besterik ez dituzte eskuratzen eta gordetzen dituzte, eta erabiltzaileak kontsultatu eta horren arabera marra ditzake.

VerticalPodAutoscaler aukera ematen du automatizatu prozesu hau. PUZaren eta memoriaren erabileraren historiaren jarraipena egiten du eta informazio horretan oinarrituta eskaera eta muga berriak ezartzen ditu.

Konputazio-potentzia modu eraginkorrean erabiltzea ez da lan erraza. Denbora guztian Tetris jotzea bezala da. Batez besteko kontsumo txikia duen konputazio potentziagatik gehiegi ordaintzen ari bazara (esan % 10), AWS Fargate edo Kubelet birtualean oinarritutako produktuak ikustea gomendatzen dizugu. Zerbitzaririk gabeko/erabileraren araberako fakturazio-eredu batean eraikita daude, baldintza horietan merkeagoa izan daitekeena.

2. Bizitasun eta presttasun zundaketak

Lehenespenez, bizitasun eta presttasun egiaztapenak ez daude gaituta Kubernetesen. Eta batzuetan piztea ahazten zaie...

Baina bestela nola abiarazi dezakezu zerbitzua berrabiarazi errore larri bat gertatuz gero? Eta nola daki karga-orekatzaileak pod bat trafikoa onartzeko prest dagoela? Edo trafiko gehiago kudea dezakeela?

Askotan proba hauek elkarren artean nahasten dira:

Bizitasuna — "biziraugarritasuna" egiaztatzea, poda huts egiten badu berrabiarazten duena;
jarrera — prest dagoen egiaztatzea, huts egiten badu, kubernetes zerbitzutik poda deskonektatzen du (hau egiaztatu daiteke kubectl get endpoints) eta trafikoa ez da bertara iristen hurrengo egiaztapena behar bezala burutu arte.

Bi egiaztapen hauek PODAREN BIZITZA ZIKLO OSOAN EGINDAKOA. Oso garrantzitsua da.

Ohiko uste oker bat da presttasun-zundak abiaraztean soilik abiarazten direla, balantzaileak poda prest dagoela jakin dezan (Ready) eta trafikoa prozesatzen has daiteke. Hala ere, hau erabiltzeko aukeretako bat baino ez da.

Beste bat da podan trafikoa gehiegizkoa dela jakiteko aukera eta gainkargatzen du (edo lekak baliabide askoko kalkuluak egiten ditu). Kasu honetan, prest egoteak laguntzen du Murriztu lekaren karga eta "hoztu".. Etorkizunean prest egotearen egiaztapena arrakastaz osatzea ahalbidetzen du handitu lekaren karga berriro. Kasu honetan (prestasun-probak huts egiten badu), bizitasun-probak huts egitea oso kontrakoa izango litzateke. Zergatik berrabiarazi osasuntsu eta gogor lan egiten duen pod bat?

Hori dela eta, kasu batzuetan, egiaztapenik ez egitea hobe da gaizki konfiguratutako parametroekin gaitzea baino. Goian esan bezala, bada bizitasuna egiaztatzeko kopiak presttasuna egiaztatzeko, orduan arazo handietan zaude. Aukera posiblea konfiguratzea da presttasun proba soilikEta bizitasun arriskutsua alde batera utzi.

Bi egiaztapen-motek ez dute huts egin behar menpekotasun arruntek huts egiten dutenean, bestela honek kaskada (elur-jausi-itxurako) hutsegite bat ekarriko du pod guztien. Beste hitz batzutan, ez ezazu zeure buruari kalterik egin.

3. LoadBalancer HTTP zerbitzu bakoitzeko

Litekeena da zure klusterrean HTTP zerbitzuak kanpo mundura birbidali nahi dituzun.

Zerbitzua irekitzen baduzu type: LoadBalancer, bere kontroladoreak (zerbitzu-hornitzailearen arabera) kanpoko LoadBalancer bat emango du eta negoziatuko du (ez da nahitaez L7-n exekutatzen, L4-n baizik), eta horrek kostuan eragin dezake (kanpoko IPv4 helbide estatikoa, konputazio-potentzia, segundoko fakturazioa). ) baliabide horien kopuru handia sortu beharra dagoelako.

Kasu honetan, askoz logikoagoa da kanpoko karga-orekatzaile bat erabiltzea, zerbitzuak irekiz type: NodePort. Edo hobeto esanda, zabaldu antzeko zerbait nginx-ingress-controller (Edo traefik), nor izango den bakarra NodePorta kanpoko karga-orekatzaileari lotutako amaiera-puntua eta klusterreko trafikoa bideratuko du erabiliz sarrera-Kubernetes baliabideak.

Elkarren artean elkarreragiten duten kluster barneko (mikro)zerbitzu batzuk "komunikatu" daitezke, antzeko zerbitzuak erabiliz KlusterIP eta DNS bidezko zerbitzuen aurkikuntza mekanismo integratua. Ez erabili haien DNS/IP publikoa, horrek latentzian eragina izan dezakeelako eta hodeiko zerbitzuen kostua handitu dezakeelako.

4. Kluster bat autoeskalatzea bere ezaugarriak kontuan hartu gabe

Nodoak kluster batean gehitzean eta kentzean, ez zenuke oinarritu behar nodo horietan PUZaren erabilera bezalako oinarrizko metrika batzuetan. Pod plangintzak asko hartu behar ditu kontuan murrizketak, hala nola pod/nodo afinitatea, kutsadurak eta tolerantziak, baliabide eskaerak, QoS, etab. Ñabardura hauek kontuan hartzen ez dituen kanpoko autoeskalatzailea erabiltzeak arazoak sor ditzake.

Imajinatu pod jakin bat programatu behar dela, baina erabilgarri dagoen CPU potentzia guztia eskatzen/desmuntatzen da eta poda egoera batean trabatu egiten da Pending. Kanpoko eskalagailu automatikoak PUZaren batez besteko karga ikusten du (ez eskatutakoa) eta ez du hedapena hasten (eskalatzea) - ez du beste nodorik gehitzen. Ondorioz, pod hau ez da programatuko.

Kasu honetan, alderantzizko eskalatzea (eskalatzea) — Kluster batetik nodo bat kentzea beti da zailagoa inplementatzea. Imajinatu egoera-pod bat duzula (biltegiratze iraunkorra konektatuta dagoela). Bolumen iraunkorrak normalean erabilgarritasun eremu zehatza eta ez dira eskualdean errepikatzen. Horrela, kanpoko autoeskalatzaile batek pod honekin nodo bat ezabatzen badu, programatzaileak ezin izango du pod hau beste nodo batean programatu, biltegiratze iraunkorra dagoen erabilgarritasun eremuan soilik egin daitekeelako. Pod egoeran itsatsita egongo da Pending.

Oso ezaguna Kubernetes komunitatean cluster-autoscaler. Kluster batean exekutatzen da, hodeiko hornitzaile nagusien APIak onartzen ditu, murrizketa guztiak kontuan hartzen ditu eta goiko kasuetan eskala dezake. Gainera, eskalatzeko gai da ezarritako muga guztiak mantenduz, eta horrela dirua aurreztuko da (bestela erabiltzen ez den edukieran gastatuko litzateke).

5. IAM/RBAC gaitasunak alde batera utzita

Kontuz sekretu iraunkorrak dituzten IAM erabiltzaileak erabiltzeko makinak eta aplikazioak. Antolatu aldi baterako sarbidea rolak eta zerbitzu-kontuak erabiliz (zerbitzu-kontuak).

Sarritan aurkitzen dugu sarbide-gakoak (eta sekretuak) aplikazioaren konfigurazioan gogor kodetuta daudela, baita sekretuen biraketa alde batera uzten ere Cloud IAM-era sarbidea izan arren. Erabili IAM rolak eta zerbitzu-kontuak erabiltzaileen ordez, hala dagokionean.

Ahaztu kube2iam eta joan zuzenean zerbitzu-kontuetarako IAM roletara (atalburuan azaltzen den moduan izen bereko oharra Š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: default

Oharpen bat. Ez da hain zaila, ezta?

Gainera, ez eman zerbitzu kontuei eta instantzia-profilei pribilegiorik admin и cluster-adminbehar ez badute. Hau apur bat zailagoa da inplementatzea, batez ere RBAC K8etan, baina zalantzarik gabe merezi du ahalegina.

6. Ez fidatu leketarako afektuaren aurkako automatikoki

Imajinatu inplementazio batzuen hiru erreplika dituzula nodo batean. Nodoa erortzen da, eta horrekin batera erreplika guztiak. Egoera desatsegina, ezta? Baina zergatik zeuden erreplika guztiak nodo berean? Kubernetesek ez al du erabilgarritasun handia (HA) eman behar?!

Zoritxarrez, Kubernetes programatzaileak, bere kabuz, ez ditu bereizitako existentziaren arauak betetzen (afinitatearen aurkakoa) leketarako. Espresuki adierazi behar dira:

// опущено для краткости
      labels:
        app: zk
// опущено для краткости
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                    - zk
              topologyKey: "kubernetes.io/hostname"

Hori da dena. Orain pod-ak nodo desberdinetan programatuko dira (baldintza hau programazioan bakarrik egiaztatzen da, baina ez haien funtzionamenduan zehar - horregatik requiredDuringSchedulingIgnoredDuringExecution).

Hemen hitz egiten ari gara podAntiAffinity nodo ezberdinetan: topologyKey: "kubernetes.io/hostname", - eta ez erabilgarritasun-eremu ezberdinei buruz. HA osoa ezartzeko, gai honetan sakondu beharko duzu.

7. PodDisruptionBudgets alde batera utzita

Imajinatu Kubernetes kluster batean produkzio-karga bat duzula. Aldian-aldian, nodoak eta klusterra bera eguneratu (edo kendu) behar dira. PodDisruptionBudget (PDB) klusterren administratzaileen eta erabiltzaileen arteko zerbitzu-berme-akordio baten antzeko zerbait da.

PDB-k nodo faltak eragindako zerbitzu-etenaldiak saihesteko aukera ematen du:

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

Adibide honetan, zuk, klusterraren erabiltzaile gisa, hauxe adieraziko diezu administratzaileei: "Aizu, zoozaintzako zerbitzu bat daukat, eta egiten duzuna edozein dela ere, zerbitzu honen 2 erreplika gutxienez beti eskuragarri izatea gustatuko litzaidake".

Honi buruz gehiago irakur dezakezu Hemen.

8. Erabiltzaile edo ingurune anitz kluster komun batean

Kubernetes izen-espazioak (izen-espazioak) ez eman isolamendu sendorik.

Uste oker arrunta da produktua ez den karga bat izen-espazio batean eta produktuen karga beste batean zabaltzen baduzu, orduan ez dute elkarri inola ere eragingo... Hala ere, nolabaiteko isolamendu maila lor daiteke baliabideen eskaerak/mugak erabiliz, kuotak ezarriz eta lehentasunezko Klaseak ezarriz. Datu-planoan isolamendu "fisiko" batzuk afinitate, tolerantzia, kutsu (edo nodo-hautatzaileak) ematen ditu, baina bereizketa hori nahikoa da. zaila gauzatu.

Bi lan-karga motak kluster berean konbinatu behar dituztenek konplexutasunari aurre egin beharko diote. Halako beharrik ez badago, eta edukitzea ordaindu dezakezu kluster bat gehiago (esan, hodei publiko batean), orduan hobe da hori egitea. Horrek isolamendu maila askoz handiagoa lortuko du.

9. kanpokoTrafficPolicy: Klusterra

Askotan ikusten dugu klusterraren barruko trafiko guztia NodePort bezalako zerbitzu baten bidez datorrela, eta horretarako politika lehenetsia ezartzen da. externalTrafficPolicy: Cluster... Hori esan nahi du NodePorta klusterreko nodo guztietan irekita dago, eta horietako edozein erabil dezakezu nahi duzun zerbitzuarekin (pod multzoa) elkarreragiteko.

Aldi berean, goian aipatutako NodePort zerbitzuarekin lotutako benetako lekak normalean jakin batean bakarrik daude eskuragarri nodo horien azpimultzoa. Beste era batera esanda, beharrezko poda ez duen nodo batera konektatzen banaiz, trafikoa beste nodo batera birbidaliko du, hop bat gehituz eta latentzia handitzea (nodoak erabilgarritasun-zona/datu-zentro desberdinetan kokatzen badira, latentzia nahiko handia izan daiteke; gainera, irteerako trafiko kostuak handituko dira).

Bestalde, Kubernetes zerbitzu jakin batek politika ezarri badu externalTrafficPolicy: Local, orduan NodePort beharrezkoak diren podak benetan exekutatzen ari diren nodo horietan soilik irekitzen da. Egoera egiaztatzen duen kanpoko karga-orekatzailea erabiltzean (osasun egiaztapena) amaierako puntuak (nola egiten du AWS ELB), Bera trafikoa beharrezko nodoetara soilik bidaliko du, eta horrek eragin onuragarria izango du atzerapenetan, informatika-beharretan, irteera-fakturan (eta zentzu onak hala agintzen du).

Aukera handia dago dagoeneko antzeko zerbait erabiltzen ari zarela traefik edo nginx-ingress-controller NodePort amaierako puntu gisa (edo LoadBalancer, NodePort ere erabiltzen duena) HTTP sarrerako trafikoa bideratzeko, eta aukera hau ezartzeak eskaeren latentzia nabarmen murriztu dezake.

В argitalpen hau KanpokoTrafficPolicyri, bere abantailak eta desabantailei buruz gehiago jakin dezakezu.

10. Ez lotu klusterrei eta ez erabili kontrol-hegazkina

Lehen, zerbitzariei izen propioekin deitzea ohikoa zen: Anton, HAL9000 eta Colossus... Gaur ausaz sortutako identifikatzaileek ordezkatu dituzte. Hala ere, ohitura mantendu zen, eta orain izen propioak multzoetara doaz.

Istorio tipiko bat (benetako gertakarietan oinarrituta): kontzeptu-froga batekin hasi zen guztia, beraz, klusterrak izen harroa zuen. probak… Urteak pasa dira eta ORAINDIK erabiltzen da produkzioan, eta denek beldur dute ukitzeko.

Ez dago ezer dibertigarri klusterrak maskota bilakatzeak, beraz, praktikatzen ari zaren bitartean aldian-aldian kentzea gomendatzen dugu hondamendien berreskurapena (Honek lagunduko du kaosaren ingeniaritza - gutxi gorabehera. itzul.). Horrez gain, kontrol-geruzan lan egiteak ez luke kalterik izango (kontrol-hegazkina). Ukitzeko beldurra izatea ez da seinale ona. Etab. hilda? Mutilak, benetan arazoak dituzue!

Bestalde, ez zara manipulatzen utzi behar. Denborarekin kontrol-geruza motela izan daiteke. Seguruenik, objektu kopuru handi bat biratzerik gabe sortzen delako gertatzen da (egoera ohikoa da Helm ezarpen lehenetsiekin erabiltzean, horregatik ez da bere egoera konfigma/sekretuetan eguneratzen; ondorioz, milaka objektu pilatzen dira. kontrol-geruza) edo kube-api objektuen etengabeko edizioarekin (eskala automatikorako, CI/CDrako, monitorizaziorako, gertaeren erregistroetarako, kontrolagailuetarako, etab.).

Horrez gain, kudeatutako Kubernetes hornitzailearekin SLA/SLO akordioak egiaztatzea eta bermeei erreparatzea gomendatzen dugu. Saltzaileak bermatu dezake geruzaren erabilgarritasuna kontrolatzea (edo bere azpiosagaiak), baina ez hari bidaltzen dizkiozun eskaeren p99 atzerapena. Beste era batera esanda, sar zaitezke kubectl get nodes, eta 10 minuturen buruan erantzuna jasoko du, eta hori ez da zerbitzu-hitzarmenaren baldintzak urratuko.

11. Bonua: azken etiketa erabiliz

Baina hau jada klasiko bat da. Azkenaldian gutxiagotan egin dugu topo teknika honekin, askok, esperientzia mingotsetik ikasita, etiketa erabiltzeari utzi diotelako. :latest eta bertsioak ainguratzen hasi zen. Aupa!

CER irudi-etiketen aldaezintasuna mantentzen du; Ezaugarri nabarmen hau ezagutzea gomendatzen dizugu.

Laburpena

Ez espero dena egun batetik bestera funtzionatuko duenik: Kubernetes ez da panazea. Aplikazio txarra horrela jarraituko du Kubernetesen ere (eta ziurrenik okerrera egingo du). Arduragabekeriak gehiegizko konplexutasuna, kontrol-geruzaren lan geldoa eta estresagarria ekarriko du. Gainera, hondamendiak berreskuratzeko estrategiarik gabe geratzeko arriskua duzu. Ez espero Kubernetes-ek isolamendua eta erabilgarritasun handia eskaintzea kutxatik kanpo. Eman denbora pixka bat zure aplikazioa hodeiko jatorrizko bihurtzen.

Hainbat talderen arrakastarik gabeko esperientziak ezagutu ditzakezu bertan ipuin bilduma hau Henning Jacobsen eskutik.

Artikulu honetan ematen den akatsen zerrendara gehitu nahi dutenek gurekin harremanetan jar daitezke Twitterren (@MarekBartik, @MstrsObserver).

PS itzultzailetik

Irakurri ere gure blogean:

«Kubernetes klusterrak diseinatzea: zenbat izan beharko lirateke?»;
«Kubernetesen Segurtasunaren ABC: autentifikazioa, baimena, auditoria»;
«Autoeskala eta baliabideen kudeaketa Kubernetes-en"(iritzia eta bideo erreportajea);
«ConfigMaps Kubernetes-en: ezagutzea merezi duten ñabardurak'.

Iturria: www.habr.com

Kubernetes erabiltzean ohiko 10 akats