Pragmatism vs Kubernetes

Ainult väike ülevaade minu haigest redigeerimisoskusest

Mõtlesin mõnda aega selle pealkirja üle mõeldes - see peaks tõesti olema “Pragmatism ja Kubernetes”, sest mõnel juhul need kaks kattuvad. Kuid ma arvasin, et versus oleks lõbusam ja provotseeriv (tore viis öelda CLICKBAIT). Kes see mees on ja mis ta Kubernetese vastu sai? Ma arvan, et mul on mõned selgitused, mida teha.

Nüüd enne selle artikli kirjutamist tegin kiire otsingu, kas keegi on juba midagi sarnast kirjutanud. See artikkel sai lähedaseks ja esitas õiged küsimused, kuid ma ei suutnud leida ühtegi, mis sõnastaks seda, mida ma üritasin öelda.

Otsimise käigus märkisin ka mõnda populaarsemat probleemi, mida tööstuse inimesed näevad Kubernetes lahendamas. Arvasin, et nende lagundamine ja arutamine võiks olla heaks artikli vorminguks.

Kõigepealt väike kontekst, lihtsalt selleks, et te teaksite, et ma pole mingil konkreetsel viisil erapoolik ja ka minu arvamuse taga on vähemalt mingid eelised. Peaksin selle postituse eesliidetama, öeldes, et olen ehitanud kasutuselevõtu torujuhtmeid / tööriistu ja hallanud rakendusi pilves (räägin peamiselt AWS-i vaatenurgast) mitmel erineval infrastruktuurimustril. EC2-d koos rakenduse AMI-dega, dokk EC2-s, ECS-is, Nomadis, Kuberneteses, EC2-d, mille on konfigureerinud Puppet ja nii palju kui tahaksin unustada; EC2-d juurutab, konfigureerib ja korraldab Ansible (pimedad päevad).

Aga kas sellest piisab, las see on?

Kiirus

Kiirus on paljudes aspektides üks suuremaid muutuste põhjustajaid tehnoloogiaettevõtetes, eriti nüüd, kui kõik on joonud Agile Kool Aid. Vajame kiireid juurutusi lühikeste tagasisideahelate jaoks, kiiret taastumist nende mõne täiendava üheksa jaoks meie tööajas, kiiretes jõudlusrakendustes, loend jätkub.

On mitmeid viise, kuidas Kubernetes lauale kiiruse toob. Rakendused paigutatakse klastrisse kaustade kaudu. Need on sisuliselt konteinerite komplekt, mis skaleeruvad omavahel, on lokaalselt võrku ühendatud ja jagavad ühte IP-aadressi ja porti. Võite neid mõelda dokkide koostamise juurutamisele, kui olete neid juba varem kasutanud. Kuna need kõik koonduvad konteineritesse, pakitakse teie rakendus ja selle keskkond dokkide piltidesse. See tähendab väga kiireid alglaadimisaegu (sõltuvalt sellest, kuidas te muidugi oma rakenduse initsialiseerite). See tähendab, et rakenduse uue versiooni juurutamisel võtab juurutamine (vähemalt) nii kaua kui vaja:

  • Koostage oma doki pilt
  • Laadige oma doki pilt üles doki registrisse
  • Määrake, millises sõlmes teie konteinerit käitatakse
  • Vormindage oma konteiner

Selle juurutamise optimeerimiseks on muidugi palju viise (see eeldab ka seda, et teil on klastris piisavalt ressursse ja te ei pea horisontaalset skaleerimist ootama), kuid ideaaljuhul on see kiireim viis, kuidas saate oma rakenduse juurutada. Loomulikult võimaldab see konstruktsioon kiirust ka teistes aspektides, näiteks ajaliselt. Uute rakenduse esinemisjuhtude lisamiseks lisakoormuse käsitlemiseks on vaja ainult viimase kahe sammu toimumist (vajadusel klastri skaleerimise aeg). Minimaalse suurusega dokipilt koos lihtsa alglaadimisskriptiga annab välkkiire juurutamise.

Seda öeldes on siin mõned punktid, mida tuleks kaaluda:

Esiteks ei ole need funktsioonid Kubernetes'i funktsioonid - need on mis tahes konteineripõhise rakenduse funktsioonid. Lisaks pole Kubernetes sugugi lihtne süsteem. Klastri käitamisel tuleb arvestada nii paljude erinevate aspektidega (nagu me arutame hiljem). Nii et kui teie eesmärk on kiirus, saab selle saavutada palju lihtsamate lahendustega. Võtke näiteks ECS kui lihtne üleminek virtuaalsetelt masinatelt konteineritele nii sellel töötavate rakenduste arendajatele kui ka seda töötavatele ja toetavatele inseneridele (sõltub muidugi teie praegusest seadistusest). Oluline on meeles pidada, et sellise tehnoloogia kasutuselevõtt ei tähenda ainult seda, et teie taristuinsenerid peavad õppima platvormi kasutamist. Devs peavad õppima, kuidas kubectl, rool ja midagi minikube taolist, kui nad tahaksid näha, kuidas nende kood lokaalselt töötab. Kõik see võtab aega (ja vähendab seega kiirust)

Teiseks (ja tõenäoliselt kõige tähtsam), kuidas aitab teie juurutamise kiirendamine tegelikult ettevõtet aidata? Päeva lõpus makstakse meile kõigile, et nad annaksid oma ettevõtetele väärtust - kas teie ja teie meeskonna aja parim kasutamine aitab säästa paar minutit teie juurutamisajast? Mõnes organisatsioonis absoluutselt, kuid võite leida, et enamikus organisatsioonides ei ole see kitsaskoht. Vaadakem lihtsustatud tarkvaraarenduse elutsüklit (SDLC).

  • Esiteks tuleb kindlaks teha probleem, mis vajab lahendamist.
  • Seejärel tuleb ülesanne tähtsuse järjekorda seada ja arendajatele määrata.
  • Seejärel kavandavad ja arendavad seadmed lahenduse.
  • Kavandatud lahenduse testimine ja kinnitamine (vajadusel) toimub.
  • Lahendus on juurutatud ja valideeritud.

Ja tsükkel jätkub.

Kui teie eesmärk on kiirus, on üsna selge, mida peame tegema - leidke SDLC kitsaskoht ja kiirendage seda. Kui kiirendate juurutusaega 5 minuti võrra, kuid juurutamise testimiseks või kinnitamiseks kulub mitu päeva, saate lõpuks kasutusele hulga juurutusi, mis on valmis testimiseks / kinnitamiseks. Tõenäoliselt olete seda tüüpi kontseptsioone näinud näiteks võrgunduses, andmebaaside / rakenduste toimivuses jne, nii et teie ettevõtte kitsaskohtade tuvastamine peaks olema üsna lihtne.

Ma hoiatasin sind

Kas kõrgem juhtkond on kaotanud usalduse väljaannete vastu, kuna nad on kogenud liiga palju halbu? Siis peaksite kindlasti töötama selle nimel, et teil oleks parem, automatiseeritud testimine ja jälgimine, et juurutamine sujuks.

Kas tootejuhtide otsustamine, millised probleemid tuleb lahendada, võtab võib-olla liiga kaua aega? Või kinnitada, et rakendatud lahendus töötab? Siis peate tõenäoliselt nende otsuste tegemiseks töötama sobivate andmete kogumisega.

Kas võtab liiga kaua aega, et välja selgitada, miks lahendus ei toimi nii hästi, kui arvasite, et peaks? Võib-olla peaksite oma infrastruktuuri / rakenduste jälgitavuse suurendamise nimel pingutama.

Seal on nii palju asju, mida saab kiirendada, kuid saate sellest siiski aru.

Ühtsed töövood

See on veel üks tegur, mida Kubernetesest rääkides näib palju olevat. See rakendab palju mustreid, mis puudutavad seda, kuidas arendajad sellega suhtlevad ja lõpuks oma koodi käitavad. Üks peamisi viise, kuidas seda teha, on nende kaudu pakutavate API-de kaudu. Kubectl toimib klastri liidesena, kontrollides arendajate juurdepääsu ja võimaldades neil kontrollida klastris toimuvat, haarata ja luua saladusi ning mis kõige tähtsam - oma rakendused juurutada. Roolidiagrammid ja dokumendifailid võimaldavad arendajatel oma juurutusplaanid mallida ja määratleda täpselt, kuidas ja kus nende kood käivitatakse - isegi juhtida, kuidas välist ja sisemist liiklust sellele suunatakse. Samuti sunnib see arendajaid mõtlema, kui palju ressursse on nende koodi käivitamiseks vaja (ja loodetavasti ka mõelda, kuidas seda optimeerida!). Kõik, kes otsustavad Kubernetesit kasutada, järgivad samu mustreid.

Juurutamised ja konfiguratsioonid on nii arendajate kui ka „DevOps people“ vahel hõlpsasti mõistetavad. Lisaks võimaldavad teie jälgimis- ja jälgimislahendused (võib-olla midagi lihtsat, näiteks mõõdikud api + prometheus + grafana), kui need on hästi välja töötatud, klastrist paljastada sama infrastruktuuri jõudluse ja APM-i mõõdikud, samuti rakenduse logid. Nii saavad arendajad valida, mida nad sooviksid, et nende rakendused paljastaks, ja näha kõike samas kohas.

Need punktid on kõik äärmiselt kaalukad ja eriti kui viibite DevOps-i ruumis, võib teil sel hetkel suu vahutav olla. See kõik hakkab kõlama natuke nagu tehniline utoopia.

Kuid enne, kui meie pead pilvedes liiga kõrgele tõusevad (vaata, mida ma seal tegin?), Vaatame lähemalt tegelikkust. Kui te pole seda juba märkama hakanud, kõlab põhimõtteliselt kõik minu punktid järgmiselt:

Jah, kuid Kubernetes ei lahenda seda probleemi.

Ja see pole erand. Mainisin, et “DevOps space” inimesed köidavad ülaltoodud funktsioone eriti seetõttu, et see on põhimõtteliselt kõigi DevOps'i põhimõtete eesmärk. Organisatsioon, kus arendajad mõistavad ja juurutavad oma juurutamist. Teage, kuidas häälestada oma rakenduste testimiseks ja silumiseks vajalikku jälgimist. Kaaluge ja optimeerige ressursikasutust. Saate üldiselt aru, kus nende kood sobib infrastruktuuriga. Asi on selles et; seda on palju vaja küsida ja ükski selline asi ei juhtu lihtsalt võluväel, kui lülitate sisse Kubernetes'i sisselülituse. Palju see on suhtumise muutmine ning võtab palju aega ja avatust, et arendada usaldust ja kohanemiseks vajalikke oskusi. Leiate, et Kubernetese kasutuselevõtmisel seisate arendajate vastu sama palju (kui mitte rohkem) vastupanu kui mis tahes muul platvormil, mida proovite volitada. Eriti kuna Kubernetes rakendab kõiki ülaltoodud tavasid ühe suure suurepärase pauguga, selle asemel, et lubada teil neid tutvustada korraga.

Kubernetes ei õpeta arendajatele ressursside kasutamist optimeerima.

Kubernetes ei pane arendajaid otsustama, et nad tahavad paremini mõista infrastruktuuri, milles nende kood töötab.

Kubernetes ei näita arendajatele standardiseeritud, korratavate juurutuste eeliseid. Või valu, kui neid pole.

Kui need asjad on saavutatud, pakub Kubernetes ühte lahendust. Mitte mingil juhul ei lahenda see maagiliselt teie probleeme ühtsete töövoogude ja DevOps-tavadega üldiselt. Leiate, et kui te nii arvate - rakendate Kubernetes ja siis on teil n + 1 töövoog, mida teie insenerid peavad õppima, hooldama ja toetama.

Skaala ja maksumus

Rühmitasin need kaks viimast punkti, kuna nad on üksteisest väga sõltuvad.

Kõige tavalisem argument skaala kohta, mida ma näen, on järgmine:

Noh, Google saab seda kasutada oma ulatusega teenuste jaoks, nii et see on osutunud usaldusväärseks igas mastaabis

Ehkki lihtne, on see täiesti mõistlik argument ja see on tegelikult väga lihtne viis valida, millisele tehnoloogiale teie ettevõte toetub. Kuid seda tuleks võtta ka koos soola teraga. Jah, kui teie ettevõte töötab Google'i skaalal ja teil on piisavalt insenere, et pühenduda Kubnernetesi klastrite käitamisele, siis tehke see igal juhul laiali. Kuid olgem ausad, peaaegu kõik, kes seda postitust loevad, töötavad ettevõttes, mis teenib suurusjärgus vähem liiklust kui Google. See on ilmne, kuid insenerid plaanivad tavaliselt ette ja tahavad, et oleks võimalik skaleerida, siis miks mitte valida lahendus, mis meie teada nende probleemidega ei puutu. Noh, kiire google'i otsing näitab teile, et peaaegu iga doki orkestreerimissüsteem on märgistatud ja tõestatud, et see töötab sellises mõõtkavas, nagu enamik inimesi kunagi lähedale ei jõua (nt nomaad, doki sülem, ECS).

Ma kuulen teid juba - aga selleks on vaja palju tööd ja näpistamist.

Kubernetes pole erand.

Google ei ehitanud Kubernetesit, lülitas selle sisse ja seadistas selle unustama. Kubernetese peal edukaks sõitmiseks on vaja nii arendajatelt kui ka pilve- / taristuinseneridelt tohutult tööd (selle nimel hääletavad palju inimesi). Sageli on eksiarvamus, et Kubernetes on see müstiline ükssarvik, mis muudab teie rakendused võitmatuks - vastupidavaks riketele ja immuunseks skaleerimise probleemidele. See ei vasta vähimalgi määral tõele ja ma arvan, et pettumus ootab neid, kes arvavad, et see nii on.

Maksumusel - idee on jällegi lihtne, kui ma saan oma rakenduste eksemplare käivitada sama hulga virtuaalsete masinatega, maksan serverite eest vähem. Lisaks sellele raiskan vähem raha, kui mul on arukas süsteem neid eksemplare ja virtuaalseid masinaid, mis sobivad ressursside tarbimisega.

Kiired maffid

Kuid nagu arvata võis, pole see sugugi nii lihtne. Konteinerite kasutamisest väärtuse saamiseks peavad oma rakendusi juurutavad arendajad mõtlema, kui palju ressursse nimetatud rakendused mugavaks tööks peavad. See pole üldse lihtne ülesanne (nagu ma puudutasin ühtsete töövoogude arutamisel). Ja seda tehes on kasu sellest, kas olete Kuberneteses või mitte. Teades täpselt, kui palju igast ressursist teie rakendus vajab, saate valida minimaalselt vajaliku üksuse serveri, virtuaalmasina, konteineri või mis iganes teie olete valinud.

Mõnel juhul võtab ressursside jagamine samasse virtuaalmasinate klastrisse ja sama tasuvuse saavutamine rohkem tehnilisi jõupingutusi. Kujutage ette, et käitate EC2 eksemplaride peal fikseeritud CPU / mälu / võrguressurssidega Kubernetes'i klastrit. Ühel päeval hakkavad teie protsessoriga seotud rakendused muutma rohkem kui teised. Teie klastrit ei kasutata CPU-ressursside jaoks piisavalt. Isegi kui teie arendajad on põhjalikult testinud ja täpsustanud, milliseid ressursse nende rakendus vajab. Täiendav keerukuse kiht lisandub sellega, et tuleb luua eraldi ressursside vajaduse iga eksemplari jaoks eraldi eksemplaride rühm (mida jällegi peavad arendajad teadma ja arvestama).

Lisaks sellele nõuab iga loodud klaster konteinerite juhtimiseks täiendavaid ressursse (see kehtib kõigi orkestreerimisplatvormide kohta). Kubernetes nõuab vähemalt 3 täiendavat eksemplari tootmises olevate serverite jaoks ja 1 mitte-tootvat keskkonda orkestreerimiseks ja API juurde pääsemiseks. Kui kasutate katse- ja tootmisklastrit, on see veel 4 juhtumit. Kui jagate need teistesse klastritesse (sisemine, välimine, võib-olla ka lavastuskeskkond), on teil Kubernetesi käitamiseks märkimisväärsed lisakulud. Siit tuleb skaala - kui te jooksete skaalal, kus see ülejääk on märkimisväärne, võib kubernetes'i rakendamise valimine selle asemel, et seda vähendada, kindlasti teie kulusid suurendada. Eriti kui te ei rända sellele õigesti ja peate pärast Kubernetesi kasutamist ikkagi oma pärandplatvormi käitama. Rääkisin pärandi kehtestamisest ja puudutasin selles postituses hunnikut neid punkte, kui olete huvitatud.

Mis saab siis, kui minu rakendus on ressursinõuete osas nii väike, et minu minimaalne arvutusarvuti / mälu / võrk ei sobi sellele mõistlikult? Noh, ausalt öeldes tundub, et teie rakendus ei tohiks üldse teie hallatavates serverites töötada - tehke neile serverita funktsioon. Tunnistan, et see võib asju natuke liiga lihtsustada. Kui olete tasakaalus, kus serverivaba käitamine pole mõttekas ja üksikute masinate käivitamine pole mõistlik, peaksite kindlasti kaaluma konteinerite kasutamist. Kuid isegi siis kaaluge konteinereid, mitte Kubernetesit (ma ju hoiatasin teid, et see oli enamiku minu punktide alus)

Tahaksin lõpetuseks öelda, et minu arvates on Kubernetes uskumatu tarkvara ja mõned asjad, mida saate sellega saavutada, on meelepuhanud. Ma palun ainult seda, et me inseneridena kaaluksime nende otsuste tegemisel pragmatismi. Ökosüsteemi, mille ta selle ümber on ehitanud, on väga lihtne, sest meile kõigile meeldib ehitada jama. Sellepärast me teeme seda, mida teeme (loodetavasti). Kuid mõne teatud kolleegi jaoks pettumuse valmistamiseks ei tohiks me ilmselt teha suuri tehnilisi otsuseid, mis põhinevad puhtalt sellel, kui lahe midagi on.

Tervitan kogu tagasisidet, arutelusid ja konstruktiivset kriitikat - olen hiljuti hakanud Twitterit kasutama, nii et palun säutsuge mind oma mõtetega!