Seueur jalma nganggap yén cukup pikeun mindahkeun aplikasi ka Kubernetes (boh nganggo Helm atanapi sacara manual) - sareng bakal aya kabagjaan. Tapi teu sagalana geus jadi basajan.
regu narjamahkeun artikel ku insinyur DevOps Julian Gindy. Anjeunna ngabejaan naon pitfalls parusahaan na Nyanghareupan salila prosés migrasi ku kituna anjeun teu lengkah dina rake sarua.
Lengkah Kahiji: Nyetél Paménta sareng Watesan Pod
Hayu urang mimitian ku nyetél lingkungan bersih dimana pods urang bakal ngajalankeun. Kubernetes hébat dina scheduling pod na failover. Tapi tétéla yén scheduler kadang teu bisa nempatkeun pod lamun hese keur estimasi sabaraha sumberdaya nu diperlukeun pikeun digawé suksés. Ieu dimana pamundut sumberdaya sareng wates muncul. Aya seueur perdebatan ngeunaan pendekatan anu pangsaéna pikeun netepkeun paménta sareng wates. Kadang-kadang sigana yén ieu langkung seueur seni tibatan élmu. Ieu pendekatan urang.
Paménta pod nyaeta nilai utama dipaké ku scheduler pikeun optimal nempatkeun pod.
ti : Léngkah saringan nangtukeun sakumpulan titik dimana Pod tiasa dijadwalkeun. Contona, saringan PodFitsResources mariksa lamun titik hiji boga sumberdaya cukup pikeun nyugemakeun requests sumberdaya husus ti pod a.
Kami nganggo pamundut aplikasi ku cara anu urang tiasa ngira-ngira sabaraha sumber nyatana Aplikasina peryogi pikeun fungsina leres. Ku cara ieu scheduler sacara réalistis tiasa nempatkeun titik. Dina awalna, urang hayang leuwih-jadwal requests pikeun mastikeun sumberdaya cukup pikeun tiap Pod, tapi urang noticed nu waktos scheduling ngaronjat sacara signifikan, sarta sababaraha pods teu pinuh dijadwalkeun, saolah-olah aya euweuh requests sumberdaya pikeun aranjeunna.
Dina hal ieu, scheduler bakal mindeng "squeeze kaluar" pods sarta teu bisa reschedule aranjeunna sabab pesawat kontrol teu boga pamanggih sabaraha sumberdaya aplikasi bakal butuh, nu mangrupakeun komponén konci tina algoritma scheduling.
wates pod mangrupakeun wates jelas pikeun pod a. Ieu ngagambarkeun jumlah maksimum sumberdaya nu klaster bakal allocate kana wadahna.
Deui, ti : Lamun wadahna boga wates memori 4 GiB, lajeng kubelet (jeung runtime wadahna) bakal ngalaksanakeun eta. Runtime nyegah wadahna ngagunakeun leuwih ti wates sumberdaya nu ditangtukeun. Salaku conto, nalika prosés dina wadahna nyobian nganggo langkung seueur tina jumlah mémori anu diidinan, kernel sistem ngeureunkeun prosésna kalayan kasalahan "kaluar tina mémori" (OOM).
Wadahna tiasa nganggo langkung seueur sumber daya tibatan anu dipénta ku sumber daya, tapi éta henteu pernah tiasa nganggo langkung ti watesna. Nilai ieu hese diatur leres, tapi penting pisan.
Ideally, urang hoyong sarat sumberdaya pod robah salila siklus hirup hiji prosés tanpa interfering jeung prosés séjén dina sistem - ieu téh tujuan pikeun netepkeun wates.
Hanjakalna, kuring henteu tiasa masihan pitunjuk khusus ngeunaan nilai-nilai anu kedah disetél, tapi urang sorangan taat kana aturan ieu:
- Ngagunakeun alat nguji beban, urang simulate tingkat dasar lalulintas sarta nitenan pamakéan sumberdaya pod (memori jeung processor).
- Atur requests pod ka nilai wenang low (kalawan wates sumberdaya ngeunaan 5 kali nilai requests) jeung niténan. Nalika pamundut dina tingkat anu handap teuing, prosésna henteu tiasa ngamimitian, sering nyababkeun kasalahan runtime Go cryptic.
Kuring dicatet yén wates sumberdaya luhur ngajadikeun scheduling leuwih hese sabab pod perlu titik udagan kalawan sumberdaya cukup sadia.
Bayangkeun kaayaan dimana anjeun gaduh pangladén wéb anu hampang kalayan wates sumberdaya anu luhur pisan, sapertos mémori 4 GB. Prosés ieu sigana bakal kedah diskalakeun sacara horisontal, sareng unggal pod énggal kedah dijadwalkeun dina titik kalayan sahenteuna 4 GB mémori anu sayogi. Upami teu aya titik sapertos kitu, kluster kedah ngenalkeun titik énggal pikeun ngolah pod ieu, anu peryogi sababaraha waktos. Penting pikeun ngahontal bédana minimum antara paménta sumberdaya sareng wates pikeun mastikeun skala gancang sareng lancar.
Lengkah Kadua: Siapkeun Tes Liveness sareng Kesiapan
Ieu topik halus sejen anu mindeng dibahas dina komunitas Kubernetes. Penting pikeun gaduh pamahaman anu hadé ngeunaan tés Liveness sareng Kesiapan sabab nyayogikeun mékanisme pikeun operasi stabil parangkat lunak sareng ngaleutikan downtime. Nanging, aranjeunna tiasa mangaruhan sacara serius kana kinerja aplikasi anjeun upami henteu dikonpigurasi leres. Di handap ieu kasimpulan naon duanana sampel.
Hirup nembongkeun lamun wadahna ngajalankeun. Upami gagal, kubelet maéhan wadahna sareng kawijakan restart diaktipkeun pikeun éta. Upami wadahna henteu dilengkepan Liveness Probe, maka kaayaan standar bakal suksés - sakumaha anu dinyatakeun dina .
Panyilidikan liveness kedah mirah, nyaéta henteu meakeun seueur sumber, sabab sering dijalankeun sareng kedah ngawartosan Kubernetes yén aplikasina jalan.
Upami anjeun nyetél pilihan pikeun ngajalankeun unggal detik, ieu bakal nambihan 1 pamundut per detik, janten sadar yén sumber tambahan bakal diperyogikeun pikeun ngolah lalu lintas ieu.
Di perusahaan kami, tes Liveness nguji komponén inti aplikasi, sanaos data (contona, tina pangkalan data jauh atanapi cache) henteu sayogi.
Kami parantos nyetél titik "kaséhatan" dina aplikasi anu ngan ukur ngabalikeun kode réspon 200. Ieu mangrupikeun indikasi yén prosésna jalan sareng sanggup nanganan pamundut (tapi henteu acan lalu lintas).
Sampel Kesiapan nunjukkeun naha wadahna geus siap ngawula requests. Upami panyilidikan kesiapan gagal, pangendali titik tungtung ngaleungitkeun alamat IP pod tina titik tungtung sadaya jasa anu cocog sareng pod. Ieu ogé dinyatakeun dina dokuméntasi Kubernetes.
Panyilidikan kesiapan meakeun langkung seueur sumber, sabab kedah pencét backend ku cara pikeun nunjukkeun yén aplikasina siap nampi pamundut.
Aya seueur perdebatan di masarakat ngeunaan naha aksés langsung kana pangkalan data. Tempo overhead nu (cék nu sering, tapi maranéhna bisa dikontrol), urang mutuskeun yén pikeun sababaraha aplikasi, kesiapan pikeun ngalayanan lalulintas ngan diitung sanggeus mariksa yen rékaman balik ti database. Uji kesiapan anu dirancang kalayan saé mastikeun tingkat kasadiaan anu langkung luhur sareng ngaleungitkeun downtime salami panyebaran.
Upami anjeun mutuskeun naroskeun pangkalan data pikeun nguji kesiapan aplikasi anjeun, pastikeun éta murah-gancang. Hayu urang nyandak patarosan ieu:
SELECT small_item FROM table LIMIT 1Ieu conto kumaha urang ngonpigurasikeun dua nilai ieu dina Kubernetes:
livenessProbe:
httpGet:
path: /api/liveness
port: http
readinessProbe:
httpGet:
path: /api/readiness
port: http periodSeconds: 2
Anjeun tiasa nambihan sababaraha pilihan konfigurasi tambahan:
initialDelaySeconds- sabaraha detik bakal lulus antara peluncuran wadahna jeung mimiti peluncuran panyilidikan.periodSeconds- antosan interval antara sampel ngalir.timeoutSeconds— Jumlah detik saatos éta pod dianggap darurat. Waktos normal.failureThresholdnyaeta jumlah gagal test saméméh sinyal balikan deui dikirim ka pod nu.successThresholdnyaeta jumlah percobaan suksés saméméh pod transisi ka kaayaan siap (sanggeus gagal nalika pod dimimitian up atanapi recovers).
Lengkah Tilu: Nyetél Kabijakan Jaringan Default Pod
Kubernetes gaduh topografi jaringan "datar", sacara standar sadaya pods saling komunikasi langsung. Dina sababaraha kasus ieu teu desirable.
Masalah kaamanan poténsial nyaéta panyerang tiasa nganggo hiji aplikasi anu rentan pikeun ngirim lalu lintas ka sadaya pods dina jaringan. Sapertos dina seueur daérah kaamanan, prinsip hak istimewa pangsaeutikna berlaku di dieu. Ideally, kawijakan jaringan kedah sacara eksplisit nyatakeun sambungan antara pods anu diidinan sareng mana anu henteu.
Salaku conto, ieu mangrupikeun kawijakan saderhana anu nolak sadaya lalu lintas anu asup pikeun rohangan ngaran anu khusus:
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
spec:
podSelector: {}
policyTypes:
- Ingress
Visualisasi konfigurasi ieu:
(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
leuwih jéntré .
Lengkah Opat: Paripolah Adat sareng Kait sareng Wadah Init
Salah sahiji tujuan utama kami nyaéta nyayogikeun panyebaran di Kubernetes tanpa downtime pikeun pamekar. Ieu sesah sabab aya seueur pilihan pikeun mareuman aplikasi sareng ngaleupaskeun sumber daya anu dianggo.
kasusah husus timbul kalawan . Kami perhatikeun yén nalika nyebarkeun Pods ieu sacara berurutan, sambungan aktip diganggu sateuacan suksés réngsé.
Saatos panalungtikan éksténsif dina Internét, tétéla yén Kubernetes henteu ngadagoan sambungan Nginx ngabéréskeun diri sateuacan mareuman pod. Kalayan bantosan hook pre-stop, kami ngalaksanakeun pungsi di handap ieu sareng ngaleungitkeun downtime:
lifecycle:
preStop:
exec:
command: ["/usr/local/bin/nginx-killer.sh"]
sarta di dieu 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 anu sanés pisan mangpaat nyaéta ngagunakeun wadah init pikeun nanganan peluncuran aplikasi khusus. Ieu hususna kapaké upami anjeun gaduh prosés migrasi pangkalan data anu intensif sumberdaya anu kedah dijalankeun sateuacan aplikasi dimimitian. Anjeun oge bisa nangtukeun wates sumberdaya nu leuwih luhur pikeun prosés ieu tanpa netepkeun wates misalna pikeun aplikasi utama.
skéma umum sejen nyaeta ngakses rusiah dina wadah init, nu nyadiakeun Kapercayaan ieu ka modul utama, nu nyegah aksés diidinan pikeun rusiah tina modul aplikasi utama sorangan.
Sakumaha biasa, kutipan tina dokuméntasi: wadahna init aman ngajalankeun kode pamaké atawa utilitas nu disebutkeun bakal kompromi kaamanan gambar wadahna aplikasi urang. Ku cara misahkeun alat-alat anu teu perlu, anjeun ngawatesan permukaan serangan tina gambar wadahna aplikasi.
Lengkah Lima: Konfigurasi kernel
Tungtungna, hayu urang ngobrol ngeunaan téknik anu langkung maju.
Kubernetes mangrupikeun platform anu fleksibel pisan anu ngamungkinkeun anjeun ngajalankeun beban kerja kumaha waé anu anjeun pikahoyong. Kami ngagaduhan sajumlah aplikasi anu épisién pisan anu intensif sumberdaya. Saatos ngalakukeun uji beban éksténsif, kami mendakan yén salah sahiji aplikasi éta sesah ngajaga beban lalu lintas anu dipiharep nalika setélan standar Kubernetes dianggo.
Sanajan kitu, Kubernetes ngidinan Anjeun pikeun ngajalankeun wadah husus nu ngan ngarobah parameter kernel pikeun pod husus. Ieu naon anu kami dianggo pikeun ngarobih jumlah maksimal sambungan anu kabuka:
initContainers:
- name: sysctl
image: alpine:3.10
securityContext:
privileged: true
command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]
Ieu mangrupikeun téknik anu langkung maju anu sering henteu diperyogikeun. Tapi lamun aplikasi anjeun berjuang pikeun Cope jeung beban beurat, anjeun tiasa nyobian tweaking sababaraha setelan ieu. Inpormasi langkung seueur ngeunaan prosés ieu sareng netepkeun nilai anu béda - sapertos biasa .
dina kacindekan
Sanaos Kubernetes sigana sapertos solusi anu luar biasa, aya sababaraha léngkah konci anu kedah dilaksanakeun supados aplikasi tetep lancar.
Sapanjang migrasi ka Kubernetes, penting pikeun nuturkeun "siklus uji beban": ngajalankeun aplikasi, uji dina beban, perhatikeun métrik sareng paripolah skala, saluyukeun konfigurasi dumasar kana data ieu, teras malikan deui siklus ieu.
Janten realistis ngeunaan lalulintas ekspektasi sarta coba balik saluareun eta pikeun nempo komponén mana nu megatkeun munggaran. Kalayan pendekatan iteratif ieu, ngan ukur sababaraha saran anu didaptarkeun tiasa cekap pikeun ngahontal kasuksésan. Atanapi kustomisasi anu langkung jero tiasa diperyogikeun.
Salawasna naroskeun ka diri anjeun patarosan ieu:
- Sabaraha sumber daya anu dikonsumsi aplikasi sareng kumaha jumlah ieu bakal robih?
- Naon sarat skala sabenerna? Sabaraha lalu lintas rata-rata aplikasi bakal dicekel? Kumaha upami lalulintas puncak?
- Sabaraha sering jasa bakal kedah skala kaluar? Sabaraha gancang pod anyar kedah didamel sareng dijalankeun pikeun nampi lalu lintas?
- Kumaha gracefully pods ditutup? Naha perlu pisan? Éta mungkin pikeun ngahontal deployment tanpa downtime?
- Kumaha ngaminimalkeun résiko kaamanan sareng ngawatesan karusakan tina polong anu badé dikompromi? Naha jasa naon waé anu ngagaduhan idin atanapi aksés anu henteu diperyogikeun?
Kubernetes nyayogikeun platform anu luar biasa anu ngamungkinkeun anjeun ngagunakeun prakték pangsaéna pikeun nyebarkeun rébuan jasa dina klaster. Nanging, sadaya aplikasi béda. Kadang palaksanaan merlukeun saeutik leuwih gawé.
Untungna, Kubernetes nyayogikeun setélan anu diperyogikeun pikeun ngahontal sagala tujuan téknis. Ku ngagunakeun kombinasi requests sumberdaya jeung wates, Liveness jeung Kasadiaan panyilidikan, wadah init, kawijakan jaringan, sarta tuning kernel custom, Anjeun bisa ngahontal kinerja tinggi sapanjang kalawan kasabaran sesar tur scalability gancang.
Naon deui anu dibaca:
- .
- .
- .
sumber: www.habr.com