🥇10 gyakori hiba a Kubernetes | használatakor ProHoster

Jegyzet. ford.: A cikk szerzői egy kis cseh cég, pipetail mérnökei. Sikerült egy csodálatos listát összegyűjteniük a Kubernetes klaszterek működésével kapcsolatos [olykor banális, de mégis] nagyon sürgető problémákról és tévhitekről.

A Kubernetes használatának évei során számos fürttel dolgoztunk (felügyelt és nem felügyelt is – GCP-n, AWS-en és Azure-on). Idővel kezdtük észrevenni, hogy bizonyos hibák folyamatosan ismétlődnek. Ebben azonban nincs szégyen: a legtöbbet mi magunk csináltuk!

A cikk tartalmazza a leggyakoribb hibákat, és megemlíti a kijavításuk módját is.

1. Erőforrások: kérések és korlátok

Ez a tétel mindenképpen megérdemli a legnagyobb figyelmet és az első helyet a listán.

CPU kérés általában vagy egyáltalán nincs megadva, vagy nagyon alacsony az értéke (hogy minden csomópontra minél több hüvelyt helyezzen el). Így a csomópontok túlterhelődnek. Magas terhelés idején a csomópont feldolgozási teljesítménye teljes mértékben kihasználásra kerül, és egy adott munkaterhelés csak azt kapja meg, amit a „kért” CPU-szabályozás. Ez megnövekedett alkalmazási késleltetéshez, időtúllépésekhez és egyéb kellemetlen következményekhez vezet. (Erről bővebben a másik friss fordításunkban olvashat: "CPU-korlátok és agresszív szabályozás a Kubernetesben"- kb. fordítás.)

Legjobb erőfszítés (rendkívül nincs ajánlott):

resources: {}

Rendkívül alacsony CPU-kérés (rendkívül nincs ajánlott):

   resources:
      Requests:
        cpu: "1m"

Másrészt a CPU-korlát jelenléte az órajelciklusok ésszerűtlen kihagyásához vezethet, még akkor is, ha a csomóponti processzor nincs teljesen betöltve. Ez ismét megnövekedett késésekhez vezethet. A paraméter körül folytatódik a vita CPU CFS kvóta a Linux kernelben és a CPU-szabályozás a beállított korlátoktól függően, valamint a CFS kvóta letiltása... Jaj, a CPU limitek több problémát okozhatnak, mint amennyit megoldanak. Erről bővebb információ az alábbi linken található.

Túlzott választék (túlkötelezettség) memóriaproblémák nagyobb problémákhoz vezethetnek. A CPU-korlát elérése az óraciklusok kihagyásával jár, míg a memóriakorlát elérése a pod megölésével jár. Megfigyelted-e valaha OOMkill? Igen, pontosan erről beszélünk.

Szeretné minimalizálni ennek a valószínűségét? Ne allokálja túl a memóriát, és használja a Garantált QoS-t (Quality of Service) úgy, hogy a memóriakérést korlátra állítja (mint az alábbi példában). Erről bővebben itt olvashat Henning Jacobs előadásai (a Zalando vezető mérnöke).

Burstable (nagyobb az esély az OOM-kioltásra):

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

Garantált:

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

Mi segíthet az erőforrások létrehozásában?

-Val metrika-szerver láthatja az aktuális CPU-erőforrás- és memóriahasználatot a pod-ok (és a bennük lévő tárolók) szerint. Valószínűleg már használja. Csak futtassa a következő parancsokat:

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

Ezek azonban csak az aktuális használatot mutatják. Hozzávetőleges képet ad a nagyságrendről, de végül szüksége lesz rá a mutatók időbeli változásainak története (olyan kérdések megválaszolásához, mint: „Mekkora volt a CPU csúcsterhelése?”, „Mekkora volt a terhelés tegnap reggel?” stb.). Ehhez használhatja Prométheusz, DataDog és egyéb eszközök. Egyszerűen lekérik a metrics-szervertől a metrikákat és tárolják, a felhasználó pedig lekérdezheti és ennek megfelelően ábrázolhatja őket.

VerticalPodAutoscaler lehetővé teszi automatizálni ez a folyamat. Nyomon követi a CPU- és memóriahasználati előzményeket, és ezen információk alapján új kéréseket és korlátokat állít be.

A számítási teljesítmény hatékony felhasználása nem könnyű feladat. Mintha állandóan Tetrisszel játszana. Ha túl sokat fizet az alacsony átlagos fogyasztású számítási teljesítményért (mondjuk ~10%), javasoljuk, hogy tekintse meg az AWS Fargate vagy a Virtual Kubelet alapú termékeket. Szerver nélküli/használatonkénti fizetéses számlázási modellre épülnek, ami ilyen körülmények között olcsóbbnak bizonyulhat.

2. Életesség- és készenléti szondák

Alapértelmezés szerint az élénkség és a készenlét ellenőrzése nincs engedélyezve a Kubernetesben. És néha elfelejtik bekapcsolni...

De hogyan lehet másként elindítani a szolgáltatás újraindítását végzetes hiba esetén? És honnan tudja a terheléselosztó, hogy a pod készen áll a forgalom fogadására? Vagy nagyobb forgalmat tud kezelni?

Ezeket a teszteket gyakran összekeverik egymással:

Életképesség — „túlélhetőség” ellenőrzés, amely sikertelenség esetén újraindítja a pod-ot;
Készenlét — készenléti ellenőrzés, ha nem sikerül, leválasztja a pod-ot a Kubernetes szolgáltatásról (ez ellenőrizhető kubectl get endpoints), és a forgalom nem érkezik meg a következő ellenőrzés sikeres befejezéséig.

Mindkét ellenőrzés A POD TELJES ÉLETCIKLUSA ALATT ELŐADVA. Ez nagyon fontos.

Általános tévhit, hogy a készenléti szondákat csak indításkor futtatják, hogy a kiegyenlítő tudhassa, hogy a pod készen áll (Ready), és megkezdheti a forgalom feldolgozását. Ez azonban csak az egyik lehetőség a felhasználásukra.

Egy másik lehetőség annak megállapítására, hogy a pod forgalom túlzott és túlterheli azt (vagy a pod erőforrásigényes számításokat végez). Ebben az esetben a készenléti ellenőrzés segít csökkentse a hüvely terhelését és „hűtse le”.. A készenléti ellenőrzés sikeres elvégzése a jövőben lehetővé teszi ismét növelje a hüvely terhelését. Ebben az esetben (ha a készenléti teszt sikertelen) az életképességi teszt sikertelensége nagyon kontraproduktív lenne. Miért kell újraindítani egy egészséges és keményen dolgozó podat?

Ezért bizonyos esetekben jobb, ha egyáltalán nem ellenőrizzük, mint engedélyezni őket helytelenül konfigurált paraméterekkel. Mint fentebb említettük, ha életerő-ellenőrzés másolatok készenléti ellenőrzés, akkor nagy bajban vagy. Lehetséges lehetőség a konfigurálás csak készültségi vizsgaÉs veszélyes élet hagyd félre.

Mindkét típusú ellenőrzésnek nem szabad meghiúsulnia, ha a közös függőségek meghiúsulnak, különben ez az összes pod lépcsőzetes (lavinaszerű) meghibásodásához vezet. Más szavakkal, ne árts magadnak.

3. LoadBalancer minden HTTP-szolgáltatáshoz

Valószínűleg vannak HTTP-szolgáltatások a fürtben, amelyeket továbbítani szeretne a külvilág felé.

Ha megnyitja a szolgáltatást mint type: LoadBalancer, a vezérlője (szolgáltatótól függően) egy külső LoadBalancert biztosít és egyeztet (nem feltétlenül L7-en fut, hanem még L4-en is), és ez befolyásolhatja a költségeket (külső statikus IPv4-cím, számítási teljesítmény, másodpercenkénti számlázás). ) nagyszámú ilyen erőforrás létrehozásának szükségessége miatt.

Ebben az esetben sokkal logikusabb egy külső terheléselosztó használata, amely megnyitja a szolgáltatásokat type: NodePort. Vagy ami még jobb, bővítsd ki valami hasonlót nginx-ingress-controller (vagy traefik), aki lesz az egyetlen Csomópont port végpont, amely a külső terheléselosztóhoz van társítva, és a fürt forgalmát a használatával irányítja behatolás-Kubernetes források.

Más klaszteren belüli (mikro)szolgáltatások, amelyek kölcsönhatásba lépnek egymással, „kommunikálhatnak” olyan szolgáltatások használatával, mint pl ClusterIP és egy beépített szolgáltatáskeresési mechanizmus DNS-en keresztül. Csak ne használja nyilvános DNS/IP-jüket, mert ez befolyásolhatja a várakozási időt, és növelheti a felhőszolgáltatások költségeit.

4. Fürt automatikus skálázása jellemzőinek figyelembevétele nélkül

Amikor csomópontokat ad hozzá egy fürthöz, és eltávolítja őket onnan, ne hagyatkozzon néhány alapvető mérőszámra, például az adott csomópontok CPU-használatára. A podtervezésnél sok mindent figyelembe kell venni korlátozások, mint például a pod/csomópont affinitás, szennyeződések és tűréshatárok, erőforráskérések, QoS stb. Ha olyan külső autoscaler-t használ, amely nem veszi figyelembe ezeket az árnyalatokat, problémákhoz vezethet.

Képzelje el, hogy egy bizonyos pod ütemezve kell lennie, de az összes rendelkezésre álló CPU teljesítmény le van kérve/leszerelve, és a pod állapotba ragad Pending. A külső autoscaler az átlagos jelenlegi CPU-terhelést látja (nem a kért), és nem kezdeményezi a bővítést (kilépés) - nem ad hozzá újabb csomópontot. Ennek eredményeként ez a pod nem lesz ütemezve.

Ebben az esetben fordított skálázás (beosztás) — egy csomópont eltávolítása a fürtből mindig nehezebben kivitelezhető. Képzelje el, hogy állapottartó podja van (perzisztens tárhellyel csatlakoztatva). Állandó kötetek általában hozzátartoznak adott rendelkezésre állási zóna és nem replikálódnak a régióban. Így, ha egy külső autoscaler töröl egy csomópontot ezzel a podlal, akkor az ütemező nem tudja ütemezni ezt a podatot egy másik csomóponton, mivel ez csak abban a rendelkezésre állási zónában lehetséges, ahol az állandó tároló található. A pod állapotában elakad Pending.

Nagyon népszerű a Kubernetes közösségben cluster-autoscaler. Fürtön fut, támogatja a nagyobb felhőszolgáltatók API-jait, minden korlátozást figyelembe vesz, és a fenti esetekben skálázható. A beállított korlátok betartása mellett is beépülhet, így pénzt takaríthat meg (amit egyébként a kihasználatlan kapacitásra költenének).

5. Az IAM/RBAC képességek figyelmen kívül hagyása

Ügyeljen arra, hogy az IAM-felhasználókat állandó titkokkal használja gépek és alkalmazások. Szerezze meg az ideiglenes hozzáférést szerepkörök és szolgáltatásfiókok segítségével (szolgáltatási számlák).

Gyakran találkozunk azzal a ténnyel, hogy a hozzáférési kulcsok (és a titkok) az alkalmazás konfigurációjában vannak kódolva, valamint figyelmen kívül hagyjuk a titkok forgását annak ellenére, hogy hozzáférésünk van a Cloud IAM-hez. Adott esetben használjon IAM-szerepköröket és szolgáltatásfiókokat a felhasználók helyett.

Felejtse el a kube2iam-et, és lépjen közvetlenül a szolgáltatásfiókok IAM-szerepköreihez (lásd: azonos nevű jegyzet Š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

Egy megjegyzés. Nem olyan nehéz, igaz?

Ezenkívül ne biztosítson jogosultságokat a szolgáltatásfiókokhoz és a példányprofilokhoz admin и cluster-adminha nincs rá szükségük. Ezt egy kicsit nehezebb megvalósítani, különösen az RBAC K8-asoknál, de mindenképpen megéri az erőfeszítést.

6. Ne hagyatkozzon a hüvelyek automatikus anti-affinitására

Képzelje el, hogy valamelyik központi telepítés három másolata van egy csomóponton. A csomópont leesik, és vele együtt az összes replika. Kellemetlen helyzet, igaz? De miért volt az összes replika ugyanazon a csomóponton? Nem a Kubernetesnek kellene magas rendelkezésre állást (HA) biztosítania?!

Sajnos a Kubernetes ütemező saját kezdeményezésére nem felel meg a külön létezés szabályainak (affinitásellenes) hüvelyekhez. Ezeket egyértelműen fel kell tüntetni:

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

Ez minden. Most a pod-ok különböző csomópontokon lesznek ütemezve (ez a feltétel csak az ütemezés során van bejelölve, de működésük során nem - ezért requiredDuringSchedulingIgnoredDuringExecution).

Itt beszélünk podAntiAffinity különböző csomópontokon: topologyKey: "kubernetes.io/hostname", - és nem a különböző elérhetőségi zónákról. A teljes értékű HA megvalósításához mélyebbre kell ásni ezt a témát.

7. A PodDisruptionBudgets figyelmen kívül hagyása

Képzelje el, hogy termelési terhelése van egy Kubernetes-fürtön. Időnként a csomópontokat és magát a fürtöt frissíteni kell (vagy le kell szerelni). A PodDisruptionBudget (PDB) olyan, mint a fürt adminisztrátorai és a felhasználók közötti szolgáltatási garanciális megállapodás.

A PDB lehetővé teszi, hogy elkerülje a csomópontok hiánya által okozott szolgáltatáskimaradásokat:

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

Ebben a példában Ön, mint a fürt felhasználója, kijelenti az adminisztrátoroknak: „Hé, van egy állatkerti gondozó szolgáltatásom, és bármit is csinál, azt szeretném, ha ennek a szolgáltatásnak legalább 2 másolata mindig elérhető lenne.”

Erről bővebben olvashat itt.

8. Több felhasználó vagy környezet egy közös fürtben

Kubernetes névterek (névterek) ne biztosítson erős szigetelést.

Gyakori tévhit az, hogy ha egy nem prod terhelést telepít az egyik névtérbe, és egy prod terhelést egy másikba, akkor semmilyen módon nem befolyásolják egymást... Egy bizonyos szintű elszigeteltség azonban elérhető az erőforráskérésekkel/korlátozásokkal, a kvóták beállításával és a priorityClasses beállításával. Az adatsíkon bizonyos „fizikai” elkülönítést affinitások, tűréshatárok, szennyeződések (vagy csomópontválasztók) biztosítanak, de az ilyen elkülönítés meglehetősen bonyolult végrehajtani.

Azoknak, akiknek mindkét típusú munkaterhelést ugyanabban a fürtben kell kombinálniuk, meg kell küzdeniük a bonyolultsággal. Ha nincs ilyen igény, és megengedheti magának, hogy legyen még egy klaszter (mondjuk nyilvános felhőben), akkor jobb ezt megtenni. Ezzel sokkal magasabb szigetelési szintet érünk el.

9. külső forgalompolitika: Klaszter

Nagyon gyakran megfigyeljük, hogy a fürtön belüli összes forgalom egy olyan szolgáltatáson keresztül érkezik, mint a NodePort, amelyhez az alapértelmezett házirend be van állítva. externalTrafficPolicy: Cluster... Ez azt jelenti Csomópont port nyitva van a fürt minden csomópontján, és bármelyiket használhatja a kívánt szolgáltatással (a podkészlettel) való interakcióhoz.

Ugyanakkor a fent említett NodePort szolgáltatáshoz társított valódi podok általában csak egy bizonyos helyen érhetők el ezen csomópontok részhalmaza. Más szóval, ha egy olyan csomóponthoz csatlakozom, amely nem rendelkezik a szükséges pod-val, akkor a forgalmat egy másik csomóponthoz továbbítja, hozzátéve egy ugrást és a késleltetés növelése (ha a csomópontok különböző rendelkezésre állási zónákban/adatközpontokban helyezkednek el, a késleltetés meglehetősen magas lehet; emellett a kilépési forgalom költségei is növekednek).

Másrészt, ha egy bizonyos Kubernetes-szolgáltatás rendelkezik házirend-beállítással externalTrafficPolicy: Local, akkor a NodePort csak azokon a csomópontokon nyílik meg, ahol a szükséges podok ténylegesen futnak. Ha külső terheléselosztót használ, amely ellenőrzi az állapotot (egészségügyi ellenőrzés) végpontok (hogyan működik AWS ELB), Ő csak a szükséges csomópontokhoz küldi a forgalmat, ami jótékony hatással lesz a késésekre, a számításigényekre, a kilépési számlákra (és a józan ész is ezt diktálja).

Nagy az esélye, hogy már használ valami hasonlót traefik vagy nginx-ingress-controller NodePort végpontként (vagy LoadBalancerként, amely szintén NodePortot használ) a HTTP bejövő forgalom irányítására, és ennek a beállításnak a megadásával jelentősen csökkenthető az ilyen kérések késleltetése.

В ez a kiadvány Többet megtudhat a külső forgalmi politikáról, annak előnyeiről és hátrányairól.

10. Ne kötődj klaszterekhez, és ne élj vissza a vezérlősíkkal

Korábban szokás volt a szervereket tulajdonnéven hívni: Anton, HAL9000 és Colossus... Ma ezeket véletlenszerűen generált azonosítók váltották fel. A szokás azonban megmaradt, és ma már a tulajdonnevek klaszterekbe kerülnek.

Egy tipikus történet (valós eseményeken alapuló): minden a koncepció bizonyításával kezdődött, így a klaszternek büszke neve volt tesztelés… Évek teltek el, és MINDIG a gyártásban használják, és mindenki fél hozzányúlni.

Nincs abban semmi mulatságos, ha a fürtök háziállattá válnak, ezért javasoljuk, hogy gyakorlás közben rendszeresen távolítsa el őket. katasztrófa utáni helyreállítás (ez segít káoszmérnökség - kb. fordítás.). Ezenkívül nem ártana a vezérlőrétegen dolgozni (vezérlő sík). Az, hogy félsz megérinteni, nem jó jel. stb halott? Srácok, tényleg bajban vagytok!

Másrészt nem szabad elragadtatni a manipulálástól. Idővel a vezérlőréteg lelassulhat. Ennek valószínűleg az az oka, hogy nagyszámú objektum jön létre elforgatásuk nélkül (gyakori helyzet a Helm alapértelmezett beállításokkal történő használatakor, ezért nem frissül az állapota a konfigurációs térképekben/titkokban – ennek eredményeként több ezer objektum halmozódik fel a vezérlőréteg) vagy a kube-api objektumok folyamatos szerkesztésével (automatikus méretezéshez, CI/CD-hez, figyeléshez, eseménynaplókhoz, vezérlőkhöz stb.).

Ezenkívül javasoljuk, hogy ellenőrizze az SLA/SLO szerződéseket a felügyelt Kubernetes szolgáltatóval, és ügyeljen a garanciákra. Az eladó garantálni tudja szabályozza a réteg elérhetőségét (vagy annak alkomponensei), de nem a neki küldött kérések p99 késleltetése. Más szóval, beléphet kubectl get nodes, és csak 10 perc múlva kap választ, és ez nem jelenti a szolgáltatási szerződés feltételeinek megsértését.

11. Bónusz: a legújabb címke használata

De ez már klasszikus. Az utóbbi időben ritkábban találkozhatunk ezzel a technikával, mivel sokan keserű tapasztalatból tanulva felhagytak a címke használatával :latest és elkezdte rögzíteni a verziókat. Hurrá!

ECR fenntartja a képcímkék megváltoztathatatlanságát; Javasoljuk, hogy ismerkedjen meg ezzel a figyelemre méltó funkcióval.

Összegzés

Ne várja el, hogy minden egyik napról a másikra működjön: a Kubernetes nem csodaszer. Rossz alkalmazás így marad még Kubernetesben is (és valószínűleg rosszabb lesz). A gondatlanság a vezérlőréteg túlzott bonyolultságához, lassú és stresszes munkájához vezet. Ezenkívül fennáll a veszélye, hogy katasztrófa-helyreállítási stratégia nélkül marad. Ne várja el a Kubernetestől, hogy már a dobozból is izolációt és magas rendelkezésre állást biztosítson. Szánjon egy kis időt arra, hogy alkalmazását valóban felhőalapúvá tegye.

Különféle csapatok sikertelen tapasztalataival ismerkedhetsz meg ezt a történetgyűjteményt írta Henning Jacobs.

Azok, akik szeretnének kiegészíteni a cikkben található hibalistát, felvehetik velünk a kapcsolatot a Twitteren (@MarekBartik, @MstrsObserver).

PS a fordítótól

Olvassa el blogunkon is:

«Kubernetes klaszterek tervezése: hány legyen?";
«A biztonság ABC-je a Kubernetesben: hitelesítés, engedélyezés, auditálás";
«Automatikus skálázás és erőforrás-kezelés a Kubernetesben"(áttekintés és videóriport);
«ConfigMaps a Kubernetesben: árnyalatok, amelyeket érdemes tudni".

Forrás: will.com

10 gyakori hiba a Kubernetes használatakor