Halo sadayana! Nami abdi Oleg Sidorenkov, abdi damel di DomClick salaku pamimpin tim infrastruktur. Kami parantos nganggo Cube pikeun dijual langkung ti tilu taun, sareng salami ieu kami parantos ngalaman seueur momen anu pikaresepeun sareng éta. Dinten ieu kuring bakal ngabejaan ka maneh kumaha, kalawan pendekatan katuhu, anjeun tiasa squeeze malah leuwih kinerja kaluar vanili Kubernetes pikeun klaster Anjeun. Siap ajeg!
Anjeun sadaya terang pisan yén Kubernetes nyaéta sistem open source scalable pikeun orkestrasi wadahna; sumur, atawa 5 binaries nu ngalakukeun magic ku ngatur siklus hirup microservices anjeun dina lingkungan server. Salaku tambahan, ieu mangrupikeun alat anu cukup fleksibel anu tiasa dirakit sapertos konstruktor Lego pikeun kustomisasi maksimal pikeun tugas anu béda.
Jeung sagalana sigana rupa: buang server kana klaster, kawas firewood kana firebox a, sarta teu nyaho duka. Tapi lamun keur lingkungan, mangka anjeun bakal mikir: "Kumaha carana abdi tiasa nyimpen seuneu dina kompor jeung kuciwa leuweung?". Dina basa sejen, kumaha carana manggihan cara pikeun ngaronjatkeun infrastruktur jeung ngurangan biaya.
1. Lacak sumber tim sareng aplikasi
Salah sahiji metodeu anu paling banal tapi efektif nyaéta ngenalkeun pamundut / wates. Pisahkeun aplikasi ku namespaces, sareng namespaces ku tim pamekaran. Setel aplikasi sateuacan nyebarkeun nilai pikeun konsumsi waktos prosésor, mémori, neundeun ephemeral.
resources:
requests:
memory: 2Gi
cpu: 250m
limits:
memory: 4Gi
cpu: 500mKu pangalaman, urang sumping ka kacindekan: teu patut inflating requests ti wates ku leuwih ti dua kali. Ukuran klaster diitung dumasar kana requests, sarta lamun nyetel aplikasi pikeun bédana sumberdaya, contona, ku 5-10 kali, lajeng ngabayangkeun naon anu bakal kajadian ka titik anjeun nalika ngeusi pods sarta ujug-ujug narima beban. Euweuh nu alus. Sahenteuna, throttling, sarta salaku maksimum, ngucapkeun wilujeung ka worker tur meunangkeun beban siklik dina sesa titik sanggeus pods mimiti gerak.
Sajaba ti éta, kalayan bantuan limitranges Anjeun tiasa nyetél nilai sumberdaya pikeun wadahna di mimiti - minimum, maksimum sareng standar:
➜ ~ kubectl describe limitranges --namespace ops
Name: limit-range
Namespace: ops
Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
---- -------- --- --- --------------- ------------- -----------------------
Container cpu 50m 10 100m 100m 2
Container ephemeral-storage 12Mi 8Gi 128Mi 4Gi -
Container memory 64Mi 40Gi 128Mi 128Mi 2Émut pikeun ngawates sumberdaya namespace supados hiji paréntah henteu tiasa nyandak sadaya sumber kluster:
➜ ~ kubectl describe resourcequotas --namespace ops
Name: resource-quota
Namespace: ops
Resource Used Hard
-------- ---- ----
limits.cpu 77250m 80
limits.memory 124814367488 150Gi
pods 31 45
requests.cpu 53850m 80
requests.memory 75613234944 150Gi
services 26 50
services.loadbalancers 0 0
services.nodeports 0 0Sakumaha anjeun tiasa tingali tina katerangan resourcequotas, upami paréntah ops hoyong nyebarkeun pods anu bakal meakeun 10 CPU sanés, maka penjadwal moal ngijinkeun éta dilakukeun sareng bakal ngaluarkeun kasalahan:
Error creating: pods "nginx-proxy-9967d8d78-nh4fs" is forbidden: exceeded quota: resource-quota, requested: limits.cpu=5,requests.cpu=5, used: limits.cpu=77250m,requests.cpu=53850m, limited: limits.cpu=10,requests.cpu=10Pikeun ngajawab masalah sarupa, Anjeun bisa nulis alat, contona, salaku , anu tiasa nyimpen sareng ngalaksanakeun kaayaan sumber paréntah.
2. Pilih gudang file pangalusna
Di dieu kuring hoyong nyabak topik volume pengkuh sareng subsistem disk tina titik pagawé Kubernetes. Kuring miharep yén teu aya anu ngagunakeun "Kubus" dina HDD dina produksi, tapi sakapeung malah SSD biasa geus teu cukup. Kami nyanghareupan masalah sapertos log anu maéhan disk ku operasi I / O, sareng henteu seueur pisan solusi di dieu:
-
Paké SSDs-kinerja tinggi atawa pindah ka NVMe (lamun ngatur hardware sorangan).
-
Turunkeun tingkat logging.
-
Laksanakeun "pinter" nyaimbangkeun pods anu ngaropea disk (
podAntiAffinity).
Potret layar di luhur nunjukkeun naon anu lumangsung dina nginx-ingress-controller sareng disk nalika access_logs diaktipkeun (~ 12k log / detik). Kaayaan sapertos kitu, tangtosna, tiasa nyababkeun degradasi sadaya aplikasi dina titik ieu.
Sedengkeun pikeun PV, aduh, kuring henteu acan nyobian sadayana. Jilid pengkuh. Anggo pilihan pangsaéna anu cocog sareng anjeun. Éta sajarahna kajantenan di nagara urang yén sabagian leutik jasa peryogi jilid RWX, sareng parantos lami aranjeunna mimiti ngagunakeun panyimpen NFS pikeun tugas ieu. Murah sareng ... cekap. Tangtosna, urang tuang telek sareng anjeunna - janten séhat, tapi urang diajar kumaha nyaluyukeun anjeunna, sareng sirahna henteu nyeri deui. Tur upami mungkin, pindah ka gudang obyék S3.
3. Ngawangun Gambar dioptimalkeun
Hadé pisan mun éta ngagunakeun gambar anu dioptimalkeun ku wadahna supados Kubernetes tiasa nyandak éta langkung gancang sareng ngalaksanakeunana langkung éfisién.
Optimasi hartosna yén gambar:
-
ngandung ngan hiji aplikasi atawa ngalakukeun ngan hiji fungsi;
-
ukuran leutik, sabab gambar badag anu parah dikirimkeun ngaliwatan jaringan;
-
gaduh titik ahir kaséhatan sareng kesiapan anu tiasa dianggo ku Kubernetes pikeun nyandak tindakan upami aya waktos downtime;
-
ngagunakeun sistem operasi anu ramah wadahna (sapertos Alpine atanapi CoreOS) anu langkung tahan kana kasalahan konfigurasi;
-
make multi-tahap ngawangun ku kituna anjeun ngan bisa nyebarkeun aplikasi disusun teu sumber nu dibéré bareng.
Aya seueur alat sareng jasa anu ngamungkinkeun anjeun mariksa sareng ngaoptimalkeun gambar dina laleur. Kadé salawasna tetep up to date jeung aman. Hasilna, anjeun meunang:
-
Ngurangan beban jaringan dina sakabéh klaster.
-
Turunkeun waktos ngamimitian wadahna.
-
Ukuran anu langkung alit tina sadaya pendaptaran Docker anjeun.
4. Paké cache DNS
Lamun urang ngobrol ngeunaan beban tinggi, tanpa tuning sistem DNS klaster, hirup téh geulis lousy. Baheula, pamekar Kubernetes ngadukung solusi kube-dns na. Éta ogé dilaksanakeun di nagara urang, tapi parangkat lunak ieu henteu cocog sareng henteu masihan kinerja anu diperyogikeun, sanaos sigana, tugasna saderhana. Teras muncul coredns, anu urang gentos sareng henteu terang duka, teras janten layanan DNS standar di K8s. Di sawatara titik, urang tumuwuh nepi ka 40 sarébu rps kana sistem DNS, sarta solusi ieu ogé teu cukup. Tapi, ku kasempetan untung, Nodelocaldns kaluar, alias node local cache, alias .
Naha urang ngagunakeun éta? Aya bug dina kernel Linux Ubuntu nu, nalika sababaraha aksés ngaliwatan conntrack NAT leuwih UDP, ngabalukarkeun kaayaan lomba pikeun nulis kana tabel conntrack, sarta bagian tina lalulintas ngaliwatan NAT leungit (unggal lalampahan ngaliwatan Service nyaeta NAT). Nodelocaldns ngarengsekeun masalah ieu ku cara ngaleungitkeun NAT sareng ningkatkeun konektipitas TCP kana DNS hulu, ogé cache queries DNS hulu sacara lokal (kalebet cache négatip 5 detik anu pondok).
5. Skala pods horisontal jeung vertikal otomatis
Naha anjeun tiasa nyarios kalayan kayakinan yén sadaya jasa mikro anjeun parantos siap pikeun beban dua dugi ka tilu kali lipet? Kumaha leres alokasi sumberdaya pikeun aplikasi anjeun? Ngajaga sababaraha pods ngajalankeun kaleuwihan beban kerja tiasa kaleuleuwihan, sareng ngajaga aranjeunna deui-deui résiko downtime tina paningkatan ngadadak dina lalu lintas kana jasa. Mean emas mantuan pikeun ngahontal mantra multiplication jasa kayaning и .
VPA ngidinan Anjeun pikeun otomatis ngangkat requests / wates wadahna anjeun dina pod dumasar kana pamakéan sabenerna. Kumaha bisa jadi mangpaat? Upami anjeun gaduh Pods anu kusabab sababaraha alesan henteu tiasa diskalakeun sacara horisontal (anu henteu tiasa dipercaya), anjeun tiasa nyobian percanten ka VPA pikeun ngarobih sumberna. Fiturna nyaéta sistem rekomendasi dumasar kana data sajarah sareng ayeuna tina métrik-server, janten upami anjeun henteu hoyong ngarobih pamundut / wates sacara otomatis, anjeun ngan saukur tiasa ngawas sumber anu disarankeun pikeun wadah anjeun sareng ngaoptimalkeun setélan pikeun nyimpen CPU sareng mémori. dina klaster.
Gambar dicokot tina https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231
Penjadwal dina Kubernetes sok dumasar kana pamundut. Naon waé nilai anu anjeun pasang di dinya, penjadwal bakal milarian titik anu cocog dumasar kana éta. Nilai wates anu diperlukeun ku kublet dina urutan uninga iraha bade throttle atawa maéhan pod a. Sarta saprak hijina parameter penting nyaéta requests nilai, VPA bakal dianggo kalayan eta. Iraha waé anjeun ngaskalakeun aplikasi anjeun sacara vertikal, anjeun netepkeun naon anu kedah diperyogikeun. Sarta naon anu bakal kajadian ka wates lajeng? Parameter ieu ogé bakal diskalakeun sacara proporsional.
Contona, ieu setélan pod has:
resources:
requests:
memory: 250Mi
cpu: 200m
limits:
memory: 500Mi
cpu: 350mMesin rekomendasi nangtukeun yén aplikasi anjeun peryogi 300m CPU sareng 500Mi pikeun ngajalankeun leres. Anjeun bakal nampi setélan ieu:
resources:
requests:
memory: 500Mi
cpu: 300m
limits:
memory: 1000Mi
cpu: 525mSakumaha didadarkeun di luhur, ieu skala proporsional dumasar kana rasio requests / wates dina manifest:
-
CPU: 200m → 300m: babandingan 1:1.75;
-
Mémori: 250Mi → 500Mi: rasio 1:2.
kalawan hal pikeun HPA, mangka mékanisme operasi leuwih transparan. Thresholds diatur pikeun metrics kayaning processor na memori, sarta lamun rata-rata sadaya réplika ngaleuwihan bangbarung, teras aplikasi skala ku +1 pod dugi nilai ragrag handap bangbarung, atawa nepi ka jumlah maksimum réplika ngahontal.
Gambar dicokot tina https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231
Salian métrik biasa sapertos CPU sareng Mémori, anjeun tiasa nyetél ambang dina métrik Prometheus khusus anjeun sareng damel sareng aranjeunna upami anjeun ngarasa ieu mangrupikeun cara anu paling akurat pikeun nangtoskeun nalika skala aplikasi anjeun. Sakali aplikasina stabil di handap ambang métrik anu ditangtukeun, HPA bakal ngamimitian ngaskalakeun pods ka jumlah réplika minimum atanapi dugi ka beban nyumponan ambang anu ditangtukeun.
6. Tong Poho Ngeunaan Node Affinity sareng Pod Affinity
Henteu sadayana titik jalan dina hardware anu sami, sareng henteu sadayana pod kedah ngajalankeun aplikasi anu intensif komputasi. Kubernetes ngidinan Anjeun pikeun nangtukeun spésialisasi node jeung pods ngagunakeun Node Afinitas и Pod Afinitas.
Upami Anjeun gaduh titik anu cocog pikeun operasi komputasi-intensif, teras pikeun efisiensi maksimum, éta hadé pikeun meungkeut aplikasi ka titik luyu. Jang ngalampahkeun ieu, make nodeSelector kalawan labél titik.
Anggap anjeun gaduh dua titik: hiji sareng CPUType=HIGHFREQ sarta sajumlah badag cores gancang, sejen kalawan MemoryType=HIGHMEMORY memori leuwih jeung kinerja gancang. Cara panggampangna nyaéta pikeun napelkeun deployment pod ka node HIGHFREQku nambahkeun kana bagian spec pamilih sapertos kieu:
…
nodeSelector:
CPUType: HIGHFREQCara anu langkung mahal sareng khusus pikeun ngalakukeun ieu nyaéta ngagunakeun nodeAffinity di sawah affinity bagian spec. Aya dua pilihan:
-
requiredDuringSchedulingIgnoredDuringExecution: setting teuas (scheduler ngan bakal nyebarkeun pods on titik husus (jeung nowhere sejenna)); -
preferredDuringSchedulingIgnoredDuringExecution: setting lemes (schedule bakal nyoba nyebarkeun ka titik husus, sarta lamun gagal, eta bakal nyoba nyebarkeun ka titik sadia salajengna).
Anjeun tiasa netepkeun sintaksis khusus pikeun ngatur labél titik, contona, In, NotIn, Exists, DoesNotExist, Gt atawa Lt. Nanging, émut yén metode kompléks dina daptar labél anu panjang bakal ngalambatkeun kaputusan dina kaayaan kritis. Dina basa sejen, ulah leuwih ngahesekeun.
Sakumaha didadarkeun di luhur, Kubernetes ngidinan Anjeun pikeun nyetel beungkeutan pods ayeuna. Hartina, anjeun bisa nyieun pods tangtu gawé bareng jeung pods séjén dina zone kasadiaan sarua (relevan pikeun awan) atawa titik.
В podAffinity huma affinity bagian spec widang anu sarua sadia sakumaha dina kasus nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution и preferredDuringSchedulingIgnoredDuringExecution. Hijina bédana éta matchExpressions bakal ngabeungkeut pods ka titik nu geus ngajalankeun pod kalawan labél éta.
Langkung seueur Kubernetes nawiskeun lapangan podAntiAffinity, anu, sabalikna, henteu ngabeungkeut pod kana titik kalayan pods khusus.
Ngeunaan babasan nodeAffinity Naséhat anu sami tiasa dipasihkeun: coba tetep aturan anu sederhana sareng logis, ulah coba overload spésifikasi pod sareng set aturan anu rumit. Gampang pisan nyiptakeun aturan anu henteu cocog sareng kaayaan kluster, nempatkeun beban tambahan dina jadwal sareng ngahinakeun kinerja sadayana.
7. Taints & Tolerations
Aya cara sejen pikeun ngatur scheduler nu. Upami anjeun gaduh klaster ageung kalayan ratusan titik sareng rébuan jasa mikro, sesah pisan pikeun nyegah pods tinangtu di-host ku titik-titik tertentu.
Mékanisme taints - aturan ngalarang - ngabantosan ieu. Contona, Anjeun bisa nyegah titik tangtu ngajalankeun pods dina skenario nu tangtu. Pikeun nerapkeun taint ka titik khusus, paké pilihan taint di kubectl. Sebutkeun konci na nilai lajeng taint kawas NoSchedule atawa NoExecute:
$ kubectl taint nodes node10 node-role.kubernetes.io/ingress=true:NoScheduleOgé sia noting yén mékanisme taint ngarojong tilu épék utama: NoSchedule, NoExecute и PreferNoSchedule.
-
NoSchedulehartina nepi ka aya entri saluyu dina spésifikasi podtolerations, éta teu tiasa disebarkeun ka titik (dina conto ieunode10). -
PreferNoSchedule- versi saderhanaNoSchedule. Dina hal ieu, scheduler bakal nyobian teu allocate pods nu teu boga entri cocog.tolerationsper titik, tapi ieu teu wates teuas. Upami teu aya sumber daya dina kluster, maka polong bakal mimiti nyebarkeun dina titik ieu. -
NoExecute- pangaruh ieu micu hiji évakuasi saharita pods nu teu boga entri cocogtolerations.
Panasaran, kabiasaan ieu tiasa dibatalkeun nganggo mékanisme toleransi. Ieu merenah lamun aya titik "dilarang" jeung anjeun kudu nempatkeun ukur jasa infrastruktur di dinya. Kumaha cara ngalakukeunana? Ngidinan ngan ukur polong anu aya toleransi anu cocog.
Ieu kumaha spésifikasi pod bakal katingalina:
spec:
tolerations:
- key: "node-role.kubernetes.io/ingress"
operator: "Equal"
value: "true"
effect: "NoSchedule"Ieu lain hartosna yén dina mangsa redeploy salajengna, pod bakal pencét persis titik ieu, ieu lain mékanisme Node Affinity jeung nodeSelector. Tapi ku ngagabungkeun sababaraha fitur, anjeun tiasa ngahontal setelan scheduler pisan fléksibel.
8. Atur Pod deployment Prioritas
Ngan kusabab anjeun parantos ngonpigurasikeun beungkeutan pod-to-node sanés hartosna yén sadaya pods kedah dirawat kalayan prioritas anu sami. Salaku conto, anjeun panginten badé nyebarkeun sababaraha Pod sateuacan anu sanés.
Kubernetes nawiskeun sababaraha cara pikeun nyetél Prioritas Pod sareng Preemption. Setelan diwangun ku sababaraha bagian: objék PriorityClass jeung pedaran widang priorityClassName dina spésifikasi pod. Pertimbangkeun conto:
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: high-priority
value: 99999
globalDefault: false
description: "This priority class should be used for very important pods only"Urang nyieun PriorityClass, pasihan nami, pedaran, sareng nilai. Beuki luhur value, nu leuwih luhur prioritas. Nilaina tiasa janten integer 32-bit kirang atanapi sami sareng 1. Nilai anu langkung luhur ditangtayungan pikeun pod sistem kritis-misi, anu biasana henteu tiasa diprediksi. Pangusiran ngan bakal lumangsung lamun pod-prioritas luhur boga tempat pikeun balikkeun sabudeureun, lajeng sababaraha pods ti titik nu tangtu bakal diungsikeun. Upami mékanisme ieu kaku teuing pikeun anjeun, maka anjeun tiasa nambihan pilihan preemptionPolicy: Never, lajeng bakal aya euweuh preemption, pod bakal kahiji dina antrian jeung ngadagoan scheduler pikeun manggihan sumberdaya bébas pikeun eta.
Salajengna, urang nyieun pod, nu urang nangtukeun nami priorityClassName:
apiVersion: v1
kind: Pod
metadata:
name: static-web
labels:
role: myrole
spec:
containers:
- name: web
image: nginx
ports:
- name: web
containerPort: 80
protocol: TCP
priorityClassName: high-priority
Anjeun tiasa nyiptakeun saloba kelas prioritas anu anjeun pikahoyong, sanaos disarankeun pikeun henteu kabawa ku ieu (sebutkeun, ngawatesan diri kana prioritas rendah, sedeng sareng luhur).
Janten, upami diperyogikeun, anjeun tiasa ningkatkeun efisiensi nyebarkeun jasa kritis, sapertos nginx-ingress-controller, coredns, jsb.
9. Optimalkeun klaster ETCD Anjeun
ETCD bisa disebut otak sakabeh klaster. Penting pisan pikeun ngajaga operasi database ieu dina tingkat anu luhur, sabab laju operasi dina "Kubus" gumantung kana éta. A cukup baku, sarta dina waktos anu sareng, leyuran alus bakal tetep hiji klaster ETCD dina titik master guna boga reureuh minimum mun kube-apiserver. Upami ieu teu mungkin, teras nempatkeun ETCD sacaket mungkin, kalayan rubakpita anu saé antara pamilon. Ogé nengetan sabaraha titik ti ETCD bisa ragrag kaluar tanpa ngarugikeun ka klaster.
Terus di pikiran nu paningkatan kaleuleuwihan dina jumlah pamilon dina klaster bisa ningkatkeun kasabaran sesar di expense kinerja, sagalana kudu di moderation.
Upami urang ngobrol ngeunaan nyetél jasa, maka aya sababaraha saran:
-
Boga hardware anu saé, dumasar kana ukuran kluster (anjeun tiasa maca ).
-
Tweak sababaraha parameter upami anjeun parantos nyebarkeun klaster antara sapasang DC atanapi jaringan sareng disk anjeun seueur anu dipikahoyong (anjeun tiasa maca ).
kacindekan
Tulisan ieu ngajelaskeun poin-poin anu tim kami nyobian sasuai. Ieu sanés déskripsi léngkah-léngkah tindakan, tapi pilihan anu tiasa mangpaat pikeun ngaoptimalkeun overhead klaster. Ieu jelas yén unggal klaster unik dina cara sorangan, sarta solusi tuning bisa rupa-rupa pisan, jadi eta bakal metot pikeun meunangkeun eupan balik ti anjeun: kumaha anjeun ngawas klaster Kubernetes anjeun, kumaha anjeun ngaronjatkeun kinerja na. Bagikeun pangalaman anjeun dina koméntar, éta bakal pikaresepeun pikeun terang éta.
sumber: www.habr.com