Roa taona lasa izay Kubernetes ao amin'ny bilaogy GitHub ofisialy. Nanomboka teo dia lasa teknolojia manara-penitra amin'ny fametrahana serivisy. Kubernetes izao dia mitantana ampahany lehibe amin'ny serivisy anatiny sy ho an'ny daholobe. Rehefa nitombo ny klustery ary nanjary henjana kokoa ny fepetra takian'ny fampandehanana, dia nanomboka nahatsikaritra izahay fa ny tolotra sasany ao amin'ny Kubernetes dia miaina tsindraindray ny fahatarana izay tsy azo hazavaina amin'ny enta-mavesatry ny fampiharana.
Amin'ny ankapobeny, ny fampiharana dia mahatsapa ny fahatarana amin'ny tambajotra toa kisendrasendra hatramin'ny 100ms na mihoatra, ka miteraka fe-potoana na andrana indray. Ny serivisy dia nanantena fa afaka mamaly ny fangatahana haingana kokoa noho ny 100ms. Saingy tsy azo atao izany raha mitaky fotoana be ny fifandraisana. Mitokana, dia nandinika ny fangatahana MySQL tena haingana izay tokony ho nalaina milliseconds, ary ny MySQL dia vita tao anatin'ny milisegogondra, fa avy amin'ny fomba fijery ny fangatahana fangatahana, ny valiny dia 100ms na mihoatra.
Nazava avy hatrany fa rehefa mifandray amin'ny node Kubernetes ihany no nitranga ny olana, na dia avy any ivelan'i Kubernetes aza ny antso. Ny fomba tsotra indrindra hamerenana ny olana dia amin'ny fitsapana , izay mandeha avy amin'ny mpampiantrano anatiny rehetra, mitsapa ny tolotra Kubernetes amin'ny seranana manokana, ary manoratra tsindraindray ny fahatarana ambony. Ato amin'ity lahatsoratra ity dia hojerentsika ny fomba nahafahantsika nanara-maso ny anton'ity olana ity.
Fanafoanana ny fahasarotana tsy ilaina amin'ny rojo mitarika ho amin'ny tsy fahombiazana
Amin'ny alàlan'ny famerenan'ny ohatra iray ihany, dia tiantsika ny hametra ny fifantohan'ny olana ary hanala ireo sosona sarotra tsy ilaina. Tany am-boalohany, be loatra ny singa tao anatin'ny fikorianan'ny Vegeta sy ny pods Kubernetes. Mba hamantarana ny olan'ny tambajotra lalindalina kokoa dia mila manilika ny sasany amin'izy ireo ianao.
Ny mpanjifa (Vegeta) dia mamorona fifandraisana TCP amin'ny node rehetra ao amin'ny cluster. Kubernetes dia miasa amin'ny maha-tambajotra overlay (eo an-tampon'ny tamba-jotra foibe data) izay mampiasa , izany hoe mandrakotra ny fonosana IP an'ny tambajotra overlay ao anatin'ny fonosana IP an'ny foibe data. Rehefa mifandray amin'ny node voalohany dia atao ny fandikana ny adiresin'ny tambajotra (NAT) handikana ny adiresy IP sy ny seranan-tsambon'ny node Kubernetes ho amin'ny adiresy IP sy seranan-tsambo ao amin'ny tambajotra overlay (indrindra indrindra, ny pod misy ny fampiharana). Ho an'ny fonosana miditra dia atao ny filaharan'ny hetsika. Izy io dia rafitra sarotra misy fanjakana maro sy singa maro izay havaozina sy ovaina hatrany rehefa apetraka sy mihetsika ny serivisy.
Utility tcpdump ao amin'ny fitsapana Vegeta dia misy fahatarana mandritra ny fifampiraharahana TCP (eo anelanelan'ny SYN sy SYN-ACK). Mba hanesorana ity fahasarotana tsy ilaina ity dia azonao ampiasaina hping3 ho an'ny "pings" tsotra miaraka amin'ny fonosana SYN. Manamarina isika raha misy fahatarana ao amin'ny fonosana valiny, ary avereno indray ny fifandraisana. Azontsika atao ny manivana ny angon-drakitra mba hampidirana fonosana lehibe kokoa noho ny 100ms fotsiny ary mahazo fomba mora kokoa hamerenana ny olana noho ny andrana feno sosona 7 ao amin'ny Vegeta. Ireto ny "pings" node Kubernetes mampiasa TCP SYN/SYN-ACK amin'ny serivisy "port node" (30927) amin'ny elanelana 10ms, voasivana amin'ny valiny miadana indrindra:
theojulienne@shell ~ $ sudo hping3 172.16.47.27 -S -p 30927 -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}.'
len=46 ip=172.16.47.27 ttl=59 DF id=0 sport=30927 flags=SA seq=1485 win=29200 rtt=127.1 ms
len=46 ip=172.16.47.27 ttl=59 DF id=0 sport=30927 flags=SA seq=1486 win=29200 rtt=117.0 ms
len=46 ip=172.16.47.27 ttl=59 DF id=0 sport=30927 flags=SA seq=1487 win=29200 rtt=106.2 ms
len=46 ip=172.16.47.27 ttl=59 DF id=0 sport=30927 flags=SA seq=1488 win=29200 rtt=104.1 ms
len=46 ip=172.16.47.27 ttl=59 DF id=0 sport=30927 flags=SA seq=5024 win=29200 rtt=109.2 ms
len=46 ip=172.16.47.27 ttl=59 DF id=0 sport=30927 flags=SA seq=5231 win=29200 rtt=109.2 ms
Afaka manao ny fandinihana voalohany avy hatrany. Raha jerena ny laharan’ny filaharana sy ny fotoana dia mazava fa tsy fitohanan’ny fiara indray mandeha ireo. Miangona matetika ny fahatarana ary voakarakara amin'ny farany.
Manaraka izany, tiantsika ho fantatra izay singa mety ho tafiditra amin'ny fitohanana. Angamba ireto ny sasany amin'ireo fitsipika iptables an-jatony ao amin'ny NAT? Sa misy olana amin'ny IPIP tunneling amin'ny tambajotra? Ny fomba iray hitsapana izany dia ny fitsapana ny dingana tsirairay amin'ny rafitra amin'ny alàlan'ny fanafoanana azy. Inona no mitranga raha esorinao ny lojika NAT sy firewall, ka ny ampahany IPIP ihany no sisa:
Soa ihany fa ny Linux dia manamora ny fidirana mivantana amin'ny sosona overlay IP raha toa ka ao amin'ny tambajotra iray ihany ny milina:
theojulienne@kube-node-client ~ $ sudo hping3 10.125.20.64 -S -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}.'
len=40 ip=10.125.20.64 ttl=64 DF id=0 sport=0 flags=RA seq=7346 win=0 rtt=127.3 ms
len=40 ip=10.125.20.64 ttl=64 DF id=0 sport=0 flags=RA seq=7347 win=0 rtt=117.3 ms
len=40 ip=10.125.20.64 ttl=64 DF id=0 sport=0 flags=RA seq=7348 win=0 rtt=107.2 ms
Raha jerena ny vokatra dia mbola mitoetra ny olana! Izany dia tsy ahitana iptables sy NAT. Ka ny olana dia ny TCP? Andao hojerentsika ny fandehan'ny ping ICMP mahazatra:
theojulienne@kube-node-client ~ $ sudo hping3 10.125.20.64 --icmp -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}.'
len=28 ip=10.125.20.64 ttl=64 id=42594 icmp_seq=104 rtt=110.0 ms
len=28 ip=10.125.20.64 ttl=64 id=49448 icmp_seq=4022 rtt=141.3 ms
len=28 ip=10.125.20.64 ttl=64 id=49449 icmp_seq=4023 rtt=131.3 ms
len=28 ip=10.125.20.64 ttl=64 id=49450 icmp_seq=4024 rtt=121.2 ms
len=28 ip=10.125.20.64 ttl=64 id=49451 icmp_seq=4025 rtt=111.2 ms
len=28 ip=10.125.20.64 ttl=64 id=49452 icmp_seq=4026 rtt=101.1 ms
len=28 ip=10.125.20.64 ttl=64 id=50023 icmp_seq=4343 rtt=126.8 ms
len=28 ip=10.125.20.64 ttl=64 id=50024 icmp_seq=4344 rtt=116.8 ms
len=28 ip=10.125.20.64 ttl=64 id=50025 icmp_seq=4345 rtt=106.8 ms
len=28 ip=10.125.20.64 ttl=64 id=59727 icmp_seq=9836 rtt=106.1 ms
Hita tamin’ny vokatra fa tsy nivaha ny olana. Sao dia tonelina IPIP ity? Andao hanatsotra kokoa ny fitsapana:
Moa ve ny fonosana rehetra alefa eo anelanelan'ireo mpampiantrano roa ireo?
theojulienne@kube-node-client ~ $ sudo hping3 172.16.47.27 --icmp -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}.'
len=46 ip=172.16.47.27 ttl=61 id=41127 icmp_seq=12564 rtt=140.9 ms
len=46 ip=172.16.47.27 ttl=61 id=41128 icmp_seq=12565 rtt=130.9 ms
len=46 ip=172.16.47.27 ttl=61 id=41129 icmp_seq=12566 rtt=120.8 ms
len=46 ip=172.16.47.27 ttl=61 id=41130 icmp_seq=12567 rtt=110.8 ms
len=46 ip=172.16.47.27 ttl=61 id=41131 icmp_seq=12568 rtt=100.7 ms
len=46 ip=172.16.47.27 ttl=61 id=9062 icmp_seq=31443 rtt=134.2 ms
len=46 ip=172.16.47.27 ttl=61 id=9063 icmp_seq=31444 rtt=124.2 ms
len=46 ip=172.16.47.27 ttl=61 id=9064 icmp_seq=31445 rtt=114.2 ms
len=46 ip=172.16.47.27 ttl=61 id=9065 icmp_seq=31446 rtt=104.2 ms
Nanatsotra ny toe-javatra izahay tamin'ny node Kubernetes roa mifampizara fonosana, na ping ICMP aza. Mbola mahita fahatarana izy ireo raha "ratsy" ilay mpampiantrano kendrena (ny sasany ratsy noho ny hafa).
Izao ny fanontaniana farany: nahoana no amin'ny mpizara kube-node ihany no misy ny fahatarana? Ary mitranga ve izany rehefa i kube-node no mpandefa na mpandray? Soa ihany fa mora fantarina ihany koa izany amin'ny alàlan'ny fandefasana fonosana avy amin'ny mpampiantrano iray ivelan'ny Kubernetes, saingy miaraka amin'ilay mpandray “fantatra ratsy” mitovy. Araka ny hitanao dia tsy nanjavona ny olana:
theojulienne@shell ~ $ sudo hping3 172.16.47.27 -p 9876 -S -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}.'
len=46 ip=172.16.47.27 ttl=61 DF id=0 sport=9876 flags=RA seq=312 win=0 rtt=108.5 ms
len=46 ip=172.16.47.27 ttl=61 DF id=0 sport=9876 flags=RA seq=5903 win=0 rtt=119.4 ms
len=46 ip=172.16.47.27 ttl=61 DF id=0 sport=9876 flags=RA seq=6227 win=0 rtt=139.9 ms
len=46 ip=172.16.47.27 ttl=61 DF id=0 sport=9876 flags=RA seq=7929 win=0 rtt=131.2 ms
Avy eo dia hanao fangatahana mitovy amin'ny loharano kube-node teo aloha mankany amin'ny mpampiantrano ivelany (izay manilika ny mpampiantrano loharano satria ny ping dia misy singa RX sy TX):
theojulienne@kube-node-client ~ $ sudo hping3 172.16.33.44 -p 9876 -S -i u10000 | egrep --line-buffered 'rtt=[0-9]{3}.'
^C
--- 172.16.33.44 hping statistic ---
22352 packets transmitted, 22350 packets received, 1% packet loss
round-trip min/avg/max = 0.2/7.6/1010.6 ms
Tamin'ny fandinihana ny fisamborana packet latency dia nahazo fampahalalana fanampiny izahay. Indrindra indrindra fa ny mpandefa (ambany) dia mahita an'io fe-potoana io, fa ny mpandray (ambony) tsy - jereo ny tsanganana Delta (ao anatin'ny segondra):
Fanampin'izany, raha jerena ny fahasamihafana eo amin'ny filaharan'ny fonosana TCP sy ICMP (amin'ny laharan'ny sequence) eo amin'ny lafiny mpandray, dia tonga amin'ny filaharana mitovy amin'ny nandefasana azy foana ny fonosana ICMP, saingy amin'ny fotoana samy hafa. Mandritra izany fotoana izany, ny fonosana TCP indraindray dia miditra, ary ny sasany amin'izy ireo dia mijanona. Indrindra indrindra, raha mandinika ny seranan-tsambon'ny fonosana SYN ianao, dia milahatra eo amin'ny sisin'ny mpandefa izy ireo, fa tsy eo amin'ny sisin'ny mpandray.
Misy fahasamihafana kely amin'ny fomba ireo lohamilina maoderina (tahaka ireo ao amin'ny ivon-tsarimihetsika) momba ny fonosana misy TCP na ICMP. Rehefa tonga ny fonosana iray, ny adaptatera tambajotra dia "hash isaky ny fifandraisana", izany hoe manandrana manapaka ny fifandraisana amin'ny filaharana ary mandefa ny filaharana tsirairay amin'ny fototry ny processeur iray. Ho an'ny TCP, ity tenifototra ity dia ahitana ny loharano sy ny adiresy IP ary ny seranana. Amin'ny teny hafa, ny fifandraisana tsirairay dia hash (mety) amin'ny fomba hafa. Ho an'ny ICMP, ny adiresy IP ihany no hashed, satria tsy misy seranana.
Fandinihana vaovao iray hafa: mandritra io vanim-potoana io isika dia mahita fahatarana ny ICMP amin'ny fifandraisana rehetra eo amin'ny mpampiantrano roa, fa ny TCP dia tsy. Izany dia milaza amintsika fa ny antony dia mety mifandray amin'ny RX filaharana hashing: ny fitohanana dia saika azo antoka fa eo amin'ny fanodinana ny RX fonosana, fa tsy amin'ny fandefasana valiny.
Izany dia manafoana ny fandefasana fonosana amin'ny lisitry ny antony mety hitranga. Fantatsika izao fa ny olan'ny fanodinana fonosana dia eo amin'ny lafiny fandraisana amin'ny mpizara kube-node sasany.
Fahatakarana ny fanodinana fonosana amin'ny kernel Linux
Mba hahatakarana ny antony mahatonga ny olana amin'ny mpandray amin'ny mpizara kube-node sasany, andeha hojerentsika ny fomba fiasan'ny kernel Linux.
Miverina amin'ny fampiharana nentim-paharazana tsotra indrindra, ny karatra tambajotra dia mandray ny fonosana ary mandefa ny kernel Linux fa misy fonosana tokony hokarakaraina. Ny kernel dia manakana ny asa hafa, manova ny contexte amin'ny mpandrindra ny interrupt, manodina ny fonosana, ary miverina amin'ny asa ankehitriny.
Miadana ity fifandimbiasana contexte ity: mety tsy ho tsikaritra amin'ny karatra tambajotra 10Mbps tamin'ny taona 90 ny fahatarana, fa amin'ny karatra 10G maoderina misy fonosana 15 tapitrisa isan-tsegondra fara-tampony, ny fototry ny mpizara kely valo dia mety ho tapaka an-tapitrisany. ny fotoana isan-tsegondra.
Mba tsy hifehezana tsy tapaka ny fanelingelenana, taona maro lasa izay no nampian'i Linux : Network API izay ampiasain'ny mpamily maoderina rehetra hanatsarana ny fampandehanana amin'ny hafainganam-pandeha avo. Amin'ny hafainganam-pandeha ambany dia mbola mahazo fahatapahana avy amin'ny karatra tambajotra amin'ny fomba taloha ny kernel. Raha vantany vao tonga ny fonosana ampy izay mihoatra ny tokonam-baravarana, ny kernel dia manakana ny interrupts ary manomboka ny fandatsaham-bato ny adaptatera tambajotra ary manangona fonosana amin'ny ampahany. Ny fanodinana dia atao amin'ny softirq, izany hoe in aorian'ny fiantsoan'ny rafitra sy ny fanakanana fitaovana, rehefa efa mandeha ny kernel (mifanohitra amin'ny habaka mpampiasa).
Haingana kokoa izany, saingy miteraka olana hafa. Raha be loatra ny fonosana, dia lany amin'ny fanodinana fonosana avy amin'ny karatra tambajotra ny fotoana rehetra, ary tsy manam-potoana hanesorana ireo filaharana ireo ny fizotran'ny habaka mpampiasa (mamaky avy amin'ny fifandraisana TCP, sns.). Farany dia feno ny filaharana ary manomboka mandatsaka fonosana izahay. Amin'ny fiezahana hitadiavana fifandanjana, ny kernel dia mametraka teti-bola ho an'ny isan'ny fonosana voahodina ao amin'ny tontolon'ny softirq. Rehefa lany io tetibola io, dia mifoha ny kofehy misaraka ksoftirqd (Ho hitanao ny iray amin'izy ireo ao ps per core) izay mitantana ireo softirqs ivelan'ny lalana syscall/interrupt mahazatra. Ity kofehy ity dia voalahatra amin'ny fampiasana ny fandaharam-potoana mahazatra, izay manandrana mizara ny loharanon-karena ara-drariny.
Rehefa avy nandinika ny fomba fiasan'ny kernel ianao dia ho hitanao fa misy ny mety hisian'ny fitohanana. Raha tsy voaray matetika ny antso softirq, dia tsy maintsy miandry fotoana vitsivitsy ny fonosana mba hokarakaraina ao amin'ny filaharana RX amin'ny karatra tambajotra. Izany dia mety ho noho ny asa sasany manakana ny processeur core, na zavatra hafa misakana ny core tsy hihazakazaka softirq.
Famaritana ny fanodinana mankany amin'ny fototra na fomba
Ny fahatarana Softirq dia vinavina fotsiny amin'izao fotoana izao. Misy dikany anefa izany, ary fantatsika fa mahita zavatra mitovy amin'izany isika. Ka ny dingana manaraka dia ny fanamafisana io teoria io. Ary raha voamarina izany, dia tadiavo ny anton'ny fahatarana.
Andao hiverina amin'ny fonosanay miadana:
len=46 ip=172.16.53.32 ttl=61 id=29573 icmp_seq=1953 rtt=99.3 ms
len=46 ip=172.16.53.32 ttl=61 id=29574 icmp_seq=1954 rtt=89.3 ms
len=46 ip=172.16.53.32 ttl=61 id=29575 icmp_seq=1955 rtt=79.2 ms
len=46 ip=172.16.53.32 ttl=61 id=29576 icmp_seq=1956 rtt=69.1 ms
len=46 ip=172.16.53.32 ttl=61 id=29577 icmp_seq=1957 rtt=59.1 ms
len=46 ip=172.16.53.32 ttl=61 id=29790 icmp_seq=2070 rtt=75.7 ms
len=46 ip=172.16.53.32 ttl=61 id=29791 icmp_seq=2071 rtt=65.6 ms
len=46 ip=172.16.53.32 ttl=61 id=29792 icmp_seq=2072 rtt=55.5 ms
Araka ny efa noresahina teo aloha, ireo fonosana ICMP ireo dia apetraka ao anaty filaharana RX NIC tokana ary karakarain'ny CPU tokana. Raha te-hahatakatra ny fomba fiasan'ny Linux isika, dia ilaina ny mahafantatra hoe aiza (izay ivon'ny CPU) sy ny fomba (softirq, ksoftirqd) no karakaraina ireo fonosana ireo mba hanarahana ny dingana.
Fotoana izao hampiasana fitaovana ahafahanao manara-maso ny kernel Linux amin'ny fotoana tena izy. Eto izahay dia nampiasa . Ity fitaovana ity dia ahafahanao manoratra programa C kely izay mampifandray ireo asa tsy misy dikany ao amin'ny kernel ary mametaka ireo zava-mitranga ao amin'ny programa Python mpampiasa-space izay afaka manodina azy ireo ary mamerina ny valiny aminao. Ny fampifandraisana ireo asa tsy ara-dalàna ao amin'ny kernel dia orinasa sarotra, fa ny fitaovana dia natao ho an'ny fiarovana ambony indrindra ary natao hanara-maso ny karazana olana momba ny famokarana izay tsy mora averina amin'ny tontolo fitsapana na fampandrosoana.
Tsotra ny drafitra eto: fantatray fa ny kernel dia manao ireo pings ICMP ireo, noho izany dia hametraka hook amin'ny asan'ny kernel izahay , izay manaiky fonosana fangatahana akora ICMP miditra ary manomboka mandefa valin-kafatra ICMP. Afaka mamantatra fonosana isika amin'ny fampitomboana ny isa icmp_seq, izay mampiseho hping3 avo kokoa.
fehezan-dalàna toa sarotra, fa tsy mampatahotra araka ny hita. asa icmp_echo no nampitain'i struct sk_buff *skb: Fonosana misy "echo request" ity. Afaka manara-maso azy isika, misintona ny filaharana echo.sequence (izay ampitahaina amin'ny icmp_seq avy hping3 выше), ary alefaso any amin'ny habaka mpampiasa. Tsara ihany koa ny maka ny anarana/id amin'izao fotoana izao. Ireto ambany ireto ny valiny izay hitantsika mivantana rehefa miroso amin'ny fonosana ny kernel:
TGID PID PROCESS ANARANA ICMP_SEQ 0 0 swapper/11 770 0 swapper/0 11 771 swapper/0 0 11 swapper/772 0 0 swapper/11 773 0 prometheus 0 11 774 swapper/20041 20086 775 swapper/0 0 11 swapper/776 0 0 spokes-report-s 11
Marihina eto fa ao anatin’ny contexte softirq Ny fizotry ny antson'ny rafitra dia hiseho ho "processes" raha ny marina dia ny kernel no mandrindra ny fonosana amin'ny tontolon'ny kernel.
Miaraka amin'ity fitaovana ity dia afaka mampifandray ireo dingana manokana amin'ny fonosana manokana izay mampiseho fahatarana ny hping3. Andao hatao tsotra grep amin'ity fisamborana ity ho an'ny soatoavina sasany icmp_seq. Ny fonosana mifanandrify amin'ireo soatoavina icmp_seq etsy ambony dia voamarika miaraka amin'ny RTT izay nojerentsika etsy ambony (ao anaty fononteny ny sanda RTT andrasana ho an'ny fonosana nosivanay noho ny sanda RTT latsaky ny 50ms):
TGID PID PROCESS NAME ICMP_SEQ ** RTT -- 10137 10436 cadvisor 1951 10137 10436 cadvisor 1952 76 76 ksoftirqd/11 1953 ** 99ms 76 76 ksoftirqd/11 1954 ** 89ms 76 76 ksoftirqd/11 1955 ** 79ms 76 76 ksoftirqd/11 1956 ** 69ms 76 76 ksoftirqd/11 1957 ** 59ms 76 76 ksoftirqd/11 1958 ** (49ms) 76 76 ksoftirqd/11 1959 ** (39ms) 76 76 ksoftirqd/11 1960 ** (29ms) 76 76 ksoftirqd/11 1961 ** (19ms) 76 76 ksoftirqd/11 1962 ** (9ms) -- 10137 10436 cadvisor 2068 10137 10436 cadvisor 2069 76 76 ksoftirqd/11 2070 ** 75ms 76 76 ksoftirqd/11 2071 ** 65ms 76 76 ksoftirqd/11 2072 ** 55ms 76 76 ksoftirqd/11 2073 ** (45ms) 76 76 ksoftirqd/11 2074 ** (35ms) 76 76 ksoftirqd/11 2075 ** (25ms) 76 76 ksoftirqd/11 2076 ** (15ms) 76 76 ksoftirqd/11 2077 ** (5ms)
Ny valiny dia milaza amintsika zavatra maromaro. Voalohany, ireo fonosana rehetra ireo dia karakarain'ny contexte ksoftirqd/11. Midika izany fa ho an'ity milina manokana ity, ny fonosana ICMP dia nafindra ho amin'ny fototra 11 amin'ny faran'ny fandraisana. Hitantsika ihany koa fa isaky ny misy ny fitohanan'ny fifamoivoizana dia misy fonosana izay karakaraina ao anatin'ny tontolon'ny antso an-tariby cadvisor. avy eo ksoftirqd mandray an-tanana ny asa ary manao ny filaharana voaangona: ny isan'ny fonosana voaangona taorian'izay cadvisor.
Ny zava-misy fa avy hatrany alohan`ny miasa foana cadvisor, dia midika ny fandraisany anjara amin'ilay olana. Mampihomehy, ny tanjona - "manadihady ny fampiasana loharanon-karena sy ny toetran'ny fampandehanana ny kaontenera mandeha" fa tsy miteraka ity olana ity.
Toy ny amin'ny lafiny hafa amin'ny kaontenera, fitaovana avo lenta avokoa ireo rehetra ireo ary azo antenaina fa hiaina olana amin'ny fampisehoana amin'ny toe-javatra tsy ampoizina.
Inona no ataon'ny cadvisor ka mampiadana ny filaharana fonosana?
Manana fahatakarana tsara isika izao ny fomba nitrangan'ny fianjerana, inona ny dingana mahatonga izany, ary inona ny CPU. Hitantsika fa noho ny fanakanana mafy dia tsy manam-potoana handaminana ny kernel Linux ksoftirqd. Ary hitantsika fa ny fonosana dia voahodina amin'ny contexte cadvisor. Lojika ny fiheverana an’izany cadvisor dia manomboka syscall miadana, aorian'izay ny fonosana rehetra voaangona tamin'io fotoana io dia voahodina:
Théorie io, fa ahoana no hitsapana azy? Ny azontsika atao dia ny manara-maso ny fototry ny CPU mandritra ity dingana ity, tadiavo ny toerana misy ny isan'ny fonosana mihoatra ny teti-bola ary ny ksoftirqd dia antsoina, ary avy eo mijery lavidavitra kokoa hahitana hoe inona marina no mandeha ao amin'ny fototry ny CPU taloha kelin'io teboka io. . Toy ny manao x-ray ny CPU isaky ny milisegondra vitsivitsy. Ho toy izao izany:
Mora, izany rehetra izany dia azo atao amin'ny fitaovana efa misy. Ohatra, manamarina ny fototry ny CPU nomena amin'ny matetika voafaritra ary afaka mamorona fandaharam-potoanan'ny antso amin'ny rafitra mandeha, anisan'izany ny habaka mpampiasa sy ny kernel Linux. Azonao atao ny mandray an'io firaketana io ary manodina azy amin'ny alàlan'ny fika kely amin'ny programa avy amin'i Brendan Gregg, izay mitahiry ny filaharan'ny trace. Afaka mitahiry trace stack andalana tokana isaky ny 1 ms isika, ary manasongadina sy mitahiry santionany 100 milisegondra alohan'ny hidiran'ny trace. ksoftirqd:
# record 999 times a second, or every 1ms with some offset so not to align exactly with timers
sudo perf record -C 11 -g -F 999
# take that recording and make a simpler stack trace.
sudo perf script 2>/dev/null | ./FlameGraph/stackcollapse-perf-ordered.pl | grep ksoftir -B 100
Ireto ny valiny:
(сотни следов, которые выглядят похожими)
cadvisor;[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];entry_SYSCALL_64_after_swapgs;do_syscall_64;sys_read;vfs_read;seq_read;memcg_stat_show;mem_cgroup_nr_lru_pages;mem_cgroup_node_nr_lru_pages cadvisor;[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];entry_SYSCALL_64_after_swapgs;do_syscall_64;sys_read;vfs_read;seq_read;memcg_stat_show;mem_cgroup_nr_lru_pages;mem_cgroup_node_nr_lru_pages cadvisor;[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];entry_SYSCALL_64_after_swapgs;do_syscall_64;sys_read;vfs_read;seq_read;memcg_stat_show;mem_cgroup_iter cadvisor;[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];entry_SYSCALL_64_after_swapgs;do_syscall_64;sys_read;vfs_read;seq_read;memcg_stat_show;mem_cgroup_nr_lru_pages;mem_cgroup_node_nr_lru_pages cadvisor;[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];[cadvisor];entry_SYSCALL_64_after_swapgs;do_syscall_64;sys_read;vfs_read;seq_read;memcg_stat_show;mem_cgroup_nr_lru_pages;mem_cgroup_node_nr_lru_pages ksoftirqd/11;ret_from_fork;kthread;kthread;smpboot_thread_fn;smpboot_thread_fn;run_ksoftirqd;__do_softirq;net_rx_action;ixgbe_poll;ixgbe_clean_rx_irq;napi_gro_receive;netif_receive_skb_internal;inet_gro_receive;bond_handle_frame;__netif_receive_skb_core;ip_rcv_finish;ip_rcv;ip_forward_finish;ip_forward;ip_finish_output;nf_iterate;ip_output;ip_finish_output2;__dev_queue_xmit;dev_hard_start_xmit;ipip_tunnel_xmit;ip_tunnel_xmit;iptunnel_xmit;ip_local_out;dst_output;__ip_local_out;nf_hook_slow;nf_iterate;nf_conntrack_in;generic_packet;ipt_do_table;set_match_v4;ip_set_test;hash_net4_kadt;ixgbe_xmit_frame_ring;swiotlb_dma_mapping_error;hash_net4_test ksoftirqd/11;ret_from_fork;kthread;kthread;smpboot_thread_fn;smpboot_thread_fn;run_ksoftirqd;__do_softirq;net_rx_action;gro_cell_poll;napi_gro_receive;netif_receive_skb_internal;inet_gro_receive;__netif_receive_skb_core;ip_rcv_finish;ip_rcv;ip_forward_finish;ip_forward;ip_finish_output;nf_iterate;ip_output;ip_finish_output2;__dev_queue_xmit;dev_hard_start_xmit;dev_queue_xmit_nit;packet_rcv;tpacket_rcv;sch_direct_xmit;validate_xmit_skb_list;validate_xmit_skb;netif_skb_features;ixgbe_xmit_frame_ring;swiotlb_dma_mapping_error;__dev_queue_xmit;dev_hard_start_xmit;__bpf_prog_run;__bpf_prog_run
Betsaka ny zavatra eto, fa ny tena zava-dehibe dia ny mahita ny lamina "cadvisor alohan'ny ksoftirqd" izay hitantsika teo aloha tao amin'ny ICMP tracer. Inona no dikan'izany?
Ny andalana tsirairay dia trace CPU amin'ny fotoana voafaritra. Ny antso tsirairay midina amin'ny stack amin'ny tsipika iray dia misaraka amin'ny semicolon. Eo afovoan'ny andalana dia hitantsika ny antsoina hoe syscall: read(): .... ;do_syscall_64;sys_read; .... Noho izany ny cadvisor dia mandany fotoana betsaka amin'ny antso an-tariby read()mifandraika amin'ny asa mem_cgroup_* (ambony amin'ny fiantsoana stack/faran'ny andalana).
Sarotra ny mahita amin'ny trace antso izay tena vakiana, ka aleo mihazakazaka strace ary andeha hojerentsika izay ataon'ny cadvisor ary mahita antso an-tariby mihoatra ny 100ms:
theojulienne@kube-node-bad ~ $ sudo strace -p 10137 -T -ff 2>&1 | egrep '<0.[1-9]'
[pid 10436] <... futex resumed> ) = 0 <0.156784>
[pid 10432] <... futex resumed> ) = 0 <0.258285>
[pid 10137] <... futex resumed> ) = 0 <0.678382>
[pid 10384] <... futex resumed> ) = 0 <0.762328>
[pid 10436] <... read resumed> "cache 154234880nrss 507904nrss_h"..., 4096) = 658 <0.179438>
[pid 10384] <... futex resumed> ) = 0 <0.104614>
[pid 10436] <... futex resumed> ) = 0 <0.175936>
[pid 10436] <... read resumed> "cache 0nrss 0nrss_huge 0nmapped_"..., 4096) = 577 <0.228091>
[pid 10427] <... read resumed> "cache 0nrss 0nrss_huge 0nmapped_"..., 4096) = 577 <0.207334>
[pid 10411] <... epoll_ctl resumed> ) = 0 <0.118113>
[pid 10382] <... pselect6 resumed> ) = 0 (Timeout) <0.117717>
[pid 10436] <... read resumed> "cache 154234880nrss 507904nrss_h"..., 4096) = 660 <0.159891>
[pid 10417] <... futex resumed> ) = 0 <0.917495>
[pid 10436] <... futex resumed> ) = 0 <0.208172>
[pid 10417] <... futex resumed> ) = 0 <0.190763>
[pid 10417] <... read resumed> "cache 0nrss 0nrss_huge 0nmapped_"..., 4096) = 576 <0.154442>
Araka ny efa nantenainao dia mahita antso miadana eto izahay read(). Avy amin'ny votoatin'ny asa famakiana sy ny contexte mem_cgroup mazava fa ireo fanamby ireo read() jereo ny rakitra memory.stat, izay mampiseho ny fampiasana fahatsiarovana sy ny fetran'ny cgroup (teknolojia mitoka-monina an'i Docker). Ny fitaovana cadvisor dia manontany ity rakitra ity mba hahazoana fampahalalana momba ny fampiasana loharano ho an'ny kaontenera. Andeha hojerentsika raha ny kernel na cadvisor no manao zavatra tsy nampoizina:
theojulienne@kube-node-bad ~ $ time cat /sys/fs/cgroup/memory/memory.stat >/dev/null
real 0m0.153s
user 0m0.000s
sys 0m0.152s
theojulienne@kube-node-bad ~ $
Ankehitriny dia afaka mamerina ny bug isika ary mahatakatra fa ny kernel Linux dia miatrika patolojia.
Nahoana no miadana be ny asa famakiana?
Amin'ity dingana ity dia mora kokoa ny mahita hafatra avy amin'ny mpampiasa hafa momba ny olana mitovy. Araka ny fantatra, ao amin'ny cadvisor tracker dia voalaza fa io bug io , tsy nisy nahatsikaritra fotsiny fa hita taratra kisendrasendra ao amin'ny tambazotran'ny tambazotra ihany koa ny latency. Tsikaritra tokoa fa ny cadvisor dia mandany fotoana CPU bebe kokoa noho ny nampoizina, saingy tsy nomena lanja loatra izany, satria manana loharano CPU be dia be ny mpizara, ka tsy nodinihina tsara ny olana.
Ny olana dia ny cgroups dia mihevitra ny fampiasana fahatsiarovana ao anatin'ny namespace (container). Rehefa mivoaka ny dingana rehetra amin'ity cgroup ity, dia mamoaka ny cgroup fahatsiarovana i Docker. Na izany aza, ny "fahatsiarovana" dia tsy hoe fahatsiarovana fotsiny. Na dia tsy ampiasaina intsony aza ny fitadidiana ny fizotrany, dia hita fa mbola manendry votoaty voatahiry ny kernel, toy ny dentries sy inodes (directory sy metadata rakitra), izay voatahiry ao amin'ny cgroup fahatsiarovana. Avy amin'ny famaritana ny olana:
zombie cgroups: cgroups izay tsy misy processus ary efa voafafa, nefa mbola misy mémoire natokana (raha ny ahy, avy amin'ny cache dentrique, fa azo atokana amin'ny cache page na tmpfs ihany koa).
Ny fisainan'ny kernel ny pejy rehetra ao amin'ny cache rehefa manafaka ny cgroup dia mety ho miadana be, noho izany dia ny fizotry ny hakamoana no voafantina: andraso mandra-pangatahana indray ireo pejy ireo, ary farany dia esory ny cgroup rehefa tena ilaina ny fahatsiarovana. Hatramin'io fotoana io dia mbola raisina an-tsaina ny cgroup rehefa manangona antontan'isa.
Amin'ny lafiny fampisehoana, nanao sorona ny fitadidiana ho an'ny zava-bita izy ireo: nanafaingana ny fanadiovana voalohany tamin'ny alàlan'ny famelabelarana fahatsiarovana voatahiry. Tsara izany. Rehefa mampiasa ny farany amin'ny fitadidiana cache ny kernel dia voafafa amin'ny farany ny cgroup, ka tsy azo antsoina hoe "leak". Indrisy, ny fampiharana manokana ny fikarohana rafitra memory.stat amin'ity kernel version (4.9) ity, miaraka amin'ny fitadidiana be dia be ao amin'ny servery, dia midika fa mila fotoana ela kokoa ny famerenana ny angon-drakitra voatahiry farany sy ny zombies cgroup.
Hita fa ny sasany amin'ireo nodesy dia nanana zombies cgroup be dia be ka nihoatra ny iray segondra ny famakiana sy ny fahatarana.
Ny vahaolana ho an'ny olan'ny cadvisor dia ny famotsorana avy hatrany ny dentries/inodes cache manerana ny rafitra, izay manafoana avy hatrany ny latency mamaky ary koa ny latency amin'ny tambajotra amin'ny mpampiantrano, satria ny fanadiovana ny cache dia mitodika amin'ny pejin'ny zombie cgroup cache ary afaka ihany koa izy ireo. Tsy vahaolana izany fa manamafy ny anton’ny olana.
Hita fa tamin'ny version kernel vaovao kokoa (4.19+) dia nihatsara ny fampandehanana antso memory.stat, ka ny fifindrana amin'ity kernel ity dia namaha ny olana. Nandritra izany fotoana izany dia nanana fitaovana izahay hamantarana ireo node misy olana ao amin'ny cluster Kubernetes, manondraka azy ireo amim-pahamendrehana ary mamerina azy ireo indray. Nosamborinay ny cluster rehetra, nahita nodes manana latency avo be izahay ary namerina azy ireo. Izany dia nanome anay fotoana hanavaozana ny OS amin'ireo mpizara sisa.
To summarize
Satria nampitsahatra ny fanodinana filaharana RX NIC nandritra ny milisegondra an-jatony ity bibikely ity, dia niteraka fahatarana ambony teo amin'ny fifandraisana fohy sy fahatarana midadasika, toy ny eo anelanelan'ny fangatahana MySQL sy ny fonosana valiny.
Ny fahatakarana sy ny fitazonana ny fahombiazan'ny rafitra fototra indrindra, toy ny Kubernetes, dia tena ilaina amin'ny fahamendrehana sy ny hafainganam-pandehan'ny serivisy rehetra mifototra amin'izy ireo. Ny rafitra rehetra tantananao dia mahazo tombony amin'ny fanatsarana ny fahombiazan'ny Kubernetes.
Source: www.habr.com