🥇Perangkat Helm dan kendalanya

Konsep pengangkut barang Typhon, Anton Swanepoel

Nama saya Dmitry Sugrobov, saya seorang pengembang di Leroy Merlin. Dalam artikel ini saya akan memberi tahu Anda mengapa Helm diperlukan, bagaimana Helm menyederhanakan pekerjaan dengan Kubernetes, apa yang berubah di versi ketiga, dan bagaimana menggunakannya untuk memperbarui aplikasi dalam produksi tanpa downtime.

Ini adalah ringkasan berdasarkan pidato di sebuah konferensi @Konferensi Kubernetes by Solusi Cloud Mail.ru — jika Anda tidak ingin membaca, tonton videonya.

Mengapa kami menggunakan Kubernetes dalam produksi

Leroy Merlin adalah pemimpin pasar ritel DIY di Rusia dan Eropa. Perusahaan kami memiliki lebih dari seratus pengembang, 33 karyawan internal, dan sejumlah besar orang yang mengunjungi hypermarket dan situs web. Untuk membuat mereka semua bahagia, kami memutuskan untuk mengikuti pendekatan standar industri. Mengembangkan aplikasi baru menggunakan arsitektur layanan mikro; menggunakan wadah untuk mengisolasi lingkungan dan memastikan pengiriman yang tepat; dan menggunakan Kubernetes untuk orkestrasi. Harga penggunaan orkestrator dengan cepat menjadi lebih murah: jumlah insinyur yang mahir dalam teknologi ini semakin bertambah di pasar, dan penyedia layanan bermunculan menawarkan Kubernetes sebagai layanan.

Segala sesuatu yang dilakukan Kubernetes, tentu saja, dapat dilakukan dengan cara lain, misalnya dengan menutupi beberapa Jenkins dan penulisan buruh pelabuhan dengan skrip, tetapi mengapa mempersulit hidup jika ada solusi yang siap pakai dan dapat diandalkan? Itu sebabnya kami datang ke Kubernetes dan telah menggunakannya dalam produksi selama satu tahun sekarang. Saat ini kami memiliki dua puluh empat cluster Kubernetes, yang tertua berusia lebih dari satu tahun, dengan sekitar dua ratus pod.

Kutukan file YAML besar di Kubernetes

Untuk meluncurkan layanan mikro di Kubernetes, kami akan membuat setidaknya lima file YAML: untuk Deployment, Service, Ingress, ConfigMap, Secrets - dan mengirimkannya ke cluster. Untuk aplikasi selanjutnya kita akan menulis paket kusen yang sama, dengan aplikasi ketiga kita akan menulis paket lain, dan seterusnya. Jika kita mengalikan jumlah dokumen dengan jumlah lingkungan, kita sudah mendapatkan ratusan file, dan ini belum memperhitungkan lingkungan dinamis.

Adam Reese, pengelola inti Helm, memperkenalkan konsep "Siklus Pengembangan di Kubernetes", yang terlihat seperti ini:

Salin YAML - salin file YAML.
Tempel YAML - tempel.
Perbaiki Indentasi - perbaiki indentasi.
Ulangi - ulangi lagi.

Opsi ini berfungsi, tetapi Anda harus menyalin file YAML berkali-kali. Untuk mengubah siklus ini, Helm diciptakan.

Apa itu Helm

Pertama, Helm - manajer paket, yang membantu Anda menemukan dan menginstal program yang Anda perlukan. Untuk menginstal misalnya MongoDB, Anda tidak perlu membuka situs resminya dan mendownload binari, cukup jalankan perintah helm install stable/mongodb.

Kedua, Helm - mesin templat, membantu membuat parameter file. Mari kita kembali ke situasi dengan file YAML di Kubernetes. Lebih mudah untuk menulis file YAML yang sama, tambahkan beberapa placeholder ke dalamnya, di mana Helm akan mengganti nilainya. Artinya, alih-alih satu set perancah yang besar, akan ada satu set templat di mana nilai-nilai yang diperlukan akan diganti pada waktu yang tepat.

Ketiga, Helm - master penerapan. Dengan itu Anda dapat menginstal, mengembalikan, dan memperbarui aplikasi. Mari kita cari tahu cara melakukan ini.

Cara menggunakan Helm untuk menyebarkan aplikasi Anda sendiri

Mari kita instal klien Helm di komputer Anda, berikut yang resmi Instruksi. Selanjutnya, kita akan membuat satu set file YAML. Daripada menentukan nilai spesifik, kami akan meninggalkan placeholder, yang akan diisi oleh Helm dengan informasi di masa mendatang. Kumpulan file seperti itu disebut diagram Helm. Itu dapat dikirim ke klien konsol Helm dengan tiga cara:

tunjukkan folder dengan templat;
kemas arsip ke dalam .tar dan arahkan ke sana;
letakkan templat di repositori jarak jauh dan tambahkan tautan ke repositori di klien Helm.

Anda juga memerlukan file dengan nilai - value.yaml. Data dari sana akan dimasukkan ke dalam template. Mari kita membuatnya juga.

Helm versi kedua memiliki aplikasi server tambahan - Tiller. Itu hang di luar Kubernetes dan menunggu permintaan dari klien Helm, dan ketika dipanggil, ia mengganti nilai yang diperlukan ke dalam templat dan mengirimkannya ke Kubernetes.

Helm 3 lebih sederhana: alih-alih memproses template di server, informasi kini diproses seluruhnya di sisi klien Helm dan dikirim langsung ke API Kubernetes. Penyederhanaan ini meningkatkan keamanan klaster dan memfasilitasi skema peluncuran.

Bagaimana cara kerjanya

Jalankan perintah helm install. Mari tunjukkan nama rilis aplikasi dan berikan jalur ke value.yaml. Pada akhirnya kami akan menunjukkan repositori di mana grafik tersebut berada dan nama grafiknya. Dalam contoh, ini masing-masing adalah “lmru” dan “bestchart”.

helm install --name bestapp --values values.yaml lmru/bestchart

Perintah hanya dapat dijalankan satu kali, namun sebaliknya dapat dijalankan lagi install perlu digunakan upgrade. Untuk mempermudah, alih-alih dua perintah, Anda dapat menjalankan perintah tersebut upgrade dengan kunci tambahan --install. Saat dijalankan untuk pertama kali, Helm akan mengirimkan perintah untuk menginstal rilis, dan akan memperbaruinya di masa mendatang.

helm upgrade --install bestapp --values values.yaml lmru/bestchart

Kesalahan dalam menerapkan versi baru aplikasi dengan Helm

Pada titik cerita ini, saya bermain Siapa yang Ingin Menjadi Jutawan dengan penonton, dan kami mencari cara agar Helm memperbarui versi aplikasinya. Tonton videonya.

Saat saya mempelajari cara kerja Helm, saya dikejutkan oleh perilaku aneh saat mencoba memperbarui versi aplikasi yang sedang berjalan. Saya memperbarui kode aplikasi, mengunggah gambar baru ke registri Docker, mengirim perintah penerapan - dan tidak ada yang terjadi. Berikut adalah beberapa cara yang tidak sepenuhnya berhasil untuk memperbarui aplikasi. Dengan mempelajari masing-masing secara lebih rinci, Anda mulai memahami struktur internal instrumen dan alasan perilaku tidak jelas ini.

Metode 1. Jangan mengubah informasi sejak peluncuran terakhir

Seperti pepatah situs resmi Helm, “Grafik Kubernetes bisa berukuran besar dan kompleks, jadi Helm berusaha untuk tidak menyentuh apa pun terlalu banyak.” Oleh karena itu, jika Anda memperbarui versi terbaru gambar aplikasi di registri buruh pelabuhan dan menjalankan perintah helm upgrade, maka tidak akan terjadi apa-apa. Helm akan mengira tidak ada yang berubah dan tidak perlu mengirimkan perintah ke Kubernetes untuk memperbarui aplikasi.

Di sini dan di bawah, tag terbaru ditampilkan hanya sebagai contoh. Saat Anda menentukan tag ini, Kubernetes akan mengunduh image dari registri buruh pelabuhan setiap saat, terlepas dari parameter imagePullPolicy. Menggunakan produksi terbaru tidak diinginkan dan menyebabkan efek samping.

Metode 2. Perbarui LABEL pada gambar

Seperti yang tertulis di hal yang sama dokumentasi, “Helm hanya akan memperbarui aplikasi jika sudah berubah sejak rilis terakhir.” Opsi logis untuk ini adalah memperbarui LABEL pada gambar buruh pelabuhan itu sendiri. Namun, Helm tidak melihat gambar aplikasi dan tidak mengetahui perubahan apa pun pada gambar tersebut. Oleh karena itu, saat memperbarui label pada gambar, Helm tidak akan mengetahuinya, dan perintah pembaruan aplikasi tidak akan dikirim ke Kubernetes.

Metode 3: Gunakan kunci --force

Mari kita beralih ke manual dan mencari kunci yang diperlukan. Kuncinya paling masuk akal --force. Meski namanya jelas, perilakunya berbeda dari yang diharapkan. Alih-alih memaksakan pembaruan aplikasi, tujuan sebenarnya adalah memulihkan rilis yang berstatus GAGAL. Jika Anda tidak menggunakan kunci ini, Anda perlu menjalankan perintah secara berurutan helm delete && helm install --replace. Disarankan untuk menggunakan kunci saja --force, yang mengotomatiskan eksekusi berurutan dari perintah-perintah ini. Informasi lebih lanjut di sini permintaan tarik. Sayangnya, untuk memberitahu Helm agar memperbarui versi aplikasi, kunci ini tidak akan berfungsi.

Metode 4. Ubah label langsung di Kubernetes

Memperbarui label secara langsung di cluster menggunakan perintah kubectl edit - ide buruk. Tindakan ini akan menyebabkan ketidakkonsistenan informasi antara aplikasi yang sedang berjalan dan aplikasi yang awalnya dikirim untuk diterapkan. Perilaku Helm selama penerapan dalam kasus ini berbeda dengan versinya: Helm 2 tidak akan melakukan apa pun, dan Helm 3 akan menerapkan versi aplikasi yang baru. Untuk memahami alasannya, Anda perlu memahami cara kerja Helm.

Bagaimana cara kerja Helm?

Untuk menentukan apakah suatu aplikasi telah berubah sejak rilis terakhirnya, Helm dapat menggunakan:

menjalankan aplikasi di Kubernetes;
nilai baru.yaml dan grafik saat ini;
Informasi rilis internal Helm.

Bagi yang lebih penasaran: di mana Helm menyimpan informasi internal tentang rilis?Dengan menjalankan perintah helm history, kami akan mendapatkan semua informasi tentang versi yang diinstal menggunakan Helm.

Ada juga informasi rinci tentang templat dan nilai yang dikirim. Kami dapat memintanya:

Pada Helm versi kedua, informasi ini terletak di namespace yang sama dengan tempat Tiller dijalankan (kube-system secara default), di ConfigMap, ditandai dengan label “OWNER=TILLER”:

Ketika Helm versi ketiga muncul, informasi berpindah ke rahasia, dan ke namespace yang sama tempat aplikasi berjalan. Berkat ini, beberapa aplikasi dapat dijalankan secara bersamaan di namespace berbeda dengan nama rilis yang sama. Dalam versi kedua, sangat memusingkan ketika namespace diisolasi tetapi dapat saling mempengaruhi.

Helm kedua, ketika mencoba memahami apakah pembaruan diperlukan, hanya menggunakan dua sumber informasi: apa yang tersedia saat ini, dan informasi internal tentang rilis, yang ada di ConfigMap.

Helm ketiga menggunakan strategi penggabungan tiga arah: selain informasi tersebut, Helm juga memperhitungkan aplikasi yang sedang berjalan di Kubernetes.

Oleh karena itu, Helm versi lama tidak akan melakukan apa pun karena tidak memperhitungkan informasi aplikasi di cluster, tetapi Helm 3 akan menerima perubahan dan mengirimkan aplikasi baru untuk diterapkan.

Metode 5. Gunakan sakelar --recreate-pods

Dengan kunci --recreate-pods Anda dapat mencapai apa yang awalnya Anda rencanakan untuk dicapai dengan kunci tersebut --force. Kontainer akan dimulai ulang dan, sesuai dengan kebijakan imagePullPolicy: Always untuk tag terbaru (lebih lanjut tentang ini pada catatan kaki di atas), Kubernetes akan mengunduh dan meluncurkan versi baru dari image tersebut. Hal ini tidak akan dilakukan dengan cara terbaik: tanpa memperhitungkan StrategyType penerapannya, hal ini akan secara tiba-tiba mematikan semua contoh aplikasi lama dan mulai meluncurkan yang baru. Selama restart, sistem tidak akan berfungsi, pengguna akan menderita.

Di Kubernetes sendiri, masalah serupa juga sudah ada sejak lama. Dan sekarang, 4 tahun setelah pembukaannya Isu, masalahnya telah diperbaiki, dan mulai Kubernetes versi 1.15, kemampuan untuk melakukan roll-restart pod muncul.

Helm cukup mematikan semua aplikasi dan meluncurkan container baru di dekatnya. Anda tidak dapat melakukan ini dalam produksi, agar tidak menyebabkan downtime aplikasi. Ini hanya diperlukan untuk kebutuhan pengembangan dan hanya dapat dilakukan di lingkungan panggung.

Bagaimana cara mengupdate versi aplikasi menggunakan Helm?

Kami akan mengubah nilai yang dikirim ke Helm. Biasanya, ini adalah nilai yang menggantikan tag gambar. Dalam kasus terbaru, yang sering digunakan untuk lingkungan tidak produktif, informasi yang dapat diubah adalah anotasi, yang tidak berguna bagi Kubernetes itu sendiri, dan bagi Helm, informasi tersebut akan bertindak sebagai sinyal perlunya memperbarui aplikasi. Pilihan untuk mengisi nilai anotasi:

Nilai acak menggunakan fungsi standar - {{ randAlphaNum 6 }}.
Ada peringatan: setelah setiap penerapan menggunakan bagan dengan variabel seperti itu, nilai anotasi akan menjadi unik, dan Helm akan berasumsi bahwa ada perubahan. Ternyata kita akan selalu me-restart aplikasi tersebut, meskipun kita belum mengubah versinya. Ini tidak penting, karena tidak akan ada waktu henti, tetapi tetap saja tidak menyenangkan.
Tempel saat ini tanggal dan waktu - {{ .Release.Date }}.
Varian mirip dengan nilai acak dengan variabel unik permanen.
Cara yang lebih tepat adalah dengan menggunakan checksum. Ini adalah SHA dari gambar atau SHA dari komit terakhir di git - {{ .Values.sha }}.
Mereka perlu dihitung dan dikirim ke klien Helm di sisi panggilan, misalnya di Jenkins. Jika aplikasinya sudah berubah, maka checksumnya pun akan berubah. Oleh karena itu, Helm hanya akan mengupdate aplikasi bila diperlukan.

Mari kita rangkum upaya kita

Helm membuat perubahan dengan cara yang paling tidak invasif, sehingga perubahan apa pun pada tingkat gambar aplikasi di Docker Registry tidak akan menghasilkan pembaruan: tidak ada yang terjadi setelah perintah dijalankan.
Ключ --force digunakan untuk memulihkan rilis yang bermasalah dan tidak terkait dengan pembaruan yang dipaksakan.
Ключ --recreate-pods akan memperbarui aplikasi secara paksa, tetapi akan melakukannya dengan cara yang merusak: ia akan mematikan semua container secara tiba-tiba. Pengguna akan menderita karena hal ini; Anda tidak boleh melakukan ini dalam produksi.
Langsung lakukan perubahan pada cluster Kubernetes menggunakan perintah kubectl edit jangan: kami akan merusak konsistensi, dan perilakunya akan berbeda bergantung pada versi Helm.
Dengan dirilisnya Helm versi baru, banyak nuansa yang muncul. Masalah dalam repositori Helm dijelaskan dalam bahasa yang jelas, mereka akan membantu Anda memahami detailnya.
Menambahkan anotasi yang dapat diedit ke bagan akan membuatnya lebih fleksibel. Ini akan memungkinkan Anda meluncurkan aplikasi dengan benar, tanpa downtime.

Sebuah pemikiran “perdamaian dunia” yang berlaku di semua bidang kehidupan: baca instruksi sebelum digunakan, bukan setelahnya. Hanya dengan informasi yang lengkap kita dapat membangun sistem yang andal dan membuat pengguna senang.

Tautan terkait lainnya:

Laporan ini pertama kali dipresentasikan pada @Konferensi Kubernetes oleh Solusi Cloud Mail.ru. Lihat Video pertunjukan lainnya dan berlangganan pengumuman acara di Telegram Sekitar Kubernetes di Mail.ru Group.

Sumber: www.habr.com

Perangkat Helm dan kendalanya