{"id":34450,"date":"2019-10-31T21:58:24","date_gmt":"2019-10-31T18:58:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kubernetes-zahvatit-mir-kogda-i-kak\/"},"modified":"2019-10-31T21:58:24","modified_gmt":"2019-10-31T18:58:24","slug":"kubernetes-zahvatit-mir-kogda-i-kak","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/kubernetes-zahvatit-mir-kogda-i-kak","title":{"rendered":"Kubernetes vallutab maailma. Millal ja kuidas?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Eel\u00f5htul DevOpsConf<\/a><\/noindex> Vitaly Khabarov<\/b> intervjuu viis\u00a0Dmitri Stolyaroviga<\/b> (distol<\/a><\/noindex>), tehnilise direktori ja ettev\u00f5tte \u201eFlant\u201c kaasasutaja. Vitaly k\u00fcsis Dmitrilt, millega tegeleb \u201eFlant\u201c, Kubernetesest, \u00f6kos\u00fcsteemi arengust ja toetamisest. R\u00e4\u00e4kisime, miks on vajalik Kubernetes ja kas see on \u00fcldse vajalik. Samuti puudutasime mikroteenuseid, Amazon AWS-i, l\u00e4henemist \u201eMul on \u00f5nne\u201c DevOpsis, Kubernetes tulevikku, miks, millal ja kuidas see haarab maailma, DevOpsi perspektiivid ja millega peaksid insenerid valmistuma ereda ja l\u00e4hedase tuleviku jaoks koos lihtsustamise ja n\u00e4rviv\u00f5rkudega.<\/p>\n

Intervjuu originaal<\/a><\/noindex> podcastina kuulamiseks DevOps Deflope \u2014 Venekeelses DevOps podcastis, ja allpool on tekstiversioon. <\/p>\n

\"Kubernetes
\n
\nSiin ja edaspidi k\u00fcsib k\u00fcsimusi Vitaly Khabarov<\/a><\/noindex> insener Express42-st.
\n<\/a><\/noindex><\/p>\n

Flantist<\/h2>\n

\n\u2014 Dima, tere. Sa oled \u201eFlant<\/a><\/noindex>\u201c tehniline direktor ja samuti selle asutaja. R\u00e4\u00e4gi palun, millega tegeleb ettev\u00f5te ja sina seal?<\/b><\/p>\n

\"KubernetesDmitri<\/b>: V\u00e4limuselt tundub, et me oleme sellised kutid, kes k\u00e4ivad, paigaldavad k\u00f5igile Kubernetes ja teevad sellega midagi. Aga see pole t\u00f5si. Alguses alustasime ettev\u00f5ttena, mis tegeleb Linuxiga, kuid juba v\u00e4ga kaua on meie peamine tegevus \u2013 v\u00f5tmehoidjaga tootmis- ja highload-projektide teenindamine. Tavaline on see, et ehitame kogu infrastruktuuri nullist ja siis vastutame selle eest kaua aega. Seega, peamine t\u00f6\u00f6, mida \u201eFlant\u201c teeb, mille eest ka raha k\u00fcsime \u2013 on vastutuse v\u00f5tmine ja tootmise rakendamine v\u00f5tmehoidjaga<\/b>.
\n

\n

\nMina, kui tehniline direktor ja \u00fcks ettev\u00f5tte kaasasutajatest, t\u00f6\u00f6tan \u00f6\u00f6p\u00e4evaringselt selle nimel, et leida viise, kuidas suurendada tootmise k\u00e4ttesaadavust, lihtsustada selle kasutamist, kergendada administraatorite elu ja muuta arendajate elu meeldivamaks.<\/p>\n

Kubernetesest<\/h2>\n

\n\u2014 Viimasel ajal olen \u201eFlanti\u201c poolt n\u00e4inud palju ettekandeid ja\u00a0artikleid<\/a><\/noindex> Kubernetesest. Kuidas te sinna j\u00f5udsite?<\/b><\/p>\n

Dmitri<\/b>: Olen sellest palju r\u00e4\u00e4kinud, kuid mul ei ole sugugi kahju seda korrata. Pean \u00f5igeks seda teemat korrata, kuna tekib segadus p\u00f5hjuse ja tagaj\u00e4rje vahel.<\/p>\n

Meil oli v\u00e4ga vaja t\u00f6\u00f6riista. Me kohtasime mitmeid probleeme, v\u00f5itlesime nendega, \u00fcletades neid erinevate lahendustega ja tundsime t\u00f6\u00f6riista vajadust. Proovisime mitmeid erinevaid variante, ehitasime oma jalgrattaid ja kogusime kogemusi. Aeglaselt j\u00f5udsime sinnamaani, et hakkasime Dockerit kasutama peaaegu kohe, kui see ilmus \u2014 umbes 2013. aastal. Selle ilmumise hetkel oli meil juba palju kogemusi konteineritega, olime juba kirjutanud oma analooge \u201eDockerile\u201c \u2014 mingisuguseid meie loomingulisi lahendusi Pythonis. Dockeri ilmumisega saime \u00e4ra visata meie lahendused ja hakata kasutama usaldusv\u00e4\u00e4rset ning kogukonna toetatud lahendust.<\/p>\n

Kubernetesega on lugu sarnane. Ajal, mil see hakkas hoogu koguma \u2014 meie jaoks on see versioon 1.2 \u2014 oli meil juba hulk loomingulisi lahendusi nii Shellis kui ka Chefis, mida me p\u00fc\u00fcdsime Dockerit orkestreerida. Me vaatlesime t\u00f5siselt Rancherit ja erinevaid teisi lahendusi, kuid siis ilmus Kubernetes, milles oli k\u00f5ik just nii, nagu me oleksime ise teinud, v\u00f5i isegi paremini. Midagi pole viga.<\/p>\n

Jah, siin on mingid l\u00f5petamata asjad, seal on mingid l\u00f5petamata asjad \u2014 palju l\u00f5petamata asju, aga 1.2 on t\u00e4iesti kohutav, aga... Kubernetes on nagu ehitatav hoone \u2014 vaatad projekti ja m\u00f5istad, et sellest saab \u00e4ge. Kui hoonel on praegu vundament ja kaks korrust, siis m\u00f5istad, et parem on veel mitte sisse kolida, kuid tarkvaraga selliseid probleeme ei ole \u2014 seda saab juba kasutada.<\/p>\n

Meil ei olnud mingeid kahtlusi, kas kasutada Kubernetesit v\u00f5i mitte. Me ootasime seda palju enne, kui see ilmus, ja p\u00fc\u00fcdsime ise analooge luua.<\/p><\/blockquote>\n

<\/p>\n

Kubernetesest<\/h2>\n

\n\u2014 Kas te osalete otseselt Kubernetes'i arenduses?<\/b><\/p>\n

Dmitri<\/b>: Kaudselt. Pigem osaleme \u00f6kos\u00fcsteemi arenduses. Me saadame teatud arvu pull request'e: Prometheusesse, erinevatesse operaatoritesse, Helmi \u2014 \u00f6kos\u00fcsteemi. Kahjuks ei suuda ma j\u00e4lgida k\u00f5ike, mida me teeme, ja v\u00f5in eksida, kuid meie k\u00e4est ei ole \u00fchtegi pulka tuuma l\u00e4inud.<\/p>\n

\u2014 Samas arendate te palju oma t\u00f6\u00f6riistu \u00fcmber Kubernetes'i?<\/b><\/p>\n

Dmitri<\/b>: Strateegia on selline: me l\u00e4heme ja teeme pull request'e k\u00f5igesse, mis juba olemas on. Kui seal pull request'eid ei v\u00f5eta vastu, siis me lihtsalt forkime need endale ja elame edasi, kuni need on meie versioonidega vastu v\u00f5etud. Siis, kui see j\u00f5uab upstream'i, naaseme tagasi upstream'i versioonile.<\/p>\n

N\u00e4iteks, meil on Prometheus-operator, millega me oleme viis korda juba \u00fcles-alla \u00fcmber l\u00fclitunud meie versioonile. Meil on vaja mingit funktsiooni, me saatsime pull requesti, peame selle homme v\u00e4lja tooma, kuid ei soovi oodata, kuni see upstreamis v\u00e4lja antakse. Seega valmistame endale, paiskame meie versiooni koos meie funktsiooniga, mis on meile vajalik, k\u00f5ikidele oma klastritele. Siis \u00fctlevad nad n\u00e4iteks upstreamis: \"Kallid, teeme selle palju \u00fcldisema juhtumi jaoks,\" me, v\u00f5i keegi teine, viimistleb selle ja aja jooksul sulandub see j\u00e4lle tagasi.<\/p>\n

K\u00f5ike, mis eksisteerib, p\u00fc\u00fcame me edasi arendada.<\/b>. Paljusid elemente, mida veel ei ole, pole veel v\u00e4lja m\u00f5eldud v\u00f5i on v\u00e4lja m\u00f5eldud, kuid pole suudetud ellu viia - me teeme. Ja mitte seet\u00f5ttu, et meile meeldib ise protsess v\u00f5i jalgrattaehitus valdkonnana, vaid lihtsalt seet\u00f5ttu, et meil on seda t\u00f6\u00f6riista vaja. Tihti k\u00fcsitakse, miks me tegime selle v\u00f5i teise asja? Vastus on lihtne - sest meil oli vaja edasi liikuda, lahendada mingi praktiline probleem ja me lahendasime selle selle t\u00f6\u00f6riistaga.<\/p>\n

Tee on alati selline: me otsime v\u00e4ga hoolikalt ja, kui me ei leia mingit lahendust, kuidas leivap\u00e4tsist trollibussi teha, siis teeme oma leivap\u00e4tsi ja oma trollibussi.<\/p><\/blockquote>\n

<\/p>\n

Flanta t\u00f6\u00f6riistad<\/h2>\n

\n\u2014 Ma kuulen, et Flantal on praegu addon-operatorid, shell-operatorid, t\u00f6\u00f6riistad dapp\/werf. Nagu ma aru saan, on see sama t\u00f6\u00f6riist erinevates inkarnatsioonides. Samuti m\u00f5istan, et Flanta sees on veel palju erinevaid t\u00f6\u00f6riistu. Kas see on t\u00f5si?<\/b><\/p>\n

Dmitri<\/b>: Meil on GitHubis veel palju asju. Ainu\u00fcksi, mis mul praegu meeles on, on statusmap - paneel Grafanale, mis on k\u00f5igile sobinud. Seda mainitakse peaaegu igas teises artiklis Kubernetes'i j\u00e4lgimise kohta Mediumis. On v\u00f5imatu l\u00fchidalt r\u00e4\u00e4kida, mis on statusmap - selleks on vaja eraldi artiklit, kuid see on v\u00e4ga kasulik asi staatuse j\u00e4lgimiseks ajas, kuna Kubernetesis on meil sageli vaja kuvada staatust ajas. Veel on meil LogHouse - see on asi ClickHouse'is ja musta maagia baasil logide kogumiseks Kubernetesis.<\/p>\n

Palju utiliite! Ja tuleb veel rohkem, sest m\u00f5ni sisemine lahendus on sel aastal vabastamisel. Suurte addon-Operaatorite p\u00f5hjal on palju addone Kubernetes'i jaoks, nagu n\u00e4iteks, kuidas \u00f5igesti seadistada sertifikaadihaldurit - t\u00f6\u00f6riist sertifikaatide haldamiseks, kuidas \u00f5igesti seadistada Prometheust koos palju lisafunktsioonide - seal on umbes kaksk\u00fcmmend erinevat binaarfaili, mis eksportivad andmeid ja koguvad midagi, ning Prometheuse jaoks on suurep\u00e4rased graafikud ja hoiatuste s\u00fcsteem. K\u00f5ik need on lihtsalt palju addone Kubernetes'ile, mis installitakse klastrisse ja muudetakse see lihtsast keeruliseks ja automaatseks, kus paljusid k\u00fcsimusi on juba lahendatud. Jah, teeme palju.<\/p>\n

\u00d6kos\u00fcsteemi areng<\/h2>\n

\n\u2014 Minu arvates on see v\u00e4ga suur panus selle t\u00f6\u00f6riista ja selle kasutusmeetodite arengusse. Kas sa saaksid enam-v\u00e4hem hinnata, kes veel teeks nii suurt panust \u00f6kos\u00fcsteemi arengusse?<\/b><\/p>\n

Dmitri<\/b>: Venemaal ei ole \u00fckski ettev\u00f5te, mis tegutseb meie turul, l\u00e4hedal.<\/b>. Muidugi, see on suur avaldus, sest on suured m\u00e4ngijad, nagu Mail ja Yandex - nad teevad ka midagi Kubernetes'iga, kuid isegi nemad ei ole l\u00e4henenud ettev\u00f5tete panusele \u00fcldiselt maailmas, kes teevad palju rohkem kui meie. Raske on v\u00f5rrelda \"Flant\" 80 inimesega ja Red Hat'iga, millel on ainult Kubernetes'e jaoks 300 inseneri, kui ma ei eksi. Raske on v\u00f5rrelda. Meie RnD osakonnas on 6 inimest, sealhulgas mina, kes arendavad k\u00f5ik meie t\u00f6\u00f6riistad. 6 inimest versus 300 Red Hat'i inseneri - kuidagi raske v\u00f5rrelda.<\/p>\n

\u2014 Siiski, isegi kui need 6 inimest suudavad teha midagi t\u00f5eliselt kasulikku ja edasi antavat, kui nad silmitsi seisavad praktilise probleemiga ja annavad lahenduse kogukonnale - huvitav juhtum. Ma m\u00f5istan, et suurtes tehnoloogiaettev\u00f5tetes, kus on oma arendus ja Kubernetes'i tugimeeskond, v\u00f5ivad sellised t\u00f6\u00f6riistad \u00fcldiselt areneda. See on nende jaoks n\u00e4ide, et saab arendada ja anda edasi kogukonnale, andes t\u00f5uke kogu kogukonnale, kes kasutab Kubernetes'i.<\/b><\/p>\n

Dmitri<\/b>: T\u00f5en\u00e4oliselt on see integratsiooni tegija erip\u00e4ra. Meil on palju projekte ja n\u00e4eme erinevaid olukordi. Meie peamine viis lisav\u00e4\u00e4rtuse loomiseks on anal\u00fc\u00fcsida neid kohti, leida \u00fchiseid jooni ja maksimaalselt odavendada neid meie jaoks. Sellega tegeleme aktiivselt. Mul on raske r\u00e4\u00e4kida Venemaast ja maailmast, kuid meil on firmas umbes 40 DevOps-inseneri, kes tegelevad Kubernetesega. Ma ei usu, et Venemaal on palju ettev\u00f5tteid, kus oleks sama palju spetsialiste, kes m\u00f5istavad Kuberneteset, kui \u00fcldse on.<\/p>\n

Ma tean k\u00f5ik DevOps-inseneri tiitlist, k\u00f5ik m\u00f5istavad ja on harjunud nimetama DevOps-insenerideks, me ei hakka seda arutama. K\u00f5ik need 40 suurep\u00e4rase DevOps-inseneri seisavad iga p\u00e4ev silmitsi probleemidega ja lahendavad neid, me lihtsalt anal\u00fc\u00fcsime seda kogemust ja \u00fcritame seda \u00fcldistada. Me m\u00f5istame, et kui see j\u00e4\u00e4b ainult meie seas, siis aasta v\u00f5i kahe p\u00e4rast on t\u00f6\u00f6riist kasutu, sest kuskil kogukonnas ilmub valmis lahendus. Pole m\u00f5tet seda kogemust enda sees hoida - see on lihtsalt energiate ja aja raiskamine dev\/null'i. Nii et me ei kahetse seda. Me avaldame k\u00f5ik suure hea meelega ja m\u00f5istame, et seda tuleb avaldada, arendada, reklaamida, et inimesed kasutaksid ja lisaksid oma kogemust - siis kasvavad ja elavad k\u00f5ik. Siis kaks aastat hiljem t\u00f6\u00f6riist ei l\u00e4he pr\u00fcgim\u00e4ele. Pole kahju energiat j\u00e4tkata, sest on n\u00e4ha, et keegi kasutab sinu t\u00f6\u00f6riista ja kahe aasta p\u00e4rast kasutavad seda k\u00f5ik.<\/p>\n

See on osa meie suurest strateegiast koos dapp\/werfiga.<\/b>. Ma ei m\u00e4leta, millal me selle arendamisega alustasime, tundub, et umbes 3 aastat tagasi. Alguses oli see t\u00e4iesti shell'il. See oli super t\u00f5estuskontseptsioon, lahendasime m\u00f5ned meie erialased probleemid - see toimis! Kuid shell'iga on seal probleeme, seda on edasi arendada v\u00f5imatu, shell'il programmeerimine on \u00fcsna vaevarikas. Meil oli harjumus kirjutada Ruby keeles, seega tegime Ruby's midagi \u00fcmber, arendasime, arendasime ja j\u00f5udsime sinnamaani, et kogukond, rahvas, kes ei \u00fctle 'me tahame v\u00f5i ei taha', keeras Ruby'le nina, kuigi see ei ole naljakas. Saime aru, et peame k\u00f5ik selle kirjutama Go keeles, et lihtsalt vastata nimekirja esimesele punktile: DevOps-t\u00f6\u00f6riist peab olema staatiline binaar<\/b>Go kasutamine ei ole nii oluline, kuid parem on statiline binaar, mis on kirjutatud Go-s.<\/p>\n

Kulusid palju ressursse, et kirjutada dapp Go-s ja nimetada see werfiks. Dapp-i ei toetata enam, see ei arene, see t\u00f6\u00f6tab mingis vanas versioonis, kuid on t\u00e4iesti olemas t\u00e4iustuste tee, mida saab j\u00e4rgida.<\/p>\n

Miks dapp loodi<\/h2>\n

\n\u2014 Kas sa saaksid l\u00fchidalt r\u00e4\u00e4kida, miks dapp loodi, milliseid probleeme see lahendab?<\/b><\/p>\n

Dmitri<\/b>: Esimene p\u00f5hjus on ehitamine. Alguses oli meil t\u00f5siseid probleeme ehitamisega, kui Docker ei osanud multi-stage, ja me tegime multi-stage ise. Siis oli meil veel palju k\u00fcsimusi image'i puhastamisega. K\u00f5ik, kes teevad CI\/CD-d, satuvad varem v\u00f5i hiljem silmitsi probleemiga, et on palju ehitatud imagesid, mis tuleb kuidagi puhastada, j\u00e4ttes alles need, mis on vajalikud.<\/p>\n

Teine p\u00f5hjus on deploy. Jah, olemas on Helm, kuid see lahendab ainult osa \u00fclesannetest. Irooniline, et \u00f6eldakse: \"Helm \u2013 Kubernetes'i pakihaldur\". Just see \"the\" on oluline. Veel on s\u00f5nad \"pakihaldur\" \u2014 millised ootused on tavaliselt pakihaldurilt? \u00dctleme: \"Pakihaldur - pane pakett!\" ja ootame, et ta \u00fctleb: \"Pakett on paigaldatud.\" <\/p>\n

Huvitav, et me r\u00e4\u00e4gime: \"Helm, pane pakett\", aga kui ta vastab, et on paigaldatud, selgub, et ta alles alustas installimist \u2013 ta \u00fctleb Kubernetes'ile: \"K\u00e4ivita see asi!\", kuid kas see k\u00e4ivitus v\u00f5i mitte, Helm ei k\u00e4sitle seda k\u00fcsimust \u00fcldse.<\/p>\n

Selgub, et Helm on lihtsalt tekstipreprotsessor, mis laadib andmed Kubernetes'i.<\/p><\/blockquote>\n

\nAga me tahame iga deploy'i raames teada \u2013 kas rakendus on produktsiooni j\u00f5udnud v\u00f5i mitte? Produktsiooni j\u00f5udmine t\u00e4hendab, et rakendus j\u00f5udis sinna, uus versioon on \u00fcles seatud ja see ei jooksnud v\u00e4hemalt kokku ning vastab \u00f5igesti. Helm ei lahenda seda \u00fclesannet. Selle \u00fclesande t\u00e4itmiseks tuleb palju vaeva n\u00e4ha, sest tuleb anda Kubernetes'ile k\u00e4su v\u00e4lja viia ja j\u00e4lgida, mis seal toimub \u2013 kas see on \u00fcles seatud v\u00f5i mitte. Ja on veel palju \u00fclesandeid, mis on seotud deploy'i, puhastamise ja ehitamisega.<\/p>\n

Plaane<\/h2>\n

\nSel aastal kavatseme minna kohalikku arendusse. Tahame j\u00f5uda selleni, et nagu varem Vagrantis \u2013 kirjutasime \u201evagrant up\u201d ja meil olid virtuaalid \u00fcles t\u00f5usnud. Tahame j\u00f5uda sellisse staadiumisse, kus projekt on Gitis, kirjutame sinna \u201ewerf up\u201d, ja see t\u00f5stab kohaliku koopia sellest projektist, mis on paigaldatud kohalikku mini-Kubisse, koos k\u00f5igi arenduseks vajalike kaustadega. S\u00f5ltuvalt arenduskeelest toimub see erinevalt, kuid ikkagi, et saaks mugavalt teha kohalikku arendust monteeritud failide puhul.<\/p>\n

Meie j\u00e4rgmine samm on tugevalt investeerida arendajate mugavusse<\/b>. Et \u00fche t\u00f6\u00f6riistaga kiiresti kohalikult \u00fcles t\u00f5sta projekt, arendada seda, pushida Gitisse, ning see k\u00e4ivitub samuti stage'ile v\u00f5i testidele, s\u00f5ltuvalt wiret', ja siis sama t\u00f6\u00f6riistaga minna tootmisse. See \u00fchtsus, \u00fchtsustamine, infrastruktuuri reprodutseeritavus kohalikust keskkonnast tootmiseni on meie jaoks v\u00e4ga oluline punkt. Kuid seda hetkel werf'is pole \u2013 alles plaanime teha.<\/p>\n

Aga tee dapp\/werf'ini on alati olnud sama, nagu Kubernetesega alguses. Me kohtusime probleemidega, lahendasime need \u00fcmbersuunamistega \u2013 v\u00e4lja m\u00f5tleme endale lahendusi shellis, milles iganes. Siis p\u00fc\u00fcdsime neid \u00fcmbersuunamisi kuidagi sirgendada, \u00fcldistada ja koondada binaridega, mis me lihtsalt jagame.<\/p>\n

On veel teine vaade kogu sellele loole, analoogiate kaudu. <\/p>\n

Kubernetes on nagu auto raam koos mootoriga. Pole uksi, klaase, raadiovastuv\u00f5tjat, l\u00f5hnastajat \u2013 absoluutselt mitte midagi. Ainult raam ja mootor. Ja on Helm \u2013 see on rool. Lahe, et rool on olemas, aga vaja on ka roolis\u00e4tet, rooliretke, k\u00e4igukasti ja rattaid, ilma nendeta ei saa midagi.<\/p><\/blockquote>\n

\nWerf'i puhul on see veel \u00fcks komponent Kubernetesega. Ainult praegu on meil werf'i alfa-versioonis n\u00e4iteks Helm sisestatud t\u00e4ielikult werf'i sisse, sest me oleme v\u00e4sinud seda ise tegema. Palju p\u00f5hjuseid seda teha, detailselt selle kohta, miks me kompileerisime helm'i koos tilleriga t\u00e4ielikult werf'i sisse, r\u00e4\u00e4gin ma just ettekanne RIT++<\/a><\/noindex>.<\/p>\n

Praegu on werf palju integreeritud komponent. Meil on valmis rool, rooli \u0161tift \u2013 ma ei ole autodes v\u00e4ga p\u00e4dev, aga see on suur plokk, mis lahendab juba piisavalt laia spektri \u00fclesandeid. Me ei pea ise kataloogis tuhnima, valima \u00fchte detaili teise juurde, m\u00f5tlema, kuidas neid omavahel kokku sobitada. Saame valmis kombaini, mis lahendab korraga palju \u00fclesandeid. Kuid sees on k\u00f5ik endiselt avatud l\u00e4htekoodiga koostisosad, kasutatakse Dockerit ehitamiseks, Helmi osa funktsionaalsuse jaoks ja veel mitu muud teeki. See on integreeritud t\u00f6\u00f6riist, et saada kiiresti ja mugavalt kvaliteetne CI\/CD kohe v\u00e4lja kastist.<\/p>\n

Kas on raske toetada Kuberneteset?<\/h2>\n

\n\u2014 Sa r\u00e4\u00e4gid kogemusest, et hakkasite kasutama Kuberneteset, see on teie raam, mootor, ja sellele saab palju erinevaid asju k\u00fclge ehitada: kere, rool, kinnitada pedaalid, istmed. Kerkib k\u00fcsimus \u2013 kui keeruline on teil Kuberneteset toetada? Teie kogemus on rikas, kui palju aega ja ressursse kulub just Kuberneteset toetamisele v\u00f5rreldes k\u00f5igega muuga?<\/b><\/p>\n

Dmitri<\/b>: See on v\u00e4ga keeruline k\u00fcsimus ja et vastata, tuleb m\u00f5ista, mis on toetamine ja mida me Kuberneteselt tahame. V\u00f5ib-olla sa avad selle?<\/p>\n

\u2014 Nii palju kui ma tean ja kuidas ma n\u00e4en, tahab praegu palju meeskondi proovida Kuberneteset. K\u00f5ik sukeldavad end sellesse, installivad selle k\u00f5iki. Mul on tunne, et inimesed ei m\u00f5ista alati selle s\u00fcsteemi keerukust.<\/b><\/p>\n

Dmitri<\/b>: Just niimoodi.<\/p>\n

\u2014 Kui keeruline on v\u00f5tta ja installida Kubernetes t\u00e4iesti nullist nii, et see oleks tootmisvalmis?<\/b><\/p>\n

Dmitri<\/b>: Kuidas sa arvad, kui keeruline on s\u00fcdant vahetada? Ma m\u00f5istan, et k\u00fcsimus on komplitseeriv. K\u00e4epide nuga ja mitte eksida \u2013 see ei ole nii keeruline. Kui sulle \u00f6eldakse, kus l\u00f5igata ja kus \u00f5mmelda, siis on protseduur iseenesest lihtne. Raskeks muutub garanteerida, et iga kord k\u00f5ik \u00f5nnestub.<\/p>\n

Kuberneteset installimine ja t\u00f6\u00f6le panemine on lihtne: t\u0161ik! \u2013 see on installitud, on palju installimise viise. Aga mis juhtub, kui tekivad probleemid?<\/p><\/blockquote>\n

\nAlati tekivad k\u00fcsimused \u2013 mida me veel ei arvestanud? Mida me veel ei teinud? Millised Linuxi tuuma parameetrid me valesti m\u00e4rkisime? Jumal, kas me \u00fcldse m\u00e4rkisime?! Millised Kubernetes komponentid me installisime, aga millised mitte? Tekivad tuhanded k\u00fcsimused ja neile vastamiseks on vaja 15-20 aastat selle valdkonna kogemust.<\/p>\n

Mul on v\u00e4rske n\u00e4ide selle teema kohta, mis v\u00f5ib avada probleemi, kas \"Kas Kubernetes'e toetamine on keeruline?\" M\u00f5ni aeg tagasi m\u00f5tlesime t\u00f5siselt, kas proovida Ciliumit rakendada Kubernetes'e v\u00f5rguna.<\/p>\n

Selgitan, mis on Cilium. Kubernetes'es on palju erinevaid v\u00f5rgusubside rakendusi, ja \u00fcks neist on lausa fantastiline - see on Cilium. Mis on selle m\u00f5te? Tuuma sees ilmus m\u00f5ni aeg tagasi v\u00f5imalus kirjutada tuuma hook'e, mis mingil moel sekkuvad v\u00f5rgusubside ja erinevate teiste s\u00fcsteemide toimimisse ning v\u00f5imaldavad m\u00f6\u00f6da minna suurtest osadest tuumas.<\/p>\n

Linuxi tuumas on ajalooliselt olemas ip rout, net-filter, sildade ja palju erinevaid vanu komponente, mille iga\u00fchel on 15, 20, 30 aastat. \u00dcldiselt nad t\u00f6\u00f6tavad, k\u00f5ik on suurep\u00e4rane, aga praegu on konteinerite liialdamise t\u00f5ttu see nagu 15 tellise torn, mille peal seisad \u00fchel jalal - kummaline tunne. See s\u00fcsteem on ajalooliselt arenenud paljude n\u00fcanssidega, nagu appendiksi areng organismis. Teatud olukordades on esinenud sooritusv\u00f5ime probleeme, n\u00e4iteks.<\/p>\n

On suurep\u00e4rane BPF ja v\u00f5imalus kirjutada tuuma hook'e - kutid kirjutasid oma hook'id tuumale. Pakett siseneva Linuxi tuuma, nad v\u00f5tavad selle kohe sisse, t\u00f6\u00f6tlevad selle ise vajalikul viisil, ilma sildadeta, ilma TCP-ta, ilma IP-stekita - l\u00fchidalt, m\u00f6\u00f6da k\u00f5ige, mis on kirjutatud Linuxi tuumas, ja kohe oksendavad konteinerisse.<\/p>\n

Mis sai? V\u00e4ga lahe j\u00f5udlus, \u00e4gedad funktsioonid - lihtsalt fantastiline! Kuid me vaatame seda ja n\u00e4eme, et igal masinal on programm, mis \u00fchendub Kubernetes'e API-ga ja saadud andmete p\u00f5hjal genereerib C-koodi ning kompileerib binaarfailid, mis laaditakse tuuma, et need hook'id t\u00f6\u00f6taksid kernel space'is.<\/p>\n

Mis juhtub, kui midagi l\u00e4heb valesti? Me ei tea. Selle m\u00f5istmiseks tuleb lugeda kogu see kood l\u00e4bi, m\u00f5ista kogu loogikat, ja see on uskumatult keeruline. Aga teisalt, on need sillad, net-filter'id, ip rout - ma ei ole nende l\u00e4htekoodiga tutvunud, ja meie ettev\u00f5ttes t\u00f6\u00f6tavad 40 inseneri samuti. V\u00f5ib-olla m\u00f5istavad m\u00f5ned osad v\u00e4hesed.<\/p>\n

Ja mis vahet seal on? Tundub, et on olemas ip rout, Linuxi tuum ja uus t\u00f6\u00f6riist - mis vahet seal on, me ei m\u00f5ista kumbagi. Kuid me kardame uut kasutada - miks? Sest kui t\u00f6\u00f6riist on 30 aastat vana, siis 30 aastaga on k\u00f5ik vead leitud, k\u00f5ikidele takistustele astutud ja pole vaja k\u00f5igest teada - t\u00f6\u00f6tab nagu must kast ja t\u00f6\u00f6tab alati. K\u00f5ik teavad, kuhu panna diagnostiline kruvikeeraja, millal k\u00e4ivitada tcpdump. K\u00f5ik tunnevad diagnostilisi t\u00f6\u00f6riistu ja m\u00f5istavad, kuidas see komponentide kogum Linuxi tuumas t\u00f6\u00f6tab - mitte kuidas see on \u00fcles ehitatud, vaid kuidas seda kasutada.<\/p>\n

Aga \u00fcli\u00e4ge Cilium ei ole 30 aastat vana, see ei ole veel valminud. Kubernetesel on sama probleem, koopia. Nii Cilium installitakse suurep\u00e4raselt kui ka Kubernetes, aga kui midagi l\u00e4heb tootmisj\u00e4rgus valesti, kas te suudate kriitilises olukorras kiiresti aru saada, mis valesti l\u00e4ks? <\/p>\n

Kui me k\u00fcsime, kas Kuberneteset on keeruline hallata - ei, see on v\u00e4ga lihtne, ja jah, uskumatult keeruline. Kubernetes t\u00f6\u00f6tab imeliselt iseenesest, aga miljardite n\u00fcanssidega.<\/p><\/blockquote>\n

<\/p>\n

M\u00f5te \"Mul vedas\"<\/h2>\n

\n- Kas on olemas ettev\u00f5tteid, kus need n\u00fcansid peaaegu garanteeritult ilmuvad? Oletame, et Yandex \u00fcleeestiliselt viib k\u00f5ik teenused Kubernetesesse, seal on tohutu koormus.<\/b><\/p>\n

Dmitri<\/b>: Ei, see ei ole ju jutt koormusest, vaid k\u00f5ige lihtsamatest asjadest. N\u00e4iteks, meil on Kubernetes, me oleme sinna rakenduse paigaldanud. Kuidas m\u00f5ista, et see t\u00f6\u00f6tab? Valmiskujul t\u00f6\u00f6riista, et teada saada, et rakendus ei kokku kuku, lihtsalt pole. Valmiskujul s\u00fcsteemi, mis saadab h\u00e4ireid - ei ole, tuleb need h\u00e4ired ja iga graafik seadistada. Ja me uuendame Kuberneteset.<\/p>\n

Ubuntu 16.04 on enduru. See on vana versioon, kuid me oleme endiselt sellel, kuna seal on LTS. Seal on systemd, mille n\u00fcanss on see, et ta ei puhasta C-gruppe. Kubernetes k\u00e4ivitab podid, loob C-gruppe, seej\u00e4rel kustutab podid ja kuidagi j\u00e4\u00e4b nii, et ma ei m\u00e4leta detaile, vabandust, et systemd sildid j\u00e4\u00e4vad alles. See toob kaasa selle, et aja jooksul hakkab iga masin tugevalt tarduma. See pole isegi k\u00fcsimus highloadi kohta. Kui k\u00e4ivitatakse pidevaid pode, n\u00e4iteks kui on Cron Job, mis pidevalt genereerib pode, siis masin Ubuntu 16.04 hakkab n\u00e4dala p\u00e4rast tarduma. Seal on pidevalt k\u00f5rge laadimise keskmine, kuna on loodud hulk C-gruppe. See on probleem, millega silmitsi seisab iga\u00fcks, kes lihtsalt installib Ubuntu 16 ja selle peale Kubernetes.<\/p>\n

Oletame, et ta kuidagi uuendab systemd v\u00f5i midagi muud, kuid Linuxi tuumas on kuni 4.16 veel naljakam \u2013 C-gruppide kustutamisel lekkivad nad tuumas ja tegelikult ei eemaldu. Seet\u00f5ttu on p\u00e4rast kuu aega selle masinaga peaaegu v\u00f5imatu vaadata statistikat m\u00e4lu osas podide kohta. Me v\u00f5tame faili, veereme programmis ja \u00fcks fail veereb 15 sekundit, kuna tuum vajab v\u00e4ga kaua aega, et arvutada endas miljonit C-gruppi, mis n\u00e4iliselt on kustutatud, kuid ei ole \u2013 nad lekkivad.<\/p>\n

Selliseid pisiasju on endiselt v\u00e4ga palju seal ja siin. See ei ole k\u00fcsimus, millega suurfirmad v\u00f5ivad aeg-ajalt silmitsi seista v\u00e4ga suurte koormuste korral \u2013 ei, see on igap\u00e4evaste asjade k\u00fcsimus. Inimesed v\u00f5ivad niimoodi kuude viisi elada \u2013 installisid Kubernetes'i, juurutati rakendus \u2013 tundub, et t\u00f6\u00f6tab. Paljude jaoks on see normaalne. Nad isegi ei saa teada, et rakendus kukub kunagi mingil p\u00f5hjusel, h\u00e4ire ei j\u00f5ua, kuid see on nende normaalsus. Varem elasime virtuaalmasinatel ilma j\u00e4lgimiseta, n\u00fc\u00fcd kolisime Kubernetes'esse samuti ilma j\u00e4lgimiseta \u2013 mis see muudab?<\/p>\n

K\u00fcsimus on selles, et kui me k\u00e4ime j\u00e4\u00e4 peal, ei tea me kunagi tema paksust, kui me ei ole seda eelnevalt m\u00f5\u00f5tnud. Paljud k\u00e4ivad ja ei vaeva end, sest nad on varem k\u00e4inud.<\/p>\n

Minu vaatenurgast on n\u00fcanss ja keerukus mis tahes s\u00fcsteemi kasutamisel selles, et tagada, et j\u00e4\u00e4 paksus on kindlasti piisav, et meie \u00fclesandeid lahendada. Just sellest on jutt.<\/p><\/blockquote>\n

\nIT-sektoris paistab, et liiga palju on l\u00e4henemist \"V\u00f5ib-olla \u00f5nnestub\". Palju inimesi installib tarkvara ja kasutab teeke lootuses, et neil vedada. \u00dcldiselt vedab paljusid. T\u00f5en\u00e4oliselt seet\u00f5ttu see toimib.<\/p>\n

- Minu pessimistlikul hinnangul n\u00e4eb see v\u00e4lja nii: kui riskid on suured ja rakendus peab t\u00f6\u00f6tama, siis on vajalik toetus \"Flantilt\", v\u00f5ib-olla Red Hatilt, v\u00f5i vajame oma sisemist meeskonda, mis on spetsiaalselt Kubernetes'ega tegelemiseks, kes on valmis seda juhtima.<\/b><\/p>\n

Dmitri<\/b>: Objektiivselt on see t\u00f5si. V\u00e4ikesel meeskonnal on riske ise Kubernetes'esse siseneda.<\/p>\n

Kas me vajame konteinerite kasutust?<\/h2>\n

\n- Kas sa saad r\u00e4\u00e4kida, kui laialdaselt Kubernetes Venemaal \u00fcldiselt levinud on?<\/b><\/p>\n

Dmitri<\/b>: Mul ei ole neid andmeid ja ma ei ole kindel, kas kellelgi need \u00fcldse olemas on. Me r\u00e4\u00e4gime: \"Kubernetes, Kubernetes\", kuid on ka teine vaatenurk sellele k\u00fcsimusele. Kui laialdaselt konteinerid levivad, ma ei tea, kuid tean \u00fchte numbrit internetis olevatest raportitest, et 70% konteineritest orkestreeritakse Kubernetes'ega. See oli usaldusv\u00e4\u00e4rne allikas piisavalt suure valimi kohta globaalses mastaabis.<\/p>\n

J\u00e4rgmiseks k\u00fcsimus - kas me vajame konteinerite kasutust?<\/b> Minu isiklik tunne ja \u00fcldine seisukoht ettev\u00f5tte \"Flant\" osas on see, et Kubernetes on de facto standard.<\/p>\n

Mitte midagi peale Kubernetes'e ei tule.<\/p><\/blockquote>\n

\nSee on absoluutne m\u00e4ngumuutus infrastruktuuri haldamise valdkonnas. Lihtsalt absoluutne - enam ei ole Ansible'i, Chefi, virtuaalmachinesid, Terraform'i. Ma ei hakka r\u00e4\u00e4kima vanadest k\u00e4sit\u00f6\u00f6meetoditest. Kubernetes on absoluutne muutja<\/b>, ja n\u00fc\u00fcd j\u00e4\u00e4b ainult nii.<\/p>\n

Selge, et m\u00f5nedel kulub paar aastat, teistel paar aastak\u00fcmmet, et seda m\u00f5ista. Mul ei ole kahtlusi, et ei tule midagi muud peale Kubernetes'e ja selle uue vaate: me ei h\u00e4iri enam operatsioonis\u00fcsteemi, vaid kasutame infrastructure as code<\/b>, ainult et mitte koodiga, vaid yml-ga - deklareeritud infrastruktuuri. Mul on tunne, et nii j\u00e4\u00e4b alati.<\/p>\n

- Ehk siis ettev\u00f5tted, kes ei ole veel Kubernetes'ele \u00fcle l\u00e4inud, peavad kindlasti sellele \u00fcle minema, v\u00f5i j\u00e4\u00e4vad unustusse. Kas ma sain sind \u00f5igesti aru?<\/b><\/p>\n

Dmitri<\/b>: See, that's not entirely correct. For instance, if we need to launch a DNS server, it can run on FreeBSD 4.10 and work perfectly for 20 years. Just operate and that's it. Perhaps after 20 years, we might need to upgrade something once. If we're talking about software in the format that we launched and it actually works for many years without any updates, without any changes, then, of course, Kubernetes won't be there. It's simply not needed.<\/p>\n

Everything related to CI\/CD\u2014anywhere Continuous Delivery is required, where version updates are needed, where active changes are necessary, anywhere where resilience must be established\u2014only Kubernetes fits here.<\/p><\/blockquote>\n

<\/p>\n

About microservices<\/h2>\n

\n\u2014 Here I have a slight dissonance. To work with Kubernetes, both external and internal support are needed\u2014that's the first point. The second is that when we're just starting development, we're a small startup, we have nothing yet, developing for Kubernetes or even for a microservice architecture can be challenging, and it's not always justified economically. I'm curious about your opinion\u2014should startups right from the start begin writing for Kubernetes or should they first create a monolith and then transition to Kubernetes?<\/b><\/p>\n

Dmitri<\/b>: Great question. I have a presentation about microservices. \u201cMicroservices: size matters.\u201d<\/a><\/noindex> I've encountered many times that people try to hammer nails with a microscope. The approach itself is correct; we design our internal software projects precisely this way. But when doing so, one must clearly understand what they are doing. Most of all in microservices, I dislike the term \u201cmicro.\u201d It historically emerged, and for some reason, people think that micro means very small, smaller than a millimeter, like a micrometer. That's not the case.<\/p>\n

For example, there's a monolith that 300 people write, and everyone involved in the development understands that there are issues, and it needs to be broken down into micro-pieces\u2014about 10, with each being written by at least 30 people. This is important, necessary, and cool. However, when a startup approaches us with 3 very cool and talented guys having written 60 microservices on a whim, I invariably look for some calming medicine.<\/p>\n

Minu arvates on sellest juba r\u00e4\u00e4gitud tuhanded kordi \u2014 oleme saanud hajutatud monoliidi \u00fches v\u00f5i teises vormis. See pole majanduslikult m\u00f5ttekas, see on \u00fcldiselt v\u00e4ga keeruline. Lihtsalt olen seda nii palju kordi n\u00e4inud, et mul on t\u00f5eliselt valus, seet\u00f5ttu j\u00e4tkan sellest r\u00e4\u00e4kimist.<\/p>\n

Algsesse k\u00fcsimusse, et konflikt eksisteerib selle vahel, et Kubernetes on hirmutav kasutada, sest pole selge, mis seal v\u00f5ib puruneda v\u00f5i mitte t\u00f6\u00f6tada, ja teisest k\u00fcljest on selge, et k\u00f5ik liigub sinna ja midagi muud ei saa olema. Vastus on kaaluda kasu, mis tuleb, ja \u00fclesannete mahtu, mille te suudate lahendada<\/b>. See on \u00fche kaalu poole. Teiselt poolt on riskid, mis on seotud seiskamise v\u00f5i reageerimisaega, k\u00e4ttesaadavuse taset \u2014 t\u00f6\u00f6 n\u00e4itajate v\u00e4henemisega.<\/p>\n

Siin on asi nii \u2014 kas me liigume kiiresti edasi ja Kubernetes v\u00f5imaldab paljusid asju teha palju kiiremini ja paremini, v\u00f5i kasutame usaldusv\u00e4\u00e4rseid, ajaga t\u00f5estatud lahendusi, kuid liigume palju aeglasemalt. Selle valiku teeb iga ettev\u00f5te. Seda v\u00f5ib vaadelda nagu radade hulgas \u2014 kui l\u00e4hed esmakordselt, v\u00f5id kohata madu, tiigrit v\u00f5i raevu t\u00e4is m\u00e4gra, ja kui oled k\u00e4inud 10 korda \u2014 oled raja l\u00e4bi jalutanud, oksad eemal viinud ning on lihtsam k\u00e4ia. Iga korraga muutub rada laiemaks. Hiljem on see asfalttee, ja veel hiljem ilus bulvar.<\/p>\n

Kubernetes ei seisa paigal. J\u00e4lle k\u00fcsimus: Kubernetes, \u00fchelt poolt, on 4-5 binaarfaili, teiselt poolt \u2014 see on kogu \u00f6kos\u00fcsteem. See on ops\u00fcsteem, mis meil masinates t\u00f6\u00f6tab. Mis see on? Ubuntu v\u00f5i Curios? See on Linuxi kernel, hunnik lisakomponente. K\u00f5ik need asjad on siin \u00fche m\u00fcrkmaoga tee pealt eemaldatud, seal on aed pandud. Kubernetes areneb v\u00e4ga kiiresti ja d\u00fcnaamiliselt ning riskide maht, avastamata ala iga kuuga v\u00e4heneb ja seega need kaalud saavad tasakaalu.<\/p>\n

Vastates k\u00fcsimusele, mida teha idufirmaga, \u00fctleksin, et tulge Flantele, makske 150 000 rubla ja saage v\u00f5tmed k\u00e4tte DevOps teenus. Kui olete v\u00e4ike idufirma, kus tegutseb paar arendajat, siis see toimib. Selle asemel, et palgata oma DevOps, kellele tuleb \u00f5petada, kuidas teie probleeme lahendada ja maksta selle aja eest palka, saate v\u00f5tmed k\u00e4tte lahenduse k\u00f5ikidele k\u00fcsimustele. Jah, on m\u00f5ned miinused. Meie, kui v\u00e4line teenusepakkuja, ei saa olla nii kaasatud ja kiiresti reageerida muudatuste tegemisele. Kuid meil on tohutult kogemusi, valmis praktikaid. Me garanteerime, et igas olukorras m\u00f5istame me kiirelt ja lahendame iga Kubernetes'e k\u00fcsimuse. <\/p>\n

Ma soovitan kategooriliselt idufirmadele ja juba v\u00e4lja kujunenud \u00e4ridele v\u00e4listada seni, kuni suudate eraldada v\u00e4hemalt 10-mehelise tegevusmeeskonna, sest muidu pole sellel m\u00f5tet. See on kategooriliselt m\u00f5istlik \u00e4ri v\u00e4ljastada.<\/p><\/blockquote>\n

<\/p>\n

Amazonist ja Google'ist<\/h2>\n

\n\u2014 Kas saab Amazonilt v\u00f5i Googlest pakutavat lahendust v\u00e4listeenuse osutajana k\u00e4sitleda?<\/b><\/p>\n

Dmitri<\/b>: Jah, loomulikult, see lahendab teatavad k\u00fcsimused. Kuid on n\u00fcansse. Sa pead ikkagi aru saama, kuidas seda kasutada. N\u00e4iteks on Amazon AWS t\u00f6\u00f6korralduses tuhandeid pisiasju: Load Balancer tuleb eelnevalt ette valmistada v\u00f5i paluda, et \u201emeie juurde tuleb liiklust, palun valmistage Load Balancer ette!\u201d Need n\u00fcansid tuleb teada.<\/p>\n

Kui p\u00f6\u00f6rdute inimeste poole, kes sellega tegelevad, saate kohe n\u00e4iliselt k\u00f5ik t\u00fc\u00fcpilised asjad kaetud. Praegu on meil 40 inseneri, aastaks l\u00f5pus on neid t\u00f5en\u00e4oliselt 60 \u2014 me oleme k\u00f5igi nende asjadega juba kokku puutunud. Isegi kui m\u00f5nel projektil seisame silmitsi uue probleemiga, k\u00fcsime me juba kiirelt \u00fcksteiselt, et teada, kuidas lahendada.<\/p>\n

T\u00f5en\u00e4oliselt on vastus selline \u2014 jah, hosted-ajalugu lihtsustab mingi osa. K\u00fcsimus on selles, kas olete valmis nende hostide usaldama ja kas nad lahendavad teie probleemid. Amazon ja Google on h\u00e4sti t\u00f5estanud oma v\u00f5imeid. K\u00f5ikide meie juhtumite puhul \u2014 kindlasti. Meil pole rohkem positiivseid kogemusi. K\u00f5ik teised pilved, millega me oleme proovinud t\u00f6\u00f6tada, loovad v\u00e4ga palju probleeme \u2014 ja Ager, ja k\u00f5ik, mis on Venemaal, ja k\u00f5ikv\u00f5imalikud OpenStack erinevates elluviimistes: Headster, Overage \u2014 k\u00f5ik, mida soovite. Need k\u00f5ik loovad probleeme, mida ei taha lahendada.<\/p>\n

Seega, vastus on jah, kuid tegelikult ei ole k\u00fcpsed hosted-lahendused kuigi palju.<\/p>\n

Kelle on Kubernetes vajalik?<\/h2>\n

\n\u2014 Aga kellele on Kubernetes vajalik? Kes peaks juba Kubernetesile \u00fcle minema, kes on t\u00fc\u00fcpiline klient, kes tuleb just Kubernetes'i p\u00e4rast?<\/b><\/p>\n

Dmitri<\/b>: K\u00fcsimus on huvitav, sest praegu just Kubernetes'e lainel tulevad meile paljud: \"Me teame, et teil on Kubernetes, tehke meile!\". Vastame neile: \"H\u00e4rrad, me ei tegele Kubernetes'ega, me tegeleme tootmise ja k\u00f5ikide sellega seotud asjadega\". Sest tootmise tegemine ilma kogu CI\/CD ja selle looga on praegu lihtsalt v\u00f5imatu. K\u00f5ik on loobunud eristamisest, et meil on arendamine arendamine ja seej\u00e4rel opereerimine opereerimine.<\/p>\n

Meie kliendid ootavad erinevaid asju, kuid k\u00f5ik ootavad mingit head imet, et neil on mingid probleemid ja praegu \u2013 hop! \u2013 Kubernetes lahendab need. Inimesed usuvad imedesse. Nad m\u00f5istavad m\u00f5istusega, et imet ei toimu, kuid hingega loodavad \u2013 \u00e4kki see Kubernetes lahendab k\u00f5ik, temast r\u00e4\u00e4gitakse nii palju! \u00c4kki ta n\u00fc\u00fcd \u2013 t\u0161ah! \u2013 ja h\u00f5bedane kuul, t\u0161ah! \u2013 ja meil on 100% t\u00f6\u00f6aeg, k\u00f5ik arendajad saavad 50 korda v\u00e4lja lasta, mis iganes tootmisse ja see ei kuku. Kokkuv\u00f5ttes, ime!<\/p>\n

Kui sellised inimesed meile tulevad, \u00fctlemme: \"Vabandage, kuid imet ei juhtu\". Terve olema, tuleb h\u00e4sti toituda ja spordiga tegeleda. Usaldusv\u00e4\u00e4rse tootmise jaoks tuleb see usaldusv\u00e4\u00e4rselt \u00e4ra teha. Mugava CI\/CD jaoks tuleb see selliseks teha. See on palju t\u00f6\u00f6d, mida tuleb teha.<\/p>\n

Vastates k\u00fcsimusele, kellele on Kubernetes vajalik \u2013 Kubernetes ei ole kellelegi vajalik.<\/p><\/blockquote>\n

\nM\u00f5nedel inimestel on vale arusaam, et neil on Kubernetes vajalik. Inimestel on vaja, neil on s\u00fcgavalt juurdunud vajadus l\u00f5petada m\u00f5tlemine, tegelemine ja huvitamine k\u00f5ikide infrastruktuuri probleemidega ja nende rakenduste k\u00e4itamise probleemidega. Nad tahavad, et rakendused lihtsalt t\u00f6\u00f6taksid ja lihtsalt deploy'itakse. Nende jaoks on Kubernetes lootus, et nad l\u00f5petavad kuulmast lugusid, et \"me olime seal lagunemas\", v\u00f5i \"me ei saa v\u00e4lja minna\", v\u00f5i midagi muud.<\/p>\n

Meile tuleb tavaliselt tehniline direktor. Temalt k\u00fcsitakse kahte asja: \u00fchelt poolt, andke meile funktsioonid, teiselt poolt \u2013 stabiilsus. Me pakume seda enda peale v\u00f5tta ja teha. H\u00f5bedane kuul, t\u00e4psemalt h\u00f5betatud, on see, et sa l\u00f5petad nende probleemide \u00fcle m\u00f5tlemise ja aja raiskamise. Sul on spetsiaalsed inimesed, kes selle k\u00fcsimuse lahendavad.<\/p>\n

Vormulatsioon, et meil v\u00f5i kellelgi on vaja Kubernetes't - on vale.<\/p><\/blockquote>\n

\nKubernetes on adminnidele v\u00e4ga vajalik, sest see on t\u00f5eliselt huvitav m\u00e4nguasi, millega saab m\u00e4ngida, nokitseda. Olgem ausad - k\u00f5ik armastavad m\u00e4nguasju. Me k\u00f5ik oleme kuskil lapsed, ja kui me n\u00e4eme uut, tahame sellega m\u00e4ngida. M\u00f5nel on see juba v\u00e4lja l\u00fclitatud, n\u00e4iteks adminni t\u00f6\u00f6s, sest on juba m\u00e4nginud ja on nii t\u00fcdinud, et ei taha enam. Kuid see ei ole kellelgi t\u00e4ielikult v\u00e4lja l\u00fclitatud. N\u00e4iteks, kui mulle m\u00e4nguasjad s\u00fcsteemiadministreerimise ja DevOpsi valdkonnas juba ammu ei meeldi, siis armastan ma ikkagi m\u00e4nguasju, ostan ikka uusi. K\u00f5ik inimesed tahavad mingil viisil ikka mingeid m\u00e4nguasju.<\/p>\n

\u00c4rge m\u00e4ngige tootmisprotsessiga. Midagi, mida ma kategooriliselt ei soovita teha ja mida ma praegu massiliselt n\u00e4en: 'Ah, uus m\u00e4nguasi!' - kiirustame seda ostma, ostsime ja: 'V\u00f5tame selle n\u00fc\u00fcd kooli, n\u00e4itame k\u00f5ikidele s\u00f5pradele'. \u00c4rge tehke nii. Vabandan, mul on lihtsalt lapsed, nad kasvavad, ma m\u00e4rkasin pidevalt midagi lastest, tajun seda enda juures ja \u00fcldistan seej\u00e4rel ka teistel.<\/p>\n

L\u00f5plik vastus: Kubernetes't ei ole teil vaja. Teil tuleb lahendada oma probleemid.<\/p><\/blockquote>\n

\nSaame saavutada seda, et:<\/p>\n