Daghang mga tawo ang naghunahuna nga igo na ang pagbalhin sa aplikasyon sa Kubernetes (bisan gamit ang Helm o mano-mano) - ug adunay kalipay. Apan dili tanan yano ra kaayo.
team gihubad ang usa ka artikulo ni DevOps engineer Julian Gindy. Gisulti niya kung unsa ang mga lit-ag nga giatubang sa iyang kompanya sa proseso sa paglalin aron dili ka makatunob sa parehas nga rake.
Unang Lakang: I-set up ang Pod Requests and Limits
Magsugod ta pinaagi sa pagpahimutang sa usa ka limpyo nga palibot diin ang atong mga pod modagan. Nindot pod ang Kubernetes sa scheduling ug failover. Apan kini nahimo nga ang scheduler usahay dili makabutang og usa ka pod kung lisud ang pagbana-bana kung pila ang mga kahinguhaan nga gikinahanglan aron malampuson nga magtrabaho. Dinhi diin ang mga hangyo alang sa mga kahinguhaan ug mga limitasyon motungha. Adunay daghang debate bahin sa labing kaayo nga pamaagi sa pagtakda sa mga hangyo ug limitasyon. Usahay ingon og kini labi pa sa usa ka arte kaysa usa ka siyensya. Ania ang among pamaagi.
Mga hangyo pod mao ang nag-unang bili nga gigamit sa scheduler sa labing maayo nga pagbutang sa pod.
Gikan : Ang lakang sa pagsala naghubit sa usa ka hugpong sa mga node diin ang usa ka Pod mahimong ma-iskedyul. Pananglitan, ang PodFitsResources filter nagsusi aron makita kung ang usa ka node adunay igo nga mga kapanguhaan aron matagbaw ang piho nga mga hangyo sa kapanguhaan gikan sa usa ka pod.
Gigamit namo ang mga hangyo sa aplikasyon sa paagi nga mabanabana namo kung pila ka mga kapanguhaan sa pagkatinuod Ang aplikasyon nanginahanglan kini nga molihok sa husto. Niining paagiha ang scheduler makabutang sa realistiko sa mga node. Sa sinugdan, gusto namong i-over-schedule ang mga hangyo aron maseguro ang igo nga mga kahinguhaan alang sa matag Pod, apan among namatikdan nga ang oras sa pag-iskedyul miusbaw pag-ayo, ug ang pipila ka Pods dili hingpit nga naka-iskedyul, ingon og walay mga hangyo sa kapanguhaan alang kanila.
Sa kini nga kaso, ang scheduler kanunay nga "magpislit" sa mga pod ug dili makahimo sa pag-reschedule kanila tungod kay ang control plane walay ideya kung unsa ka daghang mga kapanguhaan ang gikinahanglan sa aplikasyon, nga usa ka mahinungdanong bahin sa algorithm sa pag-iskedyul.
Mga limitasyon sa pod mas klaro nga limit para sa pod. Kini nagrepresentar sa labing taas nga kantidad sa mga kahinguhaan nga igahin sa cluster sa sudlanan.
Pag-usab, gikan sa : Kung ang usa ka sudlanan adunay limitasyon sa panumduman nga 4 GiB, nan ang kubelet (ug ang runtime sa sudlanan) mopatuman niini. Ang runtime nagpugong sa sudlanan sa paggamit ug labaw pa sa gitakdang limitasyon sa kahinguhaan. Pananglitan, kung ang usa ka proseso sa usa ka sudlanan mosulay sa paggamit labaw pa sa gitugotan nga kantidad sa memorya, ang kernel sa sistema magtapos sa proseso nga adunay sayup nga "out of memory" (OOM).
Ang usa ka sudlanan makagamit kanunay og dugang nga mga kahinguhaan kay sa gitino sa hangyo sa kahinguhaan, apan dili gayud kini makagamit ug labaw sa limitasyon. Kini nga kantidad lisud itakda sa husto, apan kini hinungdanon kaayo.
Sa tinuud, gusto namon nga ang mga kinahanglanon sa kahinguhaan sa usa ka pod mausab sa panahon sa siklo sa kinabuhi sa usa ka proseso nga dili manghilabot sa ubang mga proseso sa sistema - kini ang katuyoan sa pagtakda og mga limitasyon.
Ikasubo, dili ako makahatag espesipikong mga panudlo kung unsang mga kantidad ang itakda, apan kami mismo nagsunod sa mga musunud nga lagda:
- Gamit ang usa ka himan sa pagsulay sa pagkarga, among gisundog ang base nga lebel sa trapiko ug giobserbahan ang paggamit sa mga kapanguhaan sa pod (memorya ug processor).
- Ibutang ang mga hangyo sa pod sa usa ka arbitraryong ubos nga kantidad (nga adunay limitasyon sa kahinguhaan nga mga 5 ka pilo sa kantidad sa mga hangyo) ug obserbahan. Kung ang mga hangyo anaa sa ubos kaayo nga lebel, ang proseso dili makasugod, kasagaran hinungdan sa misteryosong mga sayop sa runtime sa Go.
Namatikdan nako nga ang mas taas nga mga limitasyon sa kahinguhaan naghimo sa pag-iskedyul nga mas lisud tungod kay ang pod nagkinahanglan og usa ka target node nga adunay igo nga mga kapanguhaan nga anaa.
Hunahunaa ang usa ka sitwasyon diin ikaw adunay usa ka gaan nga web server nga adunay taas kaayo nga limitasyon sa kapanguhaan, sama sa 4 GB sa memorya. Kini nga proseso lagmit kinahanglan nga i-scale sa pahalang, ug ang matag bag-ong pod kinahanglan nga ma-iskedyul sa usa ka node nga adunay labing menos 4 GB nga magamit nga memorya. Kung walay ingon nga node, ang cluster kinahanglan nga magpaila sa usa ka bag-ong node aron maproseso kini nga pod, nga mahimong magdugay. Mahinungdanon nga makab-ot ang usa ka minimum nga kalainan tali sa mga hangyo ug mga limitasyon sa kapanguhaan aron masiguro ang paspas ug hapsay nga pag-scale.
Ikaduhang Lakang: I-set up ang Liveness ug Readiness Tests
Kini usa pa ka maliputon nga hilisgutan nga kanunay nga gihisgutan sa komunidad sa Kubernetes. Importante nga adunay maayo nga pagsabot sa Liveness ug Readiness nga mga pagsulay kay naghatag kini og mekanismo para sa stable nga operasyon sa software ug mamenosan ang downtime. Bisan pa, kini mahimong seryoso nga makaapekto sa pasundayag sa imong aplikasyon kung dili husto ang pag-configure. Sa ubos mao ang usa ka summary sa kung unsa ang duha nga mga sample.
Kinabuhi nagpakita kon ang sudlanan nagdagan. Kung kini mapakyas, ang kubelet mopatay sa sudlanan ug ang restart nga palisiya gipalihok alang niini. Kung ang sudlanan wala nasangkapan sa usa ka Liveness Probe, nan ang default nga kahimtang mahimong malampuson - ingon sa gipahayag sa .
Ang liveness probes kinahanglan nga barato, i.e. dili mokonsumo sa daghang mga kahinguhaan, tungod kay kini kanunay nga nagdagan ug kinahanglan ipahibalo sa Kubernetes nga ang aplikasyon nagdagan.
Kung imong itakda ang kapilian nga modagan matag segundo, makadugang kini og 1 nga hangyo matag segundo, busa hinumdomi nga kinahanglan ang dugang nga mga kapanguhaan aron maproseso kini nga trapiko.
Sa among kompanya, ang Liveness nga mga pagsulay nagsulay sa kinauyokan nga mga sangkap sa usa ka aplikasyon, bisan kung ang datos (pananglitan, gikan sa usa ka hilit nga database o cache) dili hingpit nga magamit.
Nagbutang kami og usa ka "panglawas" nga endpoint sa mga aplikasyon nga nagbalik lang sa 200 nga tubag nga code. Kini usa ka timailhan nga ang proseso nagdagan ug makahimo sa pagdumala sa mga hangyo (apan dili pa trapiko).
Sulayi Andam nagpakita kon ang sudlanan andam na sa pag-alagad sa mga hangyo. Kung mapakyas ang probe sa pagkaandam, kuhaon sa endpoint controller ang IP address sa pod gikan sa mga endpoint sa tanan nga serbisyo nga katumbas sa pod. Gipahayag usab kini sa dokumentasyon sa Kubernetes.
Ang mga pagsusi sa kaandam nag-ut-ot sa daghang mga kapanguhaan, tungod kay kinahanglan nila nga maigo ang backend sa paagi nga ipakita nga ang aplikasyon andam na nga modawat sa mga hangyo.
Adunay daghang debate sa komunidad bahin sa direkta nga pag-access sa database. Sa pagkonsiderar sa overhead (ang mga tseke kanunay, apan kini makontrol), nakahukom kami nga alang sa pipila ka mga aplikasyon, ang pagkaandam sa pag-alagad sa trapiko giihap lamang human sa pagsusi nga ang mga rekord gibalik gikan sa database. Ang maayong pagkadisenyo nga mga pagsulay sa kaandam nagsiguro sa mas taas nga lebel sa pagkaanaa ug giwagtang ang downtime sa panahon sa pag-deploy.
Kung nakahukom ka nga mangutana sa database aron masulayan ang kaandam sa imong aplikasyon, siguroha nga kini barato kutob sa mahimo. Atong tagdon kini nga pangutana:
SELECT small_item FROM table LIMIT 1Ania ang usa ka pananglitan kung giunsa naton i-configure kining duha nga mga kantidad sa Kubernetes:
livenessProbe:
httpGet:
path: /api/liveness
port: http
readinessProbe:
httpGet:
path: /api/readiness
port: http periodSeconds: 2
Mahimo nimong idugang ang pipila ka dugang nga mga kapilian sa pag-configure:
initialDelaySeconds- pila ka segundo ang molabay tali sa paglansad sa sudlanan ug pagsugod sa paglansad sa mga pagsusi.periodSeconds- agwat sa paghulat tali sa sample run.timeoutSecondsβ ang gidaghanon sa mga segundo pagkahuman ang pod giisip nga emerhensya. Normal nga timeout.failureThresholdmao ang gidaghanon sa mga kapakyasan sa pagsulay sa wala pa ang usa ka restart signal ipadala sa pod.successThresholdmao ang gidaghanon sa malampuson nga mga pagsulay sa dili pa ang pod transisyon ngadto sa andam nga kahimtang (human sa usa ka kapakyasan sa diha nga ang pod magsugod sa o pag-ayo).
Ikatulong Lakang: Pag-set sa Default nga Mga Patakaran sa Network sa Pod
Ang Kubernetes adunay usa ka "flat" nga topograpiya sa network, sa default ang tanan nga mga pod direkta nga nakigsulti sa usag usa. Sa pipila ka mga kaso dili kini gusto.
Ang usa ka potensyal nga isyu sa seguridad mao nga ang usa ka tig-atake mahimong mogamit sa usa ka mahuyang nga aplikasyon aron ipadala ang trapiko sa tanan nga mga pod sa network. Sama sa daghang bahin sa seguridad, ang prinsipyo sa labing gamay nga pribilehiyo magamit dinhi. Sa tinuud, ang mga palisiya sa network kinahanglan nga klaro nga ipahayag kung unsang mga koneksyon tali sa mga pod ang gitugotan ug kung diin ang dili.
Pananglitan, ang mosunod usa ka yano nga palisiya nga naglimud sa tanan nga umaabot nga trapiko alang sa usa ka partikular nga namespace:
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
spec:
podSelector: {}
policyTypes:
- Ingress
Visualization niini nga configuration:
(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
Sa mga detalye .
Ikaupat nga Lakang: Pasadya nga Gawi nga adunay mga Kaw-it ug Mga Init nga Kontainer
Usa sa among nag-unang tumong mao ang paghatag og mga deployment sa Kubernetes nga walay downtime alang sa mga developers. Lisud kini tungod kay adunay daghang mga kapilian sa pagsira sa mga aplikasyon ug pagpagawas sa ilang gigamit nga mga kapanguhaan.
Ang partikular nga mga kalisdanan mitungha uban sa . Among namatikdan nga sa dihang nag-deploy niini nga mga Pod sa pagkasunodsunod, ang mga aktibong koneksyon nabalda sa wala pa makompleto.
Pagkahuman sa daghang panukiduki sa Internet, nahibal-an nga ang Kubernetes wala maghulat sa mga koneksyon sa Nginx nga mahurot ang ilang kaugalingon sa wala pa isira ang pod. Uban sa tabang sa pre-stop hook, among gipatuman ang mosunod nga gamit ug hingpit nga nawala ang downtime:
lifecycle:
preStop:
exec:
command: ["/usr/local/bin/nginx-killer.sh"]
Apan 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
Laing labi ka mapuslanon nga paradigma mao ang paggamit sa init nga mga sulud aron madumala ang paglansad sa mga piho nga aplikasyon. Kini labi ka mapuslanon kung ikaw adunay usa ka proseso sa paglalin sa database nga kusog sa kapanguhaan nga kinahanglan ipadagan sa dili pa magsugod ang aplikasyon. Mahimo usab nimong itakda ang usa ka mas taas nga limitasyon sa kapanguhaan alang niini nga proseso nga wala magtakda sa ingon nga limitasyon alang sa panguna nga aplikasyon.
Ang laing komon nga pamaagi mao ang pag-access sa mga sekreto sa init nga sudlanan, nga naghatag niini nga mga kredensyal sa main module, nga nagpugong sa dili awtorisadong pag-access sa mga sekreto gikan sa main application module mismo.
Sama sa naandan, usa ka kinutlo gikan sa dokumentasyon: init nga mga sudlanan luwas nga nagpadagan sa user code o mga utilities nga mahimoβg makompromiso ang seguridad sa imahe sa sulud sa aplikasyon. Pinaagi sa pagbulag sa wala kinahanglana nga mga himan, imong gilimitahan ang nawong sa pag-atake sa imahe sa sulud sa aplikasyon.
Ikalima nga Lakang: Pag-configure sa Kernel
Sa kataposan, maghisgot ta bahin sa mas abante nga teknik.
Ang Kubernetes usa ka hilabihan ka flexible nga plataporma nga nagtugot kanimo sa pagpadagan sa mga workloads bisan pa nga imong nakita nga angay. Kami adunay daghang mga episyente kaayo nga aplikasyon nga labi ka kusog sa kapanguhaan. Pagkahuman sa paghimo sa daghang pagsulay sa pagkarga, among nakita nga ang usa sa mga aplikasyon naglisud sa pagpadayon sa gipaabut nga pagkarga sa trapiko kung ang default nga mga setting sa Kubernetes magamit.
Bisan pa, gitugotan ka sa Kubernetes sa pagpadagan sa usa ka pribilihiyo nga sudlanan nga nagbag-o lang sa mga parameter sa kernel alang sa usa ka piho nga pod. Ania kung unsa ang among gigamit aron mabag-o ang labing kadaghan nga bukas nga koneksyon:
initContainers:
- name: sysctl
image: alpine:3.10
securityContext:
privileged: true
command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]
Kini usa ka mas abante nga teknik nga kasagaran wala kinahanglana. Apan kung ang imong aplikasyon nanlimbasug sa pagsagubang sa usa ka bug-at nga karga, mahimo nimong sulayan ang pag-tweak sa pipila niini nga mga setting. Dugang nga kasayuran bahin sa kini nga proseso ug pagtakda sa lainlaing mga kantidad - sama sa kanunay .
Sa konklusyon
Samtang ang Kubernetes ingon og usa ka out-of-the-box nga solusyon, adunay pipila ka mahinungdanong mga lakang nga kinahanglan buhaton aron mapadayon ang mga aplikasyon nga hapsay.
Sa tibuok nga paglalin ngadto sa Kubernetes, importante nga sundon ang "siklo sa pagsulay sa pagkarga": pagdagan ang aplikasyon, sulayi kini ubos sa pagkarga, pag-obserbar sa mga sukatan ug pamatasan sa pag-scale, i-adjust ang configuration base sa kini nga datos, unya balika kini nga siklo pag-usab.
Pagmarealistiko bahin sa gipaabot nga trapiko ug sulayi nga lapas pa kini aron makita kung unsang mga sangkap ang una nga nabuak. Uban niini nga nagbalikbalik nga pamaagi, pipila lamang sa nalista nga mga rekomendasyon ang mahimong igo aron makab-ot ang kalampusan. O mas lawom nga pag-customize mahimong gikinahanglan.
Kanunay pangutan-a ang imong kaugalingon niini nga mga pangutana:
- Pila ka mga kapanguhaan ang gigamit sa mga aplikasyon ug sa unsang paagi mabag-o kini nga kantidad?
- Unsa ang tinuod nga mga kinahanglanon sa scaling? Unsa kadaghan nga trapiko ang madumala sa app sa kasagaran? Unsa ang mahitungod sa peak traffic?
- Unsa ka sagad ang serbisyo kinahanglan nga sukdon? Unsa ka paspas ang bag-ong mga pod kinahanglan nga moandar aron makadawat sa trapiko?
- Unsa ka maayo ang pagsira sa mga pod? Kinahanglan ba gyud kini? Posible ba nga makab-ot ang pag-deploy nga walaβy downtime?
- Giunsa pagminus ang mga peligro sa seguridad ug limitahan ang kadaot gikan sa bisan unsang nakompromiso nga mga pod? Aduna bay mga serbisyo nga adunay pagtugot o pag-access nga wala nila kinahanglana?
Ang Kubernetes naghatag usa ka talagsaon nga plataporma nga nagtugot kanimo sa paggamit sa labing kaayo nga mga gawi aron ma-deploy ang libu-libo nga mga serbisyo sa usa ka cluster. Bisan pa, ang tanan nga mga aplikasyon lahi. Usahay ang pagpatuman nanginahanglan ug gamay nga trabaho.
Maayo na lang, ang Kubernetes naghatag sa gikinahanglan nga mga setting aron makab-ot ang tanang teknikal nga tumong. Pinaagi sa paggamit sa kombinasyon sa mga hangyo ug limitasyon sa kahinguhaan, Liveness ug Readiness probes, init nga mga sudlanan, mga polisiya sa network, ug custom kernel tuning, makab-ot nimo ang taas nga performance uban sa fault tolerance ug paspas nga scalability.
Unsa pa ang basahon:
- .
- .
- .
Source: www.habr.com