Catatan perev. : 16 Mei tahun ini adalah tonggak penting dalam pengembangan manajer paket untuk Kubernetes - Helm. Pada hari ini, rilis alpha pertama dari versi utama masa depan proyek diperkenalkan - 3.0. Pembebasannya akan membawa perubahan signifikan dan telah lama dinanti ke Helm, yang banyak diharapkan oleh komunitas Kubernetes. Kami sendiri memperlakukan ini, karena kami secara aktif menggunakan Helm untuk menyebarkan aplikasi: kami mengintegrasikannya ke dalam alat kami untuk menerapkan CI / CD werf dan dari waktu ke waktu kami memberikan kontribusi yang layak untuk pengembangan hulu. Terjemahan ini menggabungkan 7 catatan dari blog Helm resmi, yang dijadwalkan untuk rilis alpha pertama Helm 3 dan menceritakan tentang sejarah proyek dan fitur-fitur utama Helm 3. Penulis mereka adalah Matt "bacongobbler" Fisher, seorang karyawan Microsoft dan salah satu pengurus Helm utama. 15 Oktober 2015 proyek ini lahir, sekarang dikenal sebagai Helm. Hanya setahun setelah pendiriannya, komunitas Helm bergabung dengan Kubernetes, sementara aktif mengerjakan Helm 2. Pada Juni 2018, Helm
bergabung dengan CNCF sebagai proyek inkubasi. Maju cepat hingga saat ini - dan sekarang rilis alpha pertama dari Helm 3 baru sedang dalam perjalanan
(rilis ini sudah berlangsung pada pertengahan Mei - sekitar Terjemahan.) .
Dalam artikel ini, saya akan berbicara tentang bagaimana semuanya dimulai, bagaimana kita sampai ke tahap saat ini, menyajikan beberapa fitur unik yang tersedia di rilis pertama Helm 3 alpha, dan menjelaskan bagaimana kami berencana untuk mengembangkan lebih lanjut.
Ringkasan:
- sejarah penciptaan Helm;
- perpisahan lembut untuk Tiller;
- bagan repositori;
- manajemen rilis;
- perubahan dalam dependensi grafik;
- grafik perpustakaan;
- apa selanjutnya
Sejarah Helm
Kelahiran
Helm 1 dimulai sebagai proyek sumber terbuka yang dibuat oleh Deis. Kami adalah startup kecil yang
diserap oleh Microsoft pada musim semi 2017. Proyek Open Source kami yang lain, juga bernama Deis, memiliki alat
deisctl yang digunakan (antara lain) untuk menginstal dan mengoperasikan platform Deis di
cluster Armada . Armada adalah salah satu platform pertama untuk orkestrasi wadah pada saat itu.
Pada pertengahan 2015, kami memutuskan untuk mengubah arah dan memindahkan Deis (pada waktu itu diganti namanya menjadi Deis Workflow) dari Armada ke Kubernetes. Salah satu yang pertama mendesain ulang
deisctl instalasi
deisctl . Kami menggunakannya untuk menginstal dan mengelola Deis Workflow di cluster Armada.
Helm 1 dibuat menurut gambar manajer paket terkenal seperti Homebrew, apt dan yum. Tugas utamanya adalah menyederhanakan tugas-tugas seperti mengemas dan menginstal aplikasi di Kubernetes. Helm secara resmi diperkenalkan pada 2015 di konferensi KubeCon di San Francisco.
Upaya pertama kami dengan Helm berhasil, tetapi ada batasan serius. Dia mengambil satu set manifes Kubernetes, dibumbui dengan generator, sebagai blok utama * YAML, dan mengunggah hasilnya ke Kubernetes.
* Catatan perev. : Dari versi pertama Helm, sintaks YAML dipilih untuk menggambarkan sumber daya Kubernetes, dan templat Jinja dan skrip Python didukung saat menulis konfigurasi. Kami menulis lebih banyak tentang ini dan perangkat Helm versi pertama di bab “Sejarah Singkat Helm” dari materi ini .Misalnya, untuk mengganti bidang dalam file YAML, Anda harus menambahkan konstruksi berikut ke manifes:
#helm:generate sed -i -es|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml
Ini keren bahwa ada mesin template hari ini, bukan?
Karena berbagai alasan, penginstal Kubernetes awal ini memerlukan daftar file manifes yang dikodekan dengan keras dan hanya menjalankan serangkaian kecil kejadian. Sangat sulit untuk digunakan sehingga tim R&D Deis Workflow mengalami kesulitan ketika mereka mencoba untuk mentransfer produk mereka ke platform ini - namun, benih ide sudah ditabur. Upaya pertama kami adalah kesempatan belajar yang hebat: kami menyadari bahwa kami benar-benar bersemangat menciptakan alat pragmatis yang memecahkan masalah sehari-hari bagi pengguna kami.
Berdasarkan pengalaman kesalahan masa lalu, kami mulai mengembangkan Helm 2.
Helm Penciptaan 2
Pada akhir 2015, tim Google menghubungi kami. Mereka mengerjakan alat serupa untuk Kubernetes. Deployment Manager untuk Kubernetes adalah port dari alat yang ada yang digunakan untuk Google Cloud Platform. "Apakah kita," mereka bertanya, "menghabiskan beberapa hari untuk membahas persamaan dan perbedaan?"
Pada Januari 2016, tim Helm dan Deployment Manager bertemu di Seattle untuk bertukar gagasan. Negosiasi berakhir dengan rencana ambisius: untuk menggabungkan kedua proyek untuk membuat Helm 2. Bersama dengan Deis dan Google, orang-orang dari
SkippBox (sekarang bagian dari Bitnami - kira-kira. Terjemahan). Bergabung dengan tim pengembangan, dan kami mulai mengerjakan Helm 2.
Kami ingin agar Helm mudah digunakan, tetapi tambahkan yang berikut:
- templat bagan untuk penyesuaian;
- manajemen intracluster untuk tim;
- Repositori grafik kelas satu
- format paket yang stabil dengan kemampuan untuk masuk;
- Komitmen yang kuat untuk versi semantik dan menjaga kompatibilitas antara versi.
Untuk mencapai tujuan-tujuan ini, elemen kedua telah ditambahkan ke ekosistem Helm. Komponen intracluster ini disebut Tiller dan terlibat dalam pemasangan grafik Helm dan manajemennya.
Sejak rilis Helm 2 pada 2016, Kubernetes telah mendapatkan sejumlah inovasi besar. Kontrol akses berbasis peran (
RBAC )
diperkenalkan , yang akhirnya menggantikan kontrol akses berbasis atribut (ABAC). Jenis sumber daya baru diperkenalkan (Deployment pada waktu itu masih dalam status beta). Definisi Sumber Daya Kustom (awalnya disebut Sumber Daya Pihak Ketiga atau TPR) diciptakan. Dan yang paling penting, serangkaian praktik terbaik telah muncul.
Di tengah semua perubahan ini, Helm terus melayani dengan setia kepada pengguna Kubernetes. Setelah tiga tahun dan banyak penambahan baru, menjadi jelas bahwa sudah waktunya untuk membuat perubahan signifikan pada basis kode sehingga Helm dapat terus memenuhi kebutuhan yang berkembang dari ekosistem yang sedang berkembang.
Perpisahan yang lembut dengan Tiller
Selama pengembangan Helm 2, kami memperkenalkan Tiller sebagai bagian dari integrasi kami dengan Google Deployment Manager. Tiller memainkan peran penting bagi tim yang bekerja dalam kelompok umum: memungkinkan berbagai spesialis 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 untuk mengajukan izin secara default. Hal ini memungkinkan pemula untuk bereksperimen dengan Helm dan Kubernetes tanpa harus masuk ke pengaturan keamanan terlebih dahulu. Sayangnya, konfigurasi permisif ini dapat memberikan pengguna dengan rentang izin yang sangat luas yang tidak diperlukannya. Insinyur DevOps dan SRE harus mempelajari langkah-langkah operasional tambahan dengan memasang Tiller di kluster multi-penyewa.
Setelah mempelajari bagaimana anggota masyarakat menggunakan Helm dalam situasi tertentu, kami menyadari bahwa sistem manajemen pelepasan Tiller tidak perlu bergantung pada komponen intra-kluster untuk mempertahankan status atau fungsi sebagai hub pusat dengan informasi pelepasan. Sebagai gantinya, kami hanya bisa mendapatkan informasi dari server API Kubernetes, membuat grafik sisi-klien, dan menyimpan catatan instalasi ke Kubernetes.
Tugas utama Tiller dapat dilakukan tanpa Tiller, jadi salah satu keputusan pertama kami mengenai Helm 3 adalah penolakan total terhadap Tiller.
Dengan kepergian Tiller, model keamanan Helm telah disederhanakan secara radikal. Helm 3 sekarang mendukung semua metode keamanan modern, identifikasi, dan otorisasi Kubernet hari ini. Izin
helm ditentukan menggunakan
file kubeconfig . Administrator cluster dapat membatasi hak pengguna dengan tingkat granularitas apa pun. Rilis masih disimpan di dalam cluster, sisa fungsi Helm dipertahankan.
Bagan Gudang
Pada level tinggi, repositori bagan adalah tempat Anda dapat menyimpan dan berbagi bagan. Klien Helm mengemas dan mengirim grafik ke repositori. Sederhananya, repositori bagan adalah server HTTP primitif dengan file index.yaml dan beberapa bagan yang dikemas.
Meskipun ada beberapa keuntungan karena repositori API memenuhi persyaratan paling dasar untuk repositori, ia juga memiliki beberapa kelemahan:
- Repositori bagan tidak kompatibel dengan sebagian besar implementasi keamanan yang diperlukan dalam lingkungan produksi. Memiliki API standar untuk otentikasi dan otorisasi sangat penting dalam skenario produksi.
- Alat Helm untuk melacak asal grafik, yang digunakan untuk menandatangani, memverifikasi integritas dan asal grafik, adalah bagian opsional dari proses penerbitan Bagan.
- Dalam skenario multi-pengguna, bagan yang sama dapat dimuat oleh pengguna lain, menggandakan jumlah ruang yang dibutuhkan untuk menyimpan konten yang sama. Repositori yang lebih pintar telah dikembangkan untuk menyelesaikan masalah ini, tetapi mereka bukan bagian dari spesifikasi formal.
- Menggunakan file indeks tunggal untuk mencari, menyimpan metadata, dan membuat grafik mempersulit pengembangan implementasi multi-pengguna yang aman.
Proyek
Distribusi Docker (juga dikenal sebagai Docker Registry v2) adalah penerus Docker Registry dan sebenarnya bertindak sebagai seperangkat alat untuk mengemas, mengirim, menyimpan, dan mengirimkan gambar Docker. Banyak layanan cloud besar menawarkan produk-produk berbasis distribusi. Berkat perhatian yang meningkat, proyek Distribusi telah memperoleh manfaat dari perbaikan selama bertahun-tahun, praktik terbaik di bidang keamanan dan pengujian dalam kondisi "pertempuran", yang telah mengubahnya menjadi salah satu pahlawan tanpa tanda jasa paling sukses di dunia Open Source.
Tetapi tahukah Anda bahwa proyek Distribusi dirancang untuk mendistribusikan segala bentuk konten, bukan hanya untuk wadah gambar?
Berkat upaya
Open Container Initiative (atau OCI), grafik Helm dapat ditempatkan di sembarang Distribusi. Sejauh ini, proses ini masih eksperimental. Bekerja pada dukungan untuk login dan fungsi-fungsi lain yang diperlukan untuk Helm 3 yang lengkap belum berakhir, tetapi kami sangat senang belajar dari penemuan yang dibuat oleh tim OCI dan Distribusi selama bertahun-tahun. Dan berkat bimbingan dan kepemimpinan mereka, kami belajar apa pengoperasian layanan yang sangat mudah diakses dalam skala besar.
Penjelasan lebih rinci tentang beberapa perubahan mendatang pada repositori Helm-chart tersedia di
sini .
Manajemen rilis
Di Helm 3, keadaan aplikasi dimonitor dalam sebuah cluster oleh beberapa objek:
- objek rilis - merupakan turunan dari aplikasi;
- rahasia versi rilis - mewakili keadaan aplikasi yang diinginkan pada titik waktu tertentu (misalnya, rilis versi baru).
helm install panggilan membuat objek rilis dan rilis rahasia versi. Pemutakhiran
helm upgrade panggilan memerlukan objek rilis (yang dapat diubah) dan membuat rahasia versi rilis baru yang berisi nilai-nilai baru dan manifes yang disiapkan.
Objek rilis berisi informasi rilis, di mana rilis adalah instalasi khusus dari bagan dan nilai-nilai yang disebutkan. Objek ini menjelaskan metadata tingkat atas tentang rilis. Objek rilis dipertahankan sepanjang seluruh siklus hidup aplikasi dan bertindak sebagai pemilik semua rahasia versi rilis, serta semua objek yang secara langsung dibuat oleh grafik Helm.
Rahasia versi rilis mengaitkan rilis dengan serangkaian revisi (instalasi, pembaruan, kembalikan, penghapusan instalasi).
Di Helm 2, revisi sangat konsisten. Panggilan
helm install dibuat v1, pembaruan peningkatan v2 berikutnya, dan seterusnya. Rahasia versi rilis dan rilis diciutkan menjadi satu objek, yang dikenal sebagai revisi. Revision disimpan di namespace yang sama dengan Tiller, yang berarti bahwa setiap rilis adalah "global" dalam hal namespace; sebagai hasilnya, hanya satu instance dari nama yang dapat digunakan.
Di Helm 3, setiap rilis dikaitkan dengan satu atau lebih rahasia versi rilis. Objek rilis selalu menggambarkan rilis saat ini yang digunakan di Kubernetes. Setiap rahasia versi rilis hanya menjelaskan satu versi dari rilis ini. Upgrade, misalnya, akan membuat rahasia versi rilis baru dan kemudian memodifikasi objek rilis untuk mengarah ke versi baru ini. Dalam kasus rollback, Anda dapat menggunakan rahasia versi rilis sebelumnya untuk memutar kembali rilis ke kondisi sebelumnya.
Setelah meninggalkan Tiller, Helm 3 menyimpan data rilis dalam ruang nama tunggal dengan rilis. Perubahan seperti itu memungkinkan Anda untuk menginstal bagan dengan nama rilis yang sama di namespace yang berbeda, dan data disimpan di antara pembaruan cluster / reboot di etcd. Sebagai contoh, Anda dapat menginstal Wordpress di namespace "foo" dan kemudian di namespace "bar", dan kedua rilis dapat disebut "wordpress".
Perubahan Ketergantungan Bagan
Grafik yang dikemas (menggunakan
helm package ) untuk digunakan dengan Helm 2 dapat diinstal dengan Helm 3, namun, alur kerja pengembangan grafik telah sepenuhnya direvisi, sehingga beberapa perubahan perlu dilakukan untuk terus mengembangkan grafik dengan Helm 3. Secara khusus, sistem manajemen telah berubah dependensi grafik.
Sistem manajemen ketergantungan bagan telah berpindah dari
requirements.yaml dan
requirements.lock ke
Chart.yaml dan
Chart.lock . Ini berarti bahwa grafik yang menggunakan perintah
helm dependency memerlukan beberapa konfigurasi untuk bekerja di Helm 3.
Mari kita lihat sebuah contoh. Tambahkan dependensi ke bagan di Helm 2 dan lihat perubahan apa saat Anda beralih ke Helm 3.
Dalam
requirements.yaml Helm 2.yaml tampak seperti ini:
dependencies: - name: mariadb version: 5.xx repository: https://kubernetes-charts.storage.googleapis.com/ condition: mariadb.enabled tags: - database
Di Helm 3, ketergantungan yang sama akan tercermin di
Chart.yaml Anda:
dependencies: - name: mariadb version: 5.xx repository: https://kubernetes-charts.storage.googleapis.com/ condition: mariadb.enabled tags: - database
charts/ masih dimuat dan ditempatkan di
charts/ direktori, sehingga subchart di
charts/ direktori akan terus bekerja tanpa perubahan.
Memperkenalkan Grafik Perpustakaan
Helm 3 mendukung kelas bagan yang disebut
bagan perpustakaan . Bagan ini digunakan oleh bagan lain, tetapi tidak membuat artefak rilis sendiri. Templat bagan perpustakaan hanya bisa mendeklarasikan elemen
define . Konten lain hanya diabaikan. Ini memungkinkan pengguna untuk menggunakan kembali dan berbagi fragmen kode yang dapat digunakan pada banyak bagan, sehingga menghindari duplikasi dan mematuhi prinsip
KERING .
Bagan perpustakaan dideklarasikan di bagian
dependencies dari file
Chart.yaml . Instalasi dan pengelolaannya tidak berbeda dengan grafik lainnya.
dependencies: - name: mylib version: 1.xx repository: quay.io
Kami menantikan kasus penggunaan yang komponen ini akan terbuka untuk pengembang bagan, serta praktik terbaik yang mungkin timbul karena bagan perpustakaan.
Apa selanjutnya
Helm 3.0.0-alpha.1 - dasar di mana kami mulai membuat versi baru Helm. Dalam artikel tersebut saya menjelaskan beberapa fitur menarik dari Helm 3. Banyak dari mereka masih dalam tahap awal pengembangan dan ini normal; Inti dari rilis alpha adalah untuk menguji ide, mengumpulkan umpan balik dari pengguna pertama dan mengkonfirmasi asumsi kami.
Segera setelah versi alfa dirilis
(ingat bahwa ini sudah terjadi - kira-kira. Terjemahan) , Kami akan mulai menerima tambalan untuk Helm 3 dari komunitas. Penting untuk membuat fondasi yang kuat yang akan memungkinkan Anda untuk mengembangkan dan mengadopsi fungsi baru, dan pengguna akan dapat merasa terlibat dalam proses, membuka tiket dan membuat koreksi.
Dalam artikel saya mencoba menyoroti beberapa perbaikan serius yang akan muncul di Helm 3, tetapi daftar ini sama sekali tidak lengkap. Rencana skala penuh untuk Helm 3 mencakup inovasi seperti peningkatan strategi pembaruan, integrasi lebih dalam dengan pendaftar OCI, dan penggunaan skema JSON untuk memeriksa nilai grafik. Kami juga berencana untuk menghapus basis kode dan memperbarui bagian-bagiannya yang telah diabaikan selama tiga tahun terakhir.
Jika Anda merasa bahwa kami telah melewatkan sesuatu, kami akan senang mendengar pendapat Anda!
Bergabunglah dengan diskusi di
saluran Slack kami:
#helm-users untuk pertanyaan dan komunikasi yang mudah dengan komunitas;#helm-dev untuk membahas permintaan tarik, kode, dan bug.
Anda juga dapat mengobrol di Panggilan Pengembang Publik mingguan kami pada Kamis pukul 19:30 MSK. Pertemuan tersebut didedikasikan untuk membahas tugas-tugas yang dikerjakan pengembang utama dan komunitas, serta topik diskusi selama seminggu. Siapa pun dapat bergabung dan mengambil bagian dalam rapat. Tautan tersedia di saluran
#helm-dev Slack.
PS dari penerjemah
Baca juga di blog kami: