🥇Pengenalan Helm 3

Catatan. terjemahan: 16 Mei tahun ini menandai tonggak penting dalam pengembangan manajer paket untuk Kubernetes - Helm. Pada hari ini, rilis alfa pertama dari versi utama proyek di masa depan - 3.0 - disajikan. Peluncurannya akan membawa perubahan signifikan dan telah lama ditunggu-tunggu pada Helm, yang sangat diharapkan oleh banyak komunitas Kubernetes. Kami sendiri adalah salah satu dari mereka, karena kami secara aktif menggunakan Helm untuk penerapan aplikasi: kami telah mengintegrasikannya ke dalam alat kami untuk mengimplementasikan CI/CD wer dan dari waktu ke waktu kami memberikan kontribusi terhadap pengembangan hulu. Terjemahan ini menggabungkan 7 catatan dari blog resmi Helm, yang didedikasikan untuk rilis alfa pertama Helm 3 dan berbicara tentang sejarah proyek dan fitur utama Helm 3. Penulisnya adalah Matt “bacongobbler” Fisher, seorang karyawan Microsoft dan salah satu pengelola utama Helm.

Pada tanggal 15 Oktober 2015, proyek yang sekarang dikenal dengan nama Helm lahir. Hanya setahun setelah didirikan, komunitas Helm bergabung dengan Kubernetes, sambil aktif mengerjakan Helm 2. Pada bulan Juni 2018, Helm bergabung dengan CNCF sebagai proyek berkembang (inkubasi). Maju cepat hingga saat ini, dan rilis alfa pertama dari Helm 3 baru sedang dalam proses. (rilis ini sudah terjadi pada pertengahan Mei - kira-kira. terjemahan.).

Pada bagian ini, saya akan berbicara tentang awal mula semuanya, bagaimana kami mencapai posisi kami saat ini, memperkenalkan beberapa fitur unik yang tersedia dalam rilis alfa pertama Helm 3, dan menjelaskan bagaimana kami berencana untuk bergerak maju.

Ringkasan:

sejarah penciptaan Helm;
perpisahan yang lembut kepada Tiller;
repositori grafik;
manajemen rilis;
perubahan ketergantungan grafik;
bagan perpustakaan;
apa berikutnya?

Sejarah Helm

Kelahiran

Helm 1 dimulai sebagai proyek Open Source yang dibuat oleh Deis. Kami adalah startup kecil terserap Microsoft pada musim semi 2017. Proyek Open Source kami yang lain, juga bernama Deis, memiliki sebuah alat deisctl, yang digunakan (antara lain) untuk menginstal dan mengoperasikan platform Deis Cluster armada. Pada saat itu, Fleet adalah salah satu platform orkestrasi kontainer pertama.

Pada pertengahan tahun 2015, kami memutuskan untuk mengubah arah dan memindahkan Deis (saat itu berganti nama menjadi Deis Workflow) dari Fleet ke Kubernetes. Salah satu yang pertama didesain ulang adalah alat instalasinya. deisctl. Kami menggunakannya untuk menginstal dan mengelola Deis Workflow di cluster Fleet.

Helm 1 dibuat berdasarkan citra pengelola paket terkenal seperti Homebrew, apt, dan yum. Tujuan utamanya adalah untuk menyederhanakan tugas-tugas seperti mengemas dan menginstal aplikasi di Kubernetes. Helm secara resmi diperkenalkan pada tahun 2015 di konferensi KubeCon di San Francisco.

Upaya pertama kami dengan Helm berhasil, namun bukannya tanpa keterbatasan yang serius. Dia mengambil satu set manifes Kubernetes, yang dilengkapi dengan generator sebagai blok pengantar YAML (materi depan)*, dan memuat hasilnya ke Kubernetes.

* Catatan. terjemahan: Dari Helm versi pertama, sintaksis YAML dipilih untuk mendeskripsikan sumber daya Kubernetes, dan templat Jinja serta skrip Python didukung saat menulis konfigurasi. Kami menulis lebih banyak tentang ini dan struktur Helm versi pertama secara umum di bab “Sejarah Singkat Helm” bahan ini.

Misalnya, untuk mengganti kolom dalam file YAML, Anda harus menambahkan konstruksi berikut ke manifes:

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

Sangat bagus bahwa mesin template ada saat ini, bukan?

Karena berbagai alasan, penginstal Kubernetes awal ini memerlukan daftar file manifes yang dikodekan secara permanen dan hanya menjalankan rangkaian peristiwa kecil yang tetap. Sangat sulit untuk menggunakannya sehingga tim R&D Deis Workflow mengalami kesulitan ketika mereka mencoba mentransfer produk mereka ke platform ini - namun, benih idenya telah disemai. Upaya pertama kami merupakan peluang pembelajaran yang luar biasa: kami menyadari bahwa kami benar-benar bersemangat dalam menciptakan alat pragmatis yang memecahkan masalah sehari-hari bagi pengguna kami.

Berdasarkan pengalaman kesalahan masa lalu, kami mulai mengembangkan Helm 2.

Membuat Helm 2

Pada akhir tahun 2015, tim Google menghubungi kami. Mereka sedang mengerjakan alat serupa untuk Kubernetes. Deployment Manager untuk Kubernetes adalah port dari alat yang sudah ada yang digunakan untuk Google Cloud Platform. “Apakah kami ingin,” tanya mereka, “menghabiskan beberapa hari untuk mendiskusikan persamaan dan perbedaannya?”

Pada bulan Januari 2016, tim Helm dan Deployment Manager bertemu di Seattle untuk bertukar ide. Negosiasi diakhiri dengan rencana ambisius: menggabungkan kedua proyek untuk membuat Helm 2. Bersama Deis dan Google, orang-orang dari Lewati Kotak (sekarang bagian dari Bitnami - kira-kira terjemahan), dan kami mulai mengerjakan Helm 2.

Kami ingin mempertahankan kemudahan penggunaan Helm, tetapi menambahkan yang berikut:

templat bagan untuk penyesuaian;
manajemen intra-cluster untuk tim;
gudang grafik kelas dunia;
format paket stabil dengan opsi tanda tangan;
komitmen yang kuat terhadap pembuatan versi semantik dan menjaga kompatibilitas antar versi.

Untuk mencapai tujuan ini, elemen kedua telah ditambahkan ke ekosistem Helm. Komponen intra-cluster ini disebut Tiller dan bertanggung jawab untuk memasang grafik Helm dan mengelolanya.

Sejak Helm 2 dirilis pada tahun 2016, Kubernetes telah menambahkan beberapa inovasi besar. Menambahkan kontrol akses berbasis peran (RBAC), yang akhirnya menggantikan Kontrol Akses Berbasis Atribut (ABAC). Jenis sumber daya baru diperkenalkan (Penerapan masih dalam versi beta pada saat itu). Definisi Sumber Daya Kustom (awalnya disebut Sumber Daya Pihak Ketiga atau TPR) ditemukan. Dan yang paling penting, serangkaian praktik terbaik telah muncul.

Di tengah semua perubahan ini, Helm terus melayani pengguna Kubernetes dengan setia. Setelah tiga tahun dan banyak penambahan baru, jelas bahwa sudah waktunya untuk membuat perubahan signifikan pada basis kode untuk memastikan Helm dapat terus memenuhi kebutuhan ekosistem yang terus berkembang.

Perpisahan yang lembut untuk Tiller

Selama pengembangan Helm 2, kami memperkenalkan Tiller sebagai bagian dari integrasi kami dengan Deployment Manager Google. Tiller memainkan peran penting bagi tim yang bekerja dalam cluster umum: hal ini memungkinkan spesialis berbeda yang mengoperasikan infrastruktur untuk berinteraksi dengan rangkaian rilis yang sama.

Karena kontrol akses berbasis peran (RBAC) diaktifkan secara default di Kubernetes 1.6, bekerja dengan Tiller dalam produksi menjadi lebih sulit. Karena banyaknya kemungkinan kebijakan keamanan, posisi kami adalah menawarkan konfigurasi permisif secara default. Hal ini memungkinkan para pemula untuk bereksperimen dengan Helm dan Kubernetes tanpa harus mendalami pengaturan keamanan terlebih dahulu. Sayangnya, konfigurasi izin ini dapat memberi pengguna rentang izin yang terlalu luas sehingga mereka tidak memerlukannya. Insinyur DevOps dan SRE harus mempelajari langkah-langkah operasional tambahan saat menginstal Tiller di cluster multi-penyewa.

Setelah mempelajari bagaimana komunitas menggunakan Helm dalam situasi tertentu, kami menyadari bahwa sistem manajemen rilis Tiller tidak perlu bergantung pada komponen intra-cluster untuk mempertahankan status atau berfungsi sebagai pusat informasi rilis. Sebagai gantinya, kita cukup menerima informasi dari server API Kubernetes, membuat diagram di sisi klien, dan menyimpan catatan instalasi di Kubernetes.

Tujuan utama Tiller dapat tercapai tanpa Tiller, jadi salah satu keputusan pertama kami mengenai Helm 3 adalah meninggalkan Tiller sepenuhnya.

Dengan kepergian Tiller, model keamanan Helm telah disederhanakan secara radikal. Helm 3 sekarang mendukung semua metode keamanan, identitas, dan otorisasi modern Kubernetes saat ini. Izin helm ditentukan menggunakan file kubeconfig. Administrator klaster dapat membatasi hak pengguna pada tingkat perincian apa pun. Rilis masih disimpan dalam cluster, dan fungsi Helm lainnya tetap utuh.

Repositori bagan

Pada tingkat tinggi, repositori grafik adalah tempat di mana grafik dapat disimpan dan dibagikan. Klien Helm mengemas dan mengirimkan grafik ke repositori. Sederhananya, repositori grafik adalah server HTTP primitif dengan file index.yaml dan beberapa grafik yang dikemas.

Meskipun ada beberapa kelebihan Charts Repository API yang memenuhi sebagian besar persyaratan penyimpanan dasar, ada juga beberapa kelemahannya:

Repositori bagan tidak kompatibel dengan sebagian besar implementasi keamanan yang diperlukan dalam lingkungan produksi. Memiliki API standar untuk autentikasi dan otorisasi sangat penting dalam skenario produksi.
Alat asal bagan Helm, yang digunakan untuk menandatangani, memverifikasi integritas dan asal bagan, merupakan bagian opsional dari proses penerbitan Bagan.
Dalam skenario multi-pengguna, bagan yang sama dapat diunggah oleh pengguna lain, sehingga menggandakan jumlah ruang yang diperlukan untuk menyimpan konten yang sama. Repositori yang lebih cerdas telah dikembangkan untuk memecahkan masalah ini, namun mereka bukan bagian dari spesifikasi formal.
Menggunakan satu file indeks untuk mencari, menyimpan metadata, dan mengambil bagan telah mempersulit pengembangan implementasi multi-pengguna yang aman.

Proyek Distribusi Docker (juga dikenal sebagai Docker Registry v2) adalah penerus Docker Registry dan pada dasarnya bertindak sebagai seperangkat alat untuk mengemas, mengirim, menyimpan, dan mengirimkan image Docker. Banyak layanan cloud besar yang menawarkan produk berbasis Distribusi. Berkat peningkatan perhatian ini, proyek Distribusi telah memperoleh manfaat dari perbaikan selama bertahun-tahun, praktik terbaik keamanan, dan pengujian lapangan yang menjadikannya salah satu pahlawan tanpa tanda jasa paling sukses di dunia Open Source.

Namun tahukah Anda bahwa Proyek Distribusi dirancang untuk mendistribusikan segala bentuk konten, bukan hanya gambar container?

Berkat usahanya Buka Container Initiative (atau OCI), grafik Helm dapat ditempatkan pada instance Distribusi mana pun. Untuk saat ini, proses ini masih bersifat eksperimental. Dukungan login dan fitur lain yang diperlukan untuk Helm 3 lengkap masih dalam proses, namun kami sangat antusias untuk belajar dari penemuan yang telah dibuat oleh tim OCI dan Distribusi selama bertahun-tahun. Dan melalui bimbingan dan bimbingan mereka, kami belajar bagaimana mengoperasikan layanan dengan ketersediaan tinggi dalam skala besar.

Penjelasan lebih rinci tentang beberapa perubahan mendatang pada repositori grafik Helm tersedia по ссылке.

Manajemen rilis

Di Helm 3, status aplikasi dilacak dalam cluster oleh sepasang objek:

objek rilis - mewakili contoh aplikasi;
rahasia versi rilis - mewakili keadaan aplikasi yang diinginkan pada titik waktu tertentu (misalnya, rilis versi baru).

Tantangan helm install membuat objek rilis dan rahasia versi rilis. Panggilan helm upgrade memerlukan objek rilis (yang dapat diubah) dan membuat rahasia versi rilis baru yang berisi nilai-nilai baru dan manifes yang telah disiapkan.

Objek rilis berisi informasi tentang rilis, di mana rilis adalah instalasi spesifik dari bagan dan nilai bernama. Objek ini menjelaskan metadata tingkat atas tentang rilis. Objek rilis tetap ada sepanjang siklus hidup aplikasi dan merupakan pemilik semua rahasia versi rilis, serta semua objek yang dibuat langsung oleh bagan Helm.

Rahasia versi rilis mengaitkan rilis dengan serangkaian revisi (instalasi, pembaruan, rollback, penghapusan).

Di Helm 2, revisi sangat konsisten. Panggilan helm install dibuat v1, selanjutnya update (upgrade) - v2, dan seterusnya. Rahasia rilis dan versi rilis telah diciutkan menjadi satu objek yang dikenal sebagai revisi. Revisi disimpan dalam namespace yang sama dengan Tiller, yang berarti bahwa setiap rilis bersifat "global" dalam hal namespace; akibatnya, hanya satu nama yang dapat digunakan.

Di Helm 3, setiap rilis dikaitkan dengan satu atau lebih rahasia versi rilis. Objek rilis selalu menjelaskan rilis terkini yang di-deploy ke Kubernetes. Setiap rahasia versi rilis hanya menjelaskan satu versi rilis tersebut. Pemutakhiran, misalnya, akan membuat rahasia versi rilis baru dan kemudian mengubah objek rilis agar mengarah ke versi baru tersebut. Jika terjadi rollback, Anda dapat menggunakan rahasia versi rilis sebelumnya untuk mengembalikan rilis ke keadaan sebelumnya.

Setelah Tiller ditinggalkan, Helm 3 menyimpan data rilis di namespace yang sama dengan rilis tersebut. Perubahan ini memungkinkan Anda untuk menginstal bagan dengan nama rilis yang sama di namespace berbeda, dan data disimpan antara pembaruan/reboot klaster di dll. Misalnya, Anda dapat menginstal WordPress di namespace "foo" dan kemudian di namespace "bar", dan kedua rilis dapat diberi nama "wordpress".

Perubahan pada dependensi bagan

Bagan dikemas (menggunakan helm package) untuk digunakan dengan Helm 2 dapat diinstal dengan Helm 3, namun alur kerja pengembangan bagan telah dirombak total, sehingga beberapa perubahan harus dilakukan untuk melanjutkan pengembangan bagan dengan Helm 3. Secara khusus, sistem manajemen ketergantungan bagan telah berubah.

Sistem manajemen ketergantungan diagram telah berpindah dari requirements.yaml и requirements.lock pada Chart.yaml и Chart.lock. Artinya grafik yang digunakan perintah helm dependency, memerlukan beberapa pengaturan agar dapat berfungsi di Helm 3.

Mari kita lihat sebuah contoh. Mari tambahkan ketergantungan pada grafik di Helm 2 dan lihat apa yang berubah saat berpindah ke Helm 3.

Di Helm 2 requirements.yaml tampak seperti ini:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Di Helm 3, ketergantungan yang sama akan tercermin pada Anda Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Grafik masih diunduh dan ditempatkan di direktori charts/, jadi subbagan (subbagan), tergeletak di katalog charts/, akan terus bekerja tanpa perubahan.

Memperkenalkan Bagan Perpustakaan

Helm 3 mendukung kelas bagan yang disebut bagan perpustakaan (bagan perpustakaan). Bagan ini digunakan oleh bagan lain, namun tidak membuat artefak rilis apa pun sendiri. Templat bagan perpustakaan hanya bisa mendeklarasikan elemen define. Konten lain diabaikan begitu saja. Hal ini memungkinkan pengguna untuk menggunakan kembali dan membagikan cuplikan kode yang dapat digunakan di beberapa diagram, sehingga menghindari duplikasi dan mematuhi prinsip KERING.

Bagan perpustakaan dideklarasikan di bagian tersebut dependencies dalam file Chart.yaml. Memasang dan mengelolanya tidak berbeda dengan bagan lainnya.

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

Kami sangat antusias dengan kasus penggunaan komponen ini yang akan terbuka bagi pengembang bagan, serta praktik terbaik yang dapat muncul dari bagan pustaka.

Apa selanjutnya?

Helm 3.0.0-alpha.1 adalah landasan di mana kami mulai membangun Helm versi baru. Dalam artikel tersebut saya menjelaskan beberapa fitur menarik dari Helm 3. Banyak di antaranya yang masih dalam tahap awal pengembangan dan ini normal; Inti dari rilis alfa adalah untuk menguji ide, mengumpulkan masukan dari pengguna awal, dan mengonfirmasi asumsi kami.

Segera setelah versi alpha dirilis (ingat bahwa ini adalah sudah terjadi - kira-kira. terjemahkan), kami akan mulai menerima patch untuk Helm 3 dari komunitas. Anda perlu menciptakan fondasi yang kuat yang memungkinkan fungsionalitas baru dikembangkan dan diadopsi, dan agar pengguna merasa terlibat dalam proses tersebut dengan membuka tiket dan melakukan perbaikan.

Saya telah mencoba menyoroti beberapa peningkatan besar yang terjadi pada Helm 3, tetapi daftar ini tidak lengkap. Peta jalan lengkap untuk Helm 3 mencakup fitur-fitur seperti strategi pembaruan yang ditingkatkan, integrasi yang lebih mendalam dengan registri OCI, dan penggunaan skema JSON untuk memvalidasi nilai bagan. Kami juga berencana untuk membersihkan basis kode dan memperbarui bagian-bagiannya yang telah diabaikan selama tiga tahun terakhir.

Jika Anda merasa kami melewatkan sesuatu, kami ingin mendengar pendapat Anda!

Bergabunglah dalam diskusi di kami Saluran kendur:

#helm-users untuk pertanyaan dan komunikasi sederhana dengan komunitas;
#helm-dev untuk mendiskusikan permintaan tarik, kode, dan bug.

Anda juga dapat mengobrol di Panggilan Pengembang Publik mingguan kami pada hari Kamis pukul 19:30 MSK. Rapat didedikasikan untuk membahas isu-isu yang sedang dikerjakan oleh pengembang utama dan komunitas, serta topik diskusi selama seminggu. Siapa pun dapat bergabung dan mengambil bagian dalam pertemuan tersebut. Tautan tersedia di saluran Slack #helm-dev.

Memperkenalkan Helm 3