Pwynt pwysig yng ngweithrediad systemau gwasgaredig yw trin methiant. Mae Kubernetes yn helpu gyda hyn trwy ddefnyddio rheolwyr sy'n monitro iechyd eich system ac yn ailgychwyn gwasanaethau sydd wedi rhoi'r gorau i weithio. Fodd bynnag, gall Kubernetes atal eich ceisiadau yn rymus i sicrhau iechyd system gyffredinol. Yn y gyfres hon, byddwn yn edrych ar sut y gallwch chi helpu Kubernetes i wneud ei waith yn fwy effeithlon a lleihau amser segur ceisiadau.
Cyn cynwysyddion, roedd y rhan fwyaf o gymwysiadau yn rhedeg ar beiriannau rhithwir neu ffisegol. Pe bai'r rhaglen yn chwalu neu'n rhewi, fe gymerodd amser hir i ganslo'r dasg oedd ar y gweill ac ail-lwytho'r rhaglen. Yn y sefyllfa waethaf, roedd yn rhaid i rywun ddatrys y broblem hon Γ’ llaw yn y nos, ar yr oriau mwyaf amhriodol. Pe bai dim ond 1-2 o beiriannau gweithio yn cyflawni tasg bwysig, roedd aflonyddwch o'r fath yn gwbl annerbyniol.
Felly, yn lle ailgychwyn Γ’ llaw, dechreuon nhw ddefnyddio monitro lefel proses i ailgychwyn y cais yn awtomatig os bydd terfyniad annormal. Os bydd y rhaglen yn methu, mae'r broses fonitro yn dal y cod ymadael ac yn ailgychwyn y gweinydd. Gyda dyfodiad systemau fel Kubernetes, roedd y math hwn o ymateb i fethiannau system wedi'i integreiddio'n syml i'r seilwaith.
Mae Kubernetes yn defnyddio dolen digwyddiad arsylwi-gwahaniaeth-cymryd-gweithredu i sicrhau bod adnoddau'n aros yn iach wrth iddynt deithio o gynwysyddion i'r nodau eu hunain.
Mae hyn yn golygu nad oes angen i chi redeg monitro prosesau Γ’ llaw mwyach. Os bydd adnodd yn methu'r Gwiriad Iechyd, bydd Kubernetes yn darparu un arall yn ei le yn awtomatig. Fodd bynnag, mae Kubernetes yn gwneud llawer mwy na monitro'ch cais am fethiannau yn unig. Gall greu mwy o gopΓ―au o'r rhaglen i redeg ar beiriannau lluosog, diweddaru'r rhaglen, neu redeg fersiynau lluosog o'ch cais ar yr un pryd.
Felly, mae yna lawer o resymau pam y gall Kubernetes derfynu cynhwysydd cwbl iach. Er enghraifft, os ydych chi'n uwchraddio'ch defnydd, bydd Kubernetes yn atal hen godennau'n araf wrth ddechrau rhai newydd. Os byddwch chi'n cau nod, bydd Kubernetes yn rhoi'r gorau i redeg pob cod ar y nod hwnnw. Yn olaf, os bydd nod yn rhedeg allan o adnoddau, bydd Kubernetes yn cau pob cod i ryddhau'r adnoddau hynny.
Felly, mae'n hanfodol bod eich cais yn dod i ben heb fawr o effaith i'r defnyddiwr terfynol ac ychydig iawn o amser adfer. Mae hyn yn golygu, cyn cau, mae'n rhaid iddo arbed yr holl ddata y mae angen ei arbed, cau'r holl gysylltiadau rhwydwaith, cwblhau'r gwaith sy'n weddill, a rheoli tasgau brys eraill.
Yn ymarferol, mae hyn yn golygu bod yn rhaid i'ch cais allu trin y neges SITERM, y signal terfynu proses, sef y signal rhagosodedig ar gyfer y cyfleustodau lladd ar systemau gweithredu Unix. Ar Γ΄l derbyn y neges hon, dylai'r cais gau i lawr.
Unwaith y bydd Kubernetes yn penderfynu terfynu pod, mae nifer o ddigwyddiadau'n digwydd. Edrychwn ar bob cam y mae Kubernetes yn ei gymryd wrth gau cynhwysydd neu god.
Gadewch i ni ddweud ein bod am derfynu un o'r codennau. Ar y pwynt hwn, bydd yn rhoi'r gorau i dderbyn traffig newydd - ni fydd cynwysyddion sy'n rhedeg yn y pod yn cael eu heffeithio, ond bydd yr holl draffig newydd yn cael ei rwystro.
Edrychwn ar y bachyn preStop, sef gorchymyn arbennig neu gais HTTP sy'n cael ei anfon at gynwysyddion mewn pod. Os na fydd eich cais yn cau i lawr yn gywir wrth dderbyn SITERM, gallwch ddefnyddio preStop i gau i lawr yn gywir.
Bydd y rhan fwyaf o raglenni'n gadael yn osgeiddig pan fyddant yn derbyn signal SITERM, ond os ydych chi'n defnyddio cod trydydd parti neu ryw system nad ydych chi'n ei rheoli'n llawn, mae'r bachyn preStop yn ffordd wych o orfodi cau gosgeiddig heb newid y cymhwysiad.
Ar Γ΄l gweithredu'r bachyn hwn, bydd Kubernetes yn anfon signal SITERM i'r cynwysyddion yn y pod, gan roi gwybod iddynt y byddant yn cael eu datgysylltu cyn bo hir. Ar Γ΄l derbyn y signal hwn, bydd eich cod yn symud ymlaen i'r broses cau. Gall y broses hon gynnwys atal unrhyw gysylltiadau hirhoedlog megis cysylltiad cronfa ddata neu ffrwd WebSocket, gan arbed y cyflwr presennol, ac ati.
Hyd yn oed os ydych chi'n defnyddio bachyn preStop, mae'n bwysig iawn gwirio beth yn union sy'n digwydd i'ch cais pan fyddwch chi'n anfon signal SITERM ato, a sut mae'n ymddwyn, fel nad yw digwyddiadau neu newidiadau yng ngweithrediad y system a achosir gan ddiffodd pod yn dod fel syndod i chi.
Ar y pwynt hwn, bydd Kubernetes yn aros am gyfnod penodol o amser, a elwir yn terminationGracePeriodSecond, neu'r cyfnod i gau i lawr yn osgeiddig pan fydd yn derbyn signal SITERM, cyn cymryd camau pellach.
Yn ddiofyn, 30 eiliad yw'r cyfnod hwn. Mae'n bwysig nodi ei fod yn rhedeg ochr yn ochr Γ’'r bachyn preStop a'r signal SITERM. Ni fydd Kubernetes yn aros i'r bachyn preStop a SITERM ddod i ben - os bydd eich cais yn gadael cyn i'r TerminationGracePeriod ddod i ben, bydd Kubernetes yn symud ymlaen ar unwaith i'r cam nesaf. Felly, gwiriwch nad yw gwerth y cyfnod hwn mewn eiliadau yn llai na'r amser sydd ei angen i gau'r pod yn gywir, ac os yw'n fwy na 30s, cynyddwch y cyfnod i'r gwerth a ddymunir yn YAML. Yn yr enghraifft a roddir, y mae yn 60s.
Ac yn olaf, y cam olaf yw os yw cynwysyddion yn dal i redeg ar Γ΄l terminationGracePeriod, byddant yn anfon signal SIGKILL a byddant yn cael eu dileu'n rymus. Ar y pwynt hwn, bydd Kubernetes hefyd yn glanhau'r holl wrthrychau pod eraill.
Mae Kubernetes yn terfynu codennau am lawer o resymau, felly gwnewch yn siΕ΅r bod eich cais yn dod i ben yn osgeiddig beth bynnag i sicrhau gwasanaeth sefydlog.
Rhai hysbysebion π
Diolch am aros gyda ni. Ydych chi'n hoffi ein herthyglau? Eisiau gweld cynnwys mwy diddorol? Cefnogwch ni trwy osod archeb neu argymell i ffrindiau, , analog unigryw o weinyddion lefel mynediad, a ddyfeisiwyd gennym ni ar eich cyfer chi: (ar gael gyda RAID1 a RAID10, hyd at 24 craidd a hyd at 40GB DDR4).
Dell R730xd 2 gwaith yn rhatach yng nghanolfan ddata Equinix Haen IV yn Amsterdam? Dim ond yma yn yr Iseldiroedd! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - o $99! Darllenwch am
Ffynhonnell: hab.com