Helm tanpa hype. Terlihat serius
Helm adalah manajer paket untuk Kubernetes.
Sepintas, tidak buruk. Alat ini sangat menyederhanakan proses rilis, tetapi kadang-kadang bisa merepotkan, Anda tidak akan menyelesaikan apa pun!
Baru-baru ini Helm secara resmi diakui sebagai proyek teratas @CloudNativeFdn , dan banyak digunakan oleh masyarakat. Ini mengatakan banyak hal, tetapi saya ingin secara singkat berbicara tentang momen tidak menyenangkan yang terkait dengan manajer paket ini.
Apa nilai sebenarnya dari Helm?
Saya masih tidak bisa menjawab pertanyaan ini dengan percaya diri. Helm tidak menyediakan fitur khusus. Apa manfaat yang dibawa Tiller (sisi server)?
Banyak grafik Helm masih jauh dari sempurna, dan perlu upaya ekstra untuk menggunakannya di cluster Kubernetes. Misalnya, mereka tidak memiliki RBAC, batasan sumber daya, dan kebijakan jaringan. Cukup meraih dan menginstal grafik Helm dalam bentuk biner - tanpa memikirkan bagaimana itu akan berhasil - tidak akan berfungsi.
Tidak cukup hanya memuji Helm, memberikan contoh paling sederhana. Anda akan menjelaskan mengapa ini sangat baik - terutama dalam hal lingkungan kerja multi-tenant yang aman.
Kata-kata kosong. Tunjukkan kodenya!
—Linus Torvalds
Tingkat otorisasi dan kontrol akses tambahan
Saya ingat seseorang membandingkan Tiller dengan "server sudo besar." Menurut pendapat saya, ini hanya tingkat otorisasi berikutnya, yang pada saat yang sama memerlukan sertifikat TLS tambahan, tetapi tidak memberikan kemampuan kontrol akses. Mengapa tidak menggunakan Kubernetes API dan model keamanan yang ada yang mendukung audit dan RBAC?
Alat pengolah template yang berlebihan?
Faktanya adalah bahwa untuk pemrosesan dan analisis statis dari file templat Go, konfigurasi dari file values.yaml , dan kemudian manifes Kubernet yang diproses digunakan dengan metadata terkait yang disimpan dalam ConfigMap.
Dan Anda dapat menggunakan beberapa perintah sederhana:
$ # render go-template files using golang or python script $ kubectl apply --dry-run -f . $ kubectl apply -f .
Saya perhatikan bahwa pengembang biasanya menggunakan satu file values.yaml per lingkungan, atau bahkan mendapatkannya dari values.yaml.tmpl sebelum digunakan.
Ini tidak masuk akal ketika bekerja dengan rahasia Kubernetes, yang sering dienkripsi dan memiliki beberapa versi di repositori. Untuk mengatasi batasan ini, Anda perlu menggunakan plugin helm-secrets atau perintah --set key=value . Bagaimanapun, tingkat kompleksitas lain ditambahkan.
Helm sebagai alat manajemen siklus hidup infrastruktur
Lupakan. Ini tidak mungkin, terutama jika kita berbicara tentang komponen utama Kubernetes, seperti kube-dns, penyedia CNI, cluster autoscaler, dll. Siklus hidup komponen-komponen ini bervariasi, dan Helm tidak cocok untuk mereka.
Pengalaman saya dengan Helm menunjukkan bahwa alat ini sangat bagus untuk penyebaran sederhana pada sumber daya inti Kubernet, mudah diimplementasikan dari awal dan tanpa proses rilis yang rumit.
Sayangnya, dengan penyebaran yang lebih kompleks dan sering, termasuk Namespace, RBAC, NetworkPolicy, ResourceQuota dan PodSecurityPolicy, Helm tidak dapat mengatasinya.
Saya mengerti bahwa penggemar Helm mungkin tidak menyukai kata-kata saya, tetapi inilah kenyataannya.
Helm Negara
Server Tiller menyimpan informasi dalam file ConfigMap di dalam Kubernetes. Dia tidak membutuhkan database sendiri.
Sayangnya, ukuran ConfigMap tidak dapat melebihi 1 MB karena keterbatasan etcd .
Semoga seseorang menemukan cara untuk meningkatkan driver penyimpanan ConfigMap untuk mengompresi versi serial sebelum pindah ke penyimpanan. Namun, jadi, saya pikir, masalah sebenarnya masih belum bisa diselesaikan.
Kecelakaan acak dan penanganan kesalahan
Bagi saya, masalah terbesar Helm adalah rasa tidak amannya.
Kesalahan: UPGRADE GAGAL: "foo" tidak memiliki rilis yang digunakan
Ini, IMHO, adalah salah satu masalah paling menyebalkan Helm.
Jika tidak memungkinkan untuk membuat versi pertama, setiap upaya berikutnya akan gagal dengan kesalahan yang menunjukkan ketidakmungkinan memperbarui dari keadaan yang tidak diketahui.
Permintaan berikut untuk memasukkan perubahan "memperbaiki" kesalahan dengan menambahkan --force flag, yang sebenarnya hanya menutupi masalah dengan menjalankan perintah helm delete & helm install —replace .
Namun, dalam kebanyakan kasus, Anda harus melakukan pembersihan penuh dari rilis.
helm delete --purge $RELEASE_NAME
Kesalahan: rilis foo gagal: kehabisan waktu menunggu kondisi
Jika ServiceAccount hilang atau RBAC tidak mengizinkan pembuatan sumber daya tertentu, Helm akan mengembalikan pesan kesalahan berikut:
Error: release foo failed: timed out waiting for the condition
Sayangnya, akar penyebab kesalahan ini tidak dapat dilihat:
kubectl -n foo get events --sort-by='{.lastTimestamp}'
Error creating: pods "foo-5467744958" is forbidden: error looking up service account foo/foo: serviceaccount "foo" not found
Gagal tiba-tiba
Dalam kasus yang paling canggih, Helm melempar kesalahan tanpa melakukan tindakan apa pun. Misalnya, terkadang tidak memperbarui batas sumber daya.
helm init menjalankan tiller dengan satu salinan, bukan dalam konfigurasi HA
Anakan secara default tidak menyiratkan ketersediaan tinggi, dan permintaan untuk mengaktifkan perubahan dengan referensi masih terbuka.
Suatu hari itu akan menyebabkan downtime ...
Helm 3? Operator? Masa depan
Versi Helm berikutnya akan menambahkan beberapa fitur yang menjanjikan:
- arsitektur layanan tunggal tanpa pemisahan antara klien dan server. Tidak ada lagi penggarap;
- mesin skrip Lua bawaan;
- Alur kerja DevOps berdasarkan permintaan inklusi dan proyek Helm Controller baru.
Lihat Proposal Proyek Helm 3 untuk informasi lebih lanjut.
Saya sangat menyukai ide arsitektur tanpa Tiller, tetapi skrip yang didasarkan pada Lua diragukan, karena mereka dapat memperumit grafik.
Saya perhatikan bahwa baru-baru ini operator yang jauh lebih cocok untuk Kubernet daripada grafik Helm telah mendapatkan popularitas.
Saya sangat berharap bahwa komunitas akan segera menangani masalah Helm (dengan bantuan kami, tentu saja), tetapi untuk saat ini saya sendiri akan mencoba menggunakan alat ini sesedikit mungkin.
Pahami ini: artikel ini adalah pendapat pribadi saya, yang saya sampaikan ketika membuat platform cloud hybrid untuk penempatan berdasarkan Kubernetes.