Package Manager untuk Kubernetes - Helm: Past, Present, Future

Catatan perev. : Dengan artikel ini kami membuka serangkaian publikasi tentang manajer paket untuk Kubernetes, yang kami gunakan secara aktif dalam pekerjaan sehari-hari, - Helm. Penulis asli materi ini adalah Matt Butcher, salah satu pendiri proyek Helm, yang mengerjakan proyek Open Source di Microsoft dan menulis 8 buku teknis (khususnya, "Go in Practice"). Namun, artikel ini dilengkapi dengan komentar kami (terkadang ekstensif), dan akan segera diperluas dengan catatan baru tentang Helm dengan fokus yang lebih praktis. UPDATE (09/03/2018): sekuelnya keluar - " Kenalan praktis dengan manajer paket untuk Kubernetes - Helm ".



Pada bulan Juni, Helm pindah dari status proyek utama Kubernetes ke Cloud Native Computing Foundation (CNCF). CNCF menjadi organisasi induk untuk yang terbaik dari jenis alat cloud asli open source. Karena itu, merupakan kehormatan besar bagi Helm untuk menjadi bagian dari yayasan semacam itu. Dan proyek signifikan pertama kami di bawah naungan CNCF benar-benar berskala besar: kami menciptakan Helm 3.

Sejarah Singkat Helm

Helm awalnya muncul sebagai proyek Deis Open Source. Itu dimodelkan setelah Homebrew (manajer paket untuk macOS - kira - kira. Terjemahan ) , Dan tugas yang Helm 1 miliki adalah kesempatan yang dipermudah bagi pengguna untuk dengan cepat menginstal beban kerja pertama mereka di Kubernetes. Pengumuman resmi Helm berlangsung di konferensi KubeCon San Francisco pertama pada tahun 2015.

Catatan trans.: Dari versi pertama, yang disebut dm (Deployment Manager), sintaks YAML dipilih untuk menggambarkan sumber daya Kubernetes, dan templat Jinja dan skrip Python didukung saat menulis konfigurasi.

Templat aplikasi web sederhana mungkin terlihat seperti ini:


Saat menggambarkan komponen aplikasi yang diluncurkan, nama, templat yang digunakan, dan juga parameter yang diperlukan dari templat ini ditunjukkan. Dalam contoh di atas, redis frontend dan redis menggunakan templat dari repositori resmi.

Sudah dalam versi ini, Anda dapat menggunakan sumber daya dari basis pengetahuan umum, membuat repositori templat Anda sendiri dan membangun aplikasi yang kompleks karena parameter dan bersarangnya templat.

Arsitektur Helm 1 terdiri dari tiga komponen. Diagram berikut menggambarkan hubungan di antara mereka:

1. Manager melakukan fungsi server web (komunikasi dengan klien terjadi melalui API REST), mengelola penyebaran di kluster Kubernetes dan digunakan sebagai gudang data.
2. Komponen expandybird membawa konfigurasi pengguna ke bentuk datar, mis. berlaku templat Jinja dan jalankan skrip Python.
3. Setelah menerima konfigurasi datar, resourcifier melakukan panggilan yang diperlukan ke kubectl dan mengembalikan pesan status dan kesalahan, jika ada, ke manager .

Untuk memahami kemampuan versi pertama Helm, saya akan memberikan bantuan pada perintah dm :
Dan sekarang kembali ke teks asli tentang sejarah Helm ...

Beberapa bulan kemudian, kami bergabung dengan tim Kubernetes Deployment Manager dari Google dan mulai mengerjakan Helm 2. Tujuannya agar Helm mudah digunakan dengan menambahkan yang berikut:

1. templat bagan ("bagan" - analog dari paket dalam ekosistem Helm - kira - kira terjemahan. ) untuk penyesuaian;
2. manajemen cluster untuk tim;
3. repositori grafik penuh;
4. format paket yang stabil dan ditandatangani;
5. komitmen kuat untuk versi semantik dan menjaga kompatibilitas dari versi ke versi.

Untuk mencapai tujuan ini, komponen kedua telah ditambahkan ke ekosistem Helm. Itu menjadi cluster Tiller di dalam, yang menyediakan pemasangan grafik Helm dan manajemen mereka.

Catatan perev.: Dengan demikian, dalam versi kedua Helm, satu-satunya komponen yang tersisa di kluster yang bertanggung jawab atas siklus hidup instalasi ( rilis ), dan persiapan konfigurasi diserahkan kepada klien Helm.

Jika me-reboot cluster ketika menggunakan versi pertama dari Helm menyebabkan hilangnya data layanan (karena mereka disimpan dalam RAM), maka di Helm 2 semua data disimpan di ConfigMaps , mis. sumber daya di dalam Kubernetes. Langkah penting lainnya adalah transisi dari API sinkron (di mana setiap permintaan diblokir) untuk menggunakan gRPC asinkron.

Sejak peluncuran Helm 2 pada 2016, proyek Kubernetes telah mengalami pertumbuhan eksplosif dan peluang baru yang signifikan. Kontrol Akses Berbasis Peran (RBAC) telah ditambahkan. Banyak tipe sumber daya baru diperkenalkan. Menciptakan sumber daya pihak ketiga (Custom Resource Definition, CRD). Dan yang paling penting, ada praktik terbaik. Melalui semua perubahan ini, Helm terus melayani kebutuhan pengguna Kubernetes. Tetapi menjadi jelas bagi kami bahwa sudah waktunya untuk melakukan perubahan besar sehingga kebutuhan ekosistem yang berkembang ini tetap terpenuhi.

Jadi kami datang ke Helm 3. Selanjutnya saya akan berbicara tentang beberapa inovasi yang ditampilkan pada roadmap proyek.

Salam Lua

Di Helm 2, kami memperkenalkan template. Pada tahap awal pengembangan Helm 2, kami mendukung Go, template Jinja, kode Python bersih, dan kami bahkan memiliki prototipe dukungan ksonnet. Tetapi kehadiran banyak mesin untuk templat memunculkan lebih banyak masalah daripada yang dipecahkan. Karena itu, kami sampai pada titik memilih satu.

Templat Go memiliki empat keunggulan:

1. perpustakaan dibangun ke Go ;
2. templat dieksekusi dalam lingkungan kotak pasir yang sangat terbatas;
3. kita bisa memasukkan fungsi dan objek yang sewenang-wenang ke dalam mesin;
4. mereka bekerja dengan baik dengan YAML.

Meskipun kami mempertahankan antarmuka di Helm untuk mendukung mesin template lain, template Go telah menjadi standar standar kami. Dan beberapa tahun ke depan pengalaman menunjukkan bagaimana insinyur dari banyak perusahaan membuat ribuan grafik menggunakan templat Go.

Dan kami belajar tentang kekecewaan mereka:

1. Sintaksnya sulit dibaca dan kurang didokumentasikan.
2. Masalah bahasa, seperti variabel yang tidak dapat diubah, tipe data yang rumit, dan aturan visibilitas terbatas, telah mengubah hal-hal sederhana menjadi hal yang kompleks.
3. Ketidakmampuan untuk mendefinisikan fungsi di dalam templat membuat pembuatan pustaka yang dapat digunakan kembali menjadi lebih sulit.

Yang paling penting, dengan menggunakan bahasa templat, kami "memotong" objek Kubernet ke representasi garis mereka. (Dengan kata lain, pengembang template harus mengelola sumber daya Kubernetes sebagai dokumen teks dalam format YAML.)

Kerjakan objek, bukan potongan YAML

Berkali-kali, kami mendengar dari pengguna permintaan kemampuan untuk memeriksa dan memodifikasi sumber daya Kubernetes sebagai objek, bukan string. Pada saat yang sama, mereka bersikeras bahwa tidak peduli cara penerapan apa yang kami pilih untuk ini, itu harus mudah dipelajari dan dipelihara dengan baik di ekosistem.

Setelah berbulan-bulan penelitian, kami memutuskan untuk menyediakan bahasa skrip bawaan yang dapat dikemas dalam kotak pasir dan disesuaikan. Di antara 20 bahasa teratas, hanya ada satu kandidat yang memenuhi persyaratan: Lua .

Pada tahun 1993, sekelompok insinyur IT Brasil menciptakan bahasa scripting ringan untuk disematkan dalam alat mereka. Lua memiliki sintaksis yang sederhana, ia didukung secara luas dan telah ditampilkan dalam daftar 20 bahasa teratas untuk waktu yang lama. Didukung oleh IDE dan editor teks, ada banyak manual dan tutorial. Pada ekosistem yang ada, kami ingin mengembangkan solusi kami.

Pekerjaan kami pada Helm Lua masih pada tahap pembuktian konseptual, dan kami mengharapkan sintaksis yang akrab dan fleksibel. Membandingkan pendekatan lama dan baru, Anda bisa melihat di mana kita bergerak.

Berikut adalah contoh templat perapian dengan Alpine in Helm 2:

 apiVersion: v1 kind: Pod metadata: name: {{ template "alpine.fullname" . }} labels: heritage: {{ .Release.Service }} release: {{ .Release.Name }} chart: {{ .Chart.Name }}-{{ .Chart.Version }} app: {{ template "alpine.name" . }} spec: restartPolicy: {{ .Values.restartPolicy }} containers: - name: waiter image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}" imagePullPolicy: {{ .Values.image.pullPolicy }} command: ["/bin/sleep", "9000"] 

Dalam templat langsung ini, Anda dapat langsung melihat semua arahan templat {{ .Chart.Name }} , seperti {{ .Chart.Name }} .

Dan inilah definisi perapian yang sama dalam versi awal kode Lua:

 unction create_alpine_pod(_) local pod = { apiVersion = "v1", kind = "Pod", metadata = { name = alpine_fullname(_), labels = { heritage = _.Release.Service or "helm", release = _.Release.Name, chart = _.Chart.Name .. "-" .. _.Chart.Version, app = alpine_name(_) } }, spec = { restartPolicy = _.Values.restartPolicy, containers = { { name = waiter, image = _.Values.image.repository .. ":" .. _.Values.image.tag, imagePullPolicy = _.Values.image.pullPolicy, command = { "/bin/sleep", "9000" } } } } } _.resources.add(pod) end 

Tidak perlu melihat setiap baris dari contoh ini untuk memahami apa yang terjadi. Segera jelas bahwa dalam kode itu didefinisikan di bawah. Tetapi alih-alih menggunakan string YAML dengan arahan template bawaan, kami mendefinisikannya sebagai objek di Lua.

Mari kita persingkat kode ini

Karena kita bekerja secara langsung dengan objek (alih-alih memanipulasi gumpalan besar teks), kita dapat memanfaatkan skrip sepenuhnya. Peluang untuk membuat perpustakaan bersama yang muncul di sini terlihat sangat menarik. Dan kami berharap bahwa dengan memperkenalkan perpustakaan khusus (atau memungkinkan komunitas untuk membuatnya), kami dapat mengurangi kode di atas menjadi sesuatu seperti ini:

 local pods = require("mylib.pods"); function create_alpine_pod(_) myPod = pods.new("alpine:3.7", _) myPod.spec.restartPolicy = "Always" -- set any other properties _.Manifests.add(myPod) end 

Dalam contoh ini, kami menggunakan kemampuan untuk bekerja dengan definisi sumber daya sebagai objek, yang mudah untuk mengatur properti, sambil mempertahankan keringkasan dan keterbacaan kode.

Template ... Lua ... Kenapa tidak semuanya?

Meskipun templat tidak begitu bagus untuk semua tugas, mereka masih memiliki kelebihan tertentu. Templat di Go adalah teknologi stabil dengan basis pengguna yang mapan dan banyak bagan yang ada. Banyak pengembang bagan mengklaim suka menulis templat. Karena itu, kami tidak akan menghapus dukungan template.

Sebagai gantinya, kami ingin mengizinkan templat dan Lua untuk digunakan secara bersamaan. Skrip Lua akan memiliki akses ke templat Helm sebelum dan sesudah diberikan, yang akan memungkinkan pengembang bagan tingkat lanjut untuk melakukan transformasi kompleks pada bagan yang ada, sambil mempertahankan kemampuan sederhana untuk membuat bagan Helm dengan templat.

Kami sangat didorong oleh dukungan skrip pada Lua, tetapi pada saat yang sama kami menyingkirkan bagian penting dari arsitektur Helm ...

Ucapkan selamat tinggal pada Tiller

Selama pengembangan Helm 2, kami memperkenalkan Tiller sebagai komponen integrasi dengan Deployment Manager. Tiller memainkan peran penting bagi tim yang bekerja pada kluster yang sama: memungkinkan untuk berinteraksi dengan serangkaian rilis yang sama untuk banyak administrator yang berbeda.

Namun, Tiller bertindak sebagai server sudo raksasa, memberikan berbagai macam hak kepada semua orang yang memiliki akses ke Tiller. Dan skema instalasi default kami adalah konfigurasi permisif. Oleh karena itu, para insinyur DevOps dan SRE harus mempelajari langkah-langkah tambahan untuk menginstal Tiller di kluster multi-tenant.

Selain itu, dengan munculnya CRD, kami tidak lagi dapat diandalkan mengandalkan Tiller untuk mempertahankan status atau fungsi sebagai pusat hub untuk informasi rilis Helm. Kami hanya dapat menyimpan informasi ini sebagai entri terpisah di Kubernetes.

Tujuan utama Tiller dapat dicapai tanpa Tiller itu sendiri. Oleh karena itu, salah satu keputusan pertama yang dibuat selama fase perencanaan Helm 3 adalah sepenuhnya meninggalkan Tiller.

Peningkatan keamanan

Tanpa Tiller, model keamanan Helm secara radikal disederhanakan. Otentikasi pengguna didelegasikan oleh Kubernetes. Dan otorisasi juga. Hak-hak helm didefinisikan sebagai hak Kubernetes (melalui RBAC), dan administrator cluster dapat membatasi hak Helm pada tingkat rincian yang disyaratkan.

Rilis, ReleaseVersions, dan Penyimpanan Negara

Dengan tidak adanya Tiller, untuk mempertahankan keadaan berbagai rilis di dalam kluster, kami membutuhkan cara baru untuk semua klien untuk berinteraksi (tentang manajemen rilis).

Untuk melakukan ini, kami memperkenalkan dua entri baru:

1. Release - untuk instalasi spesifik dari grafik tertentu. Jika kita menjalankan helm install my-wordpress stable/wordpress , rilis yang disebut my-wordpress akan dibuat dan dikelola sepanjang umur instalasi WordPress ini.
2. ReleaseVersion - setiap kali Anda memperbarui grafik Helm, Anda harus mempertimbangkan apa yang telah berubah dan apakah perubahan itu berhasil. ReleaseVersion terkait dengan rilis dan hanya menyimpan catatan dengan informasi tentang memperbarui, memutar kembali, dan menghapus. Ketika kami menjalankan helm upgrade my-wordpress stable/wordpress , objek Release asli tetap sama, tetapi objek ReleaseVersion anak ReleaseVersion dengan informasi tentang operasi pembaruan.

Releases dan ReleaseVersions akan disimpan dalam ruang nama yang sama dengan objek grafik.

Dengan fitur-fitur ini, tim pengguna Helm akan dapat melacak catatan instalasi Helm di cluster tanpa perlu Tiller.

Tapi tunggu, itu belum semuanya!

Pada artikel ini saya mencoba berbicara tentang beberapa perubahan besar pada Helm 3. Namun, daftar ini sama sekali tidak lengkap. Rencana Helm 3 juga mencakup perubahan lain, seperti peningkatan dalam format bagan, peningkatan kinerja untuk repositori bagan, dan sistem acara baru yang dapat digunakan pengembang bagan. Kami juga membuat Eric Raymond disebut kode arkeologi dengan membersihkan basis kode dan memperbarui komponen yang telah kehilangan relevansi dalam tiga tahun terakhir.

Catatan perev. : Ini sebuah paradoks, tetapi manajer paket Helm 2, ketika install atau upgrade berhasil, mis. memiliki rilis dalam keadaan success tidak menjamin bahwa sumber daya aplikasi telah berhasil diluncurkan (misalnya, tidak ada kesalahan seperti ImagePullError ). Mungkin model acara baru akan memungkinkan Anda untuk menambahkan kait tambahan untuk sumber daya dan lebih baik mengontrol proses peluncuran - kami akan segera mengetahuinya.

Dengan aksesi Helm ke CNCF, tidak hanya Helm 3, tetapi juga Chart Museum , utilitas Chart Testing , repositori grafik resmi dan proyek lainnya di bawah naungan Helm di CNCF menginspirasi kami. Kami yakin bahwa manajemen paket yang baik untuk Kubernetes sama pentingnya bagi ekosistem asli cloud seperti halnya manajer paket yang baik untuk Linux.

PS dari penerjemah

Baca juga di blog kami:

• " Pengantar praktis untuk manajer paket untuk Kubernetes - Helm ";
• “ Berlatihlah dengan dapp. Bagian 2. Penempatan gambar Docker di Kubernetes menggunakan Helm ";
• “ Bangun dan instal aplikasi di Kubernet menggunakan dapp dan GitLab CI ”;
• “ Praktik CI / CD Terbaik dengan Kubernetes dan GitLab ” (ulasan dan laporan video) ;
• " Pengalaman kami dengan Kubernetes dalam proyek-proyek kecil " (laporan video, yang mencakup pengantar perangkat teknis Kubernetes).