Tandaan. transl.: Ang mga may-akda ng artikulong ito ay mga inhinyero mula sa isang maliit na kumpanya ng Czech, pipetail. Nagawa nilang magsama-sama ng isang napakagandang listahan ng [minsan ay karaniwan, ngunit pa rin] napaka-pinipilit na mga problema at maling kuru-kuro na may kaugnayan sa pagpapatakbo ng mga kumpol ng Kubernetes.
Sa paglipas ng mga taon ng paggamit ng Kubernetes, nagtrabaho kami sa isang malaking bilang ng mga cluster (parehong pinamamahalaan at hindi pinamamahalaan - sa GCP, AWS at Azure). Sa paglipas ng panahon, nagsimula kaming mapansin na ang ilang mga pagkakamali ay patuloy na nauulit. Gayunpaman, walang kahihiyan dito: ginawa namin ang karamihan sa kanila mismo!
Ang artikulo ay naglalaman ng mga pinakakaraniwang error at binanggit din kung paano itama ang mga ito.
1. Mga mapagkukunan: mga kahilingan at limitasyon
Ang item na ito ay tiyak na nararapat sa pinakamalapit na atensyon at unang lugar sa listahan.
Karaniwang humihiling ng CPU alinman sa hindi tinukoy sa lahat o may napakababang halaga (upang maglagay ng maraming pod sa bawat node hangga't maaari). Kaya, ang mga node ay nagiging overloaded. Sa mga oras ng mataas na pagkarga, ang kapangyarihan ng pagproseso ng node ay ganap na ginagamit at ang isang partikular na workload ay tumatanggap lamang ng kung ano ang "hinihiling" nito Pag-throttling ng CPU. Ito ay humahantong sa pagtaas ng latency ng aplikasyon, pag-timeout, at iba pang hindi kasiya-siyang kahihinatnan. (Magbasa pa tungkol dito sa aming iba pang kamakailang pagsasalin: β"- humigit-kumulang. transl.)
BestEffort (labis hindi inirerekomenda):
resources: {}Napakababa ng kahilingan ng CPU (sobrang hindi inirerekomenda):
resources:
Requests:
cpu: "1m"Sa kabilang banda, ang pagkakaroon ng limitasyon ng CPU ay maaaring humantong sa hindi makatwirang paglaktaw ng mga cycle ng orasan ng mga pod, kahit na ang node processor ay hindi ganap na na-load. Muli, maaari itong humantong sa mas mataas na pagkaantala. Nagpapatuloy ang kontrobersya sa paligid ng parameter Quota ng CPU CFS sa Linux kernel at CPU throttling depende sa mga itinakdang limitasyon, pati na rin ang hindi pagpapagana sa CFS quota... Naku, ang mga limitasyon ng CPU ay maaaring magdulot ng mas maraming problema kaysa sa kanilang malulutas. Higit pang impormasyon tungkol dito ay matatagpuan sa link sa ibaba.
Sobrang pagpili (sobrang pagtitiwala) Ang mga problema sa memorya ay maaaring humantong sa mas malalaking problema. Ang pag-abot sa limitasyon ng CPU ay nangangailangan ng paglaktaw sa mga cycle ng orasan, habang ang pag-abot sa limitasyon ng memorya ay nangangailangan ng pagpatay sa pod. Naobserbahan mo na ba OOMkill? Oo, iyon mismo ang pinag-uusapan natin.
Gusto mo bang bawasan ang posibilidad na mangyari ito? Huwag mag-over-allocate ng memory at gumamit ng Guaranteed QoS (Quality of Service) sa pamamagitan ng pagtatakda ng memory request sa limitasyon (tulad ng sa halimbawa sa ibaba). Magbasa pa tungkol dito sa (Lead Engineer sa Zalando).
Burstable (mas mataas na pagkakataong ma-OOMkill):
resources:
requests:
memory: "128Mi"
cpu: "500m"
limits:
memory: "256Mi"
cpu: 2Ginagarantiya:
resources:
requests:
memory: "128Mi"
cpu: 2
limits:
memory: "128Mi"
cpu: 2Ano ang maaaring makatulong kapag nagse-set up ng mga mapagkukunan?
May metrics-server maaari mong makita ang kasalukuyang pagkonsumo ng mapagkukunan ng CPU at paggamit ng memorya ng mga pod (at mga lalagyan sa loob ng mga ito). Malamang, ginagamit mo na ito. Patakbuhin lamang ang sumusunod na mga utos:
kubectl top pods
kubectl top pods --containers
kubectl top nodesGayunpaman, nagpapakita lamang sila ng kasalukuyang paggamit. Maaari itong magbigay sa iyo ng isang magaspang na ideya ng pagkakasunud-sunod ng magnitude, ngunit sa huli kakailanganin mo kasaysayan ng mga pagbabago sa mga sukatan sa paglipas ng panahon (upang sagutin ang mga tanong tulad ng: βAno ang pinakamataas na load ng CPU?β, βAno ang load kahapon ng umaga?β, atbp.). Para dito maaari mong gamitin Promiteyus, DataDog at iba pang mga kasangkapan. Kumuha lang sila ng mga sukatan mula sa metrics-server at iimbak ang mga ito, at maaaring i-query ng user ang mga ito at i-plot ang mga ito nang naaayon.
ay nagbibigay-daan sa awtomatiko itong proseso. Sinusubaybayan nito ang kasaysayan ng paggamit ng CPU at memorya at nagse-set up ng mga bagong kahilingan at limitasyon batay sa impormasyong ito.
Ang paggamit ng computing power nang mahusay ay hindi isang madaling gawain. Ito ay tulad ng paglalaro ng Tetris sa lahat ng oras. Kung nagbabayad ka ng masyadong malaki para sa compute power na may mababang average na pagkonsumo (sabihin na ~10%), inirerekomenda namin ang pagtingin sa mga produkto batay sa AWS Fargate o Virtual Kubelet. Binuo ang mga ito sa isang modelo ng pagsingil na walang server/pay-per-usage, na maaaring lumabas na mas mura sa mga ganitong kondisyon.
2. Liveness at kahandaan probes
Bilang default, hindi pinagana sa Kubernetes ang liveness at readiness checks. At minsan nakakalimutan nilang i-on ang mga ito...
Ngunit paano mo pa masisimulan ang pag-restart ng serbisyo kung sakaling magkaroon ng nakamamatay na error? At paano malalaman ng load balancer na ang isang pod ay handa nang tumanggap ng trapiko? O kaya nitong humawak ng mas maraming trapiko?
Ang mga pagsubok na ito ay madalas na nalilito sa isa't isa:
- Buhay na buhay β βsurvivabilityβ check, na magre-restart ng pod kung nabigo ito;
- Kahandaan β pagsusuri sa kahandaan, kung nabigo ito, dinidiskonekta nito ang pod mula sa serbisyo ng Kubernetes (maaari itong suriin gamit ang
kubectl get endpoints) at hindi dumarating ang trapiko dito hanggang sa matagumpay na nakumpleto ang susunod na pagsusuri.
Pareho sa mga tseke na ito GINAWA SA BUONG LIFE CYCLE NG POD. Napakahalaga nito.
Ang isang karaniwang maling kuru-kuro ay ang mga probe ng kahandaan ay tumatakbo lamang sa pagsisimula upang malaman ng tagabalanse na handa na ang pod (Ready) at maaaring magsimulang magproseso ng trapiko. Gayunpaman, ito ay isa lamang sa mga opsyon para sa kanilang paggamit.
Ang isa pa ay ang posibilidad na malaman na ang trapiko sa pod ay sobra-sobra at overloads ito (o ang pod ay nagsasagawa ng mga kalkulasyon na masinsinang mapagkukunan). Sa kasong ito, nakakatulong ang pagsusuri sa kahandaan bawasan ang pagkarga sa pod at "palamig" ito. Ang matagumpay na pagkumpleto ng isang pagsusuri sa kahandaan sa hinaharap ay nagbibigay-daan dagdagan muli ang pagkarga sa pod. Sa kasong ito (kung mabigo ang pagsubok sa kahandaan), ang pagkabigo ng pagsubok sa liveness ay magiging napaka-counterproductive. Bakit i-restart ang isang pod na malusog at nagtatrabaho nang husto?
Samakatuwid, sa ilang mga kaso, walang mga pagsusuri ang mas mahusay kaysa sa paganahin ang mga ito gamit ang mga parameter na hindi wastong na-configure. Gaya ng nakasaad sa itaas, kung liveness check mga kopya ng ready check, pagkatapos ikaw ay nasa malaking problema. Ang posibleng opsyon ay i-configure At iwanan.
Ang parehong uri ng mga pagsusuri ay hindi dapat mabigo kapag nabigo ang mga karaniwang dependency, kung hindi, hahantong ito sa isang cascading (tulad ng avalanche) na pagkabigo ng lahat ng pod. Sa ibang salita, .
3. LoadBalancer para sa bawat serbisyo ng HTTP
Malamang, mayroon kang mga serbisyo ng HTTP sa iyong cluster na gusto mong ipasa sa labas ng mundo.
Kung bubuksan mo ang serbisyo bilang type: LoadBalancer, ang controller nito (depende sa service provider) ay magbibigay at makikipag-ayos sa isang panlabas na LoadBalancer (hindi kinakailangang tumatakbo sa L7, ngunit sa halip kahit sa L4), at ito ay maaaring makaapekto sa gastos (panlabas na static IPv4 address, computing power, per-second billing ) dahil sa pangangailangan na lumikha ng isang malaking bilang ng mga naturang mapagkukunan.
Sa kasong ito, mas makatuwirang gumamit ng isang panlabas na balanse ng pag-load, na nagbubukas ng mga serbisyo bilang type: NodePort. O mas mabuti pa, palawakin ang isang bagay tulad ng nginx-ingress-controller (O traefik), na mag-iisa NodePort endpoint na nauugnay sa external load balancer at iruruta ang trapiko sa cluster gamit pagpasok-Mga mapagkukunan ng Kubernetes.
Ang iba pang mga intra-cluster (micro) na serbisyo na nakikipag-ugnayan sa isa't isa ay maaaring "makipag-ugnayan" gamit ang mga serbisyo tulad ng ClusterIP at isang built-in na mekanismo ng pagtuklas ng serbisyo sa pamamagitan ng DNS. Huwag lang gamitin ang kanilang pampublikong DNS/IP, dahil maaari itong makaapekto sa latency at mapataas ang halaga ng mga serbisyo sa cloud.
4. Autoscaling ang isang cluster nang hindi isinasaalang-alang ang mga tampok nito
Kapag nagdadagdag ng mga node at nag-aalis ng mga ito mula sa isang cluster, hindi ka dapat umasa sa ilang pangunahing sukatan tulad ng paggamit ng CPU sa mga node na iyon. Ang pagpaplano ng pod ay dapat isaalang-alang ang marami mga paghihigpit, gaya ng pod/node affinity, mga bahid at pagpapaubaya, mga kahilingan sa mapagkukunan, QoS, atbp. Ang paggamit ng isang panlabas na autoscaler na hindi isinasaalang-alang ang mga nuances na ito ay maaaring humantong sa mga problema.
Isipin na ang isang partikular na pod ay dapat na naka-iskedyul, ngunit ang lahat ng magagamit na kapangyarihan ng CPU ay hinihiling/na-disassemble at ang pod ay natigil sa isang estado Pending. Nakikita ng panlabas na autoscaler ang average na kasalukuyang pag-load ng CPU (hindi ang hiniling) at hindi sinisimulan ang pagpapalawak (scale-out) - hindi nagdaragdag ng isa pang node. Bilang resulta, hindi maiiskedyul ang pod na ito.
Sa kasong ito, reverse scaling (scale-in) β ang pag-alis ng node mula sa isang cluster ay palaging mas mahirap ipatupad. Isipin na mayroon kang stateful pod (na may tuluy-tuloy na storage na konektado). Mga patuloy na volume karaniwang nabibilang sa tiyak na availability zone at hindi ginagaya sa rehiyon. Kaya, kung ang isang panlabas na autoscaler ay nagde-delete ng node na may ganitong pod, hindi magagawa ng scheduler na iiskedyul ang pod na ito sa isa pang node, dahil magagawa lang ito sa availability zone kung saan matatagpuan ang patuloy na storage. Ang pod ay maiipit sa estado Pending.
Napakasikat sa komunidad ng Kubernetes . Gumagana ito sa isang kumpol, sumusuporta sa mga API mula sa mga pangunahing tagapagbigay ng ulap, isinasaalang-alang ang lahat ng mga paghihigpit at maaaring masukat sa mga kaso sa itaas. Nagagawa rin nitong mag-scale-in habang pinapanatili ang lahat ng itinakdang limitasyon, sa gayon ay nakakatipid ng pera (na kung hindi man ay gagastusin sa hindi nagamit na kapasidad).
5. Pagpapabaya sa mga kakayahan ng IAM/RBAC
Mag-ingat sa paggamit ng mga user ng IAM na may patuloy na mga lihim para sa mga makina at aplikasyon. Ayusin ang pansamantalang pag-access gamit ang mga tungkulin at account ng serbisyo (mga account ng serbisyo).
Madalas naming maranasan ang katotohanan na ang mga access key (at mga lihim) ay naka-hardcode sa configuration ng application, pati na rin ang pagpapabaya sa pag-ikot ng mga lihim sa kabila ng pagkakaroon ng access sa Cloud IAM. Gumamit ng mga tungkulin at account ng serbisyo ng IAM sa halip na mga user kung naaangkop.
Kalimutan ang tungkol sa kube2iam at dumiretso sa mga tungkulin ng IAM para sa mga account ng serbisyo (tulad ng inilarawan sa Ε 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: defaultIsang anotasyon. Hindi ganoon kahirap, tama?
Gayundin, huwag magbigay ng mga pribilehiyo sa mga account ng serbisyo at mga profile ng halimbawa admin ΠΈ cluster-adminkung hindi nila ito kailangan. Mas mahirap itong ipatupad, lalo na sa mga RBAC K8, ngunit talagang sulit ang pagsisikap.
6. Huwag umasa sa awtomatikong anti-affinity para sa mga pod
Isipin na mayroon kang tatlong replika ng ilang deployment sa isang node. Bumagsak ang node, at kasama nito ang lahat ng mga replika. Hindi kanais-nais na sitwasyon, tama ba? Ngunit bakit ang lahat ng mga replika ay nasa parehong node? Hindi ba dapat magbigay ang Kubernetes ng high availability (HA)?!
Sa kasamaang palad, ang scheduler ng Kubernetes, sa sarili nitong inisyatiba, ay hindi sumusunod sa mga patakaran ng hiwalay na pag-iral (anti-affinity) para sa mga pods. Dapat na tahasang ipahayag ang mga ito:
// ΠΎΠΏΡΡΠ΅Π½ΠΎ Π΄Π»Ρ ΠΊΡΠ°ΡΠΊΠΎΡΡΠΈ
labels:
app: zk
// ΠΎΠΏΡΡΠ΅Π½ΠΎ Π΄Π»Ρ ΠΊΡΠ°ΡΠΊΠΎΡΡΠΈ
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: "app"
operator: In
values:
- zk
topologyKey: "kubernetes.io/hostname"
Iyon lang. Ngayon, ang mga pod ay maiiskedyul sa iba't ibang mga node (ang kundisyong ito ay sinusuri lamang sa panahon ng pag-iiskedyul, ngunit hindi sa panahon ng kanilang operasyon - kaya requiredDuringSchedulingIgnoredDuringExecution).
Dito natin pinag-uusapan podAntiAffinity sa iba't ibang mga node: topologyKey: "kubernetes.io/hostname", - at hindi tungkol sa iba't ibang mga availability zone. Upang ipatupad ang isang ganap na HA, kakailanganin mong maghukay ng mas malalim sa paksang ito.
7. Hindi pinapansin ang PodDisruptionBudgets
Isipin na mayroon kang production load sa isang Kubernetes cluster. Pana-panahon, ang mga node at ang cluster mismo ay kailangang i-update (o i-decommission). Ang PodDisruptionBudget (PDB) ay parang isang kasunduan sa garantiya ng serbisyo sa pagitan ng mga administrator ng cluster at mga user.
Binibigyang-daan ka ng PDB na maiwasan ang mga pagkaantala sa serbisyo na dulot ng kakulangan ng mga node:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: zk-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: zookeeperSa halimbawang ito, ikaw, bilang isang user ng cluster, ay nagsasabi sa mga admin: βUy, mayroon akong serbisyo ng zookeeper, at anuman ang gawin mo, gusto kong maging available sa lahat ng oras ang kahit 2 replika ng serbisyong ito. .β
Maaari mong basahin ang higit pa tungkol dito .
8. Maramihang user o environment sa isang karaniwang cluster
Mga namespace ng Kubernetes (mga namespace) huwag magbigay ng malakas na pagkakabukod.
Ang isang karaniwang maling kuru-kuro ay kung mag-deploy ka ng isang non-prod load sa isang namespace at isang prod load sa isa pa, kung gayon sila hindi makakaimpluwensya sa isa't isa sa anumang paraan... Gayunpaman, maaaring makamit ang isang tiyak na antas ng paghihiwalay gamit ang mga kahilingan/limitasyon ng mapagkukunan, pagtatakda ng mga quota, at pagtatakda ng mga priorityClasses. Ang ilang "pisikal" na paghihiwalay sa data plane ay ibinibigay ng mga affinity, pagpapaubaya, mga bahid (o nodeselectors), ngunit ang naturang paghihiwalay ay medyo mahirap ipatupad.
Ang mga kailangang pagsamahin ang parehong uri ng mga workload sa parehong kumpol ay kailangang harapin ang pagiging kumplikado. Kung walang ganoong pangangailangan, at kayang-kaya mong magkaroon ng isa isa pang kumpol (sabihin, sa isang pampublikong ulap), kung gayon mas mahusay na gawin ito. Makakamit nito ang mas mataas na antas ng pagkakabukod.
9. externalTrafficPolicy: Cluster
Kadalasan ay napapansin namin na ang lahat ng trapiko sa loob ng cluster ay nagmumula sa isang serbisyo tulad ng NodePort, kung saan nakatakda ang default na patakaran externalTrafficPolicy: Cluster... Ibig sabihin nito ay NodePort ay bukas sa bawat node sa cluster, at maaari mong gamitin ang alinman sa mga ito upang makipag-ugnayan sa nais na serbisyo (set ng mga pod).
Kasabay nito, ang mga tunay na pod na nauugnay sa nabanggit na serbisyo ng NodePort ay karaniwang magagamit lamang sa isang tiyak subset ng mga node na ito. Sa madaling salita, kung kumonekta ako sa isang node na walang kinakailangang pod, ipapasa nito ang trapiko sa isa pang node, pagdaragdag ng hop at pagtaas ng latency (kung ang mga node ay matatagpuan sa iba't ibang mga availability zone/data center, ang latency ay maaaring masyadong mataas; bilang karagdagan, ang mga gastos sa paglabas ng trapiko ay tataas).
Sa kabilang banda, kung ang isang partikular na serbisyo ng Kubernetes ay may nakatakdang patakaran externalTrafficPolicy: Local, pagkatapos ay magbubukas lamang ang NodePort sa mga node kung saan aktwal na tumatakbo ang mga kinakailangang pod. Kapag gumagamit ng external load balancer na sumusuri sa estado (healthchecking) mga endpoint (paano ito ginagawa AWS ELB), Siya magpapadala lamang ng trapiko sa mga kinakailangang node, na magkakaroon ng kapaki-pakinabang na epekto sa mga pagkaantala, mga pangangailangan sa pag-compute, mga singil sa paglabas (at ang sentido komun ang nagdidikta ng pareho).
Malaki ang posibilidad na gumagamit ka na ng katulad traefik o nginx-ingress-controller bilang isang NodePort endpoint (o LoadBalancer, na gumagamit din ng NodePort) upang iruta ang trapiko sa pagpasok ng HTTP, at ang pagtatakda ng opsyong ito ay maaaring makabuluhang bawasan ang latency para sa mga naturang kahilingan.
Π Maaari kang matuto nang higit pa tungkol sa externalTrafficPolicy, ang mga pakinabang at disadvantage nito.
10. Huwag matali sa mga kumpol at huwag abusuhin ang control plane
Noong nakaraan, kaugalian na tumawag sa mga server sa pamamagitan ng mga wastong pangalan: , HAL9000 at Colossus... Ngayon ay pinalitan na sila ng mga random na nabuong identifier. Gayunpaman, nanatili ang ugali, at ngayon ang mga tamang pangalan ay napupunta sa mga kumpol.
Isang tipikal na kuwento (batay sa mga totoong pangyayari): nagsimula ang lahat sa isang patunay ng konsepto, kaya ang cluster ay nagkaroon ng isang mapagmataas na pangalan pagsubok⦠Lumipas ang mga taon at ito ay ginagamit pa rin sa produksyon, at lahat ay natatakot na hawakan ito.
Walang nakakatuwang tungkol sa mga kumpol na nagiging mga alagang hayop, kaya inirerekomenda naming alisin ang mga ito sa pana-panahon habang nagsasanay pagbawi ng kalamidad (makakatulong ito β tinatayang. transl.). Bilang karagdagan, hindi masasaktan na magtrabaho sa control layer (kontrol na eroplano). Ang takot na hawakan siya ay hindi magandang senyales. atbp patay na? Guys, ang gulo niyo talaga!
Sa kabilang banda, hindi ka dapat madala sa pagmamanipula nito. Sa oras ang control layer ay maaaring maging mabagal. Malamang, ito ay dahil sa isang malaking bilang ng mga bagay na nalilikha nang walang kanilang pag-ikot (isang karaniwang sitwasyon kapag gumagamit ng Helm na may mga default na setting, kaya naman ang estado nito sa mga configmaps/lihim ay hindi na-update - bilang isang resulta, libu-libong mga bagay ang naipon sa ang control layer) o sa patuloy na pag-edit ng mga bagay na kube-api (para sa awtomatikong pag-scale, para sa CI/CD, para sa pagsubaybay, mga log ng kaganapan, mga controller, atbp.).
Bilang karagdagan, inirerekomenda naming suriin ang mga kasunduan sa SLA/SLO sa pinamamahalaang provider ng Kubernetes at bigyang pansin ang mga garantiya. Makakasiguro ang vendor pagkakaroon ng control layer (o mga subcomponents nito), ngunit hindi ang p99 na pagkaantala ng mga kahilingang ipinadala mo dito. Sa madaling salita, maaari kang pumasok kubectl get nodes, at makatanggap lamang ng sagot pagkatapos ng 10 minuto, at hindi ito magiging paglabag sa mga tuntunin ng kasunduan sa serbisyo.
11. Bonus: gamit ang pinakabagong tag
Ngunit ito ay isa nang klasiko. Kamakailan lamang ay hindi gaanong madalas nating makita ang diskarteng ito, dahil marami, na natuto mula sa mapait na karanasan, ay tumigil sa paggamit ng tag :latest at nagsimulang mag-pin ng mga bersyon. Hooray!
ECR ; Inirerekomenda namin na maging pamilyar ka sa kahanga-hangang tampok na ito.
Buod
Huwag asahan na ang lahat ay gagana nang magdamag: Ang Kubernetes ay hindi isang panlunas sa lahat. Masamang app (at malamang na lumala pa ito). Ang kawalang-ingat ay hahantong sa labis na pagiging kumplikado, mabagal at mabigat na gawain ng control layer. Bukod pa rito, nanganganib kang maiwan nang walang diskarte sa pagbawi sa sakuna. Huwag asahan na magbibigay ang Kubernetes ng paghihiwalay at mataas na kakayahang magamit sa labas ng kahon. Gumugol ng ilang oras na gawing tunay na cloud native ang iyong application.
Maaari kang maging pamilyar sa mga hindi matagumpay na karanasan ng iba't ibang mga koponan sa ni Henning Jacobs.
Ang mga nagnanais na magdagdag sa listahan ng mga error na ibinigay sa artikulong ito ay maaaring makipag-ugnayan sa amin sa Twitter (, ).
PS mula sa tagasalin
Basahin din sa aming blog:
- Β«";
- Β«";
- Β«"(pagsusuri at ulat ng video);
- Β«'.
Pinagmulan: www.habr.com