🥇werf - alat kami untuk CI/CD dalam Kubernetes (semakan dan laporan video)

27 Mei di dewan utama persidangan DevOpsConf 2019, yang diadakan sebagai sebahagian daripada perayaan RIT++ 2019, sebagai sebahagian daripada bahagian "Penghantaran Berterusan", laporan telah diberikan "werf - alat kami untuk CI/CD dalam Kubernetes". Ia bercakap tentang mereka masalah dan cabaran yang semua orang hadapi semasa menggunakan Kubernetes, serta tentang nuansa yang mungkin tidak dapat dilihat dengan segera. Menganalisis kemungkinan penyelesaian, kami menunjukkan cara ini dilaksanakan dalam alat Sumber Terbuka werf.

Sejak pembentangan, utiliti kami (dahulunya dikenali sebagai dapp) telah mencapai kejayaan bersejarah 1000 bintang di GitHub — kami berharap komuniti penggunanya yang semakin berkembang akan menjadikan hidup lebih mudah bagi ramai jurutera DevOps.

Jadi, kami membentangkan video laporan tersebut (~47 minit, lebih bermaklumat daripada artikel) dan petikan utama daripadanya dalam bentuk teks. Pergi!

Menghantar kod kepada Kubernetes

Perbincangan bukan lagi tentang werf, tetapi mengenai CI/CD dalam Kubernetes, membayangkan bahawa perisian kami dibungkus dalam bekas Docker (Saya bercakap tentang ini dalam laporan 2016), dan K8 akan digunakan untuk menjalankannya dalam pengeluaran (lebih lanjut mengenai ini dalam Tahun 2017).

Apakah rupa penghantaran dalam Kubernetes?

Terdapat repositori Git dengan kod dan arahan untuk membinanya. Aplikasi ini dibina ke dalam imej Docker dan diterbitkan dalam Docker Registry.
Repositori yang sama juga mengandungi arahan tentang cara menggunakan dan menjalankan aplikasi. Pada peringkat penggunaan, arahan ini dihantar ke Kubernetes, yang menerima imej yang dikehendaki daripada pendaftaran dan melancarkannya.
Tambahan pula, biasanya terdapat ujian. Sebahagian daripada ini boleh dilakukan apabila menerbitkan imej. Anda juga boleh (mengikut arahan yang sama) menggunakan salinan aplikasi (dalam ruang nama K8 yang berasingan atau gugusan berasingan) dan menjalankan ujian di sana.
Akhir sekali, anda memerlukan sistem CI yang menerima acara daripada Git (atau klik butang) dan memanggil semua peringkat yang ditetapkan: membina, menerbitkan, menggunakan, menguji.

Terdapat beberapa nota penting di sini:

Kerana kita mempunyai infrastruktur yang tidak berubah (infrastruktur tidak berubah), imej aplikasi yang digunakan pada semua peringkat (pementasan, pengeluaran, dsb.), mesti ada satu. Saya bercakap tentang ini dengan lebih terperinci dan dengan contoh. di sini.
Kerana kami mengikuti infrastruktur sebagai pendekatan kod (IaC), kod aplikasi, arahan untuk memasang dan melancarkannya sepatutnya betul-betul dalam satu repositori. Untuk maklumat lanjut tentang ini, lihat laporan yang sama.
Rangkaian penghantaran (penghantaran) kita biasanya melihatnya seperti ini: aplikasi telah dipasang, diuji, dikeluarkan (peringkat pelepasan) dan itu sahaja - penghantaran telah berlaku. Tetapi pada hakikatnya, pengguna mendapat apa yang anda lancarkan, tiada kemudian apabila anda menghantarnya kepada pengeluaran, dan apabila dia dapat pergi ke sana dan pengeluaran ini berjaya. Jadi saya percaya rantaian penghantaran berakhir hanya pada peringkat operasi (lari), atau lebih tepat lagi, walaupun pada masa kod itu dialih keluar daripada pengeluaran (menggantikannya dengan yang baharu).

Mari kembali ke skim penghantaran di atas di Kubernetes: ia dicipta bukan sahaja oleh kami, tetapi oleh semua orang yang menangani masalah ini. Malah, corak ini kini dipanggil GitOps (anda boleh membaca lebih lanjut tentang istilah dan idea di sebaliknya di sini). Mari kita lihat peringkat-peringkat skim tersebut.

Pentas binaan

Nampaknya anda boleh bercakap tentang membina imej Docker pada 2019, apabila semua orang tahu cara menulis Dockerfiles dan menjalankan docker build?.. Berikut adalah nuansa yang ingin saya perhatikan:

Berat imej penting, jadi gunakan pelbagai peringkatuntuk meninggalkan dalam imej hanya aplikasi yang benar-benar diperlukan untuk operasi.
Bilangan lapisan mesti diminimumkan dengan menggabungkan rantaian RUN-perintah mengikut maksud.
Walau bagaimanapun, ini menambah masalah penyahpepijatan, kerana apabila pemasangan ranap, anda perlu mencari arahan yang betul dari rantai yang menyebabkan masalah.
Kelajuan pemasangan penting kerana kami mahu melancarkan perubahan dengan cepat dan melihat hasilnya. Sebagai contoh, anda tidak mahu membina semula kebergantungan dalam pustaka bahasa setiap kali anda membina aplikasi.
Selalunya dari satu repositori Git yang anda perlukan banyak gambar, yang boleh diselesaikan dengan satu set Dockerfiles (atau menamakan peringkat dalam satu fail) dan skrip Bash dengan pemasangan berjujukan mereka.

Ini hanyalah puncak gunung ais yang dihadapi oleh semua orang. Tetapi terdapat masalah lain, khususnya:

Selalunya di peringkat perhimpunan kita memerlukan sesuatu lekapkan (contohnya, cache hasil arahan seperti apt dalam direktori pihak ketiga).
Kami mahu Ansible bukannya menulis dalam cangkerang.
Kami mahu bina tanpa Docker (mengapa kita memerlukan mesin maya tambahan di mana kita perlu mengkonfigurasi segala-galanya untuk ini, sedangkan kita sudah mempunyai kluster Kubernetes di mana kita boleh menjalankan kontena?).
Perhimpunan selari, yang boleh difahami dengan cara yang berbeza: arahan berbeza daripada Dockerfile (jika berbilang peringkat digunakan), beberapa komit repositori yang sama, beberapa Dockerfiles.
Perhimpunan yang diedarkan: Kami ingin mengumpul perkara dalam pod yang "sementara" kerana cache mereka hilang, yang bermaksud ia perlu disimpan di suatu tempat secara berasingan.
Akhirnya, saya menamakan puncak keinginan automagik: Adalah sesuai untuk pergi ke repositori, taip beberapa arahan dan dapatkan imej siap sedia, dipasang dengan pemahaman tentang cara dan perkara yang perlu dilakukan dengan betul. Walau bagaimanapun, saya secara peribadi tidak pasti bahawa semua nuansa boleh diramalkan dengan cara ini.

Dan inilah projek-projeknya:

moby/buildkit — pembina daripada Docker Inc (sudah disepadukan ke dalam versi semasa Docker), yang cuba menyelesaikan semua masalah ini;
kaniko — pembina daripada Google yang membolehkan anda membina tanpa Docker;
Buildpacks.io — Percubaan CNCF untuk membuat sihir automatik dan, khususnya, penyelesaian yang menarik dengan asas semula untuk lapisan;
dan sekumpulan utiliti lain, seperti membina, alat tulen/img...

...dan lihat berapa banyak bintang yang mereka ada di GitHub. Iaitu, di satu pihak, docker build wujud dan boleh melakukan sesuatu, tetapi pada hakikatnya isu itu tidak diselesaikan sepenuhnya - bukti ini adalah pembangunan selari pengumpul alternatif, setiap satunya menyelesaikan beberapa bahagian masalah.

Perhimpunan di werf

Jadi kami terpaksa werf (sebelum ini terkenal seperti dapp) — Utiliti sumber terbuka daripada syarikat Flant, yang telah kami buat selama bertahun-tahun. Semuanya bermula 5 tahun yang lalu dengan skrip Bash yang mengoptimumkan pemasangan Dockerfiles, dan untuk 3 tahun yang lalu pembangunan sepenuhnya telah dijalankan dalam rangka kerja satu projek dengan repositori Git sendiri (pertama dalam Ruby, dan kemudian ditulis semula untuk Pergi, dan pada masa yang sama dinamakan semula). Apakah isu perhimpunan yang diselesaikan dalam werf?

Masalah yang dilorekkan dengan warna biru telah pun dilaksanakan, binaan selari telah dilakukan dalam hos yang sama, dan isu yang diserlahkan dalam warna kuning dirancang untuk diselesaikan pada penghujung musim panas.

Peringkat penerbitan dalam pendaftaran (terbitkan)

Kami mendail docker push... - apakah yang sukar untuk memuat naik imej ke pendaftaran? Dan kemudian timbul persoalan: "Teg apa yang harus saya letakkan pada imej?" Ia timbul atas sebab yang kita ada Gitflow (atau strategi Git lain) dan Kubernetes, dan industri cuba memastikan bahawa apa yang berlaku dalam Kubernetes mengikuti apa yang berlaku dalam Git. Lagipun, Git adalah satu-satunya sumber kebenaran kami.

Apa yang susah sangat ni? Pastikan kebolehulangan: daripada komit dalam Git, yang sifatnya tidak berubah (tidak berubah), kepada imej Docker, yang harus disimpan sama.

Ia juga penting kepada kami menentukan asal usul, kerana kami ingin memahami dari mana komit aplikasi yang dijalankan dalam Kubernetes dibina (maka kami boleh melakukan perbezaan dan perkara yang serupa).

Strategi Penandaan

Yang pertama adalah mudah teg git. Kami mempunyai pendaftaran dengan imej yang ditandakan sebagai 1.0. Kubernetes mempunyai pentas dan pengeluaran, tempat imej ini dimuat naik. Dalam Git kita membuat komitmen dan pada satu ketika kita menandakan 2.0. Kami mengumpulnya mengikut arahan dari repositori dan meletakkannya dalam pendaftaran dengan teg 2.0. Kami melancarkannya ke pentas dan, jika semuanya baik, kemudian ke pengeluaran.

Masalah dengan pendekatan ini ialah kami mula-mula meletakkan teg, dan kemudian menguji dan melancarkannya. kenapa? Pertama, ia tidak logik: kami mengeluarkan versi perisian yang belum kami uji lagi (kami tidak boleh melakukan sebaliknya, kerana untuk menyemak, kami perlu meletakkan teg). Kedua, laluan ini tidak serasi dengan Gitflow.

Pilihan kedua - git commit + tag. Cawangan induk mempunyai tag 1.0; untuknya dalam pendaftaran - imej yang digunakan untuk pengeluaran. Selain itu, kluster Kubernetes mempunyai pratonton dan kontur pementasan. Seterusnya kita mengikuti Gitflow: di cawangan utama untuk pembangunan (develop) kami membuat ciri baharu, menghasilkan komit dengan pengecam #c1. Kami mengumpulnya dan menerbitkannya dalam pendaftaran menggunakan pengecam ini (#c1). Dengan pengecam yang sama kami melancarkan untuk pratonton. Kami melakukan perkara yang sama dengan komitmen #c2 и #c3.

Apabila kami menyedari bahawa terdapat cukup ciri, kami mula menstabilkan segala-galanya. Buat cawangan dalam Git release_1.1 (di pangkalan #c3 daripada develop). Tidak perlu mengumpul keluaran ini, kerana... ini telah dilakukan pada langkah sebelumnya. Oleh itu, kita hanya boleh melancarkannya ke pementasan. Kami membetulkan pepijat masuk #c4 dan juga dilancarkan ke pementasan. Pada masa yang sama, pembangunan sedang dijalankan develop, di mana perubahan diambil secara berkala release_1.1. Pada satu ketika, kami mendapat komit yang disusun dan dimuat naik ke pementasan, yang kami gembira dengannya (#c25).

Kemudian kami menggabungkan (dengan ke hadapan pantas) cawangan pelepas (release_1.1) dalam master. Kami meletakkan teg dengan versi baharu pada komit ini (1.1). Tetapi imej ini telah dikumpulkan dalam pendaftaran, jadi untuk tidak mengumpulnya lagi, kami hanya menambah tag kedua pada imej sedia ada (kini ia mempunyai tag dalam pendaftaran #c25 и 1.1). Selepas itu, kami melancarkannya kepada pengeluaran.

Terdapat kelemahan bahawa hanya satu imej dimuat naik ke pementasan (#c25), dan dalam pengeluaran ia agak berbeza (1.1), tetapi kami tahu bahawa "secara fizikal" ini adalah imej yang sama dari pendaftaran.

Kelemahan sebenar ialah tiada sokongan untuk merge commit, anda perlu melakukan fast-forward.

Kita boleh pergi lebih jauh dan melakukan helah... Mari lihat contoh fail Docker yang mudah:

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

Mari bina fail daripadanya mengikut prinsip berikut:

SHA256 daripada pengecam imej yang digunakan (ruby:2.3 и nginx:alpine), yang merupakan jumlah semak kandungannya;
semua pasukan (RUN, CMD dan sebagainya.);
SHA256 daripada fail yang telah ditambahkan.

... dan ambil checksum (sekali lagi SHA256) daripada fail sedemikian. ini tandatangan segala-galanya yang mentakrifkan kandungan imej Docker.

Mari kita kembali kepada rajah dan bukannya commit kami akan menggunakan tandatangan tersebut, iaitu tag imej dengan tandatangan.

Sekarang, apabila perlu, sebagai contoh, untuk menggabungkan perubahan daripada keluaran kepada induk, kita boleh melakukan komit gabungan sebenar: ia akan mempunyai pengecam yang berbeza, tetapi tandatangan yang sama. Dengan pengecam yang sama kami akan melancarkan imej ke pengeluaran.

Kelemahannya ialah sekarang tidak mungkin untuk menentukan jenis komitmen yang didorong kepada pengeluaran - checksum hanya berfungsi dalam satu arah. Masalah ini diselesaikan dengan lapisan tambahan dengan metadata - saya akan memberitahu anda lebih lanjut kemudian.

Menandai dalam werf

Di werf kami pergi lebih jauh dan sedang bersiap untuk melakukan binaan teragih dengan cache yang tidak disimpan pada satu mesin... Jadi, kami sedang membina dua jenis imej Docker, kami memanggilnya peringkat и gambar.

Repositori werf Git menyimpan arahan khusus binaan yang menerangkan peringkat berbeza binaan (sebelumPasang, memasang, sebelum Persediaan, persediaan). Kami mengumpul imej peringkat pertama dengan tandatangan yang ditakrifkan sebagai jumlah semak langkah pertama. Kemudian kami menambah kod sumber, untuk imej peringkat baharu kami mengira jumlah semaknya... Operasi ini diulang untuk semua peringkat, akibatnya kami mendapat satu set imej peringkat. Kemudian kami membuat imej akhir, yang juga mengandungi metadata tentang asalnya. Dan kami menandai imej ini dengan cara yang berbeza (perincian kemudian).

Katakan selepas ini komit baru muncul di mana hanya kod aplikasi telah diubah. Apa yang akan berlaku? Untuk perubahan kod, tampalan akan dibuat dan imej peringkat baharu akan disediakan. Tandatangannya akan ditentukan sebagai jumlah semak imej peringkat lama dan tampalan baharu. Imej akhir baharu akan terbentuk daripada imej ini. Tingkah laku yang sama akan berlaku dengan perubahan pada peringkat lain.

Oleh itu, imej peringkat ialah cache yang boleh disimpan secara teragih, dan imej yang telah dibuat daripadanya dimuat naik ke Pendaftaran Docker.

Membersihkan pendaftaran

Kami tidak bercakap tentang memadam lapisan yang kekal tergantung selepas teg dipadam - ini adalah ciri standard Pendaftaran Docker itu sendiri. Kami bercakap tentang situasi apabila banyak teg Docker terkumpul dan kami faham bahawa kami tidak lagi memerlukan sebahagian daripadanya, tetapi mereka mengambil ruang (dan/atau kami membayarnya).

Apakah strategi pembersihan?

Anda tidak boleh berbuat apa-apa jangan bersihkan. Kadang-kadang lebih mudah untuk membayar sedikit untuk ruang tambahan daripada membongkar kusut besar tag. Tetapi ini hanya berfungsi sehingga titik tertentu.
Tetapan semula penuh. Jika anda memadam semua imej dan membina semula hanya yang semasa dalam sistem CI, masalah mungkin timbul. Jika bekas itu dimulakan semula dalam pengeluaran, imej baharu akan dimuatkan untuknya - imej yang belum diuji oleh sesiapa pun. Ini membunuh idea infrastruktur tidak berubah.
Biru Hijau. Satu pendaftaran mula melimpah - kami memuat naik imej ke yang lain. Masalah yang sama seperti dalam kaedah sebelumnya: pada titik manakah anda boleh mengosongkan pendaftaran yang telah mula melimpah?
Pada masa. Padamkan semua imej yang lebih lama daripada 1 bulan? Tetapi pasti akan ada perkhidmatan yang tidak dikemas kini selama sebulan...
Dengan tangan tentukan apa yang sudah boleh dipadamkan.

Terdapat dua pilihan yang benar-benar berdaya maju: jangan bersihkan atau gabungan biru-hijau + secara manual. Dalam kes kedua, kita bercakap tentang perkara berikut: apabila anda memahami bahawa sudah tiba masanya untuk membersihkan pendaftaran, anda membuat yang baharu dan menambah semua imej baharu padanya selama, sebagai contoh, sebulan. Dan selepas sebulan, lihat pod dalam Kubernetes yang masih menggunakan pendaftaran lama, dan pindahkannya juga ke pendaftaran baharu.

Apa yang telah kita datangi werf? Kami mengumpul:

Kepala Git: semua tag, semua cawangan - dengan mengandaikan bahawa kita memerlukan semua yang ditag dalam Git dalam imej (dan jika tidak, maka kita perlu memadamkannya dalam Git sendiri);
semua pod yang sedang dipam keluar ke Kubernetes;
ReplicaSets lama (yang dikeluarkan baru-baru ini), dan kami juga merancang untuk mengimbas keluaran Helm dan memilih imej terbaharu di sana.

... dan buat senarai putih daripada set ini - senarai imej yang tidak akan kami padamkan. Kami membersihkan segala-galanya, selepas itu kami mencari imej pentas anak yatim dan memadamnya juga.

Peringkat penggunaan

Perisytiharan yang boleh dipercayai

Perkara pertama yang saya ingin menarik perhatian dalam penggunaan ialah pelancaran konfigurasi sumber yang dikemas kini, yang diisytiharkan secara deklaratif. Dokumen YAML asal yang menerangkan sumber Kubernetes sentiasa sangat berbeza daripada hasil yang sebenarnya dijalankan dalam kelompok. Kerana Kubernetes menambah konfigurasi:

pengecam;
maklumat perkhidmatan;
banyak nilai lalai;
bahagian dengan status semasa;
perubahan yang dibuat sebagai sebahagian daripada webhook kemasukan;
hasil kerja pelbagai pengawal (dan penjadual).

Oleh itu, apabila konfigurasi sumber baharu muncul (baru), kita tidak boleh mengambil dan menulis ganti konfigurasi "hidup" semasa dengannya (tinggal). Untuk melakukan ini, kita perlu membandingkan baru dengan konfigurasi terakhir yang digunakan (terakhir digunakan) dan gulung ke atas tinggal menerima tampalan.

Pendekatan ini dipanggil Gabungan 2 hala. Ia digunakan, sebagai contoh, dalam Helm.

Terdapat juga Gabungan 3 hala, yang berbeza dalam hal itu:

membandingkan terakhir digunakan и baru, kami melihat apa yang telah dipadamkan;
membandingkan baru и tinggal, kita melihat apa yang telah ditambah atau diubah;
patch yang dijumlahkan digunakan untuk tinggal.

Kami menggunakan 1000+ aplikasi dengan Helm, jadi kami sebenarnya hidup dengan gabungan 2 hala. Walau bagaimanapun, ia mempunyai beberapa masalah yang telah kami selesaikan dengan patch kami, yang membantu Helm berfungsi seperti biasa.

Status pelancaran sebenar

Selepas sistem CI kami menjana konfigurasi baharu untuk Kubernetes berdasarkan acara seterusnya, ia menghantarnya untuk digunakan (mohon) kepada kelompok - menggunakan Helm atau kubectl apply. Seterusnya, gabungan N-way yang telah diterangkan berlaku, yang API Kubernetes bertindak balas dengan meluluskan sistem CI dan itu kepada penggunanya.

Walau bagaimanapun, terdapat masalah besar: selepas semua permohonan yang berjaya tidak bermakna pelancaran berjaya. Jika Kubernetes memahami perubahan yang perlu digunakan dan menerapkannya, kami masih tidak tahu keputusannya. Contohnya, mengemas kini dan memulakan semula pod di bahagian hadapan mungkin berjaya, tetapi tidak di bahagian belakang, dan kami akan mendapat versi yang berbeza bagi imej aplikasi yang sedang berjalan.

Untuk melakukan semuanya dengan betul, skim ini memerlukan pautan tambahan - penjejak khas yang akan menerima maklumat status daripada API Kubernetes dan menghantarnya untuk analisis lanjut tentang keadaan sebenar sesuatu. Kami mencipta perpustakaan Sumber Terbuka dalam Go - cubedog (lihat pengumumannya di sini), yang menyelesaikan masalah ini dan dibina ke dalam werf.

Tingkah laku penjejak ini pada peringkat werf dikonfigurasikan menggunakan anotasi yang diletakkan pada Deployments atau StatefulSets. Anotasi utama - fail-mode - memahami maksud berikut:

IgnoreAndContinueDeployProcess — kami mengabaikan masalah melancarkan komponen ini dan meneruskan penggunaan;
FailWholeDeployProcessImmediately — ralat dalam komponen ini menghentikan proses penggunaan;
HopeUntilEndOfDeployProcess — kami berharap komponen ini akan berfungsi menjelang akhir penggunaan.

Contohnya, gabungan sumber dan nilai anotasi ini fail-mode:

Apabila kami menggunakan buat kali pertama, pangkalan data (MongoDB) mungkin belum bersedia - Pengerahan akan gagal. Tetapi anda boleh menunggu masa untuk ia bermula, dan penggunaan masih akan berlaku.

Terdapat dua lagi anotasi untuk kubedog dalam werf:

failures-allowed-per-replica — bilangan jatuh yang dibenarkan untuk setiap replika;
show-logs-until — mengawal masa sehingga werf menunjukkan (dalam stdout) log daripada semua pod yang dilancarkan. Lalainya ialah PodIsReady (untuk mengabaikan mesej yang kami mungkin tidak mahu apabila trafik mula datang ke pod), tetapi nilai juga sah: ControllerIsReady и EndOfDeploy.

Apa lagi yang kita mahu daripada penempatan?

Sebagai tambahan kepada dua perkara yang telah diterangkan, kami ingin:

untuk melihat balak - dan hanya yang perlu, dan bukan semuanya berturut-turut;
trek kemajuan, kerana jika kerja itu digantung "senyap" selama beberapa minit, adalah penting untuk memahami apa yang berlaku di sana;
иметь rollback automatik sekiranya berlaku kesilapan (dan oleh itu adalah penting untuk mengetahui status sebenar penempatan). Pelancaran mestilah atom: sama ada ia berjalan hingga akhir, atau semuanya kembali ke keadaan sebelumnya.

Keputusan

Bagi kami sebagai sebuah syarikat, untuk melaksanakan semua nuansa yang diterangkan pada peringkat penghantaran yang berbeza (membina, menerbitkan, menggunakan), sistem dan utiliti CI adalah mencukupi werf.

Daripada kesimpulan:

Dengan bantuan werf, kami telah mencapai kemajuan yang baik dalam menyelesaikan sejumlah besar masalah untuk jurutera DevOps dan akan gembira jika komuniti yang lebih luas sekurang-kurangnya mencuba utiliti ini dalam tindakan. Lebih mudah untuk mencapai hasil yang baik bersama-sama.

Video dan slaid

Video daripada persembahan (~47 minit):

Pembentangan laporan:

PS

Laporan lain tentang Kubernetes di blog kami:

«Penskalaan automatik dan pengurusan sumber dalam Kubernetes» (Dmitry Stolyarov; 27 April 2019 tentang "Strike");
«Memperluas dan melengkapkan Kubernetes» (Andrey Polovov; 8 April 2019 di Saint HighLoad++);
«Pangkalan Data dan Kubernetes» (Dmitry Stolyarov; 8 November 2018 di HighLoad++);
«Pemantauan dan Kubernetes» (Dmitry Stolyarov; 28 Mei 2018 di RootConf);
«Amalan Terbaik CI/CD dengan Kubernetes dan GitLab» (Dmitry Stolyarov; 7 November 2017 di HighLoad++);
«Pengalaman kami dengan Kubernetes dalam projek kecil» (Dmitry Stolyarov; 6 Jun 2017 di RootConf).

Sumber: www.habr.com

werf - alat kami untuk CI / CD dalam Kubernetes (gambaran keseluruhan dan laporan video)