Daudzi cilvÄki uzskata, ka pietiek migrÄt lietojumprogrammu uz Kubernetes (vai nu izmantojot Helm, vai manuÄli), un viÅi bÅ«s laimÄ«gi. Bet tas nav tik vienkÄrÅ”i.
Komanda iztulkojis DevOps inženiera Džuliana Džindija rakstu. ViÅÅ” dalÄs ar kļūmÄm, ar kurÄm viÅa uzÅÄmums saskÄrÄs migrÄcijas procesa laikÄ, lai jÅ«s neuzkÄptu uz tÄ paÅ”a grÄbekļa.
Pirmais solis: Pod pieprasījumu un ierobežojumu iestatīŔana
SÄksim, izveidojot tÄ«ru vidi, kurÄ mÅ«su podi darbosies. Kubernetes paveic lielisku darbu, plÄnojot aplikumus un apstrÄdÄjot atteices apstÄkļus. Bet izrÄdÄ«jÄs, ka plÄnotÄjs dažreiz nevar ievietot podziÅu, ja ir grÅ«ti novÄrtÄt, cik daudz resursu tam nepiecieÅ”ams, lai tas veiksmÄ«gi darbotos. Å eit parÄdÄs resursu un ierobežojumu pieprasÄ«jumi. Ir daudz diskusiju par labÄko pieeju pieprasÄ«jumu un ierobežojumu noteikÅ”anai. Dažreiz patieÅ”Äm Ŕķiet, ka tÄ ir vairÄk mÄksla nekÄ zinÄtne. LÅ«k, mÅ«su pieeja.
Pod pieprasÄ«jumi - Å Ä« ir galvenÄ vÄrtÄ«ba, ko plÄnotÄjs izmanto, lai optimÄli novietotu podziÅu.
No : filtrÄÅ”anas darbÄ«ba nosaka mezglu kopu, kurÄ var ieplÄnot aplikumu. PiemÄram, filtrs PodFitsResources pÄrbauda, āāvai mezglam ir pietiekami daudz resursu, lai apmierinÄtu podziÅas specifiskos resursu pieprasÄ«jumus.
MÄs izmantojam lietojumprogrammu pieprasÄ«jumus, lai tos varÄtu izmantot, lai novÄrtÄtu, cik daudz resursu patiesÄ«bÄ Lietojumprogrammai tÄ ir nepiecieÅ”ama, lai tÄ darbotos pareizi. TÄdÄ veidÄ plÄnotÄjs var reÄlistiski izvietot mezglus. SÄkotnÄji mÄs vÄlÄjÄmies iestatÄ«t pieprasÄ«jumus ar rezervi, lai nodroÅ”inÄtu, ka katrÄ podÄ ir pietiekami liels resursu skaits, taÄu mÄs pamanÄ«jÄm, ka plÄnoÅ”anas laiki ievÄrojami palielinÄjÄs un daži aplikumi nekad netika pilnÄ«bÄ ieplÄnoti, it kÄ par tiem nebÅ«tu saÅemti resursu pieprasÄ«jumi.
Å ÄdÄ gadÄ«jumÄ plÄnotÄjs bieži izstumtu aplikumus un nevarÄtu tos pÄrplÄnot, jo vadÄ«bas plaknei nebija ne jausmas, cik daudz resursu lietojumprogrammai bÅ«s nepiecieÅ”ams, kas ir plÄnoÅ”anas algoritma galvenÄ sastÄvdaļa.
Podu ierobežojumi - Ŕī ir skaidrÄka pÄksts robeža. Tas atspoguļo maksimÄlo resursu daudzumu, ko klasteris pieŔķirs konteineram.
Atkal, no : ja konteineram ir iestatÄ«ts 4 GiB atmiÅas ierobežojums, kubelet (un konteinera izpildlaiks) to ieviesÄ«s. Izpildlaiks neļauj konteineram izmantot vairÄk par norÄdÄ«to resursu ierobežojumu. PiemÄram, kad process konteinerÄ mÄÄ£ina izmantot vairÄk nekÄ atļauts atmiÅas apjoms, sistÄmas kodols pabeidz procesu ar kļūdu āout of memoryā (OOM).
Konteiners vienmÄr var izmantot vairÄk resursu, nekÄ norÄdÄ«ts resursa pieprasÄ«jumÄ, taÄu nekad nevar izmantot vairÄk, nekÄ norÄdÄ«ts ierobežojumÄ. Å o vÄrtÄ«bu ir grÅ«ti pareizi iestatÄ«t, taÄu tÄ ir ļoti svarÄ«ga.
IdeÄlÄ gadÄ«jumÄ mÄs vÄlamies, lai podziÅas resursu prasÄ«bas mainÄ«tos procesa dzÄ«ves cikla laikÄ, netraucÄjot citiem sistÄmas procesiem ā tas ir ierobežojumu noteikÅ”anas mÄrÄ·is.
DiemžÄl nevaru sniegt konkrÄtus norÄdÄ«jumus par to, kÄdas vÄrtÄ«bas iestatÄ«t, bet mÄs paÅ”i ievÄrojam Å”Ädus noteikumus:
- Izmantojot slodzes pÄrbaudes rÄ«ku, mÄs simulÄjam trafika bÄzes lÄ«meni un uzraugÄm pod resursu (atmiÅas un procesora) izmantoÅ”anu.
- MÄs iestatÄm apkopÄju pieprasÄ«jumus uz patvaļīgi zemu vÄrtÄ«bu (ar resursu ierobežojumu apmÄram 5 reizes par pieprasÄ«jumu vÄrtÄ«bu) un novÄrojam. Ja pieprasÄ«jumu ir pÄrÄk maz, procesu nevar sÄkt, bieži izraisot noslÄpumainas Go izpildlaika kļūdas.
Å emiet vÄrÄ, ka augstÄki resursu ierobežojumi apgrÅ«tina plÄnoÅ”anu, jo podam ir nepiecieÅ”ams mÄrÄ·a mezgls ar pietiekamiem pieejamiem resursiem.
IedomÄjieties situÄciju, kad jums ir viegls tÄ«mekļa serveris ar ļoti lielu resursu ierobežojumu, piemÄram, 4 GB atmiÅas. Å im procesam, visticamÄk, bÅ«s jÄmÄro horizontÄli, un katrs jaunais modulis bÅ«s jÄplÄno mezglÄ ar vismaz 4 GB pieejamo atmiÅu. Ja Å”Äda mezgla nav, klasterim ir jÄievieÅ” jauns mezgls, lai apstrÄdÄtu Å”o podziÅu, kas var aizÅemt kÄdu laiku. Ir svarÄ«gi lÄ«dz minimumam samazinÄt atŔķirÄ«bu starp resursu pieprasÄ«jumiem un ierobežojumiem, lai nodroÅ”inÄtu Ätru un vienmÄrÄ«gu mÄrogoÅ”anu.
Otrais solis: dzīvīguma un gatavības testu iestatīŔana
Å Ä« ir vÄl viena smalka tÄma, kas bieži tiek apspriesta Kubernetes kopienÄ. Ir svarÄ«gi labi izprast dzÄ«vÄ«guma un gatavÄ«bas testus, jo tie nodroÅ”ina programmatÅ«ras vienmÄrÄ«gu darbÄ«bu un samazina dÄ«kstÄves laiku. TomÄr, ja tie nav pareizi konfigurÄti, tie var nopietni ietekmÄt jÅ«su lietojumprogrammas veiktspÄju. TÄlÄk ir sniegts abu paraugu kopsavilkums.
DzÄ«vÄ«gums parÄda, vai konteiners darbojas. Ja tas neizdodas, kubelet nogalina konteineru un tam tiek iespÄjota restartÄÅ”anas politika. Ja konteiners nav aprÄ«kots ar Liveness zondi, noklusÄjuma stÄvoklis bÅ«s veiksmÄ«gs - tas ir rakstÄ«ts .
Liveness zondÄm jÄbÅ«t lÄtÄm, kas nozÄ«mÄ, ka tÄm nevajadzÄtu patÄrÄt daudz resursu, jo tÄs darbojas bieži un tÄm ir jÄinformÄ Kubernetes, ka lietojumprogramma darbojas.
Ja iestatÄt opciju palaist katru sekundi, tiks pievienots 1 pieprasÄ«jums sekundÄ, tÄpÄc Åemiet vÄrÄ, ka Ŕīs trafika apstrÄdei bÅ«s nepiecieÅ”ami papildu resursi.
MÅ«su uzÅÄmumÄ Liveness testi pÄrbauda lietojumprogrammas pamatkomponentus pat tad, ja dati (piemÄram, no attÄlÄs datu bÄzes vai keÅ”atmiÅas) nav pilnÄ«bÄ pieejami.
MÄs esam konfigurÄjuÅ”i lietotnes ar āveselÄ«basā galapunktu, kas vienkÄrÅ”i atgriež atbildes kodu 200. Tas norÄda, ka process darbojas un spÄj apstrÄdÄt pieprasÄ«jumus (bet vÄl ne trafiku).
Paraugs GatavÄ«ba norÄda, vai konteiners ir gatavs apkalpot pieprasÄ«jumus. Ja gatavÄ«bas zonde neizdodas, galapunkta kontrolleris noÅem pod IP adresi no visu pakalpojumu galapunktiem, kas atbilst pod. Tas ir norÄdÄ«ts arÄ« Kubernetes dokumentÄcijÄ.
GatavÄ«bas pÄrbaudes patÄrÄ vairÄk resursu, jo tie ir jÄnosÅ«ta uz aizmugursistÄmu tÄdÄ veidÄ, kas norÄda, ka lietojumprogramma ir gatava pieÅemt pieprasÄ«jumus.
SabiedrÄ«bÄ notiek daudz diskusiju par to, vai tieÅ”i piekļūt datu bÄzei. Å emot vÄrÄ pieskaitÄmÄs izmaksas (pÄrbaudes tiek veiktas bieži, bet tÄs var pielÄgot), mÄs nolÄmÄm, ka dažÄm lietojumprogrammÄm gatavÄ«ba apkalpot trafiku tiek skaitÄ«ta tikai pÄc tam, kad ir pÄrbaudÄ«ts, vai ieraksti tiek atgriezti no datu bÄzes. Labi izstrÄdÄti gatavÄ«bas izmÄÄ£inÄjumi nodroÅ”inÄja augstÄku pieejamÄ«bas lÄ«meni un novÄrsa dÄ«kstÄves izvietoÅ”anas laikÄ.
Ja nolemjat vaicÄt datu bÄzÄ, lai pÄrbaudÄ«tu lietojumprogrammas gatavÄ«bu, pÄrliecinieties, vai tÄ ir pÄc iespÄjas lÄtÄka. PieÅemsim Å”o pieprasÄ«jumu:
SELECT small_item FROM table LIMIT 1Å eit ir piemÄrs, kÄ mÄs konfigurÄjam Ŕīs divas vÄrtÄ«bas Kubernetes:
livenessProbe:
httpGet:
path: /api/liveness
port: http
readinessProbe:
httpGet:
path: /api/readiness
port: http periodSeconds: 2
Varat pievienot dažas papildu konfigurÄcijas opcijas:
initialDelaySecondsā cik sekundes paies no konteinera palaiÅ”anas lÄ«dz paraugu ÅemÅ”anas sÄkumam.periodSecondsā gaidÄ«Å”anas intervÄls starp paraugu ÅemÅ”anu.timeoutSecondsā sekunžu skaits, pÄc kura vienÄ«ba tiek uzskatÄ«ta par avÄrijas situÄciju. RegulÄra taimauts.failureThresholdā testa kļūmju skaits pirms restartÄÅ”anas signÄla nosÅ«tÄ«Å”anas uz pod.successThresholdā veiksmÄ«go zondu skaits, pirms pods pÄriet gatavÄ«bas stÄvoklÄ« (pÄc kļūmes, kad pods ieslÄdzas vai atjaunojas).
TreÅ”Ä darbÄ«ba: noklusÄjuma tÄ«kla politiku iestatÄ«Å”ana podam
Kubernetes tÄ«kla topogrÄfija ir āplakanaā; pÄc noklusÄjuma visi podi sazinÄs tieÅ”i viens ar otru. Dažos gadÄ«jumos tas nav vÄlams.
IespÄjama droŔības problÄma ir tÄda, ka uzbrucÄjs var izmantot vienu ievainojamu lietojumprogrammu, lai nosÅ«tÄ«tu trafiku uz visiem tÄ«kla blokiem. TÄpat kÄ daudzÄs droŔības jomÄs, arÄ« Å”eit tiek piemÄrots mazÄko privilÄÄ£iju princips. IdeÄlÄ gadÄ«jumÄ tÄ«kla politikÄm bÅ«tu skaidri jÄnorÄda, kuri savienojumi starp podiem ir atļauti un kuri nav.
PiemÄram, tÄlÄk ir vienkÄrÅ”a politika, kas liedz visu ienÄkoÅ”o trafiku konkrÄtai nosaukumvietai.
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
spec:
podSelector: {}
policyTypes:
- Ingress
Å Ä«s konfigurÄcijas vizualizÄcija:
(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
SÄ«kÄka informÄcija .
Ceturtais solis: pielÄgota darbÄ«ba, izmantojot ÄÄ·us un init konteinerus
Viens no mÅ«su galvenajiem mÄrÄ·iem bija nodroÅ”inÄt Kubernetes izvietoÅ”anu bez dÄ«kstÄves izstrÄdÄtÄjiem. Tas ir sarežģīti, jo ir daudz iespÄju lietojumprogrammu izslÄgÅ”anai un to izmantoto resursu atbrÄ«voÅ”anai.
ÄŖpaÅ”as grÅ«tÄ«bas radÄs ar . MÄs pamanÄ«jÄm, ka, kad Å”ie podi tika izvietoti secÄ«gi, aktÄ«vie savienojumi tika pÄrtraukti pirms veiksmÄ«gas pabeigÅ”anas.
PÄc plaÅ”as izpÄtes tieÅ”saistÄ izrÄdÄs, ka Kubernetes negaida, lÄ«dz Nginx savienojumi izsÄ«ks, pirms pÄrtrauks podziÅu. Izmantojot pirmsapstÄÅ”anÄs ÄÄ·i, mÄs ieviesÄm Å”Ädu funkcionalitÄti un pilnÄ«bÄ atbrÄ«vojÄmies no dÄ«kstÄves:
lifecycle:
preStop:
exec:
command: ["/usr/local/bin/nginx-killer.sh"]
Bet 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
VÄl viena ÄrkÄrtÄ«gi noderÄ«ga paradigma ir init konteineru izmantoÅ”ana konkrÄtu lietojumprogrammu palaiÅ”anai. Tas ir Ä«paÅ”i noderÄ«gi, ja jums ir resursietilpÄ«gs datu bÄzes migrÄcijas process, kas jÄpalaiž pirms lietojumprogrammas palaiÅ”anas. Å im procesam var norÄdÄ«t arÄ« lielÄku resursu ierobežojumu, nenosakot Å”Ädu ierobežojumu galvenajai lietojumprogrammai.
VÄl viena izplatÄ«ta shÄma ir piekļuve noslÄpumiem sÄkuma konteinerÄ, kas nodroÅ”ina Å”os akreditÄcijas datus galvenajam modulim, kas novÄrÅ” nesankcionÄtu piekļuvi noslÄpumiem no paÅ”a galvenÄ lietojumprogrammas moduļa.
KÄ parasti, citÄjiet no dokumentÄcijas: Init konteineri droÅ”i palaiž pielÄgotu kodu vai utilÄ«tas, kas citÄdi samazinÄtu lietojumprogrammas konteinera attÄla droŔību. Turot nevajadzÄ«gus rÄ«kus atseviŔķi, jÅ«s ierobežojat lietojumprogrammas konteinera attÄla uzbrukuma virsmu.
Piektais solis: Kodola konfigurÄÅ”ana
Visbeidzot, parunÄsim par progresÄ«vÄku tehniku.
Kubernetes ir ÄrkÄrtÄ«gi elastÄ«ga platforma, kas ļauj darbinÄt darba slodzes tÄ, kÄ jums Ŕķiet piemÄrots. Mums ir vairÄkas augstas veiktspÄjas lietojumprogrammas, kas ir ÄrkÄrtÄ«gi resursietilpÄ«gas. PÄc plaÅ”as slodzes pÄrbaudes mÄs atklÄjÄm, ka vienai lietojumprogrammai bija grÅ«ti tikt galÄ ar paredzamo trafika slodzi, kad bija spÄkÄ Kubernetes noklusÄjuma iestatÄ«jumi.
TomÄr Kubernetes ļauj palaist priviliÄ£Ätu konteineru, kas maina kodola parametrus tikai konkrÄtam podam. LÅ«k, ko izmantojÄm, lai mainÄ«tu maksimÄlo atvÄrto savienojumu skaitu:
initContainers:
- name: sysctl
image: alpine:3.10
securityContext:
privileged: true
command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]
Å Ä« ir progresÄ«vÄka tehnika, kas bieži vien nav nepiecieÅ”ama. Bet, ja jÅ«su lietojumprogrammai ir grÅ«ti tikt galÄ ar lielu slodzi, varat mÄÄ£inÄt pielÄgot dažus no Å”iem iestatÄ«jumiem. SÄ«kÄka informÄcija par Å”o procesu un dažÄdu vÄrtÄ«bu iestatÄ«Å”anu - kÄ vienmÄr .
NoslÄgumÄ
Lai gan Kubernetes var Ŕķist gatavs risinÄjums, ir jÄveic dažas galvenÄs darbÄ«bas, lai jÅ«su lietojumprogrammas darbotos nevainojami.
VisÄ Kubernetes migrÄcijas laikÄ ir svarÄ«gi ievÄrot "slodzes pÄrbaudes ciklu": palaidiet lietojumprogrammu, pÄrbaudiet to ielÄdes, novÄrojiet metriku un mÄrogoÅ”anas darbÄ«bu, pielÄgojiet konfigurÄciju, pamatojoties uz Å”iem datiem, un pÄc tam atkÄrtojiet ciklu vÄlreiz.
Esiet reÄlistisks attiecÄ«bÄ uz paredzamo trafiku un mÄÄ£iniet to pÄrsniegt, lai redzÄtu, kuri komponenti sabojÄjas vispirms. Izmantojot Å”o iteratÄ«vo pieeju, panÄkumu gÅ«Å”anai var pietikt tikai ar dažiem no uzskaitÄ«tajiem ieteikumiem. Vai arÄ« tas var prasÄ«t dziļÄku pielÄgoÅ”anu.
VienmÄr uzdodiet sev Å”os jautÄjumus:
- Cik resursus patÄrÄ lietojumprogrammas un kÄ mainÄ«sies Å”is apjoms?
- KÄdas ir reÄlÄs mÄrogoÅ”anas prasÄ«bas? Cik lielu trafiku lietotne vidÄji apkalpos? KÄ ar maksimÄlo satiksmi?
- Cik bieži pakalpojumam bÅ«s jÄmÄro horizontÄli? Cik Ätri jauni podi ir jÄpievieno tieÅ”saistÄ, lai saÅemtu trafiku?
- Cik pareizi pÄkstis izslÄdzas? Vai tas vispÄr ir vajadzÄ«gs? Vai ir iespÄjams panÄkt izvietoÅ”anu bez dÄ«kstÄves?
- KÄ jÅ«s varat samazinÄt droŔības riskus un ierobežot bojÄjumus, ko rada jebkÄdi apdraudÄti podi? Vai kÄdiem pakalpojumiem ir atļaujas vai piekļuve, kas tiem nav nepiecieÅ”ama?
Kubernetes nodroÅ”ina neticamu platformu, kas ļauj izmantot labÄko praksi tÅ«kstoÅ”iem pakalpojumu izvietoÅ”anai klasterÄ«. TomÄr katrs pieteikums ir atŔķirÄ«gs. Dažreiz ievieÅ”ana prasa nedaudz vairÄk darba.
Par laimi, Kubernetes nodroÅ”ina nepiecieÅ”amo konfigurÄciju visu tehnisko mÄrÄ·u sasniegÅ”anai. Izmantojot resursu pieprasÄ«jumu un ierobežojumu kombinÄciju, dzÄ«vÄ«guma un gatavÄ«bas zondes, iniciÄÅ”anas konteinerus, tÄ«kla politikas un pielÄgotu kodola regulÄÅ”anu, varat sasniegt augstu veiktspÄju, kÄ arÄ« kļūdu toleranci un Ätru mÄrogojamÄ«bu.
Ko vÄl lasÄ«t:
- .
- .
- .
Avots: www.habr.com