Athugið. þýð.: Höfundar þessarar greinar eru verkfræðingar frá litlu tékknesku fyrirtæki, pipetail. Þeim tókst að setja saman frábæran lista yfir [stundum banal, en samt] mjög brýn vandamál og ranghugmyndir sem tengjast rekstri Kubernetes klasa.
Í gegnum árin sem við höfum notað Kubernetes höfum við unnið með fjölda klasa (bæði stýrðum og óstýrðum - á GCP, AWS og Azure). Með tímanum fórum við að taka eftir því að sum mistök voru stöðugt endurtekin. Hins vegar er engin skömm í þessu: við höfum gert þær flestar sjálfar!
Greinin inniheldur algengustu villurnar og einnig er minnst á hvernig eigi að leiðrétta þær.
1. Ресурсы: запросы и лимиты
Þetta atriði á svo sannarlega skilið nánustu athygli og fyrsta sæti á listanum.
CPU request обычно annað hvort alls ekki tilgreint eða hefur mjög lágt gildi (til að setja eins marga belg á hvern hnút og mögulegt er). Þannig verða hnútarnir ofhlaðnir. Á tímum mikils álags er vinnslumáttur hnútsins fullnýttur og tiltekið vinnuálag fær aðeins það sem það "beðið um" af троттлинга CPU. Это приводит к повышению задержек в приложении, таймаутам и другим неприятным последствиям. (Lestu meira um þetta í annarri nýlegri þýðingu okkar: ""- ca. þýðing.)
Besta tilraun (ákaflega ekki mælt með):
resources: {}Mjög lág CPU beiðni (mjög ekki mælt með):
resources:
Requests:
cpu: "1m"С другой стороны, наличие лимита CPU может приводить к необоснованному пропуску тактов pod’ами, даже если процессор узла загружен не полностью. Опять же, это может привести к увеличению задержек. Продолжаются споры вокруг параметра CPU CFS quota í Linux kjarnanum og CPU inngjöf eftir settum mörkum, auk þess að slökkva á CFS kvótanum... Því miður, CPU takmörk geta valdið fleiri vandamálum en þau geta leyst. Nánari upplýsingar um þetta má finna á hlekknum hér að neðan.
Óhóflegt úrval (overcommiting) minnisvandamál geta leitt til stærri vandamála. Að ná hámarki CPU felur í sér að sleppa klukkulotum, en að ná minnismörkum felur í sér að drepa fræbelginn. Hefur þú einhvern tíma fylgst með OOMkill? Já, það er einmitt það sem við erum að tala um.
Хотите свести к минимуму вероятность этого события? Не распределяйте чрезмерные объемы памяти и используйте Guaranteed QoS (Quality of Service), устанавливая memory request равным лимиту (как в примере ниже). Подробнее об этом читайте в (Aðalverkfræðingur hjá Zalando).
Sprengjanlegt (meiri líkur á að verða OOM-drepa):
resources:
requests:
memory: "128Mi"
cpu: "500m"
limits:
memory: "256Mi"
cpu: 2Guaranteed:
resources:
requests:
memory: "128Mi"
cpu: 2
limits:
memory: "128Mi"
cpu: 2Hvað mun hugsanlega hjálpa við að setja upp úrræði?
Með metrics-þjónn þú getur séð núverandi auðlindanotkun CPU og minnisnotkun eftir belgjum (og ílátum inni í þeim). Líklegast ertu nú þegar að nota það. Keyrðu bara eftirfarandi skipanir:
kubectl top pods
kubectl top pods --containers
kubectl top nodesHins vegar sýna þeir aðeins núverandi notkun. Það getur gefið þér grófa hugmynd um stærðargráðuna, en á endanum þarftu история изменения метрик во времени (til að svara spurningum eins og: „Hver var hámarkshleðsla örgjörva?“, „Hver var álagið í gærmorgun?“ osfrv.). Fyrir þetta geturðu notað Prometheus, DataDog og önnur verkfæri. Þeir fá einfaldlega mælikvarða frá metric-server og geyma þær og notandinn getur spurt þær og teiknað þær í samræmi við það.
gerir gera sjálfvirkan þessu ferli. Það fylgist með sögu örgjörva og minnisnotkunar og setur upp nýjar beiðnir og takmarkanir byggðar á þessum upplýsingum.
Að nota tölvuafl á skilvirkan hátt er ekki auðvelt verkefni. Það er eins og að spila Tetris allan tímann. Ef þú ert að borga of mikið fyrir tölvuafl með lágri meðalnotkun (segjum ~10%), mælum við með að skoða vörur byggðar á AWS Fargate eða Virtual Kubelet. Þeir eru byggðir á netþjónslausu/borga-fyrir-notkun innheimtulíkani, sem gæti reynst ódýrara við slíkar aðstæður.
2. Lífs- og viðbúnaðarrannsóknir
Sjálfgefið er að athuganir á virkni og viðbúnaði eru ekki virkjar í Kubernetes. Og stundum gleyma þeir að kveikja á þeim...
Но как еще можно инициировать перезапуск сервиса в случае неустранимой ошибки? И как балансировщик нагрузки узнает, что некий pod готов принимать трафик? Или что он способен обработать больше трафика?
Þessum prófum er oft ruglað saman:
- Lifandi — „lifunarhæfni“ athugun, sem endurræsir belginn ef hún mistekst;
- Reiðubúin — viðbúnaðarathugun, ef það mistekst, aftengir það podinn frá Kubernetes þjónustunni (þetta er hægt að athuga með því að nota
kubectl get endpoints) и трафик на него не поступает до тех пор, пока очередная проверка не завершится успешно.
Báðar þessar athuganir FRAMKVÆMD Á ALLA LÍFSFERÐ LÍFSINS. Það er mjög mikilvægt.
Algengur misskilningur er að viðbúnaðarkannanir séu aðeins keyrðir við ræsingu svo að jafnvægismaður geti vitað að belgurinn sé tilbúinn (Ready) og getur hafið vinnslu umferðar. Hins vegar er þetta aðeins einn af valkostunum fyrir notkun þeirra.
Annar er möguleikinn á að komast að því að umferðin á belgnum er óhófleg og ofhleður það (eða belgurinn framkvæmir auðlindafreka útreikninga). Í þessu tilviki hjálpar viðbúnaðarathugunin minnka álagið á belgnum og „kæla“ það. Árangursrík lokið viðbúnaðarathugun í framtíðinni leyfir auka álagið á belginn aftur. Í þessu tilviki (ef viðbúnaðarprófið mistekst) myndi bilun á lífleikaprófinu vera mjög óheppilegt. Зачем перезапускать pod, который здоров и трудится изо всех сил?
Þess vegna, í sumum tilfellum, er ekkert athugað betra en að virkja þær með rangt stilltum breytum. Eins og fram kemur hér að ofan, ef lífleikaathugun afritar viðbúnaðarathugun, þá ertu í miklum vandræðum. Mögulegur valkostur er að stilla Og оставить в стороне.
Оба типа проверок не должны завершаться неудачей при падении общих зависимостей, иначе это приведет к каскадному (лавинообразному) отказу всех pod’ов. Другими словами, .
3. LoadBalancer fyrir hverja HTTP þjónustu
Líklega ertu með HTTP þjónustu í klasanum þínum sem þú vilt senda til umheimsins.
Ef þú opnar þjónustuna sem type: LoadBalancer, stjórnandi þess (fer eftir þjónustuveitunni) mun útvega og semja um utanaðkomandi LoadBalancer (ekki endilega keyrandi á L7, heldur jafnvel á L4), og það getur haft áhrif á kostnaðinn (ytri kyrrstöðu IPv4 vistfang, tölvuorka, innheimta á sekúndu ) vegna nauðsyn þess að búa til mikinn fjölda slíkra auðlinda.
Í þessu tilfelli er miklu rökréttara að nota einn ytri álagsjafnara, opnunarþjónustu sem type: NodePort. Eða enn betra, stækka eitthvað eins og nginx-ingress-controller (Eða traefik), sem verður sá eini NodePort endapunktur sem tengist ytri álagsjafnara og mun beina umferð í þyrpingunni með því að nota innrás-Kubernetes auðlindir.
Önnur innan klasa (ör) þjónusta sem hefur samskipti sín á milli geta „samskipti“ með því að nota þjónustu eins og ClusterIP og innbyggt þjónustuuppgötvunarkerfi í gegnum DNS. Bara ekki nota opinbera DNS/IP þeirra, þar sem þetta getur haft áhrif á leynd og aukið kostnað við skýjaþjónustu.
4. Sjálfstýring á klasa án þess að taka tillit til eiginleika hans
Þegar þú bætir hnútum við og fjarlægir þá úr þyrpingu ættirðu ekki að treysta á nokkrar grunntölur eins og örgjörvanotkun á þessum hnútum. Belgskipulag verður að taka tillit til margra takmarkanir, таких как affinity pod’ов/узлов, taints и tolerations, запросы ресурсов, QoS и т.д. Использование внешнего autoscaler’а, не учитывающего эти нюансы, может привести к проблемам.
Ímyndaðu þér að ákveðinn belg ætti að vera tímasettur, en allt tiltækt örgjörvaafl er beðið um/tekin í sundur og belgurinn festist í ástandi Pending. Ytri autoscaler sér meðaltal núverandi örgjörvaálags (ekki það sem óskað er eftir) og byrjar ekki stækkun (scale-out) - bætir ekki við öðrum hnút. Þar af leiðandi verður þetta hlað ekki tímasett.
Í þessu tilviki, öfug mælikvarða (skalað inn) — að fjarlægja hnút úr klasa er alltaf erfiðara í framkvæmd. Ímyndaðu þér að þú sért með staðgóðan belg (með viðvarandi geymslu tengdri). Viðvarandi bindi tilheyra venjulega sérstakt framboðssvæði og eru ekki endurteknar á svæðinu. Þannig, ef utanaðkomandi sjálfvirkur mælikvarði eyðir hnút með þessum belg, þá mun tímaáætlunarmaðurinn ekki geta tímasett þennan belg á annan hnút, þar sem þetta er aðeins hægt að gera á tiltæku svæði þar sem viðvarandi geymslan er staðsett. Belgurinn verður fastur í ríkinu Pending.
Mjög vinsælt í Kubernetes samfélaginu . Það keyrir á klasa, styður API frá helstu skýjaveitum, tekur tillit til allra takmarkana og getur skalað í ofangreindum tilvikum. Það er líka hægt að stækka inn á meðan öllum settum takmörkunum er viðhaldið og sparar þannig peninga (sem annars væri eytt í ónotaða afkastagetu).
5. Vanræksla IAM/RBAC getu
Varist að nota IAM notendur með viðvarandi leyndarmál fyrir vélar og forrit. Организуйте временный доступ, используя роли и учетные записи служб (þjónustureikningar).
Við lendum oft í þeirri staðreynd að aðgangslyklar (og leyndarmál) eru harðkóðaðir í stillingar forritsins, auk þess að vanrækja snúning leyndarmála þrátt fyrir að hafa aðgang að Cloud IAM. Notaðu IAM hlutverk og þjónustureikninga í stað notenda þar sem við á.
Забудьте о kube2iam и переходите сразу к ролям IAM для service accounts (как это описывается в Š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: defaultEin athugasemd. Ekki svo erfitt, ekki satt?
Einnig má ekki veita þjónustureikningum og tilvikasniðum réttindi admin и cluster-adminef þeir þurfa þess ekki. Þetta er aðeins erfiðara í framkvæmd, sérstaklega í RBAC K8s, en örugglega þess virði.
6. Ekki treysta á sjálfvirka and-sækni fyrir belg
Ímyndaðu þér að þú sért með þrjár eftirlíkingar af einhverri dreifingu á hnút. Hnúturinn fellur, og með honum allar eftirmyndirnar. Óþægilegt ástand, ekki satt? En hvers vegna voru allar eftirmyndirnar á sama hnút? Á Kubernetes ekki að bjóða upp á mikið framboð (HA)?!
Því miður, Kubernetes tímaáætlun, að eigin frumkvæði, er ekki í samræmi við reglur um aðskilda tilveru (andstæðingur) для pod’ов. Их необходимо явно прописать:
// опущено для краткости
labels:
app: zk
// опущено для краткости
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: "app"
operator: In
values:
- zk
topologyKey: "kubernetes.io/hostname"
Вот и все. Теперь pod’ы будут планироваться на различные узлы (это условие проверяется только во время планирования, но не их работы — отсюда и requiredDuringSchedulingIgnoredDuringExecution).
Hér erum við að tala um podAntiAffinity á mismunandi hnútum: topologyKey: "kubernetes.io/hostname", - og ekki um mismunandi framboðssvæði. Til að innleiða fullgildan HA verður þú að kafa dýpra í þetta efni.
7. Hunsa PodDisruptionBudgets
Ímyndaðu þér að þú hafir framleiðsluálag á Kubernetes klasa. Reglulega þarf að uppfæra hnúta og klasann sjálfan (eða taka úr notkun). PodDisruptionBudget (PDB) er eitthvað eins og þjónustuábyrgðarsamningur milli klasastjórnenda og notenda.
PDB gerir þér kleift að forðast þjónustutruflanir af völdum skorts á hnútum:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: zk-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: zookeeperÍ þessu dæmi segir þú, sem notandi þyrpingarinnar, við stjórnendur: „Hæ, ég er með dýraverndarþjónustu, og sama hvað þú gerir, ég myndi vilja hafa að minnsta kosti 2 eftirlíkingar af þessari þjónustu alltaf tiltækar.
Þú getur lesið meira um þetta .
8. Margir notendur eða umhverfi í sameiginlegum klasa
Kubernetes nafnarými (nafnarými) veita ekki sterka einangrun.
Algengur misskilningur er að ef þú setur upp hleðslu sem ekki er stofnað í eitt nafnrými og vöruhleðslu í annað, þá mun ekki hafa áhrif á hvort annað á nokkurn hátt... Hins vegar er hægt að ná ákveðinni einangrun með því að nota auðlindabeiðnir/takmarkanir, kvótasetningu og forgangsflokka. Einhver „líkamleg“ einangrun í gagnaplaninu er veitt af skyldleika, þolmörkum, blettum (eða hnútavali), en slíkur aðskilnaður er alveg erfitt framkvæma.
Þeir sem þurfa að sameina báðar tegundir vinnuálags í sama klasa þurfa að takast á við flókið. Ef það er engin slík þörf, og þú hefur efni á að hafa einn enn einn þyrping (segjum, í opinberu skýi), þá er betra að gera það. Þetta mun ná miklu meiri einangrun.
9. externalTrafficPolicy: Klasi
Mjög oft sjáum við að öll umferð innan þyrpingarinnar kemur í gegnum þjónustu eins og NodePort, sem sjálfgefna stefnan er sett fyrir. externalTrafficPolicy: Cluster... Það þýðir að NodePort er opinn á hverjum hnút í þyrpingunni og þú getur notað hvaða þeirra sem er til að hafa samskipti við viðkomandi þjónustu (sett af belgjum).
Á sama tíma eru raunverulegir belg sem tengjast ofangreindri NodePort þjónustu venjulega aðeins fáanlegir á ákveðnum подмножестве этих узлов. Другими словами, если я подключусь к узлу, на котором нет нужного pod’а, он будет перенаправлять трафик на другой узел, að bæta við humli og vaxandi leynd (ef hnútar eru staðsettir á mismunandi tiltækum svæðum/gagnaverum getur leynd verið nokkuð mikil; auk þess mun útgöngukostnaður aukast).
Á hinn bóginn, ef ákveðin Kubernetes þjónusta hefur sett stefnu externalTrafficPolicy: Local, то NodePort открывается только на тех узлах, где фактически запущены нужные pod’ы. При использовании внешнего балансировщика нагрузок, проверяющего состояния (heilsuskoðun) endapunktar (hvernig virkar það AWS ELB), он mun senda umferð aðeins til nauðsynlegra hnúta, sem mun hafa jákvæð áhrif á tafir, tölvuþarfir, útgöngureikninga (og skynsemi segir til um það sama).
Það eru miklar líkur á að þú sért nú þegar að nota eitthvað eins og traefik eða nginx-ingress-controller sem NodePort endapunkt (eða LoadBalancer, sem notar einnig NodePort) til að beina HTTP innkomu umferð, og með því að setja þennan valkost getur það dregið verulega úr leynd fyrir slíkar beiðnir.
В Þú getur lært meira um externalTrafficPolicy, kosti hennar og galla.
10. Ekki binda þig við klasa og ekki misnota stjórnplanið
Áður fyrr var venja að kalla netþjóna réttum nöfnum: , HAL9000 og Colossus... Í dag hefur þeim verið skipt út fyrir handahófskennt auðkenni. Venjan hélst þó og nú fara sérnöfn í klasa.
Типичная история (основанная на реальных событиях): все начиналось с доказательства концепции, поэтому кластер носил гордое имя próf... Ár eru liðin og það er ENN notað í framleiðslu, og allir eru hræddir við að snerta það.
Það er ekkert skemmtilegt við að klasar breytast í gæludýr, svo við mælum með að fjarlægja þá reglulega á meðan þú æfir hamfarabata (þetta mun hjálpa - ca. þýðing.). Að auki myndi það ekki skaða að vinna á stjórnunarlaginu (stjórnflugvél). Að vera hræddur við að snerta hann er ekki gott merki. O.s.frv. dauður? Strákar, þið eruð virkilega í vandræðum!
Á hinn bóginn ættirðu ekki að láta þér líða vel með að hagræða því. Með tíma eftirlitslagið getur orðið hægt. Líklegast er þetta vegna þess að mikill fjöldi hluta er búinn til án þess að þeir snúist (algengt ástand þegar Helm er notað með sjálfgefnum stillingum, sem er ástæðan fyrir því að ástand hans í configmaps/leyndarmálum er ekki uppfært - þar af leiðandi safnast þúsundir hluta upp í stýrilagið) eða með stöðugri klippingu á kube-api hlutum (fyrir sjálfvirka mælikvarða, fyrir CI/CD, fyrir eftirlit, atburðaskrár, stýringar osfrv.).
Að auki mælum við með að athuga SLA/SLO samninga við stýrða Kubernetes þjónustuveituna og fylgjast með ábyrgðunum. Seljandi getur ábyrgst stjórna lag framboð (eða undirþættir þess), en ekki p99 seinkun beiðna sem þú sendir til þess. Með öðrum orðum, þú getur slegið inn kubectl get nodes, og fá svar aðeins eftir 10 mínútur, og það mun ekki vera brot á skilmálum þjónustusamnings.
11. Bónus: að nota nýjasta merkið
А вот это уже классика. В последнее время мы встречаемся с подобной техникой не так часто, поскольку многие, наученные горьким опытом, перестали использовать тег :latest og byrjaði að festa útgáfur. Húrra!
ECR ; Við mælum með að þú kynnir þér þennan merkilega eiginleika.
Yfirlit
Не ждите, что все заработает по мановению руки: Kubernetes — это не панацея. Плохое приложение (og það mun líklega versna). Kæruleysi mun leiða til óhóflegs flækjustigs, hægfara og streituvaldandi vinnu stjórnlagsins. Að auki er hætta á að þú verðir skilinn eftir án hamfarabatastefnu. Ekki búast við að Kubernetes bjóði upp á einangrun og mikið framboð úr kassanum. Eyddu smá tíma í að gera forritið þitt raunverulega skýjamætt.
Þú getur kynnt þér misheppnaða reynslu ýmissa liða í от Henning Jacobs.
Желающие дополнить список ошибок, приведенный в этой статье, могут связаться с нами в Twitter (, ).
PS frá þýðanda
Lestu líka á blogginu okkar:
- «»;
- «»;
- «"(rýni og myndbandsskýrsla);
- «'.
Heimild: www.habr.com