🥇Pengenalan Helm 3

Catatan. terjemah: 16 Mei tahun ini menandakan peristiwa penting dalam pembangunan pengurus pakej untuk Kubernetes - Helm. Pada hari ini, keluaran alfa pertama versi utama masa depan projek - 3.0 - telah dibentangkan. Pelancarannya akan membawa perubahan ketara dan lama ditunggu-tunggu kepada Helm, yang mana ramai dalam komuniti Kubernetes menaruh harapan tinggi. Kami sendiri adalah salah satu daripada ini, kerana kami secara aktif menggunakan Helm untuk penggunaan aplikasi: kami telah menyepadukannya ke dalam alat kami untuk melaksanakan CI/CD werf dan dari semasa ke semasa kami memberi sumbangan kepada pembangunan huluan. Terjemahan ini menggabungkan 7 nota dari blog Helm rasmi, yang didedikasikan untuk keluaran alpha pertama Helm 3 dan bercakap tentang sejarah projek dan ciri utama Helm 3. Pengarang mereka ialah Matt "bacongobbler" Fisher, seorang pekerja Microsoft dan salah satu penyelenggara utama Helm.

Pada 15 Oktober 2015, projek yang kini dikenali sebagai Helm telah dilahirkan. Hanya setahun selepas penubuhannya, komuniti Helm menyertai Kubernetes, sambil aktif mengusahakan Helm 2. Pada Jun 2018, Helm menyertai CNCF sebagai projek membangun (mengeram). Cepat ke masa kini, dan keluaran alfa pertama Helm 3 baharu sedang dalam perjalanan. (keluaran ini telah pun berlaku pada pertengahan Mei - lebih kurang. terjemah.).

Dalam bahagian ini, saya akan bercakap tentang di mana semuanya bermula, bagaimana kami sampai ke tempat kami hari ini, memperkenalkan beberapa ciri unik yang tersedia dalam keluaran alfa pertama Helm 3 dan menerangkan cara kami merancang untuk bergerak ke hadapan.

Ringkasan:

sejarah penciptaan Helm;
perpisahan tender kepada Tiller;
repositori carta;
pengurusan pelepasan;
perubahan dalam kebergantungan carta;
carta perpustakaan;
apa yang akan datang?

Sejarah Helm

kelahiran

Helm 1 bermula sebagai projek Sumber Terbuka yang dicipta oleh Deis. Kami adalah permulaan kecil diserap Microsoft pada musim bunga 2017. Projek Sumber Terbuka kami yang lain, juga bernama Deis, mempunyai alat deisctl, yang digunakan (antara lain) untuk memasang dan mengendalikan platform Deis dalam Kelompok armada. Pada masa itu, Fleet merupakan salah satu platform orkestrasi kontena yang pertama.

Pada pertengahan 2015, kami memutuskan untuk menukar haluan dan memindahkan Deis (pada masa itu dinamakan Deis Workflow) daripada Fleet ke Kubernetes. Salah satu yang pertama direka bentuk semula ialah alat pemasangan. deisctl. Kami menggunakannya untuk memasang dan mengurus Deis Workflow dalam kelompok Fleet.

Helm 1 dicipta dalam imej pengurus pakej terkenal seperti Homebrew, apt dan yum. Matlamat utamanya adalah untuk memudahkan tugas seperti membungkus dan memasang aplikasi pada Kubernetes. Helm diperkenalkan secara rasmi pada 2015 di persidangan KubeCon di San Francisco.

Percubaan pertama kami dengan Helm berjaya, tetapi ia bukan tanpa beberapa batasan yang serius. Dia mengambil satu set manifes Kubernetes, berperisa dengan penjana sebagai blok YAML pengenalan (perkara depan)*, dan memuatkan hasilnya ke dalam Kubernetes.

* Catatan. terjemah: Daripada versi pertama Helm, sintaks YAML telah dipilih untuk menerangkan sumber Kubernetes, dan templat Jinja serta skrip Python disokong semasa menulis konfigurasi. Kami menulis lebih lanjut tentang ini dan struktur versi pertama Helm secara umum dalam bab "Sejarah Ringkas Helm" bahan ini.

Sebagai contoh, untuk menggantikan medan dalam fail YAML, anda perlu menambah binaan berikut pada manifes:

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

Hebatnya enjin templat wujud hari ini, bukan?

Atas banyak sebab, pemasang Kubernetes awal ini memerlukan senarai fail manifes berkod keras dan hanya melaksanakan urutan peristiwa kecil dan tetap. Sangat sukar untuk digunakan sehingga pasukan R&D Deis Workflow mengalami kesukaran apabila mereka cuba memindahkan produk mereka ke platform ini - namun, benih idea itu telah pun disemai. Percubaan pertama kami ialah peluang pembelajaran yang hebat: kami menyedari bahawa kami benar-benar bersemangat untuk mencipta alat pragmatik yang menyelesaikan masalah harian untuk pengguna kami.

Berdasarkan pengalaman kesilapan lalu, kami mula membangunkan Helm 2.

Membuat Helm 2

Pada penghujung tahun 2015, pasukan Google menghubungi kami. Mereka sedang mengusahakan alat yang serupa untuk Kubernetes. Pengurus Penerapan untuk Kubernetes ialah pelabuhan alat sedia ada yang digunakan untuk Google Cloud Platform. “Adakah kami ingin,” mereka bertanya, “untuk menghabiskan beberapa hari membincangkan persamaan dan perbezaan?”

Pada Januari 2016, pasukan Pengurus Helm dan Penerapan bertemu di Seattle untuk bertukar-tukar idea. Rundingan berakhir dengan rancangan yang bercita-cita tinggi: untuk menggabungkan kedua-dua projek untuk mencipta Helm 2. Bersama-sama dengan Deis dan Google, lelaki dari SkippBox (kini sebahagian daripada Bitnami - lebih kurang transl.), dan kami mula bekerja pada Helm 2.

Kami ingin mengekalkan kemudahan penggunaan Helm, tetapi tambahkan yang berikut:

templat carta untuk penyesuaian;
pengurusan intra-kluster untuk pasukan;
repositori carta bertaraf dunia;
format pakej yang stabil dengan pilihan tandatangan;
komitmen yang kuat terhadap versi semantik dan mengekalkan keserasian ke belakang antara versi.

Untuk mencapai matlamat ini, elemen kedua telah ditambahkan pada ekosistem Helm. Komponen intra-kluster ini dipanggil Tiller dan bertanggungjawab untuk memasang carta Helm dan mengurusnya.

Sejak pengeluaran Helm 2 pada 2016, Kubernetes telah menambah beberapa inovasi utama. Menambah kawalan akses berasaskan peranan (RBAC), yang akhirnya menggantikan Kawalan Akses Berasaskan Atribut (ABAC). Jenis sumber baharu telah diperkenalkan (Pengeluaran masih dalam versi beta pada masa itu). Definisi Sumber Tersuai (asalnya dipanggil Sumber Pihak Ketiga atau TPR) telah dicipta. Dan yang paling penting, satu set amalan terbaik telah muncul.

Di tengah-tengah semua perubahan ini, Helm terus melayani pengguna Kubernetes dengan setia. Selepas tiga tahun dan banyak penambahan baharu, adalah jelas bahawa sudah tiba masanya untuk membuat perubahan ketara pada pangkalan kod untuk memastikan Helm dapat terus memenuhi keperluan ekosistem yang semakin berkembang.

Ucapan selamat tinggal kepada Tiller

Semasa pembangunan Helm 2, kami memperkenalkan Tiller sebagai sebahagian daripada penyepaduan kami dengan Pengurus Penerapan Google. Tiller memainkan peranan penting untuk pasukan yang bekerja dalam kelompok yang sama: ia membenarkan pakar berbeza yang mengendalikan infrastruktur berinteraksi dengan set keluaran yang sama.

Memandangkan kawalan akses berasaskan peranan (RBAC) didayakan secara lalai dalam Kubernetes 1.6, bekerja dengan Tiller dalam pengeluaran menjadi lebih sukar. Disebabkan oleh banyaknya kemungkinan dasar keselamatan, kedudukan kami adalah untuk menawarkan konfigurasi permisif secara lalai. Ini membenarkan pemula untuk bereksperimen dengan Helm dan Kubernetes tanpa perlu menyelami tetapan keselamatan terlebih dahulu. Malangnya, konfigurasi kebenaran ini boleh memberikan pengguna julat keizinan yang terlalu luas yang mereka tidak perlukan. Jurutera DevOps dan SRE terpaksa mempelajari langkah operasi tambahan apabila memasang Tiller dalam kelompok berbilang penyewa.

Selepas mengetahui cara komuniti menggunakan Helm dalam situasi tertentu, kami menyedari bahawa sistem pengurusan keluaran Tiller tidak perlu bergantung pada komponen intra-kluster untuk mengekalkan keadaan atau berfungsi sebagai hab pusat untuk maklumat keluaran. Sebaliknya, kami hanya boleh menerima maklumat daripada pelayan API Kubernetes, menjana carta pada bahagian klien dan menyimpan rekod pemasangan dalam Kubernetes.

Matlamat utama Tiller boleh dicapai tanpa Tiller, jadi salah satu keputusan pertama kami mengenai Helm 3 adalah untuk meninggalkan Tiller sepenuhnya.

Dengan tiadanya Tiller, model keselamatan Helm telah dipermudahkan secara radikal. Helm 3 kini menyokong semua kaedah keselamatan, identiti dan kebenaran moden Kubernetes semasa. Kebenaran helm ditentukan menggunakan fail kubeconfig. Pentadbir kluster boleh menyekat hak pengguna kepada mana-mana tahap butiran. Keluaran masih disimpan dalam kluster, dan fungsi Helm yang lain kekal utuh.

Repositori carta

Pada tahap yang tinggi, repositori carta ialah tempat di mana carta boleh disimpan dan dikongsi. Pelanggan Helm membungkus dan menghantar carta ke repositori. Ringkasnya, repositori carta ialah pelayan HTTP primitif dengan fail index.yaml dan beberapa carta berpakej.

Walaupun terdapat beberapa kelebihan pada Charts Repository API yang memenuhi kebanyakan keperluan storan asas, terdapat juga beberapa kelemahan:

Repositori carta tidak serasi dengan kebanyakan pelaksanaan keselamatan yang diperlukan dalam persekitaran pengeluaran. Mempunyai API standard untuk pengesahan dan kebenaran adalah sangat penting dalam senario pengeluaran.
Alat asal carta Helm, yang digunakan untuk menandatangani, mengesahkan integriti dan asal carta, adalah bahagian pilihan dalam proses penerbitan Carta.
Dalam senario berbilang pengguna, carta yang sama boleh dimuat naik oleh pengguna lain, menggandakan jumlah ruang yang diperlukan untuk menyimpan kandungan yang sama. Repositori yang lebih pintar telah dibangunkan untuk menyelesaikan masalah ini, tetapi ia bukan sebahagian daripada spesifikasi rasmi.
Menggunakan fail indeks tunggal untuk mencari, menyimpan metadata dan mendapatkan semula carta telah menyukarkan untuk membangunkan pelaksanaan berbilang pengguna yang selamat.

Projek Pengagihan Docker (juga dikenali sebagai Docker Registry v2) ialah pengganti kepada Docker Registry dan pada asasnya bertindak sebagai satu set alat untuk pembungkusan, penghantaran, penyimpanan dan penghantaran imej Docker. Banyak perkhidmatan awan besar menawarkan produk berasaskan Pengedaran. Terima kasih kepada peningkatan perhatian ini, projek Pengedaran telah mendapat manfaat daripada penambahbaikan selama bertahun-tahun, amalan terbaik keselamatan dan ujian lapangan yang menjadikannya salah satu wira tanpa tanda jasa yang paling berjaya dalam dunia Sumber Terbuka.

Tetapi adakah anda tahu bahawa Projek Pengedaran direka untuk mengedarkan sebarang bentuk kandungan, bukan hanya imej kontena?

Berkat usaha Inisiatif Kontena Terbuka (atau OCI), Carta Helm boleh diletakkan pada mana-mana contoh Pengedaran. Buat masa ini, proses ini adalah percubaan. Sokongan log masuk dan ciri lain yang diperlukan untuk Helm 3 penuh sedang dalam proses, tetapi kami teruja untuk belajar daripada penemuan yang telah dilakukan oleh pasukan OCI dan Pengedaran selama ini. Dan melalui bimbingan dan bimbingan mereka, kami belajar bagaimana rasanya mengendalikan perkhidmatan yang sangat tersedia pada skala.

Penerangan yang lebih terperinci tentang beberapa perubahan yang akan datang pada repositori carta Helm tersedia по ссылке.

Pengurusan pelepasan

Dalam Helm 3, keadaan aplikasi dijejaki dalam kelompok oleh sepasang objek:

objek pelepasan - mewakili contoh aplikasi;
rahsia versi keluaran - mewakili keadaan aplikasi yang dikehendaki pada masa tertentu (contohnya, keluaran versi baharu).

Panggil helm install mencipta objek keluaran dan rahsia versi keluaran. Panggil helm upgrade memerlukan objek keluaran (yang boleh diubah) dan mencipta rahsia versi keluaran baharu yang mengandungi nilai baharu dan manifes yang disediakan.

Objek keluaran mengandungi maklumat tentang keluaran, dengan keluaran ialah pemasangan khusus carta dan nilai yang dinamakan. Objek ini menerangkan metadata peringkat atas tentang keluaran. Objek keluaran kekal sepanjang kitaran hayat aplikasi dan merupakan pemilik semua rahsia versi keluaran, serta semua objek yang dicipta secara langsung oleh carta Helm.

Rahsia versi keluaran mengaitkan keluaran dengan satu siri semakan (pemasangan, kemas kini, pemulangan semula, pemadaman).

Dalam Helm 2, semakan sangat konsisten. Panggil helm install mencipta v1, kemas kini seterusnya (naik taraf) - v2, dan seterusnya. Rahsia versi keluaran dan keluaran telah diruntuhkan menjadi satu objek yang dikenali sebagai semakan. Semakan telah disimpan dalam ruang nama yang sama seperti Tiller, yang bermaksud bahawa setiap keluaran adalah "global" dari segi ruang nama; akibatnya, hanya satu contoh nama boleh digunakan.

Dalam Helm 3, setiap keluaran dikaitkan dengan satu atau lebih rahsia versi keluaran. Objek keluaran sentiasa menerangkan keluaran semasa yang digunakan untuk Kubernetes. Setiap rahsia versi keluaran menerangkan hanya satu versi keluaran itu. Peningkatan, sebagai contoh, akan mencipta rahsia versi keluaran baharu dan kemudian menukar objek keluaran untuk menghala ke versi baharu itu. Dalam kes pemulangan semula, anda boleh menggunakan rahsia versi keluaran sebelumnya untuk melancarkan keluaran ke keadaan sebelumnya.

Selepas Tiller ditinggalkan, Helm 3 menyimpan data keluaran dalam ruang nama yang sama dengan keluaran. Perubahan ini membolehkan anda memasang carta dengan nama keluaran yang sama dalam ruang nama yang berbeza, dan data disimpan antara kemas kini kelompok/but semula dalam etcd. Sebagai contoh, anda boleh memasang WordPress dalam ruang nama "foo" dan kemudian dalam ruang nama "bar", dan kedua-dua keluaran boleh dinamakan "wordpress".

Perubahan pada kebergantungan carta

Carta dibungkus (menggunakan helm package) untuk digunakan dengan Helm 2 boleh dipasang dengan Helm 3, namun aliran kerja pembangunan carta telah dirombak sepenuhnya, jadi beberapa perubahan mesti dibuat untuk meneruskan pembangunan carta dengan Helm 3. Khususnya, sistem pengurusan pergantungan carta telah berubah.

Sistem pengurusan pergantungan carta telah beralih daripada requirements.yaml и requirements.lock pada Chart.yaml и Chart.lock. Ini bermakna carta yang menggunakan arahan helm dependency, memerlukan beberapa persediaan untuk berfungsi dalam Helm 3.

Mari kita lihat contoh. Mari tambahkan pergantungan pada carta dalam Helm 2 dan lihat perkara yang berubah apabila beralih ke Helm 3.

Dalam Helm 2 requirements.yaml kelihatan seperti ini:

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

Dalam Helm 3, pergantungan yang sama akan ditunjukkan dalam anda Chart.yaml:

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

Carta masih dimuat turun dan diletakkan dalam direktori charts/, jadi subcarta (subcarta), terletak dalam katalog charts/, akan terus berfungsi tanpa perubahan.

Memperkenalkan Carta Perpustakaan

Helm 3 menyokong kelas carta yang dipanggil carta perpustakaan (carta perpustakaan). Carta ini digunakan oleh carta lain, tetapi tidak mencipta sebarang artifak keluaran sendiri. Templat carta perpustakaan hanya boleh mengisytiharkan elemen define. Kandungan lain diabaikan begitu sahaja. Ini membolehkan pengguna menggunakan semula dan berkongsi coretan kod yang boleh digunakan merentas berbilang carta, dengan itu mengelakkan pertindihan dan mematuhi prinsip DRY.

Carta perpustakaan diisytiharkan dalam bahagian dependencies dalam fail Chart.yaml. Memasang dan mengurusnya tidak berbeza dengan carta lain.

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

Kami teruja dengan kes penggunaan komponen ini akan dibuka untuk pembangun carta, serta amalan terbaik yang boleh muncul daripada carta perpustakaan.

Apa seterusnya?

Helm 3.0.0-alpha.1 ialah asas di mana kami mula membina versi baharu Helm. Dalam artikel itu saya menerangkan beberapa ciri menarik Helm 3. Kebanyakannya masih dalam peringkat awal pembangunan dan ini adalah perkara biasa; Tujuan keluaran alfa adalah untuk menguji idea, mengumpulkan maklum balas daripada pengguna awal dan mengesahkan andaian kami.

Sebaik sahaja versi alpha dikeluarkan (ingat bahawa ini adalah sudah berlaku - lebih kurang terjemah.), kami akan mula menerima patch untuk Helm 3 daripada komuniti. Anda perlu mencipta asas yang kukuh yang membolehkan fungsi baharu dibangunkan dan diterima pakai, dan untuk pengguna merasai terlibat dalam proses dengan membuka tiket dan membuat pembetulan.

Saya telah cuba menyerlahkan beberapa penambahbaikan utama yang datang ke Helm 3, tetapi senarai ini sama sekali tidak lengkap. Pelan hala tuju penuh untuk Helm 3 termasuk ciri seperti strategi kemas kini yang dipertingkatkan, penyepaduan yang lebih mendalam dengan pendaftaran OCI dan penggunaan skema JSON untuk mengesahkan nilai carta. Kami juga merancang untuk membersihkan pangkalan kod dan mengemas kini bahagiannya yang telah diabaikan sejak tiga tahun lalu.

Jika anda rasa kami terlepas sesuatu, kami ingin mendengar pendapat anda!

Sertai perbincangan di kami Saluran kendur:

#helm-users untuk soalan dan komunikasi mudah dengan masyarakat;
#helm-dev untuk membincangkan permintaan tarik, kod dan pepijat.

Anda juga boleh bersembang dalam Panggilan Pembangun Awam mingguan kami pada hari Khamis pukul 19:30 MSK. Mesyuarat dikhususkan untuk membincangkan isu yang sedang diusahakan oleh pembangun utama dan komuniti, serta topik perbincangan untuk minggu ini. Sesiapa sahaja boleh menyertai dan mengambil bahagian dalam mesyuarat. Pautan tersedia dalam saluran Slack #helm-dev.

Memperkenalkan Helm 3