Akeh wong sing percaya yen cukup kanggo mindhah aplikasi menyang Kubernetes (nggunakake Helm utawa manual) lan dheweke bakal seneng. Nanging iku ora sing prasaja.
tim nerjemahake artikel dening insinyur DevOps Julian Gindi. Dheweke nuduhake apa pitfalls perusahaan ditemoni sak proses migrasi supaya sampeyan ora langkah ing rake padha.
Langkah Siji: Nyetel Panjaluk lan Watesan Pod
Ayo miwiti kanthi nyiyapake lingkungan sing resik ing ngendi polong kita bakal mlaku. Kubernetes nindakake tugas sing apik kanggo nggawe jadwal pod lan nangani kahanan gagal. Nanging ternyata panjadwal kadhangkala ora bisa nyelehake polong yen angel ngira jumlah sumber daya sing dibutuhake supaya bisa sukses. Iki ngendi panjalukan kanggo sumber daya lan watesan teka munggah. Ana akeh debat babagan pendekatan paling apik kanggo nyetel panjalukan lan watesan. Kadhangkala pancen rumangsa luwih seni tinimbang ngelmu. Punika pendekatan kita.
Panjaluk Pod - Iki minangka nilai utama sing digunakake panjadwal kanggo nyelehake polong kanthi optimal.
Saka : Langkah nyaring nemtokake set simpul ngendi pod bisa dijadwal. Contone, saringan PodFitsResources mriksa apa simpul nduweni sumber daya sing cukup kanggo nyukupi panjalukan sumber daya tartamtu saka pod.
Kita nggunakake panjalukan aplikasi supaya bisa digunakake kanggo ngira jumlah sumber daya nyatane Aplikasi kasebut mbutuhake supaya bisa digunakake kanthi bener. Kanthi cara iki panjadwal bisa nyelehake simpul kanthi realistis. Kaping pisanan, kita pengin nyetel panjalukan kanthi wates kanggo mesthekake yen saben pod duwe sumber daya sing cukup akeh, nanging kita ngeweruhi manawa wektu jadwal tambah akeh lan sawetara pod ora tau dijadwalake kanthi lengkap, kaya-kaya ora ana panjaluk sumber daya sing ditampa.
Ing kasus iki, panjadwal bakal kerep push metu pods lan ora bisa reschedule amarga pesawat kontrol ora ngerti carane akeh sumber daya aplikasi bakal mbutuhake, komponen tombol saka algoritma jadwal.
watesan pod - iki watesan luwih cetha kanggo polong. Iku nuduhake jumlah maksimum sumber daya sing kluster bakal nyedhiakke kanggo wadhah.
Maneh, saka : Yen wadhah wis 4 GiB watesan memori nyetel, banjur kubelet (lan runtime wadhah) bakal ngleksanakake. Runtime ora ngidini wadhah nggunakake luwih saka watesan sumber daya sing ditemtokake. Contone, nalika proses ing wadhah nyoba nggunakake luwih saka jumlah memori sing diijini, kernel sistem mungkasi proses kasebut kanthi kesalahan "kehabisan memori" (OOM).
Wadhah bisa tansah nggunakake sumber daya liyane saka kasebut ing request sumber, nanging ora bisa nggunakake luwih saka sing ditemtokake ing watesan. Nilai iki angel disetel kanthi bener, nanging penting banget.
Saenipun, kita pengin syarat sumber daya pod kanggo ngganti liwat siklus urip saka proses tanpa ngganggu pangolahan liyane ing sistem-iku goal nyetel watesan.
Sayange, aku ora bisa menehi instruksi khusus babagan nilai sing kudu disetel, nanging kita dhewe netepi aturan ing ngisor iki:
- Nggunakake alat testing mbukak, kita simulasi tingkat lalu lintas baseline lan ngawasi nggunakake sumber pod (memori lan prosesor).
- Kita nyetel panjalukan pod menyang nilai sing kurang (kanthi watesan sumber daya kira-kira 5 kaping nilai panjalukan) lan mirsani. Nalika panjalukan kurang, proses ora bisa diwiwiti, asring nyebabake kesalahan runtime Go sing misterius.
Elinga yen watesan sumber daya sing luwih dhuwur nggawe jadwal luwih angel amarga pod mbutuhake simpul target kanthi sumber daya sing cukup.
Mbayangno kahanan sing duwe server web entheng karo watesan sumber daya dhuwur banget, ngandika 4 memori GB. Proses iki mesthine kudu skala horisontal, lan saben modul anyar kudu dijadwalake ing simpul kanthi paling ora 4 GB memori sing kasedhiya. Yen ora ana simpul kasebut, kluster kudu ngenalake simpul anyar kanggo ngolah pod kasebut, sing mbutuhake sawetara wektu. Penting kanggo njaga prabΓ©dan antarane panjalukan sumber daya lan watesan minimal kanggo mesthekake skala cepet lan lancar.
Langkah loro: nyiyapake tes Liveness lan Kesiapan
Iki minangka topik subtle liyane sing asring dibahas ing komunitas Kubernetes. Penting kanggo ngerti babagan tes Liveness lan Readiness amarga menehi mekanisme supaya piranti lunak bisa mlaku kanthi lancar lan nyuda downtime. Nanging, bisa nyebabake kinerja serius ing aplikasi sampeyan yen ora dikonfigurasi kanthi bener. Ing ngisor iki ringkesan saka loro conto kasebut.
Urip nuduhake apa wadhah mlaku. Yen gagal, kubelet mateni wadhah kasebut lan kabijakan miwiti maneh diaktifake. Yen wadhah kasebut ora dilengkapi probe Liveness, mula kahanan standar bakal sukses - iki sing dicritakake .
Liveness probe kudu murah, tegese padha ora kudu nggunakake akeh sumber daya, amarga padha mbukak kerep lan kudu ngandhani Kubernetes yen aplikasi wis mlaku.
Yen sampeyan nyetel pilihan kanggo mbukak saben detik, iki bakal nambah 1 panjalukan saben detik, supaya weruh yen sumber daya tambahan bakal dibutuhake kanggo nangani lalu lintas iki.
Ing perusahaan kita, tes Liveness mriksa komponen inti saka aplikasi, sanajan data (contone, saka database remot utawa cache) ora bisa diakses kanthi lengkap.
Kita wis ngonfigurasi aplikasi kanthi titik pungkasan "kesehatan" sing mung ngasilake kode respon 200. Iki minangka indikasi yen proses kasebut mlaku lan bisa ngolah panjaluk (nanging durung lalu lintas).
Sample Kesiapan nuduhake apa wadhah siap kanggo ngawula panjalukan. Yen probe kesiapan gagal, pengontrol endpoint mbusak alamat IP pod saka titik pungkasan kabeh layanan sing cocog karo pod. Iki uga kasebut ing dokumentasi Kubernetes.
Penyelidikan kesiapan nggunakake sumber daya luwih akeh amarga kudu dikirim menyang backend kanthi cara sing nuduhake aplikasi siap nampa panjaluk.
Ana akeh debat ing masyarakat babagan apa ngakses database langsung. Diwenehi overhead (mriksa dileksanakake kerep, nanging bisa diatur), kita mutusakΓ© sing kanggo sawetara aplikasi, kesiapan kanggo ngawula lalu lintas mung diitung sawise verifikasi sing cathetan bali saka database. Uji coba kesiapan sing dirancang kanthi apik njamin kasedhiyan tingkat sing luwih dhuwur lan ngilangi downtime sajrone panyebaran.
Yen sampeyan arep takon database kanggo nyoba kesiapan aplikasi, priksa manawa iku minangka murah sabisa. Ayo njaluk panjaluk iki:
SELECT small_item FROM table LIMIT 1Mangkene conto carane ngatur rong nilai kasebut ing Kubernetes:
livenessProbe:
httpGet:
path: /api/liveness
port: http
readinessProbe:
httpGet:
path: /api/readiness
port: http periodSeconds: 2
Sampeyan bisa nambah sawetara opsi konfigurasi tambahan:
initialDelaySeconds- pinten detik bakal liwati antarane peluncuran wadhah lan wiwitan conto.periodSeconds- interval nunggu antarane sampel nganggo.timeoutSeconds- jumlah detik sawise unit kasebut dianggep darurat. wektu entek reguler.failureThreshold- jumlah gagal test sadurunge sinyal restart dikirim menyang pod.successThreshold- jumlah probe sing sukses sadurunge polong dadi siap (sawise gagal, nalika polong diwiwiti utawa pulih).
Langkah telu: nyetel kabijakan jaringan standar kanggo pod
Kubernetes duwe topografi jaringan "flat"; kanthi standar, kabeh pods komunikasi langsung karo siji liyane. Ing sawetara kasus iki ora dikarepake.
Masalah keamanan sing potensial yaiku penyerang bisa nggunakake aplikasi sing rawan kanggo ngirim lalu lintas menyang kabeh pod ing jaringan. Kaya ing pirang-pirang wilayah keamanan, prinsip hak istimewa sing paling sithik ditrapake ing kene. Saenipun, kabijakan jaringan kudu kanthi tegas nemtokake sambungan endi sing diidini lan sing ora.
Contone, ing ngisor iki ana kabijakan prasaja sing nolak kabeh lalu lintas mlebu kanggo ruang jeneng tartamtu:
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
spec:
podSelector: {}
policyTypes:
- Ingress
Visualisasi konfigurasi iki:
(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
Rincian liyane .
Langkah papat: prilaku adat nggunakake pancingan lan kontaner init
Salah sawijining tujuan utama yaiku nyedhiyakake penyebaran menyang Kubernetes tanpa downtime kanggo pangembang. Iki angel amarga ana akeh pilihan kanggo mateni aplikasi lan mbebasake sumber daya sing digunakake.
Kangelan tartamtu muncul karo . Kita weruh yen polong kasebut disebarake kanthi urutan, sambungan aktif ilang sadurunge rampung.
Sawise riset ekstensif online, ternyata Kubernetes ora ngenteni sambungan Nginx kesel dhewe sadurunge mungkasi pod. Nggunakake pancing pre-stop, kita nindakake fungsi ing ngisor iki lan nyingkirake downtime:
lifecycle:
preStop:
exec:
command: ["/usr/local/bin/nginx-killer.sh"]
Nanging nginx-killer.sh:
#!/bin/bash
sleep 3
PID=$(cat /run/nginx.pid)
nginx -s quit
while [ -d /proc/$PID ]; do
echo "Waiting while shutting down nginx..."
sleep 10
done
Paradigma liyane sing migunani banget yaiku nggunakake wadhah init kanggo nangani wiwitan aplikasi tartamtu. Iki utamanΓ© migunani yen sampeyan duwe proses migrasi database intensif sumber daya sing kudu mbukak sadurunge aplikasi diwiwiti. Sampeyan uga bisa nemtokake watesan sumber daya sing luwih dhuwur kanggo proses iki tanpa nyetel watesan kasebut kanggo aplikasi utama.
Skema umum liyane yaiku ngakses rahasia ing wadhah init sing nyedhiyakake kredensial kasebut menyang modul utama, sing nyegah akses ora sah menyang rahasia saka modul aplikasi utama dhewe.
Kaya biasane, kutipan saka dokumentasi: Wadhah Init kanthi aman mbukak kode khusus utawa keperluan sing bakal nyuda keamanan gambar wadhah aplikasi. Kanthi misahake alat sing ora perlu, sampeyan mbatesi permukaan serangan saka gambar wadhah aplikasi.
Langkah Lima: Konfigurasi Kernel
Pungkasan, ayo ngomong babagan teknik sing luwih maju.
Kubernetes minangka platform sing fleksibel banget sing ngidini sampeyan mbukak beban kerja kanthi cara sing cocog. Kita duwe sawetara aplikasi kinerja dhuwur sing sumber daya banget intensif. Sawise nganakake tes beban ekstensif, kita nemokake manawa ana siji aplikasi sing berjuang kanggo ngatasi beban lalu lintas sing dikarepake nalika setelan gawan Kubernetes ditrapake.
Nanging, Kubernetes ngidini sampeyan mbukak wadhah khusus sing ngganti parameter kernel mung kanggo pod tartamtu. Iki sing digunakake kanggo ngganti jumlah maksimum sambungan mbukak:
initContainers:
- name: sysctl
image: alpine:3.10
securityContext:
privileged: true
command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]
Iki minangka teknik sing luwih maju sing asring ora dibutuhake. Nanging yen aplikasi sampeyan berjuang kanggo ngatasi beban sing abot, sampeyan bisa nyoba ngapiki sawetara setelan kasebut. Rincian liyane babagan proses iki lan nyetel nilai sing beda - kaya biasane .
Ing kesimpulan
Nalika Kubernetes katon kaya solusi sing wis siyap, ana sawetara langkah penting sing kudu ditindakake supaya aplikasi sampeyan bisa mlaku kanthi lancar.
Sajrone migrasi Kubernetes sampeyan, penting kanggo ngetutake "siklus uji coba": bukak aplikasi, muat test, mirsani metrik lan prilaku skala, atur konfigurasi adhedhasar data kasebut, banjur baleni siklus maneh.
Dadi realistis babagan lalu lintas sing dikarepake lan coba push ngluwihi kanggo ndeleng komponen sing rusak dhisik. Kanthi pendekatan iteratif iki, mung sawetara rekomendasi sing kadhaptar bisa uga cukup kanggo nggayuh sukses. Utawa mbutuhake kustomisasi sing luwih jero.
Tansah takon dhewe pitakonan iki:
- Pira sumber daya sing dikonsumsi aplikasi lan kepiye volume iki bakal diganti?
- Apa syarat skala nyata? Pira lalu lintas sing bakal ditindakake aplikasi rata-rata? Apa babagan lalu lintas puncak?
- Sepira kerepe layanan kasebut kudu skala horisontal? Sepira cepet polong anyar kudu digawa online kanggo nampa lalu lintas?
- Carane bener pods mati? Apa iki perlu kabeh? Apa bisa entuk penyebaran tanpa downtime?
- Kepiye carane bisa nyuda risiko keamanan lan mbatesi karusakan saka polong sing dikompromi? Apa layanan apa wae sing duwe ijin utawa akses sing ora dibutuhake?
Kubernetes nyedhiyakake platform sing luar biasa sing ngidini sampeyan nggunakake praktik paling apik kanggo nyebarake ewu layanan ing kluster. Nanging, saben aplikasi beda. Kadhangkala implementasine mbutuhake karya liyane.
Untunge, Kubernetes nyedhiyakake konfigurasi sing dibutuhake kanggo nggayuh kabeh tujuan teknis. Nggunakake kombinasi panjalukan lan watesan sumber daya, panyelidikan Liveness lan Kesiapan, wadhah init, kabijakan jaringan, lan tuning kernel khusus, sampeyan bisa entuk kinerja dhuwur bebarengan karo toleransi kesalahan lan skalabilitas kanthi cepet.
Apa maneh sing kudu diwaca:
- .
- .
- .
Source: www.habr.com