Catetan. narjamahkeun.: Nu nulis artikel ieu insinyur ti pausahaan Czech leutik, pipetail. Aranjeunna junun nunda babarengan daptar éndah [kadang banal, tapi tetep] masalah pisan mencét sarta misconceptions patali operasi klaster Kubernetes.
Salila sababaraha taun nganggo Kubernetes, kami parantos damel sareng sajumlah ageung klaster (duanana junun sareng henteu diurus - dina GCP, AWS sareng Azure). Kana waktu, urang mimiti perhatikeun yén sababaraha kasalahan anu terus-terusan terus-terusan. Nanging, teu aya éra dina hal ieu: kami parantos ngalaksanakeun kalolobaanana nyalira!
Tulisan éta ngandung kasalahan anu paling umum sareng ogé nyebatkeun kumaha ngabenerkeunana.
1. Sumberdaya: requests sarta wates
Item ieu pasti pantes perhatian anu pangdeukeutna sareng tempat munggaran dina daptar.
pamundut CPU biasana boh teu dieusian pisan atawa boga nilai pisan low (pikeun nempatkeun saloba pods dina unggal titik-gancang). Ku kituna, titik jadi overloaded. Dina waktos beban tinggi, kakuatan pamrosésan titik dimangpaatkeun sapinuhna sareng beban kerja khusus nampi ngan ukur anu "dipénta" ku CPU throttling. Ieu ngakibatkeun ngaronjat latency aplikasi, timeouts, sarta konsékuansi pikaresepeun lianna. (Baca langkung seueur ngeunaan ieu dina tarjamahan panganyarna kami: ""- kira-kira. tarjamah.)
BestEffort (pisan teu dianjurkeun):
resources: {}Paménta CPU pisan low (kacida teu dianjurkeun):
resources:
Requests:
cpu: "1m"Di sisi séjén, ayana wates CPU bisa ngakibatkeun skipping wajar tina siklus jam ku pods, sanajan processor node teu pinuh dimuat. Deui, ieu bisa ngakibatkeun ngaronjat reureuh. Kontrovérsi terus sabudeureun parameter kuota CPU CFS dina kernel Linux Ubuntu jeung CPU throttling gumantung kana wates set, kitu ogé nganonaktipkeun kuota CFS ... Alas, wates CPU bisa ngabalukarkeun leuwih masalah ti aranjeunna tiasa ngajawab. Inpo nu langkung lengkep ihwal ieu tiasa dipendakan dina tautan di handap ieu.
Pilihan kaleuleuwihan (overcommitting) masalah memori bisa ngakibatkeun masalah nu leuwih gede. Ngahontal wates CPU merlukeun skipping siklus jam, bari ngahontal wates memori entails maéhan pod. Dupi anjeun kantos niténan OOMkill? Sumuhun, éta kahayang urang ngobrol ngeunaan.
Naha anjeun hoyong ngaleutikan kamungkinan kajadian ieu? Ulah over-allocate mémori jeung make Guaranteed QoS (Quality of Service) ku netepkeun pamundut memori ka wates nu (sakumaha dina conto di handap). Baca leuwih seueur tentang ieu dina (Lead Insinyur di Zalando).
Burstable (kasempetan leuwih luhur meunang OOMkilled):
resources:
requests:
memory: "128Mi"
cpu: "500m"
limits:
memory: "256Mi"
cpu: 2dijamin:
resources:
requests:
memory: "128Mi"
cpu: 2
limits:
memory: "128Mi"
cpu: 2Naon anu berpotensi ngabantosan nalika nyetél sumberdaya?
jeung métrik-server anjeun tiasa ningali konsumsi sumberdaya CPU ayeuna sareng pamakean mémori ku pods (sareng peti di jerona). Paling dipikaresep, anjeun geus maké éta. Ngan ngajalankeun paréntah di handap ieu:
kubectl top pods
kubectl top pods --containers
kubectl top nodesNanging, aranjeunna ngan ukur nunjukkeun panggunaan ayeuna. Éta tiasa masihan anjeun gambaran kasar ngeunaan tatanan gedéna, tapi pamustunganana anjeun peryogi sajarah parobahan dina métrik kana waktu (Pikeun ngajawab patarosan sapertos: "Naon beban CPU puncak?", "Naon beban kamari isuk?", jsb). Pikeun ieu anjeun tiasa nganggo Prometheus, DataDog jeung parabot lianna. Éta ngan saukur meunang metrics ti metrics-server tur nyimpen aranjeunna, sarta pamaké bisa query aranjeunna sarta plot aranjeunna sasuai.
Hal ieu ngamungkinkeun ngajadikeun otomatis prosés ieu. Éta ngalacak sajarah panggunaan CPU sareng mémori sareng nyetél pamundut sareng wates énggal dumasar kana inpormasi ieu.
Ngagunakeun daya komputasi sacara éfisién sanés tugas anu gampang. Éta sapertos maén Tetris sepanjang waktos. Upami anjeun mayar teuing kanggo daya itung kalayan konsumsi rata-rata rendah (sebutkeun ~10%), kami nyarankeun ningali produk dumasar kana AWS Fargate atanapi Virtual Kubelet. Éta diwangun dina modél tagihan tanpa server / bayar-per-pamakéan, anu tiasa janten langkung mirah dina kaayaan sapertos kitu.
2. Liveness jeung kasiapan usik
Sacara standar, cek liveness sareng kasiapan teu diaktipkeun dina Kubernetes. Sareng sakapeung aranjeunna hilap ngahurungkeunana...
Tapi kumaha deui anjeun tiasa ngamimitian balikan deui jasa upami aya kasalahan anu fatal? Sareng kumaha panyimbang beban terang yén pod siap nampi lalu lintas? Atawa nu eta tiasa ngadamel langkung lalulintas?
Tés ieu sering bingung saling:
- Hirup - cek "survivability", nu restarts pod lamun gagal;
- Kesiapan - pariksa kesiapan, upami gagal, éta pegatkeun sambungan pod tina layanan Kubernetes (ieu tiasa dipariksa nganggo
kubectl get endpoints) sareng lalulintas henteu dugi ka éta dugi ka pamariksaan salajengna parantos suksés.
Duanana cék ieu Dilaksanakeun salila sakabéh siklus kahirupan POD. Hal ieu kacida penting.
A misconception umum nyaéta yén panyilidikan kesiapan ngan dijalankeun dina ngamimitian jadi balancer bisa nyaho yén pod geus siap (Ready) sareng tiasa ngamimitian ngolah lalu lintas. Sanajan kitu, ieu ngan salah sahiji pilihan pikeun pamakéan maranéhanana.
Sejen nyaeta kamungkinan manggihan yén lalulintas dina pod kaleuleuwihan na overloads eta (atawa pod ngalakukeun itungan sumberdaya-intensif). Dina hal ieu, pariksa kesiapan mantuan ngurangan beban dina pod jeung "tiis" eta. Parantosan suksés cek kesiapan di hareup ngamungkinkeun ningkatkeun beban dina pod deui. Dina hal ieu (upami tés kesiapan gagal), gagalna tés liveness bakal pisan kontraproduktif. Naha ngamimitian deui pod anu séhat sareng kerja keras?
Ku alatan éta, dina sababaraha kasus, teu aya cék anu langkung saé tibatan ngaktipkeun aranjeunna kalayan parameter anu teu leres dikonpigurasi. Salaku nyatakeun di luhur, lamun cék liveness salinan cék kesiapan, mangka anjeun dina masalah badag. Pilihan anu mungkin nyaéta ngonpigurasikeun jeung ninggalkeun kumisan.
Kadua jinis pamariksaan henteu kedah gagal nalika katergantungan umum gagal, upami henteu, ieu bakal ngakibatkeun kagagalan cascading (kawas longsoran) sadaya pods. Istilah sanésna, .
3. LoadBalancer pikeun tiap jasa HTTP
Paling dipikaresep, anjeun boga jasa HTTP dina klaster anjeun nu Anjeun hoyong teruskeun ka dunya luar.
Lamun anjeun muka layanan salaku type: LoadBalancer, controller na (gumantung kana panyadia ladenan) bakal nyadiakeun jeung negotiate hiji LoadBalancer éksternal (teu merta ngajalankeun on L7, tapi malah dina L4), sarta ieu bisa mangaruhan biaya (alamat IPv4 statik éksternal, kakuatan komputasi, tagihan per detik. ) alatan kudu nyieun sajumlah badag sumberdaya misalna.
Dina hal ieu, éta leuwih logis ngagunakeun hiji balancer beban éksternal, jasa muka salaku type: NodePort. Atawa hadé acan, dilegakeun hal kawas nginx-ingress-controller (atawa traefik), anu bakal jadi hiji-hijina NodePort titik tungtung pakait sareng beban balancer éksternal sarta bakal ruteu lalulintas di kluster ngagunakeun ingress-sumberdaya Kubernetes.
Ladenan intra-cluster (mikro) anu saling berinteraksi tiasa "komunikasi" nganggo jasa sapertos KlusterIP sarta mékanisme kapanggihna jasa diwangun-di via DNS. Entong nganggo DNS/IP umumna, sabab ieu tiasa mangaruhan latency sareng ningkatkeun biaya jasa awan.
4. Autoscaling klaster tanpa nyokot kana akun fitur na
Nalika nambihan titik sareng ngahapus tina kluster, anjeun henteu kedah ngandelkeun sababaraha métrik dasar sapertos pamakean CPU dina titik éta. Perencanaan pod kedah tumut kana seueur larangan, sapertos afinitas pod/node, taint sareng tolerations, pamundut sumberdaya, QoS, jsb. Ngagunakeun autoscaler éksternal anu henteu merhatikeun nuansa ieu tiasa nyababkeun masalah.
Ngabayangkeun nu hiji pod tangtu kudu dijadwalkeun, tapi kabeh kakuatan CPU sadia dipénta / disassembled na pod nyangkut dina kaayaan Pending. Autoscaler éksternal ningali rata-rata beban CPU ayeuna (sanés anu dipénta) sareng henteu ngamimitian ékspansi (skala kaluar) - teu nambahan titik sejen. Hasilna, pod ieu moal dijadwalkeun.
Dina hal ieu, balikkeun skala (skala-in) - nyoplokkeun titik tina klaster sok leuwih hese pikeun nerapkeun. Bayangkeun yén anjeun gaduh pod stateful (kalayan panyimpenan pengkuh disambungkeun). Jilid pengkuh biasana milik zone kasadiaan husus sarta teu replicated di wewengkon. Ku kituna, lamun hiji autoscaler éksternal ngahapus hiji titik kalawan pod ieu, scheduler moal bisa ngajadwalkeun pod ieu dina titik sejen, sabab ieu ngan bisa dipigawé di zone kasadiaan dimana gudang pengkuh ayana. Pod bakal macét dina kaayaan Pending.
Populér pisan di komunitas Kubernetes . Éta dijalankeun dina klaster, ngadukung API ti panyadia awan utama, tumut kana akun sadaya larangan sareng tiasa skala dina kasus di luhur. Éta ogé bisa skala-di bari ngajaga sagala wates set, kukituna nyimpen duit (anu disebutkeun bakal spent dina kapasitas henteu kapake).
5. Neglecting IAM / kamampuhan RBAC
Awas ngagunakeun pamaké IAM kalawan Rahasia pengkuh pikeun mesin sarta aplikasi. Atur aksés samentara nganggo peran sareng akun jasa (rekening jasa).
Urang mindeng sapatemon kanyataan yén konci aksés (jeung Rahasia) hardcoded dina konfigurasi aplikasi, kitu ogé neglecting rotasi Rahasia sanajan ngabogaan aksés ka Cloud IAM. Anggo peran IAM sareng akun jasa tibatan pangguna upami cocog.
Poho ngeunaan kube2iam sareng langsung ka peran IAM pikeun akun jasa (sapertos dijelaskeun dina Š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: defaultHiji anotasi. Henteu sesah, leres?
Ogé, ulah masihan hak istimewa pikeun akun jasa sareng profil conto admin и cluster-adminupami aranjeunna henteu peryogi. Ieu saeutik leuwih hese pikeun nerapkeun, utamana dina RBAC K8s, tapi pasti patut usaha.
6. Ulah ngandelkeun otomatis anti pangirut pikeun pods
Bayangkeun yén anjeun gaduh tilu réplika sababaraha panyebaran dina titik. Node ragrag, sarta babarengan jeung éta sakabéh réplika. kaayaan teu pikaresepeun, katuhu? Tapi naha éta sadayana réplika dina titik anu sami? Naha Kubernetes henteu kedah nyayogikeun kasadiaan anu luhur (HA)?!
Hanjakalna, penjadwal Kubernetes, dina prakarsa sorangan, teu sasuai jeung aturan ayana misah (anti afinitas) pikeun pods. Aranjeunna kedah dinyatakeun sacara eksplisit:
// опущено для краткости
labels:
app: zk
// опущено для краткости
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: "app"
operator: In
values:
- zk
topologyKey: "kubernetes.io/hostname"
Éta hungkul. Ayeuna pods bakal dijadwalkeun dina titik béda (kaayaan ieu dipariksa ngan salila scheduling, tapi teu salila operasi maranéhanana - ku kituna requiredDuringSchedulingIgnoredDuringExecution).
Di dieu urang ngobrol ngeunaan podAntiAffinity dina titik béda: topologyKey: "kubernetes.io/hostname", - teu ngeunaan zona kasadiaan béda. Pikeun nerapkeun HA full-fledged, anjeun bakal kudu ngagali deeper kana topik ieu.
7. Ignoring PodDisruptionBudgets
Bayangkeun yén anjeun gaduh beban produksi dina klaster Kubernetes. Périodik, titik sareng klasterna sorangan kedah diropéa (atanapi dinonaktipkeun). PodDisruptionBudget (PDB) mangrupikeun perjanjian jaminan jasa antara pangurus klaster sareng pangguna.
PDB ngamungkinkeun anjeun pikeun ngahindarkeun gangguan jasa anu disababkeun ku kurangna titik:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: zk-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: zookeeperDina conto ieu, anjeun, salaku pamaké klaster, nyarios ka admins: "Héy, kuring boga layanan zookeeper, tur euweuh urusan naon anjeun ngalakukeun, Abdi hoyong sahenteuna 2 réplika tina jasa ieu salawasna sadia."
Anjeun tiasa maca langkung seueur ngeunaan ieu .
8. Sababaraha pamaké atawa lingkungan dina klaster umum
spasi ngaran Kubernetes (spasi ngaran) teu nyadiakeun insulasi kuat.
A misconception umum nyaéta yén lamun nyebarkeun beban non-prod kana hiji namespace sarta beban prod kana sejen, lajeng aranjeunna moal mangaruhan silih sagala cara... Sanajan kitu, tingkat nu tangtu isolasi bisa dihontal maké requests sumberdaya / watesan, netepkeun kuota, sarta netepkeun priorityClasses. Sababaraha isolasi "fisik" dina pesawat data disadiakeun ku affinities, tolerations, taints (atawa nodeselectors), tapi separation misalna cukup hese ngalaksanakeun.
Anu kedah ngahijikeun dua jinis beban kerja dina klaster anu sami kedah ngatasi pajeulitna. Upami teu aya kabutuhan sapertos kitu, sareng anjeun tiasa mampuh gaduh hiji hiji deui klaster (sebutkeun, dina awan umum), mangka éta hadé pikeun ngalakukeunana. Ieu bakal ngahontal tingkat insulasi anu langkung luhur.
9. externalTrafficPolicy: klaster
Sering pisan urang ningali yén sadaya lalu lintas di jero kluster asalna tina jasa sapertos NodePort, dimana kawijakan standar diatur externalTrafficPolicy: Cluster... Éta hartosna éta NodePort dibuka dina unggal titik dina kluster, tur anjeun tiasa nganggo salah sahiji aranjeunna pikeun berinteraksi sareng layanan nu dipikahoyong (set pods).
Dina waktos anu sami, pods nyata anu aya hubunganana sareng jasa NodePort anu disebatkeun di luhur biasana ngan ukur aya dina sababaraha tempat subset tina titik ieu. Dina basa sejen, lamun kuring nyambung ka titik nu teu boga pod diperlukeun, éta bakal neruskeun lalulintas keur titik sejen, nambahkeun hop a sarta ngaronjatkeun latency (lamun titik lokasina di zona kasadiaan béda / puseur data, latency bisa jadi rada luhur; Sajaba ti éta, waragad lalulintas kaluar bakal naek).
Di sisi séjén, lamun jasa Kubernetes tangtu boga set kawijakan externalTrafficPolicy: Local, teras NodePort dibuka ngan dina titik-titik dimana polong anu diperyogikeun leres-leres jalan. Nalika nganggo pangimbang beban éksternal anu mariksa kaayaan (pariksa kaséhatan) titik tungtung (kumaha eta ngalakukeun AWS ELB), Anjeunna bakal ngirim lalulintas ngan ka titik perlu, nu bakal boga pangaruh mangpaat dina reureuh, kabutuhan komputasi, tagihan egress (jeung akal sehat dictates sarua).
Aya kamungkinan luhur yén anjeun parantos nganggo anu sapertos kitu traefik atawa nginx-ingress-controller salaku titik tungtung NodePort (atanapi LoadBalancer, anu ogé ngagunakeun NodePort) pikeun jalur lalu lintas ingress HTTP, sareng netepkeun pilihan ieu tiasa sacara signifikan ngirangan latency pikeun pamundut sapertos kitu.
В Anjeun tiasa diajar langkung seueur ngeunaan externalTrafficPolicy, kaunggulan sareng kalemahanana.
10. Ulah meunang dihijikeun ka klaster sarta ulah nyiksa pesawat kontrol
Saméméhna, geus biasa nelepon server ku ngaran ditangtoskeun: , HAL9000 na Colossus ... Dinten aranjeunna geus diganti ku identifiers dihasilkeun acak. Nanging, kabiasaan éta tetep, sareng ayeuna nami anu leres angkat ka klaster.
Hiji carita has (dumasar kana kajadian nyata): eta sadayana dimimitian ku bukti konsép, jadi klaster miboga ngaran reueus uji… Taun-taun parantos kaliwat sareng masih dianggo dina produksi, sareng sadayana sieun nyabak.
Henteu aya anu pikaresepeun ngeunaan klaster anu janten piaraan, janten kami nyarankeun ngahapus aranjeunna sacara périodik nalika latihan recovery musibah (ieu bakal ngabantosan - kira-kira. tarjamah.). Sajaba ti éta, teu bakal menyakiti pikeun berpungsi dina lapisan kontrol (pesawat kontrol). Sieun nyabak anjeunna sanés tanda anu saé. Jsb maot? Guys, anjeun bener dina masalah!
Di sisi anu sanésna, anjeun teu kedah kabawa ku manipulasi éta. Kalawan waktu lapisan kontrol bisa jadi slow. Paling dipikaresep, ieu téh alatan sajumlah badag objék dijieun tanpa rotasi maranéhanana (kaayaan umum nalika ngagunakeun Helm kalawan setélan standar, naha nu kaayaanana di configmaps / Rahasia teu diropéa - salaku hasilna, rébuan objék ngumpulkeun dina. lapisan kontrol) atawa kalayan ngedit konstan objék kube-api (pikeun skala otomatis, pikeun CI / CD, pikeun monitoring, log acara, controller, jsb).
Salaku tambahan, kami nyarankeun parios perjanjian SLA / SLO sareng panyadia Kubernetes anu diurus sareng merhatikeun jaminan. Penjual tiasa ngajamin kasadiaan lapisan kontrol (atawa subkomponén na), tapi teu reureuh p99 of requests anjeun ngirim ka eta. Dina basa sejen, Anjeun bisa ngasupkeun kubectl get nodes, sarta nampa jawaban ngan sanggeus 10 menit, sarta ieu moal jadi palanggaran istilah tina perjangjian jasa.
11. bonus: ngagunakeun tag panganyarna
Tapi ieu téh geus klasik. Akhir-akhir ieu kami jarang mendakan téknik ieu, sabab seueur, anu diajar tina pangalaman pait, parantos lirén nganggo tag :latest tur mimitian pinning versi. Horeeee!
ECR ; Kami nyarankeun yén anjeun familiarize diri sareng fitur anu luar biasa ieu.
singgetan
Entong ngarepkeun sadayana tiasa dianggo sapeuting: Kubernetes sanés panacea. Aplikasi goréng (jeung eta meureun bakal meunang parah). Carelessness bakal ngakibatkeun pajeulitna kaleuleuwihan, karya slow sarta stres tina lapisan kontrol. Salaku tambahan, anjeun résiko ditinggalkeun tanpa strategi pamulihan bencana. Tong ngarepkeun Kubernetes nyayogikeun isolasi sareng kasadiaan anu luhur di luar kotak. Méakkeun sababaraha waktos ngajantenkeun aplikasi anjeun leres-leres awan.
Anjeun tiasa kenal sareng pangalaman gagal tina sababaraha tim di ku Henning Jacobs.
Anu hoyong nambihan kana daptar kasalahan anu dipasihkeun dina tulisan ieu tiasa ngahubungi kami dina Twitter (, ).
PS ti penerjemah
Baca ogé dina blog urang:
- «";
- «";
- «"(review jeung laporan video);
- «".
sumber: www.habr.com