werf - mūsu rīks CI / CD pakalpojumā Kubernetes (pārskats un video pārskats)

27. maijā DevOpsConf 2019 konferences galvenajā zālē, kas notika festivāla ietvaros RIT++ 2019. gads, kā daļa no sadaļas "Nepārtraukta piegāde", tika sniegts ziņojums "werf - mūsu rīks CI/CD in Kubernetes". Tas runā par tiem problēmas un izaicinājumi, ar kuriem saskaras ikviens, izvietojot Kubernetes, kā arī par niansēm, kas var nebūt uzreiz pamanāmas. Analizējot iespējamos risinājumus, mēs parādām, kā tas tiek īstenots atvērtā pirmkoda rīkā werf.

Kopš prezentācijas mūsu utilīta (agrāk pazīstama kā dapp) ir sasniegusi vēsturisku pavērsienu 1000 zvaigžņu vietnē GitHub — mēs ceram, ka tā augošā lietotāju kopiena atvieglos dzīvi daudziem DevOps inženieriem.

Tātad, mēs piedāvājam reportāžas video (~47 minūtes, daudz informatīvāks par rakstu) un galvenais izraksts no tā teksta formā. Aiziet!

Koda piegāde Kubernetes

Runa vairs nebūs par werf, bet gan par CI/CD Kubernetes, norādot, ka mūsu programmatūra ir iepakota Docker konteineros (Es par to runāju 2016. gada pārskats), un K8s tiks izmantoti, lai to palaistu ražošanā (vairāk par to sadaļā 2017 gadā).

Kā izskatās piegāde Kubernetes?

• Ir Git repozitorijs ar kodu un instrukcijām tā izveidei. Lietojumprogramma ir iebūvēta Docker attēlā un publicēta Docker reģistrā.
• Tajā pašā repozitorijā ir arī norādījumi par lietojumprogrammas izvietošanu un palaišanu. Izvietošanas stadijā šie norādījumi tiek nosūtīti Kubernetes, kas saņem vajadzīgo attēlu no reģistra un palaiž to.
• Turklāt parasti ir testi. Dažus no tiem var izdarīt, publicējot attēlu. Varat arī (ievērojot tos pašus norādījumus) izvietot lietojumprogrammas kopiju (atsevišķā K8s nosaukumvietā vai atsevišķā klasterī) un tur veikt testus.
• Visbeidzot, jums ir nepieciešama CI sistēma, kas saņem notikumus no Git (vai pogu klikšķus) un izsauc visus norādītos posmus: izveidojiet, publicējiet, izvietojiet, pārbaudiet.

Šeit ir dažas svarīgas piezīmes:

1. Jo mums ir nemainīga infrastruktūra (nemainīga infrastruktūra), lietojumprogrammas attēls, kas tiek izmantots visos posmos (iestudēšana, ražošana utt.), tādam jābūt. Es par to runāju sīkāk un ar piemēriem. šeit.
2. Jo mēs sekojam infrastruktūrai kā koda pieejai (IaC), lietojumprogrammas kodam, instrukcijām tā montāžai un palaišanai jābūt tieši vienā repozitorijā. Plašāku informāciju par to skatiet tas pats ziņojums.
3. Piegādes ķēde (Piegāde) mēs parasti to redzam šādi: lietojumprogramma tika samontēta, pārbaudīta, izlaista (izlaiduma posms) un viss - piegāde ir notikusi. Taču patiesībā lietotājs saņem to, ko jūs izlaidāt, nē tad, kad jūs to piegādājāt ražošanai, un kad viņš varēja tur aizbraukt, un šī ražošana strādāja. Tāpēc es uzskatu, ka piegādes ķēde beidzas tikai ekspluatācijas stadijā (skriet), vai precīzāk, pat tajā brīdī, kad kods tika izņemts no ražošanas (aizvietojot to ar jaunu).

Atgriezīsimies pie iepriekš minētās piegādes shēmas Kubernetes: to izgudrojām ne tikai mēs, bet burtiski visi, kas nodarbojās ar šo problēmu. Faktiski šo modeli tagad sauc par GitOps (jūs varat lasīt vairāk par terminu un tā idejām šeit). Apskatīsim shēmas posmus.

Celtniecības posms

Šķiet, ka jūs varat runāt par Docker attēlu veidošanu 2019. gadā, kad visi zina, kā rakstīt Dockerfiles un palaist docker build?.. Lūk, nianses, kurām vēlos pievērst uzmanību:

1. Attēla svars svarīgi, tāpēc izmantojiet daudzpakāpjuatstāt attēlā tikai to aplikāciju, kas patiešām ir nepieciešama darbībai.
2. Slāņu skaits jāsamazina, apvienojot ķēdes RUN-pavēles pēc nozīmes.
3. Tomēr tas rada papildu problēmas atkļūdošana, jo, kad montāža avarē, jums ir jāatrod pareizā komanda no ķēdes, kas izraisīja problēmu.
4. Montāžas ātrums svarīgi, jo mēs vēlamies ātri ieviest izmaiņas un redzēt rezultātus. Piemēram, jūs nevēlaties atjaunot atkarības valodu bibliotēkās katru reizi, kad veidojat lietojumprogrammu.
5. Bieži vien no viena Git repozitorija jums ir nepieciešams daudz attēlu, ko var atrisināt ar Dockerfailu kopu (vai nosauktiem posmiem vienā failā) un Bash skriptu ar to secīgo montāžu.

Tā bija tikai aisberga redzamā daļa, ar ko saskaras ikviens. Bet ir arī citas problēmas, jo īpaši:

1. Bieži vien montāžas stadijā mums kaut kas ir vajadzīgs mount (piemēram, trešās puses direktorijā saglabājiet tādas komandas rezultātu kā apt).
2. Mēs gribam Iespējams tā vietā, lai rakstītu čaulā.
3. Mēs gribam veidot bez Docker (kāpēc mums ir vajadzīga papildu virtuālā mašīna, kurā mums viss ir jākonfigurē, ja mums jau ir Kubernetes klasteris, kurā mēs varam palaist konteinerus?).
4. Paralēlā montāža, ko var saprast dažādi: dažādas komandas no Dockerfile (ja tiek izmantots vairākpakāpju), vairākas vienas un tās pašas repozitorijas commits, vairāki Dockerfile.
5. Sadalīta montāža: Mēs vēlamies savākt lietas pākstīs, kas ir "īslaicīgas", jo to kešatmiņa pazūd, kas nozīmē, ka tā ir jāglabā kaut kur atsevišķi.
6. Visbeidzot es nosaucu vēlmju virsotni automātiska: Ideāli būtu aiziet uz repozitoriju, ierakstīt kādu komandu un iegūt gatavu attēlu, kas samontēts ar izpratni, kā un ko pareizi darīt. Taču es personīgi neesmu pārliecināts, ka visas nianses šādi var paredzēt.

Un šeit ir projekti:

• moby/buildkit — celtnieks no Docker Inc (jau integrēts pašreizējās Docker versijās), kas cenšas atrisināt visas šīs problēmas;
• kaniko — Google celtnieks, kas ļauj būvēt bez Docker;
• Buildpacks.io — CNCF mēģinājums radīt automātisku maģiju un jo īpaši interesantu risinājumu ar slāņu pārbāzi;
• un virkni citu komunālo pakalpojumu, piemēram būvēt, oriģinālie instrumenti/att...

...un paskatieties, cik daudz zvaigžņu viņiem ir GitHub. Tas ir, no vienas puses, docker build pastāv un var kaut ko darīt, bet patiesībā problēma nav pilnībā atrisināta - pierādījums tam ir paralēla alternatīvu kolektoru attīstība, no kuriem katrs atrisina kādu daļu problēmu.

Montāža werf

Tātad mums ir jādara werf (agrāk slavens kā dapp) — Atvērtā koda utilīta no uzņēmuma Flant, ko esam ražojuši jau daudzus gadus. Viss sākās pirms 5 gadiem ar Bash skriptiem, kas optimizēja Dockerfiles montāžu, un pēdējos 3 gadus ir veikta pilnvērtīga izstrāde viena projekta ietvaros ar savu Git repozitoriju (vispirms Rubīnā un pēc tam pārrakstīts to Go, un tajā pašā laikā pārdēvēja). Kādas montāžas problēmas tiek atrisinātas werf?

Problēmas, kas iekrāsotas zilā krāsā, jau ir īstenotas, paralēlā būvēšana tika veikta tajā pašā resursdatorā, un dzeltenā iezīmētās problēmas plānots pabeigt līdz vasaras beigām.

Publicēšanas posms reģistrā (publicēšana)

Mēs zvanījām docker push... - kas varētu būt grūti augšupielādējot attēlu reģistrā? Un tad rodas jautājums: "Kādu tagu man vajadzētu pievienot attēlam?" Tas rodas tā iemesla dēļ, kāds mums ir Gitflow (vai cita Git stratēģija) un Kubernetes, un nozare cenšas nodrošināt, lai tas, kas notiek Kubernetes, atbilstu tam, kas notiek Git. Galu galā Gits ir mūsu vienīgais patiesības avots.

Kas tur tik grūts? Nodrošiniet reproducējamību: no apņemšanās Gitā, kas pēc būtības ir nemainīgs (nemainīgs), uz Docker attēlu, kas ir jāsaglabā tāds pats.

Tas ir svarīgi arī mums noteikt izcelsmi, jo gribam saprast, no kura commit ir uzbūvēta Kubernetes darbojošā aplikācija (tad varam veikt diffus un tamlīdzīgas lietas).

Atzīmēšanas stratēģijas

Pirmais ir vienkāršs git diena. Mums ir reģistrs ar attēlu, kas atzīmēts kā 1.0. Kubernetes ir skatuve un producēšana, kur tiek augšupielādēts šis attēls. Programmā Git mēs veicam saistības un kādā brīdī atzīmējam 2.0. Mēs to savācam saskaņā ar repozitorija norādījumiem un ievietojam to reģistrā ar tagu 2.0. Mēs to izrullējam uz skatuves un, ja viss ir kārtībā, tad uz ražošanu.

Šīs pieejas problēma ir tāda, ka mēs vispirms ievietojām tagu un tikai pēc tam to pārbaudījām un izlaidām. Kāpēc? Pirmkārt, tas ir vienkārši neloģiski: mēs izdodam programmatūras versiju, kuru vēl neesam pat pārbaudījuši (citādi nevaram, jo, lai pārbaudītu, ir jāievieto tags). Otrkārt, šis ceļš nav saderīgs ar Gitflow.

Otrā iespēja - git commit + tag. Galvenā filiālei ir atzīme 1.0; par to reģistrā - attēls, kas izvietots ražošanā. Turklāt Kubernetes klasterim ir priekšskatījuma un iestudējuma kontūras. Tālāk mēs sekojam Gitflow: galvenajā attīstības filiālē (develop) mēs izveidojam jaunus līdzekļus, kā rezultātā tiek veikta apņemšanās ar identifikatoru #c1. Mēs to apkopojam un publicējam reģistrā, izmantojot šo identifikatoru (#c1). Ar to pašu identifikatoru mēs izlaižam priekšskatījumu. Mēs darām to pašu ar saistībām #c2 и #c3.

Kad mēs sapratām, ka ir pietiekami daudz funkciju, mēs sākam visu stabilizēt. Izveidojiet filiāli programmā Git release_1.1 (uz pamatnes #c3 no develop). Nav nepieciešams vākt šo izlaidumu, jo... tas tika darīts iepriekšējā darbībā. Tāpēc mēs varam to vienkārši izvērst iestudēšanai. Mēs izlabojam kļūdas #c4 un līdzīgi izrullēt iestudēšanai. Tajā pašā laikā notiek attīstība develop, kur periodiski tiek veiktas izmaiņas no release_1.1. Kādā brīdī mēs saņemam apņemšanos, kas tiek apkopota un augšupielādēta inscenēšanai, un mēs esam apmierināti ar (#c25).

Pēc tam mēs sapludinām (ar ātri pārtīšanu) atbrīvošanas zaru (release_1.1) meistarā. Mēs ievietojām tagu ar jauno versiju šai apņemšanai (1.1). Bet šis attēls jau ir savākts reģistrā, tāpēc, lai tas vairs netiktu savākts, mēs vienkārši pievienojam otru tagu esošajam attēlam (tagad tam ir tagi reģistrā #c25 и 1.1). Pēc tam mēs to izrullējam uz ražošanu.

Ir trūkums, ka inscenēšanai tiek augšupielādēts tikai viens attēls (#c25), un ražošanā tas ir savādāk (1.1), taču mēs zinām, ka “fiziski” tie ir viens un tas pats attēls no reģistra.

Patiesais trūkums ir tas, ka nav atbalsta sapludināšanas saistībām, jums ir jādara ātri uz priekšu.

Mēs varam iet tālāk un veikt triku... Apskatīsim vienkārša Dockerfile piemēru:

FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb

FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/public

Izveidosim no tā failu pēc šāda principa:

• SHA256 no izmantoto attēlu identifikatoriem (ruby:2.3 и nginx:alpine), kas ir to satura kontrolsummas;
• visas komandas (RUN, CMD un tā tālāk.);
• SHA256 no failiem, kas tika pievienoti.

... un paņemiet kontrolsummu (atkal SHA256) no šāda faila. Šis parakstu viss, kas nosaka Docker attēla saturu.

Atgriezīsimies pie diagrammas un apņemšanos vietā izmantosim šādus parakstus, t.i. atzīmējiet attēlus ar parakstiem.

Tagad, kad ir nepieciešams, piemēram, sapludināt izmaiņas no laidiena uz galveno, mēs varam veikt reālu sapludināšanas apņemšanos: tai būs cits identifikators, bet tas pats paraksts. Ar to pašu identifikatoru mēs izlaidīsim attēlu ražošanā.

Trūkums ir tāds, ka tagad nebūs iespējams noteikt, kāda veida saistības tika virzītas uz ražošanu - kontrolsummas darbojas tikai vienā virzienā. Šo problēmu atrisina papildu slānis ar metadatiem — es jums pastāstīšu vairāk vēlāk.

Atzīmēšana werf

werf mēs gājām vēl tālāk un gatavojamies veikt izkliedētu būvēšanu ar kešatmiņu, kas netiek glabāta vienā mašīnā... Tātad, mēs veidojam divu veidu Docker attēlus, mēs tos saucam posms и attēls.

werf Git repozitorijā tiek glabāti būvējumam specifiski norādījumi, kas apraksta dažādus būvēšanas posmus (pirms instalēšanas, uzstādīt, pirms iestatīšanas, iestatīšana). Mēs apkopojam pirmā posma attēlu ar parakstu, kas definēts kā pirmo soļu kontrolsumma. Tad pievienojam pirmkodu, jaunajam skatuves attēlam aprēķinām tā kontrolsummu... Šīs darbības atkārtojas visiem posmiem, kā rezultātā iegūstam skatuves attēlu kopu. Tad mēs izveidojam galīgo attēlu, kurā ir arī metadati par tā izcelsmi. Un mēs atzīmējam šo attēlu dažādos veidos (sīkāka informācija vēlāk).

Pieņemsim, ka pēc tam parādās jauna apņemšanās, kurā ir mainīts tikai lietojumprogrammas kods. Kas notiks? Koda izmaiņām tiks izveidots ielāps un sagatavots jauns skatuves attēls. Tās paraksts tiks noteikts kā vecā skatuves tēla un jaunā ielāpa kontrolsumma. No šī attēla tiks izveidots jauns galīgais attēls. Līdzīga uzvedība notiks ar izmaiņām citos posmos.

Tādējādi skatuves attēli ir kešatmiņa, kuru var glabāt izplatīti, un no tās jau izveidotie attēli tiek augšupielādēti Docker reģistrā.

Reģistra tīrīšana

Mēs nerunājam par slāņu dzēšanu, kas palika karājušies pēc dzēstiem tagiem - tā ir paša Docker reģistra standarta funkcija. Mēs runājam par situāciju, kad sakrājas daudz Docker tagu un saprotam, ka daļa no tiem mums vairs nav vajadzīgi, bet tie aizņem vietu (un/vai mēs par to maksājam).

Kādas ir tīrīšanas stratēģijas?

1. Jūs varat vienkārši neko nedarīt netīrīt. Reizēm patiešām ir vieglāk nedaudz samaksāt par papildu vietu, nekā izjaukt milzīgu tagu mudžekli. Bet tas darbojas tikai līdz noteiktam brīdim.
2. Pilnīga atiestatīšana. Ja izdzēšat visus attēlus un atjaunojat tikai pašreizējos attēlus CI sistēmā, var rasties problēma. Ja konteiners tiek restartēts ražošanā, tam tiks ielādēts jauns attēls - tāds, kuru vēl neviens nav pārbaudījis. Tas nogalina ideju par nemainīgu infrastruktūru.
3. Zils zaļš. Viens reģistrs sāka pārpildīt - mēs augšupielādējam attēlus citā. Tāda pati problēma kā iepriekšējā metodē: kurā brīdī jūs varat notīrīt reģistru, kas ir sācis pārpildīt?
4. Ar laiku. Vai dzēst visus attēlus, kas vecāki par 1 mēnesi? Bet noteikti būs kāds serviss, kas mēnesi nav atjaunināts...
5. ar rokām noteikt, ko jau var izdzēst.

Ir divas patiesi dzīvotspējīgas iespējas: netīrīt vai zili zaļa + kombinācija manuāli. Pēdējā gadījumā mēs runājam par sekojošo: kad saprotat, ka ir pienācis laiks tīrīt reģistru, izveidojiet jaunu un pievienojiet tam visus jaunos attēlus, piemēram, mēneša laikā. Un pēc mēneša skatiet, kuri Kubernetes podi joprojām izmanto veco reģistru, un pārsūtiet tos arī uz jauno reģistru.

Pie kā esam nonākuši werf? Mēs savācam:

1. Git head: visi tagi, visi zari - pieņemot, ka mums ir nepieciešams viss, kas attēlos ir atzīmēts Git (un ja nē, tad mums tas ir jāizdzēš pašā Gitā);
2. visas pākstis, kas šobrīd tiek izsūknētas uz Kubernetes;
3. vecie ReplicaSets (kas nesen tika izlaists), un mēs arī plānojam skenēt Helm izlaidumus un atlasīt tur jaunākos attēlus.

... un izveidojiet balto sarakstu no šīs kopas - attēlu sarakstu, kurus mēs neizdzēsīsim. Mēs iztīrām visu pārējo, pēc tam atrodam bāreņu skatuves attēlus un arī tos izdzēšam.

Izvietošanas stadija

Uzticama deklarativitāte

Pirmais punkts, kam vēlos pievērst uzmanību izvietošanā, ir atjauninātās resursa konfigurācijas izvēršana, kas deklaratīvi deklarēta. Sākotnējais YAML dokuments, kurā aprakstīti Kubernetes resursi, vienmēr ļoti atšķiras no rezultāta, kas faktiski darbojas klasterī. Tā kā Kubernetes papildina konfigurāciju:

1. identifikatori;
2. pakalpojumu informācija;
3. daudzas noklusējuma vērtības;
4. sadaļa ar pašreizējo statusu;
5. izmaiņas, kas veiktas uzņemšanas tīmekļa aizķeres ietvaros;
6. dažādu kontrolieru (un plānotāja) darba rezultāts.

Tāpēc, kad parādās jauna resursa konfigurācija (jauns), mēs nevaram vienkārši ņemt un pārrakstīt pašreizējo, “tiešo” konfigurāciju ar to (dzīvot). Lai to izdarītu, mums būs jāsalīdzina jauns ar pēdējo lietoto konfigurāciju (pēdējo reizi lietots) un ritiniet uz dzīvot saņēma plāksteri.

Šo pieeju sauc Divvirzienu sapludināšana. To lieto, piemēram, Helmā.

Ir arī Divvirzienu sapludināšana, kas atšķiras ar to:

• salīdzinot pēdējo reizi lietots и jauns, mēs skatāmies, kas tika izdzēsts;
• salīdzinot jauns и dzīvot, mēs skatāmies, kas ir pievienots vai mainīts;
• uzlikts summētais plāksteris dzīvot.

Ar Helm mēs izvietojam vairāk nekā 1000 lietojumprogrammu, tāpēc mēs faktiski izmantojam divvirzienu sapludināšanu. Tomēr tam ir vairākas problēmas, kuras esam atrisinājuši ar saviem ielāpiem, kas palīdz Helmam normāli strādāt.

Reāls izlaišanas statuss

Kad mūsu CI sistēma ģenerē jaunu Kubernetes konfigurāciju, pamatojoties uz nākamo notikumu, tā nosūta to lietošanai (pieteikties) uz kopu - izmantojot Helm vai kubectl apply. Tālāk notiek jau aprakstītā N-way sapludināšana, uz kuru Kubernetes API apstiprinoši reaģē uz CI sistēmu un tā – uz tās lietotāju.

Tomēr ir milzīga problēma: galu galā veiksmīga pieteikšanās nenozīmē veiksmīgu izlaišanu. Ja Kubernetes saprot, kādas izmaiņas ir jāpiemēro, un piemēro tās, mēs joprojām nezinām, kāds būs rezultāts. Piemēram, podziņu atjaunināšana un restartēšana priekšgalā var būt veiksmīga, bet ne aizmugursistēmā, un mēs iegūsim dažādas darbojošos lietojumprogrammu attēlu versijas.

Lai visu izdarītu pareizi, šai shēmai ir nepieciešama papildu saite - īpašs izsekotājs, kas saņems statusa informāciju no Kubernetes API un pārsūtīs to tālākai lietas reālā stāvokļa analīzei. Mēs izveidojām atvērtā pirmkoda bibliotēku pakalpojumā Go - kubsuns (skatiet tās paziņojumu šeit), kas atrisina šo problēmu un ir iebūvēts werf.

Šī izsekotāja darbība werf līmenī tiek konfigurēta, izmantojot anotācijas, kas tiek ievietotas izvietojumos vai StatefulSets. Galvenā anotācija - fail-mode - saprot šādas nozīmes:

• IgnoreAndContinueDeployProcess — mēs ignorējam šīs sastāvdaļas ieviešanas problēmas un turpinām izvēršanu;
• FailWholeDeployProcessImmediately — kļūda šajā komponentā aptur izvietošanas procesu;
• HopeUntilEndOfDeployProcess — mēs ceram, ka šis komponents darbosies līdz izvietošanas beigām.

Piemēram, šī resursu un anotācijas vērtību kombinācija fail-mode:

Kad mēs izvietojam pirmo reizi, datubāze (MongoDB) var vēl nebūt gatava — izvietošana neizdosies. Bet jūs varat gaidīt brīdi, kad tas sāksies, un izvietošana joprojām notiks.

Ir vēl divas anotācijas kubedog in werf:

• failures-allowed-per-replica — katras kopijas pieļaujamo kritienu skaits;
• show-logs-until — regulē brīdi, līdz kuram werf rāda (in stdout) baļķus no visām izritinātajām pākstīm. Noklusējums ir PodIsReady (lai ignorētu ziņojumus, kurus mēs, iespējams, nevēlamies, kad satiksme sāk plūst uz podziņu), taču ir derīgas arī vērtības: ControllerIsReady и EndOfDeploy.

Ko vēl mēs vēlamies no izvietošanas?

Papildus diviem jau aprakstītajiem punktiem mēs vēlētos:

• redzēt baļķi - un tikai nepieciešamās, un ne visu pēc kārtas;
• dziesmu progresu, jo, ja darbs “pa kluso” karājas vairākas minūtes, ir svarīgi saprast, kas tur notiek;
• ir automātiska atgriešana ja kaut kas nogāja greizi (un tāpēc ir ļoti svarīgi zināt izvietošanas patieso statusu). Izlaišanai ir jābūt kodolīgai: vai nu tas iet līdz galam, vai arī viss atgriežas iepriekšējā stāvoklī.

Rezultāti

Mums kā uzņēmumam, lai ieviestu visas aprakstītās nianses dažādos piegādes posmos (veidot, publicēt, izvietot), pietiek ar CI sistēmu un utilītu werf.

Secinājuma vietā:

Ar werf palīdzību mēs esam guvuši labus panākumus daudzu DevOps inženieru problēmu risināšanā un būtu priecīgi, ja plašāka sabiedrība vismaz izmēģinātu šo utilītu darbībā. Kopā būs vieglāk sasniegt labu rezultātu.

Videoklipi un slaidi

Video no izrādes (~47 minūtes):

Ziņojuma prezentācija:

PS

Citi ziņojumi par Kubernetes mūsu emuārā:

• «Automērogošana un resursu pārvaldība Kubernetes» (Dmitrijs Stoļarovs; 27. gada 2019. aprīlis kanālā “Streiks”);
• «Kubernetes paplašināšana un papildināšana» (Andrijs Polovs; 8. gada 2019. aprīlis pakalpojumā Saint HighLoad++);
• «Datu bāzes un Kubernetes» (Dmitrijs Stoļarovs; 8. gada 2018. novembris vietnē HighLoad++);
• «Monitorings un Kubernetes» (Dmitrijs Stoļarovs; 28. gada 2018. maijā, RootConf);
• «CI/CD labākā prakse ar Kubernetes un GitLab» (Dmitrijs Stoļarovs; 7. gada 2017. novembris vietnē HighLoad++);
• «Mūsu pieredze ar Kubernetes mazos projektos» (Dmitrijs Stoļarovs; 6. gada 2017. jūnijs, RootConf).

Avots: www.habr.com