werf - nia ilo por CI / KD en Kubernetes (superrigardo kaj videoraporto)

La 27-an de majo en la ĉefa salono de la konferenco DevOpsConf 2019, okazigita kadre de la festivalo RIT++ 2019, kadre de la sekcio "Kontinua Livero", raporto ricevis "werf - nia ilo por CI/KD en Kubernetes". Ĝi parolas pri tiuj problemoj kaj defioj, kiujn ĉiuj alfrontas dum deplojiĝo al Kubernetes, same kiel pri nuancoj kiuj eble ne tuj rimarkeblas. Analizante eblajn solvojn, ni montras kiel ĉi tio estas efektivigita en Malfermfonta ilo werf.

Ekde la prezento, nia utileco (antaŭe konata kiel dapp) atingis historian mejloŝtonon de 1000 steloj en GitHub — ni esperas, ke ĝia kreskanta komunumo de uzantoj faciligos la vivon al multaj DevOps-inĝenieroj.

Do, ni prezentu video de la raporto (~47 minutoj, multe pli informa ol la artikolo) kaj la ĉefa eltiraĵo el ĝi tekste. Iru!

Liverante kodon al Kubernetes

La babilado ne plu estos pri werf, sed pri CI/KD en Kubernetes, implicante ke nia programaro estas pakita en Docker-ujoj. (Mi parolis pri tio en 2016 raporto), kaj K8s estos uzataj por funkcii ĝin en produktado (pli pri tio en 2017 jaro).

Kiel aspektas livero en Kubernetes?

• Estas Git-deponejo kun la kodo kaj instrukcioj por konstrui ĝin. La aplikaĵo estas enkonstruita en Docker-bildon kaj publikigita en la Docker-Registro.
• La sama deponejo ankaŭ enhavas instrukciojn pri kiel disfaldi kaj ruli la aplikaĵon. En la deploja stadio, ĉi tiuj instrukcioj estas senditaj al Kubernetes, kiu ricevas la deziratan bildon de la registro kaj lanĉas ĝin.
• Plie, estas kutime testoj. Iuj el ĉi tiuj povas esti faritaj dum publikigado de bildo. Vi ankaŭ povas (sekvante la samajn instrukciojn) deploji kopion de la aplikaĵo (en aparta K8s-nomspaco aŭ aparta areto) kaj fari testojn tie.
• Fine, vi bezonas CI-sistemon, kiu ricevas eventojn de Git (aŭ butonklakojn) kaj vokas ĉiujn elektitajn stadiojn: konstrui, publikigi, disfaldi, testi.

Estas kelkaj gravaj notoj ĉi tie:

1. Ĉar ni havas neŝanĝeblan infrastrukturon (neŝanĝebla infrastrukturo), la aplika bildo kiu estas uzata en ĉiuj stadioj (scenigo, produktado, ktp.), devas esti unu. Mi parolis pri tio pli detale kaj kun ekzemploj. tie.
2. Ĉar ni sekvas la infrastrukturon kiel kodan alproksimiĝon (IaC), la aplika kodo, instrukcioj por kunmeti kaj lanĉi ĝin devus esti ĝuste en unu deponejo. Por pliaj informoj pri tio, vidu la sama raporto.
3. Livera ĉeno (livero) ni kutime vidas ĝin tiel: la aplikaĵo estis kunmetita, testita, liberigita (eldonstadio) kaj jen ĝi - livero okazis. Sed fakte, la uzanto ricevas tion, kion vi eligis, ne tiam kiam vi liveris ĝin al produktado, kaj kiam li povis iri tien kaj ĉi tiu produktado funkciis. Do mi kredas, ke la liverĉeno finiĝas nur en la funkcia stadio (kuri), aŭ pli precize, eĉ en la momento kiam la kodo estis forigita de produktado (anstataŭigante ĝin per nova).

Ni revenu al la ĉi-supra liverskemo en Kubernetes: ĝi estis inventita ne nur de ni, sed de laŭvorte ĉiuj, kiuj traktis ĉi tiun problemon. Fakte, ĉi tiu ŝablono nun nomiĝas GitOps (vi povas legi pli pri la termino kaj la ideoj malantaŭ ĝi tie). Ni rigardu la stadiojn de la skemo.

Konstrua stadio

Ŝajnus, ke vi povas paroli pri konstruado de Docker-bildoj en 2019, kiam ĉiuj scias kiel skribi Dockerfiles kaj ruli docker build?.. Jen la nuancoj, kiujn mi ŝatus atenti:

1. Bilda pezo gravas, do uzu pluretapalasi en la bildo nur la aplikaĵon, kiu estas vere necesa por la operacio.
2. Nombro de tavoloj devas esti minimumigita per kombinado de ĉenoj de RUN-komandoj laŭ signifo.
3. Tamen, ĉi tio aldonas problemojn senararigado, ĉar kiam la asembleo frakasas, vi devas trovi la ĝustan komandon de la ĉeno, kiu kaŭzis la problemon.
4. Rapideco de muntado grava ĉar ni volas rapide efektivigi ŝanĝojn kaj vidi la rezultojn. Ekzemple, vi ne volas rekonstrui dependecojn en lingvaj bibliotekoj ĉiufoje kiam vi konstruas aplikaĵon.
5. Ofte de unu Git-deponejo vi bezonas multaj bildoj, kiu povas esti solvita per aro de Dockerfiles (aŭ nomitaj stadioj en unu dosiero) kaj Bash-skripto kun ilia sinsekva kunigo.

Ĉi tio estis nur la pinto de la glacimonto, kiun ĉiuj alfrontas. Sed estas aliaj problemoj, precipe:

1. Ofte en la kunvenstadio ni bezonas ion monto (ekzemple, konservu la rezulton de komando kiel apt en triaparta dosierujo).
2. Ni volas Respondema anstataŭ skribi en ŝelo.
3. Ni volas konstrui sen Docker (kial ni bezonas plian virtualan maŝinon, en kiu ni devas agordi ĉion por ĉi tio, kiam ni jam havas Kubernetes-grupon en kiu ni povas ruli ujojn?).
4. Paralela asembleo, kiu povas esti komprenata en malsamaj manieroj: malsamaj komandoj de la Dockerfile (se plurŝtupa estas uzata), pluraj komits de la sama deponejo, pluraj Dockerfile.
5. Distribuita asembleo: Ni volas kolekti aferojn en podoj, kiuj estas "efemeraj" ĉar ilia kaŝmemoro malaperas, kio signifas, ke ĝi devas esti konservita ie aparte.
6. Fine, mi nomis la pinton de deziroj aŭtomagio: Estus ideale iri al la deponejo, tajpi iun komandon kaj akiri pretan bildon, kunmetitan kun kompreno pri kiel kaj kion fari ĝuste. Tamen mi persone ne certas, ke ĉiuj nuancoj povas esti antaŭvideblaj tiel.

Kaj jen la projektoj:

• moby/buildkit — konstruanto de Docker Inc (jam integrita al nunaj versioj de Docker), kiu provas solvi ĉiujn ĉi tiujn problemojn;
• kaniko — konstruanto de Google, kiu permesas vin konstrui sen Docker;
• Buildpacks.io — Provo de CNCF fari aŭtomatan magion kaj, precipe, interesan solvon kun rebazo por tavoloj;
• kaj amaso da aliaj utilecoj, kiel ekzemple konstrui, genuinetools/img...

...kaj rigardu kiom da steloj ili havas sur GitHub. Tio estas, unuflanke, docker build ekzistas kaj povas fari ion, sed en realeco la afero ne estas tute solvita - pruvo de tio estas paralela evoluo de alternativaj kolektantoj, el kiuj ĉiu solvas iun parton de la problemoj.

Asembleo en werf

Do ni atingis werf (antaŭe fama kiel dapp) — Malfermkoda ilo de la kompanio Flant, kiun ni faras de multaj jaroj. Ĉio komenciĝis antaŭ 5 jaroj per Bash-skriptoj, kiuj optimumigis la asembleon de Dockerfiles, kaj dum la lastaj 3 jaroj plena disvolviĝo estis farita kadre de unu projekto kun sia propra Git-deponejo. (unue en Ruby, kaj poste reverkita iri, kaj samtempe renomita). Kiuj asembleaj aferoj estas solvitaj en werf?

La problemoj ombritaj en bluo jam estis efektivigitaj, la paralela konstruo estis farita ene de la sama gastiganto, kaj la temoj elstarigitaj flava estas planitaj por esti kompletigitaj antaŭ la fino de la somero.

Etapo de publikigo en registro (publikigi)

Ni telefonis docker push... - kio povus esti malfacila pri alŝuto de bildo al la registro? Kaj tiam ŝprucas la demando: "Kian etikedon mi metu sur la bildon?" Ĝi ŝprucas pro la kialo, ke ni havas Gitflow (aŭ alia Git-strategio) kaj Kubernetes, kaj la industrio provas certigi, ke kio okazas en Kubernetes sekvas tion, kio okazas en Git. Post ĉio, Git estas nia sola fonto de vero.

Kio estas tiel malfacila pri ĉi tio? Certigu reprodukteblecon: de commit en Git, kiu estas neŝanĝebla en naturo (neŝanĝebla), al Docker-bildo, kiu devus esti konservita la sama.

Ĝi ankaŭ estas grava por ni determini originon, ĉar ni volas kompreni, de kiu komito la aplikaĵo kuranta en Kubernetes estis konstruita (tiam ni povas fari diferencojn kaj similajn aferojn).

Etikedaj Strategioj

La unua estas simpla git-etikedo. Ni havas registron kun bildo etikedita kiel 1.0. Kubernetes havas scenejon kaj produktadon, kie ĉi tiu bildo estas alŝutita. En Git ni faras kommitaĵojn kaj iam ni etikedas 2.0. Ni kolektas ĝin laŭ la instrukcioj de la deponejo kaj metas ĝin en la registron kun la etikedo 2.0. Ni ruliĝas ĝin al scenejo kaj, se ĉio estas bona, tiam al produktado.

La problemo kun ĉi tiu aliro estas, ke ni unue metis la etikedon, kaj nur tiam testis kaj ruliĝis ĝin. Kial? Unue, ĝi estas simple mallogika: ni eldonas version de programaro, kiun ni eĉ ne testis ankoraŭ (ni ne povas fari alie, ĉar por kontroli, ni devas meti etikedon). Due, ĉi tiu vojo ne kongruas kun Gitflow.

La dua eblo estas git commit + etikedo. La majstra branĉo havas etikedon 1.0; por ĝi en registro - bildo deplojita al produktado. Krome, la Kubernetes-areto havas antaŭrigardon kaj aranĝajn konturojn. Poste ni sekvas Gitflow: en la ĉefa branĉo por evoluo (develop) ni faras novajn funkciojn, rezultigante engaĝiĝon kun la identigilo #c1. Ni kolektas ĝin kaj publikigas ĝin en la registro uzante ĉi tiun identigilon (#c1). Kun la sama identigilo ni ruliĝas por antaŭrigardi. Ni faras la samon kun commits #c2 и #c3.

Kiam ni rimarkis, ke estas sufiĉe da funkcioj, ni komencas stabiligi ĉion. Kreu branĉon en Git release_1.1 (sur la bazo #c3 el develop). Ne necesas kolekti ĉi tiun eldonon, ĉar... ĉi tio estis farita en la antaŭa paŝo. Sekve, ni povas simple ruliĝi ĝin al enscenigo. Ni korektas cimojn #c4 kaj simile ruliĝas al surscenigo. Samtempe evoluas en develop, kie ŝanĝoj estas periode prenitaj de release_1.1. Iam ni ricevas kompilaĵon kompilita kaj alŝutita al enscenigo, pri kiu ni ĝojas (#c25).

Tiam ni kunfandas (kun rapida antaŭen) la eldonbranĉo (release_1.1) en majstro. Ni metis etikedon kun la nova versio sur ĉi tiun kommit (1.1). Sed ĉi tiu bildo jam estas kolektita en la registro, do por ne kolekti ĝin denove, ni simple aldonas duan etikedon al la ekzistanta bildo (nun ĝi havas etikedojn en la registro. #c25 и 1.1). Post tio, ni ruliĝas ĝin al produktado.

Estas malavantaĝo, ke nur unu bildo estas alŝutita al surscenigo (#c25), kaj en produktado ĝi estas iom malsama (1.1), sed ni scias, ke "fizike" ĉi tiuj estas la sama bildo de la registro.

La vera malavantaĝo estas, ke ne ekzistas subteno por kunfandaj komitaĵoj, vi devas fari rapide antaŭen.

Ni povas iri plu kaj fari lertaĵon... Ni rigardu ekzemplon de simpla Dockerfile:

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

Ni konstruu dosieron el ĝi laŭ la sekva principo:

• SHA256 de la identigiloj de la bildoj uzitaj (ruby:2.3 и nginx:alpine), kiuj estas ĉeksumoj de ilia enhavo;
• ĉiuj teamoj (RUN, CMD kaj tiel plu.);
• SHA256 el dosieroj aldonitaj.

... kaj prenu la kontrolsumon (denove SHA256) el tia dosiero. Ĉi tio subskribo ĉio, kio difinas la enhavon de la bildo de Docker.

Ni reiru al la diagramo kaj anstataŭ kommits ni uzos tiajn subskribojn, t.e. etikedi bildojn kun subskriboj.

Nun, kiam necesas, ekzemple, kunfandi ŝanĝojn de eldono al majstro, ni povas fari veran merge-komision: ĝi havos malsaman identigilon, sed la saman subskribon. Kun la sama identigilo ni disvolvos la bildon al produktado.

La malavantaĝo estas, ke nun ne eblos determini, kian transdonon estis puŝita al produktado - ĉeksumoj funkcias nur en unu direkto. Ĉi tiu problemo estas solvita per plia tavolo kun metadatenoj - mi rakontos al vi pli poste.

Etikedado en werf

En werf ni iris eĉ plu kaj prepariĝas fari distribuitan konstruon kun kaŝmemoro, kiu ne estas konservita en unu maŝino... Do, ni konstruas du specojn de Docker-bildoj, ni nomas ilin. scenejo и bildo.

La werf Git-deponejo konservas konstruspecifajn instrukciojn, kiuj priskribas la malsamajn stadiojn de la konstruo (antaŭ Instali, instali, antaŭ Agordo, agordi). Ni kolektas la unuan fazan bildon kun subskribo difinita kiel la kontrolsumo de la unuaj paŝoj. Poste ni aldonas la fontkodon, por la nova etapobildo ni kalkulas ĝian kontrolsumon... Ĉi tiuj operacioj estas ripetataj por ĉiuj etapoj, rezulte de kiuj ni ricevas aron da scenejaj bildoj. Poste ni faras la finan bildon, kiu ankaŭ enhavas metadatenojn pri ĝia origino. Kaj ni etikedas ĉi tiun bildon en malsamaj manieroj (detaloj poste).

Supozu post ĉi tio nova komit aperas en kiu nur la aplika kodo estis ŝanĝita. Kio okazos? Por kodŝanĝoj, diakilo estos kreita kaj nova scena bildo estos preparita. Ĝia subskribo estos determinita kiel la kontrolsumo de la malnova scenbildo kaj la nova flikaĵo. Nova fina bildo estos formita de ĉi tiu bildo. Simila konduto okazos kun ŝanĝoj en aliaj stadioj.

Tiel, scenejaj bildoj estas kaŝmemoro, kiu povas esti stokita distribue, kaj la bildoj jam kreitaj de ĝi estas alŝutitaj al la Docker-Registro.

Purigado de la registro

Ni ne parolas pri forigo de tavoloj, kiuj restis pendantaj post forigitaj etikedoj - ĉi tio estas norma trajto de la Docker Registry mem. Ni parolas pri situacio, kiam amasiĝas multaj Docker-etikedoj kaj ni komprenas, ke ni ne plu bezonas kelkajn el ili, sed ili okupas spacon (kaj/aŭ ni pagas por ĝi).

Kio estas la purigaj strategioj?

1. Vi povas simple fari nenion ne purigu. Foje estas vere pli facile pagi iom por kroma spaco ol malimpliki grandegan miksaĵon da etikedoj. Sed ĉi tio funkcias nur ĝis certa punkto.
2. Plena rekomencigita. Se vi forigas ĉiujn bildojn kaj rekonstruas nur la nunajn en la CI-sistemo, eble aperos problemo. Se la ujo estas rekomencita en produktado, nova bildo estos ŝarĝita por ĝi - unu kiu ankoraŭ ne estis testita de iu ajn. Ĉi tio mortigas la ideon de neŝanĝebla infrastrukturo.
3. Bluverda. Unu registro komencis superflui - ni alŝutas bildojn al alia. La sama problemo kiel en la antaŭa metodo: je kia punkto vi povas forigi la registron, kiu komencis superflui?
4. Laŭ tempo. Ĉu forigi ĉiujn bildojn pli malnovajn ol 1 monaton? Sed certe estos servo, kiu ne estas ĝisdatigita dum monato...
5. Mane determini kio jam povas esti forigita.

Estas du vere realigeblaj ebloj: ne purigi aŭ kombinaĵo de bluverda + permane. En ĉi-lasta kazo, ni parolas pri la sekvanta: kiam vi komprenas, ke estas tempo purigi la registron, vi kreas novan kaj aldonas ĉiujn novajn bildojn al ĝi dum, ekzemple, monato. Kaj post unu monato, vidu, kiuj balgoj en Kubernetes ankoraŭ uzas la malnovan registron, kaj translokigu ilin ankaŭ al la nova registro.

Al kio ni venis werf? Ni kolektas:

1. Git-kapo: ĉiuj etikedoj, ĉiuj branĉoj - supozante, ke ni bezonas ĉion, kio estas etikedita en Git en la bildoj (kaj se ne, tiam ni devas forigi ĝin en Git mem);
2. ĉiuj balgoj kiuj estas nuntempe pumpitaj al Kubernetes;
3. malnovaj ReplicaSets (kio estis lastatempe liberigita), kaj ni ankaŭ planas skani Helm-eldonojn kaj elekti la plej novajn bildojn tie.

... kaj faru blankan liston el ĉi tiu aro - liston de bildoj, kiujn ni ne forigos. Ni purigas ĉion alian, post kio ni trovas orfajn scenejajn bildojn kaj ankaŭ forigas ilin.

Deploji stadion

Fidinda deklaro

La unua punkto, pri kiu mi ŝatus atentigi en la deplojo, estas la lanĉo de la ĝisdatigita rimeda agordo, deklarita. La originala YAML-dokumento priskribanta Kubernetes-resursojn ĉiam estas tre malsama de la rezulto efektive kuranta en la areto. Ĉar Kubernetes aldonas al la agordo:

1. identigiloj;
2. serva informo;
3. multaj defaŭltaj valoroj;
4. sekcio kun aktuala stato;
5. ŝanĝoj faritaj kiel parto de la agnoska rethoko;
6. la rezulto de la laboro de diversaj regiloj (kaj la planisto).

Tial, kiam nova rimeda agordo aperas (nova), ni ne povas simple preni kaj anstataŭi la nunan, "vivan" agordon per ĝi (vivi). Por fari tion ni devos kompari nova kun la lasta aplikata agordo (laste aplikata) kaj ruliĝu sur vivi ricevita flikaĵo.

Ĉi tiu aliro nomiĝas 2-voja kunfandiĝo. Ĝi estas uzata, ekzemple, en Helm.

Estas ankaŭ 3-voja kunfandiĝo, kiu malsamas en tio:

• komparante laste aplikata и nova, ni rigardas tion, kio estis forigita;
• komparante nova и vivi, ni rigardas kio estis aldonita aŭ ŝanĝita;
• la sumigita flikaĵo estas aplikata al vivi.

Ni deplojas pli ol 1000 aplikojn kun Helm, do ni efektive vivas kun dudirekta kunfandiĝo. Tamen ĝi havas kelkajn problemojn, kiujn ni solvis per niaj diakiloj, kiuj helpas al Helm funkcii normale.

Vera lanĉa stato

Post kiam nia CI-sistemo generas novan agordon por Kubernetes bazita sur la sekva evento, ĝi transdonas ĝin por uzo (apliki) al areto - uzante Helm aŭ kubectl apply. Poste okazas la jam priskribita N-voja kunfandiĝo, al kiu la Kubernetes API respondas aprobe al la CI-sistemo, kaj tio al sia uzanto.

Tamen, estas grandega problemo: finfine sukcesa aplikado ne signifas sukcesan lanĉon. Se Kubernetes komprenas kiajn ŝanĝojn necesas apliki kaj aplikas ĝin, ni ankoraŭ ne scias, kia estos la rezulto. Ekzemple, ĝisdatigi kaj rekomenci podojn en la fasado povas esti sukcesa, sed ne en la backend, kaj ni ricevos malsamajn versiojn de la ruliĝantaj aplikaĵbildoj.

Por fari ĉion ĝuste, ĉi tiu skemo postulas aldonan ligon - specialan spurilon, kiu ricevos statusajn informojn de la Kubernetes API kaj transdonos ĝin por plia analizo de la reala stato de la aferoj. Ni kreis Malfermfontan bibliotekon en Go - kubohundo (vidu ĝian anoncon tie), kiu solvas ĉi tiun problemon kaj estas konstruita en werf.

La konduto de ĉi tiu spurilo ĉe la werf-nivelo estas agordita per komentarioj, kiuj estas metitaj sur Deplojoj aŭ StatefulSets. Ĉefa komentario - fail-mode - komprenas la jenajn signifojn:

• IgnoreAndContinueDeployProcess — ni ignoras la problemojn de disvolvado de ĉi tiu komponanto kaj daŭrigas la deplojon;
• FailWholeDeployProcessImmediately — eraro en ĉi tiu komponanto haltigas la disfaldan procezon;
• HopeUntilEndOfDeployProcess — ni esperas, ke ĉi tiu komponanto funkcios antaŭ la fino de la deplojo.

Ekzemple, ĉi tiu kombinaĵo de rimedoj kaj komentario valoroj fail-mode:

Kiam ni deplojas por la unua fojo, la datumbazo (MongoDB) eble ankoraŭ ne estas preta - Deplojoj malsukcesos. Sed vi povas atendi la momenton por ke ĝi komenciĝu, kaj la deplojo ankoraŭ okazos.

Estas du pliaj komentarioj por kubedog en werf:

• failures-allowed-per-replica — la nombro da permesitaj faloj por ĉiu kopio;
• show-logs-until — reguligas la momenton ĝis kiu werf montras (en stdout) protokolojn de ĉiuj elrulitaj podoj. La defaŭlta estas PodIsReady (por ignori mesaĝojn, kiujn ni verŝajne ne volas, kiam trafiko komencas veni al la pod), sed valoroj ankaŭ validas: ControllerIsReady и EndOfDeploy.

Kion alian ni volas de deplojo?

Krom la du jam priskribitaj punktoj, ni ŝatus:

• por vidi ŝtipoj — kaj nur la necesaj, kaj ne ĉio en vico;
• trako progreso, ĉar se la laboro pendas "silente" dum kelkaj minutoj, gravas kompreni, kio okazas tie;
• havi aŭtomata retroiro se io misfunkciis (kaj tial estas grave scii la realan staton de la deplojo). La lanĉo devas esti atoma: aŭ ĝi iras ĝis la fino, aŭ ĉio revenas al sia antaŭa stato.

Rezultoj

Por ni kiel kompanio, por efektivigi ĉiujn priskribitajn nuancojn en malsamaj stadioj de livero (konstruo, publikigo, disfaldiĝo), CI-sistemo kaj utileco sufiĉas. werf.

Anstataŭ konkludo:

Kun la helpo de werf, ni faris bonan progreson en solvado de granda nombro da problemoj por DevOps-inĝenieroj kaj ĝojus se la pli larĝa komunumo almenaŭ provus ĉi tiun utilecon en ago. Estos pli facile atingi bonan rezulton kune.

Filmetoj kaj diapozitivoj

Video de la prezentado (~47 minutoj):

Prezento de la raporto:

PS

Aliaj raportoj pri Kubernetes en nia blogo:

• «Aŭtoskalado kaj administrado de rimedoj en Kubernetes» (Dmitry Stolyarov; la 27-an de aprilo 2019 pri "Striko");
• «Etendante kaj kompletigante Kubernetes» (Andrey Polovov; la 8-an de aprilo 2019 sur Saint HighLoad++);
• «Datumbazoj kaj Kubernetes» (Dmitry Stolyarov; la 8-an de novembro 2018 ĉe HighLoad++);
• «Monitorado kaj Kubernetes» (Dmitry Stolyarov; la 28-an de majo 2018 ĉe RootConf);
• «CI/CD Plej bonaj Praktikoj kun Kubernetes kaj GitLab» (Dmitry Stolyarov; la 7-an de novembro 2017 ĉe HighLoad++);
• «Nia sperto kun Kubernetes en malgrandaj projektoj» (Dmitry Stolyarov; junio 6, 2017 ĉe RootConf).

fonto: www.habr.com