Mewn disgwyliad Vitaly Khabarov gyfweld Dmitry Stolyarov (), cyfarwyddwr technegol a chyd-sylfaenydd cwmni Flant. Gofynnodd Vitaly i Dmitry am yr hyn y mae Flant yn ei wneud, am Kubernetes, datblygu ecosystemau, cefnogaeth. Buom yn trafod pam fod angen Kubernetes ac a oes ei angen o gwbl. A hefyd am ficrowasanaethau, Amazon AWS, yr ymagwedd “Byddaf yn lwcus” at DevOps, dyfodol Kubernetes ei hun, pam, pryd a sut y bydd yn cymryd drosodd y byd, rhagolygon DevOps a'r hyn y dylai peirianwyr baratoi ar ei gyfer yn y dyfodol disglair ac agos gyda symleiddio a rhwydweithiau niwral.
gwrandewch fel podlediad ar DevOps Deflop - podlediad iaith Rwsieg am DevOps, ac isod mae'r fersiwn testun.
Yma ac isod mae'n gofyn cwestiynau peiriannydd o Express42.
Ynglŷn â "Fflant"
- Helo Dima. Chi yw'r cyfarwyddwr technegol"" a hefyd ei sylfaenydd. Dywedwch wrthym beth mae'r cwmni'n ei wneud a beth ydych chi ynddo?
Dmitry: O'r tu allan mae'n ymddangos fel ni yw'r guys sy'n mynd o gwmpas yn gosod Kubernetes i bawb ac yn gwneud rhywbeth ag ef. Ond nid yw hynny'n wir. Dechreuon ni fel cwmni sy'n delio â Linux, ond ers amser maith ein prif weithgaredd fu gwasanaethu cynhyrchu a phrosiectau un contractwr llwyth uchel. Fel arfer rydym yn adeiladu'r seilwaith cyfan o'r dechrau ac yna'n gyfrifol amdano am amser hir, hir. Felly, y prif waith y mae “Flant” yn ei wneud, y mae'n derbyn arian amdano cymryd cyfrifoldeb a gweithredu cynhyrchu un contractwr.
Rwyf i, fel cyfarwyddwr technegol ac un o sylfaenwyr y cwmni, yn treulio trwy'r dydd a'r nos yn ceisio darganfod sut i gynyddu hygyrchedd cynhyrchu, symleiddio ei weithrediad, gwneud bywyd gweinyddwyr yn haws, a bywyd datblygwyr yn fwy dymunol. .
Am Kubernetes
- Yn ddiweddar rydw i wedi bod yn gweld llawer o adroddiadau o'r Fflint a am Kubernetes. Sut daethoch chi iddo?
Dmitry: Dw i wedi siarad am hyn sawl gwaith yn barod, ond does dim ots gen i ei ailadrodd o gwbl. Rwy’n meddwl ei bod yn iawn ailadrodd y pwnc hwn oherwydd bod dryswch rhwng achos ac effaith.
Roedd gwir angen teclyn arnom. Fe wnaethon ni wynebu llawer o broblemau, cael trafferth, eu goresgyn â baglau amrywiol a theimlo'r angen am declyn. Aethom trwy lawer o wahanol opsiynau, adeiladu ein beiciau ein hunain, a chael profiad. Yn raddol fe gyrhaeddon ni'r pwynt lle dechreuon ni ddefnyddio Docker bron cyn gynted ag yr ymddangosodd - tua 2013. Ar adeg ei ymddangosiad, roedd gennym eisoes lawer o brofiad gyda chynwysyddion, roeddem eisoes wedi ysgrifennu analog o “Docker” - rhai o'n baglau ein hunain yn Python. Gyda dyfodiad Docker, daeth yn bosibl taflu'r baglau allan a defnyddio datrysiad dibynadwy a gefnogir gan y gymuned.
Gyda Kubernetes mae'r stori'n debyg. Erbyn iddi ddechrau ennill momentwm - i ni dyma fersiwn 1.2 - roedd gennym eisoes griw o faglau ar Shell a Chef, y gwnaethom geisio eu trefnu gyda Docker rywsut. Roeddem yn edrych o ddifrif tuag at Rancher ac amrywiol atebion eraill, ond yna ymddangosodd Kubernetes, lle mae popeth yn cael ei weithredu yn union fel y byddem wedi'i wneud neu hyd yn oed yn well. Nid oes dim i gwyno yn ei gylch.
Oes, mae yna ryw fath o amherffeithrwydd yma, mae yna ryw fath o amherffeithrwydd yno - mae yna lawer o amherffeithrwydd, ac mae 1.2 yn gyffredinol yn ofnadwy, ond... Mae Kubernetes fel adeilad sy'n cael ei adeiladu - rydych chi'n edrych ar y prosiect ac yn deall y bydd yn cwl. Os oes gan yr adeilad sylfaen a dau lawr bellach, yna rydych chi'n deall ei bod yn well peidio â symud i mewn eto, ond nid oes unrhyw broblemau o'r fath gyda'r meddalwedd - gallwch chi ei ddefnyddio eisoes.
Nid oedd gennym eiliad pan wnaethom feddwl am ddefnyddio Kubernetes ai peidio. Roeddem yn aros amdano ymhell cyn iddo ymddangos, ac yn ceisio creu analogau ein hunain.
Am Kubernetes
— A ydych chi'n ymwneud yn uniongyrchol â datblygu Kubernetes ei hun?
Dmitry: canolig. Yn hytrach, rydym yn cymryd rhan yn natblygiad yr ecosystem. Rydym yn anfon nifer benodol o geisiadau tynnu: i Prometheus, at weithredwyr amrywiol, i Helm - i'r ecosystem. Yn anffodus, ni allaf gadw golwg ar bopeth a wnawn a gallwn fod yn anghywir, ond nid oes un pwll gennym ni i mewn i'r craidd.
- Ar yr un pryd, a ydych chi'n datblygu llawer o'ch offer o amgylch Kubernetes?
Dmitry: Dyma'r strategaeth: awn a thynnu ceisiadau at bopeth sy'n bodoli eisoes. Os na fydd ceisiadau tynnu'n cael eu derbyn yno, rydyn ni'n syml yn eu fforchio ein hunain ac yn byw nes eu bod yn cael eu derbyn gyda'n hadeiladau. Yna, pan fydd yn cyrraedd yr afon i fyny, rydym yn mynd yn ôl i'r fersiwn i fyny'r afon.
Er enghraifft, mae gennym ni weithredwr Prometheus, a buom yn newid yn ôl ac ymlaen i'r rhan i fyny'r afon o'n cynulliad 5 gwaith eisoes yn ôl pob tebyg. Mae angen rhyw fath o nodwedd arnom, fe wnaethom anfon cais tynnu, mae angen i ni ei gyflwyno yfory, ond nid ydym am aros iddo gael ei ryddhau i fyny'r afon. Yn unol â hynny, rydym yn ymgynnull i ni ein hunain, yn cyflwyno ein cynulliad gyda'n nodwedd, y mae arnom ei angen am ryw reswm, i'n holl glystyrau. Yna, er enghraifft, maen nhw'n ei droi drosodd i ni yn yr afon gyda'r geiriau: “Bois, gadewch i ni ei wneud ar gyfer achos mwy cyffredinol,” rydyn ni, neu rywun arall, yn ei orffen, a thros amser mae'n uno yn ôl eto.
Rydym yn ceisio datblygu popeth sy'n bodoli. Mae llawer o elfennau nad ydynt yn bodoli eto, nad ydynt wedi'u dyfeisio eto, neu wedi'u dyfeisio, ond nad ydynt wedi cael amser i'w rhoi ar waith - rydym yn ei wneud. Ac nid oherwydd ein bod yn hoffi'r broses neu adeiladu beiciau fel diwydiant, ond yn syml oherwydd bod angen yr offeryn hwn arnom. Gofynnir y cwestiwn yn aml, pam y gwnaethom hyn neu'r peth hwnnw? Mae'r ateb yn syml - ie, oherwydd roedd yn rhaid inni fynd ymhellach, datrys rhywfaint o broblem ymarferol, a gwnaethom ei datrys gyda'r twla hwn.
Mae’r llwybr bob amser fel hyn: rydym yn chwilio’n ofalus iawn ac, os nad ydym yn dod o hyd i unrhyw ateb ar sut i wneud trolïau allan o dorth o fara, yna rydym yn gwneud ein torth ein hunain a’n trolïau ein hunain.
Offer Fanta
— Gwn fod gan Flant bellach weithredwyr addon, gweithredwyr cregyn, ac offer dap/werf. Fel y deallaf, yr un offeryn yw hwn mewn gwahanol ymgnawdoliadau. Rwyf hefyd yn deall bod llawer mwy o offer gwahanol o fewn Flaunt. Mae hyn yn wir?
Dmitry: Mae gennym ni lawer mwy ar GitHub. O’r hyn rwy’n ei gofio nawr, mae gennym ni fap statws – panel ar gyfer Grafana y mae pawb wedi dod ar ei draws. Fe'i crybwyllir ym mron pob ail erthygl am fonitro Kubernetes ar Ganolig. Mae'n amhosibl esbonio'n fyr beth yw map statws - mae angen erthygl ar wahân, ond mae'n beth defnyddiol iawn ar gyfer monitro statws dros amser, oherwydd yn Kubernetes yn aml mae angen i ni ddangos statws dros amser. Mae gennym hefyd LogHouse - mae hwn yn beth sy'n seiliedig ar ClickHouse a hud du ar gyfer casglu boncyffion yn Kubernetes.
Llawer o gyfleustodau! A bydd hyd yn oed mwy, oherwydd bydd nifer o atebion mewnol yn cael eu rhyddhau eleni. O'r rhai mawr iawn yn seiliedig ar y gweithredwr addon, mae yna griw o ategion ar gyfer Kubernetes, a sut i osod rheolwr sert yn iawn - offeryn ar gyfer rheoli tystysgrifau, sut i osod Prometheus yn gywir gyda chriw o ategolion - mae'r rhain tua ugain yn wahanol deuaidd sy'n allforio data ac yn casglu rhywbeth, i'r Prometheus hwn sydd â'r graffeg a'r rhybuddion mwyaf anhygoel. Dim ond criw o ategion i Kubernetes yw hyn i gyd, sy'n cael eu gosod mewn clwstwr, ac mae'n troi o fod yn syml i oer, soffistigedig, awtomatig, lle mae llawer o faterion eisoes wedi'u datrys. Ydym, rydym yn gwneud llawer.
Datblygu ecosystem
“Mae’n ymddangos i mi fod hwn yn gyfraniad mawr iawn i ddatblygiad yr offeryn hwn a’i ddulliau o’i ddefnyddio.” A allwch chi amcangyfrif yn fras pwy arall fyddai’n gwneud yr un cyfraniad at ddatblygiad yr ecosystem?
Dmitry: Yn Rwsia, o'r cwmnïau sy'n gweithredu yn ein marchnad, nid oes neb hyd yn oed yn agos. Wrth gwrs, mae hwn yn ddatganiad uchel, oherwydd mae yna chwaraewyr mawr fel Mail a Yandex - maen nhw hefyd yn gwneud rhywbeth gyda Kubernetes, ond hyd yn oed nid ydyn nhw'n dod yn agos at gyfraniad cwmnïau yn y byd i gyd sy'n gwneud llawer mwy na ni. Mae'n anodd cymharu Flant, sydd â staff o 80 o bobl, a Red Hat, sydd â 300 o beirianwyr fesul Kubernetes yn unig, os nad wyf yn camgymryd. Mae'n anodd cymharu. Mae gennym ni 6 o bobl yn yr adran RnD, gan gynnwys fi, sy'n torri ein holl offer. 6 o bobl yn erbyn 300 o beirianwyr Red Hat - mae'n anodd cymharu rhywsut.
- Fodd bynnag, pan fydd hyd yn oed y 6 o bobl hyn yn gallu gwneud rhywbeth defnyddiol iawn a dieithrio, pan fyddant yn wynebu problem ymarferol ac yn rhoi'r ateb i'r gymuned - achos diddorol. Deallaf, mewn cwmnïau technoleg mawr, lle mae ganddynt eu tîm datblygu a chymorth Kubernetes eu hunain, mewn egwyddor, y gellir datblygu'r un offer. Mae hyn yn enghraifft iddynt o'r hyn y gellir ei ddatblygu a'i roi i'r gymuned, gan roi hwb i'r gymuned gyfan sy'n defnyddio Kubernetes.
Dmitry: Mae'n debyg bod hyn yn nodwedd o'r integreiddiwr, ei hynodrwydd. Mae gennym lawer o brosiectau ac rydym yn gweld llawer o wahanol sefyllfaoedd. I ni, y brif ffordd o greu gwerth ychwanegol yw dadansoddi'r achosion hyn, dod o hyd i gyffredinedd a'u gwneud mor rhad â phosibl i ni. Rydym wrthi’n gweithio ar hyn. Mae'n anodd i mi siarad am Rwsia a'r byd, ond mae gennym ni tua 40 o beirianwyr DevOps yn y cwmni sy'n gweithio ar Kubernetes. Nid wyf yn credu bod yna lawer o gwmnïau yn Rwsia gyda nifer tebyg o arbenigwyr sy'n deall Kubernetes, os o gwbl.
Rwy'n deall popeth am deitl swydd peiriannydd DevOps, mae pawb yn deall popeth ac wedi arfer galw peirianwyr DevOps yn beirianwyr DevOps, ni fyddwn yn trafod hyn. Mae'r holl beirianwyr 40 DevOps anhygoel hyn yn wynebu ac yn datrys problemau bob dydd, rydyn ni'n dadansoddi'r profiad hwn ac yn ceisio cyffredinoli. Rydym yn deall, os bydd yn aros y tu mewn i ni, yna mewn blwyddyn neu ddwy bydd yr offeryn yn ddiwerth, oherwydd yn rhywle yn y gymuned bydd Tula parod yn ymddangos. Nid oes diben cronni'r profiad hwn yn fewnol - yn syml, mae'n draenio egni ac amser i dev/null. Ac nid ydym yn teimlo trueni amdano o gwbl. Rydyn ni'n cyhoeddi popeth gyda phleser mawr ac yn deall bod angen ei gyhoeddi, ei ddatblygu, ei hyrwyddo, ei hyrwyddo, fel bod pobl yn ei ddefnyddio ac yn ychwanegu eu profiad - yna mae popeth yn tyfu ac yn byw. Yna ar ôl dwy flynedd nid yw'r offeryn yn mynd i'r sbwriel. Nid yw'n drueni parhau i arllwys cryfder, oherwydd mae'n amlwg bod rhywun yn defnyddio'ch teclyn, ac ar ôl dwy flynedd mae pawb yn ei ddefnyddio.
Mae hyn yn rhan o'n strategaeth fawr gyda dapp/werf. Nid wyf yn cofio pan ddechreuon ni ei wneud, mae'n ymddangos fel 3 blynedd yn ôl. I ddechrau, roedd yn gyffredinol ar y gragen. Roedd yn brawf gwych o gysyniad, fe wnaethom ddatrys rhai o'n problemau penodol - fe weithiodd! Ond mae yna broblemau gyda'r gragen, mae'n amhosibl ei ehangu ymhellach, mae rhaglennu ar y gragen yn dasg arall. Roedd gennym ni arferiad o ysgrifennu yn Ruby, yn unol â hynny, fe wnaethon ni ail-wneud rhywbeth yn Ruby, datblygu, datblygu, datblygu, a rhedeg i mewn i'r ffaith bod y gymuned, y dorf nad yw'n dweud “rydym ei eisiau neu nid ydym ei eisiau, ” yn troi ei drwyn i fyny at Ruby, pa mor ddoniol yw hynny? Fe wnaethon ni sylweddoli y dylem ni ysgrifennu'r holl bethau hyn yn Go dim ond i gwrdd â'r pwynt cyntaf ar y rhestr wirio: Dylai offeryn DevOps fod yn ddeuaidd statig. Nid yw mynd neu beidio mor bwysig, ond mae deuaidd statig wedi'i ysgrifennu yn Go yn well.
Fe wnaethon ni wario ein hegni, ailysgrifennu'r dapp yn Go a'i alw'n werf. Nid yw'r Dapp bellach yn cael ei gefnogi, heb ei ddatblygu, yn rhedeg mewn rhai fersiwn ddiweddaraf, ond mae llwybr uwchraddio absoliwt i'r brig, a gallwch ei ddilyn.
Pam cafodd y dapp ei greu?
— A allwch chi ddweud wrthym yn gryno pam y crëwyd y dapp, pa broblemau y mae'n eu datrys?
Dmitry: Y rheswm cyntaf sydd yn y gymanfa. I ddechrau, cawsom broblemau difrifol gyda'r adeiladu pan nad oedd gan Docker alluoedd aml-gam, felly gwnaethom aml-gam ar ein pennau ein hunain. Yna cawsom lawer mwy o broblemau gyda glanhau'r ddelwedd. Mae pawb sy'n gwneud CI / CD, yn gynt yn hytrach nag yn hwyrach, yn wynebu'r broblem bod yna griw o ddelweddau wedi'u casglu, mae angen i chi rywsut lanhau'r hyn nad oes ei angen a gadael yr hyn sydd ei angen.
Yr ail reswm yw lleoli. Oes, mae Helm, ond dim ond rhai o'r problemau y mae'n eu datrys. Yn ddigon hwyliog, ysgrifennwyd mai “Helm yw Rheolwr Pecyn Kubernetes.” Yn union beth “y”. Mae yna hefyd y geiriau “Rheolwr Pecyn” – beth yw’r disgwyliad arferol gan Reolwr Pecynnau? Rydyn ni'n dweud: "Rheolwr Pecyn - gosodwch y pecyn!" ac rydym yn disgwyl iddo ddweud wrthym: “Mae'r pecyn wedi'i gyflwyno.”
Mae'n ddiddorol ein bod ni'n dweud: “Helm, gosodwch y pecyn,” a phan fydd yn ateb ei fod wedi ei osod, mae'n ymddangos ei fod newydd ddechrau'r gosodiad - nododd Kubernetes: “Lansio'r peth hwn!”, ac a ddechreuodd ai peidio , p'un a yw'n gweithio ai peidio , nid yw Helm yn datrys y mater hwn o gwbl.
Mae'n ymddangos mai dim ond rhagbrosesydd testun yw Helm sy'n llwytho data i Kubernetes.
Ond fel rhan o unrhyw ddefnydd, rydym am wybod a yw'r cais wedi'i ryddhau i'w gynhyrchu ai peidio? Mae cyflwyno i prod yn golygu bod y cais wedi symud yno, mae'r fersiwn newydd wedi'i ddefnyddio, ac o leiaf nid yw'n chwalu yno ac yn ymateb yn gywir. Nid yw Helm yn datrys y broblem hon mewn unrhyw ffordd. Er mwyn ei ddatrys, mae angen i chi dreulio llawer o ymdrech, oherwydd mae angen i chi roi'r gorchymyn i Kubernetes gyflwyno a monitro'r hyn sy'n digwydd yno - p'un a yw'n cael ei ddefnyddio neu ei gyflwyno. Ac mae yna hefyd lawer o dasgau sy'n ymwneud â lleoli, glanhau a chydosod.
Cynlluniau
Eleni byddwn yn dechrau datblygu lleol. Rydyn ni eisiau cyflawni'r hyn a oedd yn Vagrant yn flaenorol - fe wnaethon ni deipio “crwydrol” a defnyddio peiriannau rhithwir. Rydyn ni am gyrraedd y pwynt lle mae prosiect yn Git, rydyn ni'n ysgrifennu “werf up” yno, ac mae'n dod â chopi lleol o'r prosiect hwn i fyny, wedi'i leoli mewn mini-Kub lleol, gyda'r holl gyfeirlyfrau sy'n gyfleus i'w datblygu yn gysylltiedig. . Yn dibynnu ar yr iaith ddatblygu, gwneir hyn yn wahanol, ond serch hynny, fel y gellir cynnal datblygiad lleol yn gyfleus o dan ffeiliau wedi'u gosod.
Y cam nesaf i ni yw buddsoddi mewn cyfleustra i ddatblygwyr. I ddefnyddio prosiect yn lleol yn gyflym gydag un offeryn, ei ddatblygu, ei wthio i mewn i Git, a bydd hefyd yn cael ei gyflwyno i lwyfan neu brofion, yn dibynnu ar y piblinellau, ac yna'n defnyddio'r un offeryn i fynd i gynhyrchu. Mae'r undod hwn, yr uno, ac atgynhyrchu seilwaith o'r amgylchedd lleol i werthiant yn bwynt pwysig iawn i ni. Ond nid yw hyn mewn werf eto - dim ond cynllunio yr ydym yn ei wneud.
Ond mae'r llwybr i dapp/werf bob amser wedi bod yr un peth â Kubernetes ar y dechrau. Daethom ar draws problemau, eu datrys gyda datrysiadau - daethom o hyd i rai atebion i ni ein hunain ar y gragen, ar unrhyw beth. Yna fe wnaethon nhw geisio sythu'r atebion hyn rywsut, eu cyffredinoli a'u cyfuno'n ddeuaidd yn yr achos hwn, yr ydym yn ei rannu'n syml.
Mae ffordd arall i edrych ar y stori gyfan hon, gyda chyfatebiaethau.
Mae Kubernetes yn ffrâm car gydag injan. Does dim drysau, gwydr, radio, coeden Nadolig - dim byd o gwbl. Dim ond y ffrâm a'r injan. Ac mae Helm - dyma'r llyw. Cŵl - mae olwyn lywio, ond mae angen pin llywio, rac llywio, blwch gêr ac olwynion hefyd, ac ni allwch wneud hebddynt.
Yn achos werff, mae hon yn gydran arall i Kubernetes. Dim ond nawr yn y fersiwn alffa o werff, er enghraifft, mae Helm yn cael ei lunio y tu mewn i werff, oherwydd rydyn ni wedi blino gwneud hynny ein hunain. Mae yna lawer o resymau dros wneud hyn, dywedaf wrthych yn fanwl pam y gwnaethom lunio'r llyw cyfan ynghyd â tiller y tu mewn i werff .
Nawr mae werff yn gydran fwy integredig. Rydyn ni'n cael olwyn lywio orffenedig, pin llywio - dydw i ddim yn dda iawn gyda cheir, ond mae hwn yn floc mawr sydd eisoes yn datrys ystod eithaf eang o broblemau. Nid oes angen i ni fynd trwy'r catalog ein hunain, dewis un rhan ar gyfer y llall, meddwl sut i'w sgriwio gyda'i gilydd. Rydyn ni'n cael cyfuniad parod sy'n datrys nifer fawr o broblemau ar unwaith. Ond mae tu mewn iddo wedi'i adeiladu o'r un cydrannau ffynhonnell agored, mae'n dal i ddefnyddio Docker ar gyfer cydosod, Helm ar gyfer rhai o'r swyddogaethau, ac mae yna sawl llyfrgell arall. Offeryn integredig yw hwn i gael CI / CD oer allan o'r blwch yn gyflym ac yn gyfleus.
A yw Kubernetes yn anodd ei gynnal?
- Rydych chi'n siarad am y profiad y gwnaethoch chi ddechrau defnyddio Kubernetes, mae hon yn ffrâm i chi, injan, ac y gallwch chi hongian llawer o wahanol bethau arno: corff, llyw, sgriw ar bedalau, seddi. Mae'r cwestiwn yn codi - pa mor anodd yw cefnogaeth Kubernetes i chi? Mae gennych chi lawer o brofiad, faint o amser ac adnoddau ydych chi'n ei wario ar gefnogi Kubernetes ar wahân i bopeth arall?
Dmitry: Mae hwn yn gwestiwn anodd iawn ac i'w ateb, mae angen i ni ddeall beth yw cefnogaeth a beth rydym ei eisiau gan Kubernetes. Efallai y gallwch chi ddatgelu?
- Hyd y gwn ac fel y gwelaf, nawr mae llawer o dimau eisiau rhoi cynnig ar Kubernetes. Mae pawb yn harneisio eu hunain iddo, yn ei roi ar eu gliniau. Mae gen i deimlad nad yw pobl bob amser yn deall cymhlethdod y system hon.
Dmitry: Mae fel yna.
— Pa mor anodd yw hi i gymryd a gosod Kubernetes o'r dechrau fel ei fod yn barod i gynhyrchu?
Dmitry: Pa mor anodd ydych chi'n meddwl yw trawsblannu calon? Deallaf fod hwn yn gwestiwn cyfaddawdu. Nid yw defnyddio sgalpel a pheidio â gwneud camgymeriad mor anodd â hynny. Os ydynt yn dweud wrthych ble i dorri a ble i wnio, yna nid yw'r weithdrefn ei hun yn gymhleth. Mae'n anodd gwarantu dro ar ôl tro y bydd popeth yn gweithio allan.
Mae'n hawdd gosod Kubernetes a'i gael i weithio: cyw! - Wedi'i osod, mae yna lawer o ddulliau gosod. Ond beth sy'n digwydd pan fydd problemau'n codi?
Mae cwestiynau'n codi bob amser - beth nad ydym wedi'i gymryd i ystyriaeth eto? Beth nad ydym wedi'i wneud eto? Pa baramedrau cnewyllyn Linux a nodwyd yn anghywir? Arglwydd, wnaethon ni hyd yn oed sôn amdanyn nhw?! Pa gydrannau Kubernetes rydyn ni wedi'u darparu a pha rai nad ydyn ni wedi'u darparu? Mae miloedd o gwestiynau yn codi, ac i'w hateb, mae angen i chi dreulio 15-20 mlynedd yn y diwydiant hwn.
Mae gennyf enghraifft ddiweddar ar y pwnc hwn a allai ddatgelu ystyr y broblem “A yw Kubernetes yn anodd ei chynnal?” Beth amser yn ôl buom yn ystyried o ddifrif a ddylem geisio gweithredu Cilium fel rhwydwaith yn Kubernetes.
Gadewch imi egluro beth yw Cilium. Mae gan Kubernetes lawer o wahanol weithrediadau o'r is-system rwydweithio, ac mae un ohonynt yn cŵl iawn - Cilium. Beth yw ei ystyr? Yn y cnewyllyn, beth amser yn ôl daeth yn bosibl ysgrifennu bachau ar gyfer y cnewyllyn, sydd mewn rhyw ffordd neu'i gilydd yn ymosod ar is-system y rhwydwaith ac amrywiol is-systemau eraill, ac yn caniatáu ichi osgoi darnau mawr yn y cnewyllyn.
Yn hanesyddol mae gan y cnewyllyn Linux rout ip, gor-hidlo, pontydd a llawer o wahanol hen gydrannau sy'n 15, 20, 30 oed. Yn gyffredinol, maen nhw'n gweithio, mae popeth yn wych, ond nawr maen nhw wedi pentyrru cynwysyddion, ac mae'n edrych fel twr o 15 o frics ar ben ei gilydd, ac rydych chi'n sefyll arno ar un goes - teimlad rhyfedd. Mae'r system hon wedi datblygu'n hanesyddol gyda llawer o arlliwiau, fel yr atodiad yn y corff. Mewn rhai sefyllfaoedd mae problemau perfformiad, er enghraifft.
Mae BPF gwych a'r gallu i ysgrifennu bachau ar gyfer y cnewyllyn - ysgrifennodd y bois eu bachau eu hunain ar gyfer y cnewyllyn. Daw'r pecyn i mewn i'r cnewyllyn Linux, maen nhw'n ei dynnu allan yn syth wrth y mewnbwn, yn ei brosesu eu hunain fel y dylai heb bontydd, heb TCP, heb stac IP - yn fyr, gan osgoi popeth sydd wedi'i ysgrifennu yn y cnewyllyn Linux, ac yna poeri allan i'r cynhwysydd.
Beth ddigwyddodd? Perfformiad cŵl iawn, nodweddion cŵl - dim ond cŵl! Ond edrychwn ar hyn a gweld bod rhaglen ar bob peiriant sy'n cysylltu ag API Kubernetes ac, yn seiliedig ar y data y mae'n ei dderbyn o'r API hwn, yn cynhyrchu cod C ac yn llunio deuaidd y mae'n ei lwytho i'r cnewyllyn fel bod y bachau hyn yn gweithio yn y gofod cnewyllyn.
Beth sy'n digwydd os aiff rhywbeth o'i le? Nid ydym yn gwybod. I ddeall hyn, mae angen i chi ddarllen yr holl god hwn, deall yr holl resymeg, ac mae'n anhygoel pa mor anodd ydyw. Ond, ar y llaw arall, mae yna bontydd, ffilterau rhwyd, ip rout - nid wyf wedi darllen eu cod ffynhonnell, ac nid oes gennyf ychwaith y 40 peiriannydd sy'n gweithio yn ein cwmni. Efallai mai dim ond ychydig sy'n deall rhai rhannau.
A beth yw'r gwahaniaeth? Mae'n ymddangos bod yna ip rout, y cnewyllyn Linux, ac mae yna declyn newydd - pa wahaniaeth mae'n ei wneud, nid ydym yn deall y naill na'r llall. Ond rydym yn ofni defnyddio rhywbeth newydd - pam? Oherwydd os yw'r offeryn yn 30 mlwydd oed, yna mewn 30 mlynedd mae'r holl fygiau wedi'u darganfod, mae'r holl gamgymeriadau wedi'u camu ymlaen ac nid oes angen i chi wybod am bopeth - mae'n gweithio fel blwch du ac mae bob amser yn gweithio. Mae pawb yn gwybod pa sgriwdreifer diagnostig i lynu ym mha le, pa tcpdump i redeg ar ba funud. Mae pawb yn gwybod yn dda am gyfleustodau diagnostig ac yn deall sut mae'r set hon o gydrannau'n gweithio yn y cnewyllyn Linux - nid sut mae'n gweithio, ond sut i'w ddefnyddio.
Ac nid yw'r Cilium hynod o cŵl yn 30 oed, nid yw wedi heneiddio eto. Mae gan Kubernetes yr un broblem, copi. Bod Cilium wedi'i osod yn berffaith, bod Kubernetes wedi'i osod yn berffaith, ond pan fydd rhywbeth yn mynd o'i le wrth gynhyrchu, a allwch chi ddeall yn gyflym mewn sefyllfa dyngedfennol beth aeth o'i le?
Pan ddywedwn a yw'n anodd cynnal Kubernetes - na, mae'n hawdd iawn, ac ydy, mae'n anhygoel o anodd. Mae Kubernetes yn gweithio'n wych ar ei ben ei hun, ond gyda biliwn o arlliwiau.
Ynglŷn â'r dull “Byddaf yn ffodus”.
- A oes yna gwmnïau lle mae'r arlliwiau hyn bron yn sicr o ymddangos? Tybiwch fod Yandex yn trosglwyddo'r holl wasanaethau i Kubernetes yn sydyn, bydd llwyth enfawr yno.
Dmitry: Na, nid sgwrs am y llwyth yw hon, ond am y pethau symlaf. Er enghraifft, mae gennym Kubernetes, rydym wedi defnyddio'r cais yno. Sut ydych chi'n gwybod ei fod yn gweithio? Yn syml, nid oes offeryn parod i ddeall nad yw'r rhaglen yn chwalu. Nid oes system barod sy'n anfon rhybuddion; mae angen i chi ffurfweddu'r rhybuddion hyn a phob amserlen. Ac rydym yn diweddaru Kubernetes.
Mae gen i Ubuntu 16.04. Gallwch ddweud bod hwn yn fersiwn hen, ond rydym yn dal arno oherwydd ei fod yn LTS. Mae systemd, a'r naws yw nad yw'n glanhau grwpiau C. Mae Kubernetes yn lansio codennau, yn creu grwpiau C, yna'n dileu codennau, a rhywsut mae'n troi allan - dydw i ddim yn cofio'r manylion, mae'n ddrwg gennyf - bod sleisys systemd yn aros. Mae hyn yn arwain at y ffaith, dros amser, bod unrhyw gar yn dechrau arafu'n gryf. Nid yw hwn hyd yn oed yn gwestiwn am lwyth uchel. Os caiff codennau parhaol eu lansio, er enghraifft, os oes Cron Job sy'n cynhyrchu codennau'n gyson, yna bydd y peiriant gyda Ubuntu 16.04 yn dechrau arafu ar ôl wythnos. Bydd cyfartaledd llwyth cyson uchel oherwydd y ffaith bod criw o grwpiau C wedi'u creu. Dyma'r broblem y bydd unrhyw berson sy'n gosod Ubuntu 16 a Kubernetes ar ei ben yn ei hwynebu.
Gadewch i ni ddweud ei fod rywsut yn diweddaru systemd neu rywbeth arall, ond yn y cnewyllyn Linux hyd at 4.16 mae hyd yn oed yn fwy doniol - pan fyddwch chi'n dileu grwpiau C, maen nhw'n gollwng yn y cnewyllyn ac nid ydyn nhw'n cael eu dileu mewn gwirionedd. Felly, ar ôl mis o weithio ar y peiriant hwn, bydd yn amhosibl edrych ar yr ystadegau cof ar gyfer yr aelwydydd. Rydyn ni'n cymryd ffeil allan, yn ei rolio yn y rhaglen, ac mae un ffeil yn rholio am 15 eiliad, oherwydd mae'r cnewyllyn yn cymryd amser hir iawn i gyfrif miliwn o grwpiau C ynddo'i hun, sy'n ymddangos yn cael ei ddileu, ond na - maen nhw'n gollwng .
Mae yna lawer o bethau bach o'r fath o hyd yma ac acw. Nid yw hwn yn fater y gall cwmnïau anferth ei wynebu weithiau o dan lwythi trwm iawn - na, mater o bethau bob dydd ydyw. Gall pobl fyw fel hyn am fisoedd - fe wnaethon nhw osod Kubernetes, defnyddio'r cymhwysiad - mae'n ymddangos ei fod yn gweithio. I lawer o bobl mae hyn yn normal. Ni fyddant hyd yn oed yn gwybod y bydd y cais hwn yn chwalu am ryw reswm, ni fyddant yn derbyn rhybudd, ond ar eu cyfer dyma'r norm. Yn flaenorol, roeddem yn byw ar beiriannau rhithwir heb fonitro, nawr fe wnaethom symud i Kubernetes, hefyd heb fonitro - beth yw'r gwahaniaeth?
Y cwestiwn yw, pan fyddwn yn cerdded ar rew, ni fyddwn byth yn gwybod ei drwch oni bai ein bod yn ei fesur ymlaen llaw. Mae llawer o bobl yn cerdded ac nid ydynt yn poeni, oherwydd eu bod wedi cerdded o'r blaen.
O'm safbwynt i, naws a chymhlethdod gweithredu unrhyw system yw sicrhau bod trwch yr iâ yn union ddigon i ddatrys ein problemau. Dyma beth rydyn ni'n siarad amdano.
Mewn TG, mae'n ymddangos i mi, mae gormod o ddulliau “Byddaf yn ffodus”. Mae llawer o bobl yn gosod meddalwedd ac yn defnyddio llyfrgelloedd meddalwedd yn y gobaith y byddant yn ffodus. Yn gyffredinol, mae llawer o bobl yn ffodus. Mae'n debyg mai dyna pam ei fod yn gweithio.
- O fy asesiad pesimistaidd, mae'n edrych fel hyn: pan fo'r risgiau'n uchel, a rhaid i'r cais weithio, yna mae angen cefnogaeth Flaunt, efallai gan Red Hat, neu mae angen eich tîm mewnol eich hun wedi'i neilltuo'n benodol i Kubernetes, sy'n barod. i'w dynnu i ffwrdd.
Dmitry: Yn wrthrychol, dyma felly. Mae mynd i mewn i stori Kubernetes ar gyfer tîm bach ar eich pen eich hun yn cynnwys nifer o risgiau.
A oes angen cynwysyddion arnom?
- A allwch chi ddweud wrthym pa mor eang yw Kubernetes yn Rwsia?
Dmitry: Nid oes gennyf y data hwn, ac nid wyf yn siŵr bod gan unrhyw un arall. Rydyn ni'n dweud: “Kubernetes, Kubernetes,” ond mae ffordd arall o edrych ar y mater hwn. Nid wyf ychwaith yn gwybod pa mor eang yw cynwysyddion, ond gwn ffigwr o adroddiadau ar y Rhyngrwyd bod 70% o gynwysyddion yn cael eu trefnu gan Kubernetes. Roedd yn ffynhonnell ddibynadwy ar gyfer sampl eithaf mawr ledled y byd.
Yna cwestiwn arall - a oes angen cynwysyddion? Fy nheimlad personol i a safbwynt cyffredinol cwmni Flant yw bod Kubernetes yn safon de facto.
Fydd dim byd ond Kubernetes.
Mae hwn yn newidiwr gemau llwyr ym maes rheoli seilwaith. Jyst absoliwt - dyna ni, dim mwy Ansible, Chef, peiriannau rhithwir, Terraform. Nid wyf yn sôn am yr hen ddulliau fferm gyfunol. Mae Kubernetes yn newidiwr absoliwt, ac yn awr ni bydd ond fel hyn.
Mae’n amlwg ei bod yn cymryd cwpl o flynyddoedd i rai, ac i eraill ychydig ddegawdau, i wireddu hyn. Nid oes gennyf unrhyw amheuaeth na fydd dim byd ond Kubernetes a'r wedd newydd hon: nid ydym bellach yn niweidio'r system weithredu, ond yn defnyddio seilwaith fel cod, yn unig nid gyda chod, ond gyda yml - seilwaith a ddisgrifir yn ddeclaratively. Mae gen i deimlad y bydd hi bob amser fel hyn.
- Hynny yw, bydd y cwmnïau hynny nad ydynt eto wedi newid i Kubernetes yn bendant yn newid iddo neu'n aros yn ebargofiant. Yr wyf yn deall chi yn gywir?
Dmitry: Nid yw hyn ychwaith yn hollol wir. Er enghraifft, os oes gennym y dasg o redeg gweinydd DNS, yna gellir ei redeg ar FreeBSD 4.10 a gall weithio'n berffaith am 20 mlynedd. Dim ond gweithio a dyna ni. Efallai ymhen 20 mlynedd bydd angen diweddaru rhywbeth unwaith. Os ydym yn sôn am feddalwedd yn y fformat a lansiwyd gennym ac mewn gwirionedd mae'n gweithio am flynyddoedd lawer heb unrhyw ddiweddariadau, heb wneud newidiadau, yna, wrth gwrs, ni fydd Kubernetes. Nid oes ei angen yno.
Popeth sy'n ymwneud â CI / CD - lle bynnag y mae angen Cyflenwi Parhaus, lle mae angen i chi ddiweddaru fersiynau, gwneud newidiadau gweithredol, lle bynnag y mae angen i chi adeiladu goddefgarwch nam - dim ond Kubernetes.
Ynglŷn â microwasanaethau
- Yma mae gennyf ychydig anghyseinedd. I weithio gyda Kubernetes, mae angen cefnogaeth allanol neu fewnol arnoch chi - dyma'r pwynt cyntaf. Yn ail, pan ydym newydd ddechrau datblygu, rydym yn fusnes cychwynnol bach, nid oes gennym unrhyw beth eto, gall datblygiad ar gyfer Kubernetes neu bensaernïaeth microservice yn gyffredinol fod yn gymhleth ac nid yw bob amser wedi'i gyfiawnhau'n economaidd. Mae gen i ddiddordeb yn eich barn chi - a oes angen i fusnesau newydd ddechrau ysgrifennu ar gyfer Kubernetes ar unwaith o'r dechrau, neu a allant ysgrifennu monolith o hyd, ac yna dim ond dod i Kubernetes?
Dmitry: Cwestiwn cŵl. Mae gennyf sgwrs am ficrowasanaethau Lawer gwaith rwyf wedi dod ar draws pobl yn ceisio morthwylio ewinedd gyda microsgop. Mae'r dull ei hun yn gywir; rydym ni ein hunain yn dylunio ein meddalwedd mewnol fel hyn. Ond pan fyddwch chi'n gwneud hyn, mae angen i chi ddeall yn glir beth rydych chi'n ei wneud. Y gair sy'n gas gen i fwyaf am ficrowasanaethau yw "micro." Yn hanesyddol, tarddodd y gair hwn yno, ac am ryw reswm mae pobl yn meddwl bod micro yn fach iawn, yn llai na milimedr, fel micromedr. Mae hyn yn anghywir.
Er enghraifft, mae monolith wedi'i ysgrifennu gan 300 o bobl, ac mae pawb a gymerodd ran yn y datblygiad yn deall bod problemau yno, a dylid ei dorri'n ficro-ddarnau - tua 10 darn, pob un ohonynt wedi'i ysgrifennu gan 30 o bobl. mewn fersiwn lleiaf. Mae hyn yn bwysig, yn angenrheidiol ac yn oer. Ond pan ddaw busnes cychwynnol atom ni, lle ysgrifennodd 3 dyn cŵl a thalentog iawn 60 o ficrowasanaethau ar eu gliniau, bob tro rwy'n edrych am Corvalol.
Mae'n ymddangos i mi fod hyn eisoes wedi cael ei siarad filoedd o weithiau - cawsom monolith dosbarthedig mewn rhyw ffurf neu'i gilydd. Nid yw hyn wedi'i gyfiawnhau'n economaidd, mae'n anodd iawn yn gyffredinol ym mhopeth. Rydw i newydd weld hwn gymaint o weithiau ei fod yn fy mrifo, felly rwy'n parhau i siarad amdano.
I'r cwestiwn cychwynnol, mae gwrthdaro rhwng y ffaith bod Kubernetes, ar y naill law, yn frawychus i'w ddefnyddio, oherwydd nid yw'n glir beth allai dorri yno neu beidio â gweithio, ar y llaw arall, mae'n amlwg bod popeth yn mynd yno ac ni fydd dim ond Kubernetes yn bodoli. Ateb - pwyso a mesur faint o fudd a ddaw, faint o dasgau y gallwch eu datrys. Mae hyn ar un ochr i'r raddfa. Ar y llaw arall, mae risgiau yn gysylltiedig ag amser segur neu gyda gostyngiad mewn amser ymateb, lefel argaeledd - gyda gostyngiad mewn dangosyddion perfformiad.
Dyma hi - naill ai rydyn ni'n symud yn gyflym, ac mae Kubernetes yn caniatáu inni wneud llawer o bethau'n llawer cyflymach ac yn well, neu rydyn ni'n defnyddio atebion dibynadwy, â phrawf amser, ond yn symud yn llawer arafach. Mae hwn yn ddewis y mae'n rhaid i bob cwmni ei wneud. Gallwch chi feddwl amdano fel llwybr yn y jyngl - pan fyddwch chi'n cerdded am y tro cyntaf, gallwch chi gwrdd â neidr, teigr neu fochyn daear gwallgof, a phan fyddwch chi wedi cerdded 10 gwaith, rydych chi wedi sathru'r llwybr, wedi'i ddileu y canghennau a cherdded yn haws. Bob tro mae'r llwybr yn ehangu. Yna mae'n ffordd asffalt, ac yn ddiweddarach rhodfa hardd.
Nid yw Kubernetes yn aros yn ei unfan. Cwestiwn eto: Mae Kubernetes, ar y naill law, yn 4-5 deuaidd, ar y llaw arall, dyma'r ecosystem gyfan. Dyma'r system weithredu sydd gennym ar ein peiriannau. Beth yw hwn? Ubuntu neu Curios? Dyma'r cnewyllyn Linux, criw o gydrannau ychwanegol. Yr holl bethau hyn yma, taflwyd un neidr wenwynig allan o'r ffordd, codwyd ffens yno. Mae Kubernetes yn datblygu'n gyflym iawn ac yn ddeinamig, ac mae nifer y risgiau, cyfaint yr anhysbys yn gostwng bob mis ac, yn unol â hynny, mae'r graddfeydd hyn yn ail-gydbwyso.
Gan ateb y cwestiwn o beth ddylai cychwyn busnes ei wneud, byddwn yn dweud - dewch i Flaunt, talwch 150 mil rubles a chael gwasanaeth hawdd un contractwr DevOps. Os ydych chi'n fusnes bach gydag ychydig o ddatblygwyr, mae hyn yn gweithio. Yn lle llogi eich DevOps eich hun, a fydd angen dysgu sut i ddatrys eich problemau a thalu cyflog ar hyn o bryd, fe gewch ateb un contractwr i bob mater. Oes, mae yna rai anfanteision. Ni allwn ni, fel cwmni allanol, gymryd cymaint o ran ac ymateb yn gyflym i newidiadau. Ond mae gennym lawer o arbenigedd ac arferion parod. Rydyn ni'n gwarantu, mewn unrhyw sefyllfa, y byddwn ni'n bendant yn darganfod yn gyflym ac yn codi unrhyw Kubernetes oddi wrth y meirw.
Rwy’n argymell yn gryf allanoli busnesau newydd a busnesau sefydledig hyd at faint lle gallwch neilltuo tîm o 10 o bobl i weithrediadau, oherwydd fel arall nid oes unrhyw bwynt. Mae'n bendant yn gwneud synnwyr i allanoli hyn.
Am Amazon a Google
— A ellir ystyried gwesteiwr o ddatrysiad o Amazon neu Google fel ffynhonnell allanol?
Dmitry: Ydy, wrth gwrs, mae hyn yn datrys nifer o faterion. Ond eto mae yna arlliwiau. Mae angen i chi ddeall sut i'w ddefnyddio o hyd. Er enghraifft, mae yna fil o bethau bach yng ngwaith Amazon AWS: mae angen cynhesu'r Cydbwysedd Llwyth neu mae'n rhaid ysgrifennu cais ymlaen llaw “Bois, byddwn ni'n derbyn traffig, yn cynhesu'r Balancer Llwyth i ni!” Mae angen i chi wybod y naws hyn.
Pan fyddwch chi'n troi at bobl sy'n arbenigo yn hyn, rydych chi'n cau bron pob un o'r pethau nodweddiadol. Bellach mae gennym 40 o beirianwyr, erbyn diwedd y flwyddyn mae'n debyg y bydd 60 - rydym yn bendant wedi dod ar draws yr holl bethau hyn. Hyd yn oed os byddwn yn dod ar draws y broblem hon eto ar ryw brosiect, rydym yn gofyn i'n gilydd yn gyflym ac yn gwybod sut i'w datrys.
Mae'n debyg mai'r ateb yw - wrth gwrs, mae stori wedi'i lletya yn gwneud rhywfaint yn haws. Y cwestiwn yw a ydych chi'n barod i ymddiried yn y gwesteiwyr hyn ac a fyddant yn datrys eich problemau. Mae Amazon a Google wedi gwneud yn dda. Ar gyfer ein holl achosion - yn union. Nid ydym yn cael unrhyw brofiadau mwy cadarnhaol. Mae'r holl gymylau eraill y gwnaethom geisio gweithio gyda nhw yn creu llawer o broblemau - Ager, a phopeth sydd yn Rwsia, a phob math o OpenStack mewn gwahanol weithrediadau: Headster, Overage - beth bynnag rydych chi ei eisiau. Maent i gyd yn creu problemau nad ydych am eu datrys.
Felly, yr ateb yw ydy, ond, mewn gwirionedd, nid oes llawer iawn o atebion lletyol aeddfed.
Pwy sydd angen Kubernetes?
- Ac eto, pwy sydd angen Kubernetes? Pwy ddylai newid i Kubernetes eisoes, sef y cleient Flaunt nodweddiadol sy'n dod yn benodol ar gyfer Kubernetes?
Dmitry: Mae hwn yn gwestiwn diddorol, oherwydd ar hyn o bryd, yn sgil Kubernetes, mae llawer o bobl yn dod atom: "Bois, rydyn ni'n gwybod eich bod chi'n gwneud Kubernetes, gwnewch hynny i ni!" Rydyn ni'n eu hateb: “Boneddigion, dydyn ni ddim yn gwneud Kubernetes, rydyn ni'n gwneud prod a phopeth sy'n gysylltiedig ag ef.” Oherwydd ar hyn o bryd mae'n amhosibl gwneud cynnyrch heb wneud yr holl CI/CD a'r stori gyfan hon. Mae pawb wedi symud i ffwrdd o'r rhaniad y mae gennym ddatblygiad trwy ddatblygiad, ac yna ecsbloetio trwy ecsbloetio.
Mae ein cleientiaid yn disgwyl pethau gwahanol, ond mae pawb yn aros am ryw wyrth dda bod ganddynt broblemau penodol, ac yn awr - hop! - Bydd Kubernetes yn eu datrys. Mae pobl yn credu mewn gwyrthiau. Yn eu meddyliau maen nhw'n deall na fydd gwyrth, ond yn eu heneidiau maen nhw'n gobeithio - beth os bydd y Kubernetes hwn nawr yn datrys popeth i ni, maen nhw'n siarad cymaint amdano! Yn sydyn fe nawr - tisian! - a bwled arian, tisian! - ac mae gennym ni 100% uptime, gall pob datblygwr ryddhau beth bynnag sy'n mynd i mewn i gynhyrchu 50 gwaith, ac nid yw'n chwalu. Yn gyffredinol, gwyrth!
Pan ddaw pobl o'r fath atom, dywedwn: "Mae'n ddrwg gennym, ond nid oes y fath beth â gwyrth." I fod yn iach, mae angen i chi fwyta'n dda ac ymarfer corff. Er mwyn cael cynnyrch dibynadwy, mae angen ei wneud yn ddibynadwy. I gael CI/CD cyfleus, mae angen i chi ei wneud fel hyn. Mae hynny'n llawer o waith sydd angen ei wneud.
Ateb y cwestiwn o bwy sydd angen Kubernetes - does neb angen Kubernetes.
Mae gan rai pobl y camsyniad bod angen Kubernetes arnynt. Mae angen i bobl, mae ganddyn nhw angen dwfn i roi'r gorau i feddwl, astudio, a bod â diddordeb yn holl broblemau seilwaith a phroblemau rhedeg eu cymwysiadau. Maen nhw eisiau i geisiadau weithio a dim ond eu defnyddio. Iddyn nhw, Kubernetes yw’r gobaith y byddan nhw’n rhoi’r gorau i glywed y stori “roedden ni’n gorwedd yno,” neu “ni allwn ni ei chyflwyno,” neu rywbeth arall.
Mae'r cyfarwyddwr technegol fel arfer yn dod atom ni. Maen nhw'n gofyn dau beth iddo: ar y naill law, rhowch nodweddion i ni, ar y llaw arall, sefydlogrwydd. Rydym yn awgrymu eich bod yn ei gymryd arnoch chi'ch hun a'i wneud. Y fwled arian, neu yn hytrach arian-plated, yw y byddwch yn rhoi'r gorau i feddwl am y problemau hyn a gwastraffu amser. Bydd gennych bobl arbennig a fydd yn cau'r mater hwn.
Mae'r geiriad sydd ei angen arnom ni neu unrhyw un arall Kubernetes yn anghywir.
Mae gwir angen Kubernetes ar weinyddwyr, oherwydd mae'n degan diddorol iawn y gallwch chi chwarae ag ef a tincer gydag ef. Gadewch i ni fod yn onest - mae pawb wrth eu bodd â theganau. Rydyn ni i gyd yn blant yn rhywle, a phan rydyn ni'n gweld un newydd, rydyn ni eisiau ei chwarae. I rai, mae hyn wedi cael ei ddigalonni, er enghraifft, yn y weinyddiaeth, oherwydd eu bod eisoes wedi chwarae digon ac eisoes wedi blino i'r pwynt nad ydyn nhw eisiau gwneud hynny. Ond nid yw hyn yn cael ei golli yn llwyr i neb. Er enghraifft, os wyf wedi blino ar deganau ym maes gweinyddu system a DevOps ers amser maith, yna rwy'n dal i garu'r teganau, rwy'n dal i brynu rhai newydd. Mae pawb, un ffordd neu'r llall, yn dal i fod eisiau rhyw fath o deganau.
Nid oes angen chwarae gyda chynhyrchu. Beth bynnag dwi'n bendant yn argymell peidio â'i wneud a'r hyn dwi'n ei weld nawr yn llu: "O, tegan newydd!" — rhedon nhw i’w brynu, ei brynu a: “Dewch i ni fynd ag e i’r ysgol nawr a’i ddangos i’n ffrindiau i gyd.” Peidiwch â gwneud hyn. Rwy'n ymddiheuro, mae fy mhlant yn tyfu i fyny, rwy'n gweld rhywbeth mewn plant yn gyson, yn sylwi arno ynof fy hun, ac yna'n ei gyffredinoli i eraill.
Yr ateb terfynol yw: nid oes angen Kubernetes arnoch chi. Mae angen i chi ddatrys eich problemau.
Yr hyn y gallwch ei gyflawni yw:
- nid yw prod yn disgyn;
- hyd yn oed os bydd yn ceisio cwympo, rydym yn gwybod amdano ymlaen llaw, a gallwn roi rhywbeth ynddo;
- gallwn ei newid ar y cyflymder y mae ein busnes ei angen, a gallwn ei wneud yn gyfleus; nid yw'n achosi unrhyw broblemau i ni.
Mae dau angen gwirioneddol: dibynadwyedd a dynameg/hyblygrwydd cyflwyno. Mae angen i bawb sy'n gwneud rhyw fath o brosiectau TG ar hyn o bryd, ni waeth ym mha fath o fusnes - meddal ar gyfer lleddfu'r byd, ac sy'n deall hyn, ddatrys yr anghenion hyn. Mae Kubernetes gyda'r dull cywir, gyda'r ddealltwriaeth gywir a gyda digon o brofiad yn caniatáu ichi eu datrys.
Ynglŷn â gweinydd
- Os edrychwch ychydig ymhellach i'r dyfodol, ac yna'n ceisio datrys y broblem o absenoldeb cur pen gyda seilwaith, gyda chyflymder y broses gyflwyno a chyflymder y newidiadau i gymwysiadau, mae atebion newydd yn ymddangos, er enghraifft, heb weinydd. Ydych chi'n teimlo unrhyw botensial i'r cyfeiriad hwn a, gadewch i ni ddweud, perygl i Kubernetes ac atebion tebyg?
Dmitry: Yma mae angen i ni wneud sylw eto nad wyf yn gweledydd sy'n edrych ymlaen ac yn dweud - bydd fel hyn! Er mai dim ond yr un peth wnes i. Rwy'n edrych ar fy nhraed ac yn gweld criw o broblemau yno, er enghraifft, sut mae transistorau'n gweithio mewn cyfrifiadur. Mae'n ddoniol, iawn? Rydym yn dod ar draws rhai bygiau yn y CPU.
Gwneud yn ddi-weinydd yn eithaf dibynadwy, rhad, effeithlon a chyfleus, gan ddatrys yr holl faterion ecosystem. Yma cytunaf ag Elon Musk bod angen ail blaned i greu goddefgarwch bai ar gyfer dynoliaeth. Er nad wyf yn gwybod beth mae'n ei ddweud, rwy'n deall nad wyf yn barod i hedfan i'r blaned Mawrth fy hun ac ni fydd yn digwydd yfory.
Gyda gweinydd di-weinydd mae'n amlwg yn glir bod hwn yn beth ideolegol gywir, fel goddef bai ar gyfer dynoliaeth - cael dwy blaned yn well nag un. Ond sut i wneud hynny nawr? Nid yw anfon un alldaith yn broblem os ydych chi'n canolbwyntio'ch ymdrechion arno. Mae anfon sawl alldaith a setlo miloedd o bobl yno, rwy’n meddwl, hefyd yn realistig. Ond i'w wneud yn gwbl oddefgar o fai fel bod hanner y ddynoliaeth yn byw yno, mae'n ymddangos i mi bellach yn amhosibl, heb ei ystyried.
Gydag un ar un heb weinydd: mae'r peth yn cŵl, ond mae'n bell o broblemau 2019. Yn nes at 2030 - gadewch i ni fyw i'w weld. Nid oes gennyf unrhyw amheuaeth y byddwn yn byw, byddwn yn bendant yn byw (ailadrodd cyn mynd i'r gwely), ond yn awr mae angen i ni ddatrys problemau eraill. Mae fel credu yn y stori dylwyth teg merlen Rainbow. Ydy, mae cwpl y cant o achosion yn cael eu datrys, ac maen nhw'n cael eu datrys yn berffaith, ond yn oddrychol, enfys yw di-weinydd ... I mi, mae'r pwnc hwn yn rhy bell ac yn rhy annealladwy. Dydw i ddim yn barod i siarad. Yn 2019, ni allwch ysgrifennu un cais heb weinydd.
Sut y bydd Kubernetes yn esblygu
— Wrth inni symud tuag at y dyfodol pell a allai fod yn wych, sut ydych chi’n meddwl y bydd Kubernetes a’r ecosystem o’i gwmpas yn datblygu?
Dmitry: Rwyf wedi meddwl llawer am hyn ac mae gennyf ateb clir. Mae'r cyntaf yn wladwriaethol - wedi'r cyfan, mae'n haws gwneud heb wladwriaeth. Buddsoddodd Kubernetes fwy yn hyn i ddechrau, dechreuodd y cyfan ag ef. Mae di-wladwriaeth yn gweithio bron yn berffaith yn Kubernetes, does dim byd i gwyno amdano. Mae yna lawer o broblemau o hyd, neu yn hytrach, naws. Mae popeth yno eisoes yn gweithio'n wych i ni, ond dyna ni. Bydd yn cymryd o leiaf ychydig flynyddoedd yn fwy i hyn weithio i bawb. Nid dangosydd wedi ei gyfrifo yw hwn, ond fy nheimlad o fy mhen.
Yn fyr, dylai - ac fe fydd - gwladwriaethol yn datblygu'n gryf iawn, oherwydd bod ein holl statws yn storio cymwysiadau; nid oes unrhyw gymwysiadau di-wladwriaeth. Mae hyn yn rhith; mae angen rhyw fath o gronfa ddata a rhywbeth arall arnoch bob amser. Mae Statefull yn ymwneud â sythu popeth sy'n bosibl, trwsio'r holl fygiau, gwella'r holl broblemau sy'n cael eu hwynebu ar hyn o bryd - gadewch i ni ei alw'n fabwysiadu.
Bydd lefel yr anhysbys, lefel y problemau heb eu datrys, lefel y tebygolrwydd o ddod ar draws rhywbeth yn gostwng yn sylweddol. Mae hon yn stori bwysig. A gweithredwyr - popeth sy'n ymwneud â chodeiddio rhesymeg gweinyddu, rhesymeg rheoli er mwyn cael gwasanaeth hawdd: gwasanaeth hawdd MySQL, gwasanaeth hawdd RabbitMQ, gwasanaeth hawdd Memcache - yn gyffredinol, yr holl gydrannau hyn y mae angen i ni fod yn sicr o weithio allan ohonynt y bocs. Mae hyn yn datrys y boen yr ydym am gael cronfa ddata, ond nid ydym am ei gweinyddu, neu rydym eisiau Kubernetes, ond nid ydym am ei gweinyddu.
Bydd y stori hon am ddatblygiad gweithredwyr ar ryw ffurf neu'i gilydd yn bwysig yn ystod yr ychydig flynyddoedd nesaf.
Rwy'n credu y dylai'r rhwyddineb defnydd gynyddu'n fawr - bydd y blwch yn dod yn fwy a mwy du, yn fwy a mwy dibynadwy, gyda mwy a mwy o nobiau syml.
Gwrandewais unwaith ar hen gyfweliad gyda Isaac Asimov o'r 80au ar YouTube ar Saturday Night Live - rhaglen fel Urgant, dim ond diddorol. Fe ofynnon nhw iddo am ddyfodol cyfrifiaduron. Dywedodd fod y dyfodol mewn symlrwydd, yn union fel y radio. Roedd y derbynnydd radio yn beth cymhleth yn wreiddiol. I ddal ton, bu'n rhaid i chi droi'r nobiau am 15 munud, troi'r sgiwerau a gwybod yn gyffredinol sut mae popeth yn gweithio, deall ffiseg trawsyrru tonnau radio. O ganlyniad, dim ond un bwlyn oedd ar ôl yn y radio.
Nawr yn 2019 pa radio? Yn y car, mae'r derbynnydd radio yn dod o hyd i'r holl donnau ac enwau'r gorsafoedd. Nid yw ffiseg y broses wedi newid mewn 100 mlynedd, ond mae rhwyddineb defnydd wedi newid. Nawr, ac nid yn unig nawr, eisoes yn 1980, pan gafwyd cyfweliad ag Azimov, roedd pawb yn defnyddio'r radio ac nid oedd neb yn meddwl sut roedd yn gweithio. Roedd bob amser yn gweithio - dyna a roddir.
Yna dywedodd Azimov y byddai'r un peth gyda chyfrifiaduron - bydd rhwyddineb defnydd yn cynyddu. Tra yn 1980 bu'n rhaid i chi gael eich hyfforddi i wasgu botymau ar gyfrifiadur, ni fydd hynny'n wir yn y dyfodol.
Mae gen i deimlad gyda Kubernetes a chyda'r seilwaith hefyd y bydd cynnydd enfawr mewn rhwyddineb defnydd. Mae hyn, yn fy marn i, yn amlwg - mae'n gorwedd ar yr wyneb.
Beth i'w wneud gyda pheirianwyr?
— Beth felly fydd yn digwydd i'r peirianwyr a'r gweinyddwyr system sy'n cefnogi Kubernetes?
Dmitry: Beth ddigwyddodd i'r cyfrifydd ar ôl dyfodiad 1C? Tua'r un peth. Cyn hyn, roedden nhw'n cyfrif ar bapur - nawr yn y rhaglen. Mae cynhyrchiant llafur wedi cynyddu yn ôl gorchmynion maint, ond nid yw llafur ei hun wedi diflannu. Pe bai'n cymryd 10 peiriannydd i sgriwio bwlb golau o'r blaen, nawr bydd un yn ddigon.
Mae faint o feddalwedd a nifer y tasgau, mae'n ymddangos i mi, bellach yn tyfu'n gyflymach nag y mae DevOps newydd yn ymddangos ac mae effeithlonrwydd yn cynyddu. Mae yna brinder penodol yn y farchnad ar hyn o bryd a bydd yn para am amser hir. Yn ddiweddarach, bydd popeth yn dychwelyd i ryw fath o normalrwydd, lle bydd effeithlonrwydd gwaith yn cynyddu, bydd mwy a mwy heb weinydd, bydd niwron yn cael ei gysylltu â Kubernetes, a fydd yn dewis yr holl adnoddau yn union yn ôl yr angen, ac yn gyffredinol bydd gwnewch bopeth ei hun, fel y dylai - mae'r person yn camu i ffwrdd a pheidiwch ag ymyrryd.
Ond bydd angen i rywun wneud penderfyniadau o hyd. Mae'n amlwg bod lefel cymwysterau ac arbenigedd y person hwn yn uwch. Y dyddiau hyn, yn yr adran gyfrifo, nid oes angen 10 o weithwyr yn cadw llyfrau fel nad yw eu dwylo'n blino. Yn syml, nid yw'n angenrheidiol. Mae llawer o ddogfennau'n cael eu sganio a'u cydnabod yn awtomatig gan y system rheoli dogfennau electronig. Mae un prif gyfrifydd craff yn ddigon, sydd eisoes â llawer mwy o sgiliau, gyda dealltwriaeth dda.
Yn gyffredinol, dyma'r ffordd i fynd ym mhob diwydiant. Mae'r un peth gyda cheir: yn flaenorol, daeth car gyda mecanic a thri gyrrwr. Y dyddiau hyn, mae gyrru car yn broses syml yr ydym i gyd yn cymryd rhan ynddi bob dydd. Does neb yn meddwl bod car yn rhywbeth cymhleth.
Ni fydd DevOps neu beirianneg systemau yn diflannu - bydd gwaith lefel uchel ac effeithlonrwydd yn cynyddu.
— Clywais hefyd syniad diddorol y bydd y gwaith yn cynyddu mewn gwirionedd.
Dmitry: Wrth gwrs, cant y cant! Oherwydd bod faint o feddalwedd rydyn ni'n ei ysgrifennu yn tyfu'n gyson. Mae nifer y problemau rydyn ni'n eu datrys gyda meddalwedd yn cynyddu'n gyson. Mae maint y gwaith yn cynyddu. Nawr mae marchnad DevOps wedi'i gorboethi'n ofnadwy. Gellir gweld hyn yn y disgwyliadau cyflog. Mewn ffordd dda, heb fynd i fanylion, dylai fod yna rai iau sydd eisiau X, canolwyr sydd eisiau 1,5X, a phobl hŷn sydd eisiau 2X. Ac yn awr, os edrychwch ar farchnad gyflog Moscow DevOps, mae iau eisiau o X i 3X a dymuniadau uwch o X i 3X.
Does neb yn gwybod faint mae'n ei gostio. Mae lefel y cyflog yn cael ei fesur gan eich hyder - gwallgofdy llwyr, a dweud y gwir, marchnad sydd wedi'i gorboethi'n ofnadwy.
Wrth gwrs, bydd y sefyllfa hon yn newid yn fuan iawn - dylai rhywfaint o dirlawnder ddigwydd. Nid yw hyn yn wir gyda datblygu meddalwedd - er gwaethaf y ffaith bod angen datblygwyr ar bawb, ac mae angen datblygwyr da ar bawb, mae'r farchnad yn deall pwy sy'n werth beth - mae'r diwydiant wedi setlo i lawr. Nid yw hynny'n wir gyda DevOps y dyddiau hyn.
- O'r hyn a glywais, deuthum i'r casgliad na ddylai gweinyddwr y system bresennol boeni gormod, ond mae'n bryd uwchraddio ei sgiliau a pharatoi ar gyfer y ffaith y bydd mwy o waith yfory, ond y bydd yn fwy cymwys.
Dmitry: cant y cant. Yn gyffredinol, rydyn ni'n byw yn 2019 a rheol bywyd yw hyn: dysgu gydol oes - rydym yn dysgu trwy gydol ein bywydau. Mae'n ymddangos i mi bod pawb bellach yn gwybod ac yn teimlo hyn, ond nid yw'n ddigon gwybod - mae'n rhaid i chi ei wneud. Bob dydd mae'n rhaid i ni newid. Os na fyddwn yn gwneud hyn, yna yn hwyr neu'n hwyrach byddwn yn cael ein gadael ar ymylon y proffesiwn.
Byddwch yn barod ar gyfer troadau sydyn 180 gradd. Dydw i ddim yn diystyru sefyllfa lle mae rhywbeth yn newid yn radical, rhywbeth newydd yn cael ei ddyfeisio - mae'n digwydd. Neidiwch! - ac rydyn ni nawr yn gweithredu'n wahanol. Mae'n bwysig bod yn barod ar gyfer hyn a pheidio â phoeni. Efallai y bydd yn digwydd yfory bydd popeth a wnaf yn troi allan i fod yn ddiangen - dim byd, rwyf wedi astudio ar hyd fy oes ac yn barod i ddysgu rhywbeth arall. Nid yw'n broblem. Nid oes angen bod ofn sicrwydd swydd, ond mae angen i chi fod yn barod i ddysgu rhywbeth newydd yn gyson.
Dymuniadau a munud o hysbysebu
- A oes gennych unrhyw ddymuniad?
Dmitry: Oes, mae gen i sawl dymuniad.
Cyntaf a masnachol - tanysgrifio i . Annwyl ddarllenwyr, ewch i YouTube a thanysgrifiwch i'n sianel. Mewn tua mis byddwn yn dechrau ehangu gweithredol ar y gwasanaeth fideo.Bydd gennym lawer o gynnwys addysgol am Kubernetes, yn agored ac yn amrywiol: o bethau ymarferol, i lawr i labordai, i bethau damcaniaethol sylfaenol dwfn a sut i ddefnyddio Kubernetes yn y lefel egwyddorion a phatrymau.
Yr ail mercantile wish - ewch i a rhoi sêr oherwydd rydyn ni'n bwydo arnyn nhw. Os na fyddwch chi'n rhoi sêr i ni, ni fydd gennym unrhyw beth i'w fwyta. Mae fel mana mewn gêm gyfrifiadurol. Rydyn ni'n gwneud rhywbeth, rydyn ni'n gwneud, rydyn ni'n ceisio, mae rhywun yn dweud bod y rhain yn feiciau ofnadwy, rhywun bod popeth yn hollol anghywir, ond rydyn ni'n parhau ac yn gweithredu'n gwbl onest. Rydyn ni'n gweld problem, yn ei datrys ac yn rhannu ein profiad. Felly, rho inni seren, nid yw'n mynd i ffwrdd oddi wrthych, ond fe ddaw atom ni, oherwydd yr ydym ni'n bwydo arnynt.
Yn drydydd, dymuniad pwysig, ac nid yw bellach yn fasnachol - rhoi'r gorau i gredu mewn straeon tylwyth teg. Rydych chi'n weithwyr proffesiynol. Mae DevOps yn broffesiwn difrifol a chyfrifol iawn. Rhoi'r gorau i chwarae yn y gweithle. Gadewch iddo glicio i chi a byddwch yn ei ddeall. Dychmygwch eich bod chi'n dod i'r ysbyty, ac yno mae'r meddyg yn arbrofi arnoch chi. Rwy’n deall y gallai hyn fod yn sarhaus i rywun, ond, yn fwyaf tebygol, nid yw hyn yn ymwneud â chi, ond am rywun arall. Dywedwch wrth eraill am stopio hefyd. Mae hyn wir yn difetha bywyd i bob un ohonom - mae llawer yn dechrau trin llawdriniaethau, gweinyddwyr a DevOps fel dudes sydd wedi torri rhywbeth eto. Roedd hyn yn “torri” gan amlaf oherwydd ein bod yn mynd i chwarae, heb edrych yn annelwig mai dyma fel y mae, a dyna fel y mae.
Nid yw hyn yn golygu na ddylech arbrofi. Mae angen i ni arbrofi, rydyn ni'n ei wneud ein hunain. I fod yn onest, rydyn ni ein hunain weithiau'n chwarae gemau - mae hyn, wrth gwrs, yn ddrwg iawn, ond does dim byd dynol yn estron i ni. Gadewch i ni ddatgan 2019 yn flwyddyn o arbrofion difrifol, wedi'u hystyried yn ofalus, ac nid gemau ar gynhyrchu. Mae'n debyg felly.
- Diolch yn fawr iawn!
Dmitry: Diolch, Vitaly, am yr amser ac am y cyfweliad. Annwyl ddarllenwyr, diolch yn fawr iawn os ydych chi wedi cyrraedd y pwynt hwn yn sydyn. Gobeithiaf ein bod wedi dod ag o leiaf cwpl o feddyliau ichi.
Yn y cyfweliad, cyffyrddodd Dmitry â mater werff. Nawr mae hon yn gyllell Swistir gyffredinol sy'n datrys bron pob problem. Ond nid felly y bu bob amser. Ar yn yr wyl Bydd Dmitry Stolyarov yn dweud wrthych yn fanwl am yr offeryn hwn. yn yr adroddiad bydd popeth: problemau a naws cudd Kubernetes, opsiynau ar gyfer datrys yr anawsterau hyn a gweithrediad presennol werff yn fanwl. Ymunwch â ni ar Fai 27 a 28, byddwn yn creu'r offer perffaith.
Ffynhonnell: hab.com