Keamanan Helm

Inti cerita tentang pengelola paket paling populer untuk Kubernetes dapat digambarkan menggunakan emoji:

• kotaknya adalah Helm (yang paling mirip dengan rilisan Emoji terbaru);
• kunci - keamanan;
• pria kecil adalah solusi dari masalah tersebut.

Faktanya, semuanya akan menjadi sedikit lebih rumit, dan ceritanya penuh dengan detail teknis Cara membuat Helm aman.

• Secara singkat apa itu Helm jika Anda belum tahu atau lupa. Masalah apa yang dipecahkannya dan di mana lokasinya dalam ekosistem.
• Mari kita lihat arsitektur Helm. Percakapan tentang keamanan dan cara membuat alat atau solusi lebih aman tidak akan lengkap tanpa memahami arsitektur komponen.
• Mari kita bahas komponen Helm.
• Pertanyaan paling membara adalah masa depan - versi baru Helm 3. 

Semua yang ada di artikel ini berlaku untuk Helm 2. Versi ini sedang dalam produksi dan kemungkinan besar adalah versi yang Anda gunakan saat ini, dan versi inilah yang mengandung risiko keamanan.

Tentang pembicara: Alexander Khayorov (allexx) telah berkembang selama 10 tahun, membantu meningkatkan konten Konferensi Python Moskow++ dan bergabung dengan panitia KTT Helm. Sekarang dia bekerja di Chainstack sebagai pemimpin pengembangan - ini adalah gabungan antara manajer pengembangan dan orang yang bertanggung jawab untuk mengirimkan rilis final. Artinya, terletak di medan perang, di mana segala sesuatu terjadi mulai dari pembuatan suatu produk hingga pengoperasiannya.

Chainstack adalah startup kecil yang tumbuh aktif dengan misi memungkinkan klien melupakan infrastruktur dan kompleksitas pengoperasian aplikasi terdesentralisasi; tim pengembangan berlokasi di Singapura. Jangan meminta Chainstack untuk menjual atau membeli mata uang kripto, tetapi tawarkan untuk berbicara tentang kerangka kerja blockchain perusahaan, dan mereka akan dengan senang hati menjawab Anda.

Kemudi

Ini adalah manajer paket (grafik) untuk Kubernetes. Cara paling intuitif dan universal untuk membawa aplikasi ke cluster Kubernetes.

Tentu saja, kita berbicara tentang pendekatan yang lebih struktural dan industrial daripada membuat manifes YAML Anda sendiri dan menulis utilitas kecil.

Helm merupakan yang terbaik yang ada saat ini dan populer.

Mengapa Helm? Terutama karena didukung oleh CNCF. Cloud Native adalah organisasi besar dan merupakan perusahaan induk untuk proyek Kubernetes, dll, Fluentd, dan lainnya.

Fakta penting lainnya adalah Helm adalah proyek yang sangat populer. Ketika saya mulai berbicara tentang cara mengamankan Helm pada Januari 2019, proyek ini mendapat seribu bintang di GitHub. Pada bulan Mei ada 12 ribu di antaranya.

Banyak orang yang tertarik dengan Helm, jadi meskipun Anda belum menggunakannya, Anda akan mendapat manfaat dengan mengetahui keamanannya. Keamanan itu penting.

Tim inti Helm didukung oleh Microsoft Azure dan oleh karena itu merupakan proyek yang cukup stabil, tidak seperti banyak proyek lainnya. Dirilisnya Helm 3 Alpha 2 pada pertengahan bulan Juli menunjukkan bahwa cukup banyak orang yang mengerjakan proyek tersebut, dan mereka memiliki keinginan dan energi untuk mengembangkan dan meningkatkan Helm.

Helm memecahkan beberapa akar masalah manajemen aplikasi di Kubernetes.

• Kemasan aplikasi. Bahkan aplikasi seperti “Hello, World” di WordPress sudah terdiri dari beberapa layanan, dan Anda ingin mengemasnya menjadi satu.
• Mengelola kompleksitas yang timbul saat mengelola aplikasi ini.
• Siklus hidup yang tidak berakhir setelah aplikasi diinstal atau disebarkan. Ia terus hidup, perlu diperbarui, dan Helm membantu dalam hal ini dan mencoba mengambil tindakan dan kebijakan yang tepat untuk hal ini.

Mengantongi itu diatur dengan jelas: ada metadata yang sepenuhnya sesuai dengan pekerjaan manajer paket biasa untuk Linux, Windows atau MacOS. Artinya, repositori, ketergantungan pada berbagai paket, informasi meta untuk aplikasi, pengaturan, fitur konfigurasi, pengindeksan informasi, dll. Helm memungkinkan Anda memperoleh dan menggunakan semua ini untuk aplikasi.

Manajemen Kompleksitas. Jika Anda memiliki banyak aplikasi dengan jenis yang sama, maka diperlukan parameterisasi. Templat berasal dari ini, tetapi untuk menghindari keharusan membuat cara Anda sendiri dalam membuat templat, Anda dapat menggunakan apa yang ditawarkan Helm secara langsung.

Manajemen Siklus Hidup Aplikasi - menurut saya, ini adalah pertanyaan yang paling menarik dan belum terselesaikan. Inilah sebabnya saya datang ke Helm pada hari itu. Kami perlu memantau siklus hidup aplikasi dan ingin memindahkan CI/CD dan siklus aplikasi kami ke paradigma ini.

Helm memungkinkan Anda untuk:

• mengelola penerapan, memperkenalkan konsep konfigurasi dan revisi;
• berhasil melakukan rollback;
• gunakan pengait untuk berbagai acara;
• tambahkan pemeriksaan aplikasi tambahan dan tanggapi hasilnya.

Selain itu Helm memiliki “baterai” - sejumlah besar hal lezat yang dapat dimasukkan dalam bentuk plugin, menyederhanakan hidup Anda. Plugin dapat ditulis secara mandiri, cukup terisolasi dan tidak memerlukan arsitektur yang harmonis. Jika Anda ingin mengimplementasikan sesuatu, saya sarankan melakukannya sebagai plugin, dan mungkin memasukkannya ke dalam upstream.

Helm didasarkan pada tiga konsep utama:

• Repo Bagan — deskripsi dan serangkaian parameterisasi yang mungkin untuk manifes Anda. 
• config —yaitu, nilai yang akan diterapkan (teks, nilai numerik, dll.).
• Lepaskan mengumpulkan dua komponen atas, dan bersama-sama mereka berubah menjadi Rilis. Rilis dapat dibuat versinya, sehingga mencapai siklus hidup yang terorganisir: kecil pada saat instalasi dan besar pada saat peningkatan, penurunan versi, atau rollback.

Arsitektur helm

Diagram tersebut secara konseptual menggambarkan arsitektur tingkat tinggi Helm.

Izinkan saya mengingatkan Anda bahwa Helm adalah sesuatu yang berhubungan dengan Kubernetes. Oleh karena itu, kita tidak dapat melakukannya tanpa cluster Kubernetes (persegi panjang). Komponen kube-apiserver berada pada master. Tanpa Helm kita memiliki Kubeconfig. Helm membawa satu biner kecil, jika Anda bisa menyebutnya begitu, utilitas Helm CLI, yang diinstal pada komputer, laptop, mainframe - pada apa pun.

Tapi ini tidak cukup. Helm memiliki komponen server yang disebut Tiller. Ini mewakili kepentingan Helm dalam cluster; ini adalah aplikasi dalam cluster Kubernetes, sama seperti aplikasi lainnya.

Komponen Chart Repo selanjutnya adalah repositori dengan grafik. Ada repositori resmi, dan mungkin ada repositori pribadi suatu perusahaan atau proyek.

Interaksi

Mari kita lihat bagaimana komponen arsitektur berinteraksi ketika kita ingin menginstal aplikasi menggunakan Helm.

• Kami berbicara Helm install, akses repositori (Chart Repo) dan dapatkan grafik Helm.

• Utilitas Helm (Helm CLI) berinteraksi dengan Kubeconfig untuk mengetahui cluster mana yang harus dihubungi. 
• Setelah menerima informasi ini, utilitas merujuk ke Tiller, yang terletak di cluster kami, sebagai sebuah aplikasi. 
• Tiller memanggil Kube-apiserver untuk melakukan tindakan di Kubernetes, membuat beberapa objek (layanan, pod, replika, rahasia, dll.).

Selanjutnya, kita akan memperumit diagram untuk melihat vektor serangan yang dapat diekspos oleh seluruh arsitektur Helm secara keseluruhan. Lalu kami akan mencoba melindunginya.

vektor serangan

Titik lemah potensial yang pertama adalah API istimewa-pemakai. Sebagai bagian dari skema, ini adalah peretas yang telah memperoleh akses admin ke Helm CLI.

Pengguna API yang tidak memiliki hak istimewa juga dapat menimbulkan bahaya jika berada di suatu tempat di dekatnya. Pengguna seperti itu akan memiliki konteks yang berbeda, misalnya, ia dapat diperbaiki dalam satu namespace cluster di pengaturan Kubeconfig.

Vektor serangan yang paling menarik mungkin adalah proses yang berada dalam cluster di dekat Tiller dan dapat mengaksesnya. Ini bisa berupa server web atau layanan mikro yang melihat lingkungan jaringan cluster.

Varian serangan yang eksotis namun semakin populer melibatkan Chart Repo. Bagan yang dibuat oleh penulis yang tidak bermoral mungkin berisi sumber daya yang tidak aman, dan Anda akan menyelesaikannya dengan mengambilnya berdasarkan keyakinan. Atau dapat menggantikan bagan yang Anda unduh dari repositori resmi dan, misalnya, membuat sumber daya dalam bentuk kebijakan dan meningkatkan aksesnya.

Mari kita coba menangkis serangan dari keempat sisi ini dan mencari tahu di mana terdapat masalah dalam arsitektur Helm, dan di mana, mungkin, tidak ada masalah.

Mari kita perbesar diagramnya, tambahkan lebih banyak elemen, tetapi pertahankan semua komponen dasarnya.

Helm CLI berkomunikasi dengan Chart Repo, berinteraksi dengan Kubeconfig, dan pekerjaan ditransfer ke cluster ke komponen Tiller.

Tiller diwakili oleh dua objek:

• Tiller-deploy svc, yang mengekspos layanan tertentu;
• Pod penerapan anakan (dalam diagram dalam satu salinan dalam satu replika), tempat seluruh beban berjalan, yang mengakses cluster.

Protokol dan skema yang berbeda digunakan untuk interaksi. Dari sudut pandang keamanan, kami paling tertarik pada:

• Mekanisme Helm CLI mengakses repo grafik: protokol apa, apakah ada otentikasi dan apa yang dapat dilakukan dengannya.
• Protokol yang digunakan Helm CLI, menggunakan kubectl, untuk berkomunikasi dengan Tiller. Ini adalah server RPC yang dipasang di dalam cluster.
• Tiller sendiri dapat diakses oleh layanan mikro yang berada di cluster dan berinteraksi dengan Kube-apiserver.

Mari kita bahas semua bidang ini secara berurutan.

RBAC

Tidak ada gunanya membicarakan keamanan apa pun untuk Helm atau layanan lain apa pun dalam cluster kecuali RBAC diaktifkan.

Sepertinya ini bukan rekomendasi terbaru, tapi saya yakin masih banyak orang yang belum mengaktifkan RBAC bahkan dalam tahap produksi, karena banyak keributan dan banyak hal yang perlu dikonfigurasi. Namun, saya mendorong Anda untuk melakukan ini.

https://rbac.dev/ — pengacara situs web untuk RBAC. Ini berisi sejumlah besar materi menarik yang akan membantu Anda menyiapkan RBAC, menunjukkan mengapa itu bagus dan bagaimana pada dasarnya menerapkannya dalam produksi.

Saya akan mencoba menjelaskan cara kerja Tiller dan RBAC. Tiller bekerja di dalam cluster pada akun layanan tertentu. Biasanya, jika RBAC tidak dikonfigurasi, ini akan menjadi pengguna super. Dalam konfigurasi dasar, Tiller akan menjadi admin. Inilah sebabnya mengapa sering dikatakan bahwa Tiller adalah terowongan SSH ke cluster Anda. Faktanya, hal ini benar, sehingga Anda dapat menggunakan akun layanan khusus yang terpisah, bukan Akun Layanan Default pada diagram di atas.

Saat Anda menginisialisasi Helm dan menginstalnya di server untuk pertama kalinya, Anda dapat mengatur akun layanan menggunakan --service-account. Ini akan memungkinkan Anda untuk menggunakan pengguna dengan hak minimum yang diperlukan. Benar, Anda harus membuat "karangan bunga" seperti itu: Role dan RoleBinding.

Sayangnya, Helm tidak akan melakukan ini untuk Anda. Anda atau administrator klaster Kubernetes Anda perlu menyiapkan serangkaian Peran dan Pengikatan Peran untuk akun layanan terlebih dahulu agar dapat meneruskan Helm.

Timbul pertanyaan – apa perbedaan antara Role dan ClusterRole? Perbedaannya adalah ClusterRole berfungsi untuk semua namespace, tidak seperti Roles dan RoleBindings biasa, yang hanya berfungsi untuk namespace khusus. Anda dapat mengonfigurasi kebijakan untuk seluruh klaster dan semua namespace, atau mempersonalisasikan setiap namespace satu per satu.

Perlu disebutkan bahwa RBAC memecahkan masalah besar lainnya. Banyak orang yang mengeluh karena Helm, sayangnya, tidak multitenancy (tidak mendukung multitenancy). Jika beberapa tim menggunakan sebuah cluster dan menggunakan Helm, pada dasarnya tidak mungkin untuk mengatur kebijakan dan membatasi akses mereka dalam cluster ini, karena ada akun layanan tertentu yang menjalankan Helm, dan semua sumber daya di cluster dibuat darinya. , yang terkadang sangat merepotkan. Ini benar - seperti file biner itu sendiri, seperti prosesnya, Helm Tiller tidak memiliki konsep multitenancy.

Namun, ada cara hebat yang memungkinkan Anda menjalankan Tiller beberapa kali dalam sebuah cluster. Tidak ada masalah dengan ini, Tiller dapat diluncurkan di setiap namespace. Dengan demikian, Anda dapat menggunakan RBAC, Kubeconfig sebagai konteks, dan membatasi akses ke Helm khusus.

Ini akan terlihat seperti ini.

Misalnya, ada dua Kubeconfig dengan konteks untuk tim berbeda (dua namespace): Tim X untuk tim pengembangan dan cluster admin. Cluster admin memiliki Tiller sendiri yang luas, yang terletak di namespace sistem Kube, yang juga merupakan akun layanan tingkat lanjut. Dan namespace terpisah untuk tim pengembangan, mereka akan dapat menyebarkan layanan mereka ke namespace khusus.

Ini adalah pendekatan yang bisa diterapkan, Tiller tidak terlalu haus kekuasaan sehingga akan sangat mempengaruhi anggaran Anda. Ini adalah salah satu solusi cepat.

Jangan ragu untuk mengonfigurasi Tiller secara terpisah dan memberikan Kubeconfig konteks untuk tim, untuk pengembang tertentu, atau untuk lingkungan: Pengembangan, Staging, Produksi (diragukan bahwa semuanya akan berada di cluster yang sama, namun hal ini dapat dilakukan).

Melanjutkan cerita kita, mari beralih dari RBAC dan membahas tentang ConfigMaps.

ConfigMap

Helm menggunakan ConfigMaps sebagai penyimpan datanya. Ketika kita berbicara tentang arsitektur, tidak ada database di mana pun yang menyimpan informasi tentang rilis, konfigurasi, rollback, dll. ConfigMaps digunakan untuk ini.

Masalah utama dengan ConfigMaps sudah diketahui - pada prinsipnya mereka tidak aman; tidak mungkin menyimpan data sensitif. Kita berbicara tentang segala sesuatu yang tidak boleh melampaui layanan, misalnya kata sandi. Cara paling asli bagi Helm saat ini adalah beralih dari penggunaan ConfigMaps ke rahasia.

Hal ini dilakukan dengan sangat sederhana. Ganti pengaturan Tiller dan tentukan bahwa penyimpanannya akan dirahasiakan. Kemudian untuk setiap penerapan Anda tidak akan menerima ConfigMap, tetapi sebuah rahasia.

Anda dapat berargumen bahwa rahasia itu sendiri adalah konsep yang aneh dan tidak terlalu aman. Namun, perlu dipahami bahwa pengembang Kubernetes sendiri yang melakukan hal ini. Mulai dari versi 1.10, yaitu. Untuk beberapa waktu sekarang, setidaknya di cloud publik, dimungkinkan untuk menghubungkan penyimpanan yang benar untuk menyimpan rahasia. Tim ini kini berupaya mencari cara untuk mendistribusikan akses ke rahasia, pod individual, atau entitas lain dengan lebih baik.

Lebih baik mentransfer Storage Helm ke rahasia, dan mereka, pada gilirannya, diamankan secara terpusat.

Tentu saja itu akan tetap ada batas penyimpanan data 1 MB. Helm di sini menggunakan etcd sebagai penyimpanan terdistribusi untuk ConfigMaps. Dan di sana mereka menganggap bahwa ini adalah potongan data yang cocok untuk direplikasi, dll. Ada diskusi menarik tentang ini di Reddit, saya sarankan mencari bacaan lucu ini untuk akhir pekan atau membaca ekstraknya di sini.

Repo Bagan

Grafik adalah yang paling rentan secara sosial dan dapat menjadi sumber “Man in the middle”, terutama jika Anda menggunakan solusi saham. Pertama-tama, kita berbicara tentang repositori yang diekspos melalui HTTP.

Anda pasti perlu mengekspos Helm Repo melalui HTTPS - ini adalah pilihan terbaik dan tidak mahal.

Perhatikan mekanisme tanda tangan bagan. Teknologinya sangat sederhana. Ini sama dengan yang Anda gunakan di GitHub, mesin PGP biasa dengan kunci publik dan privat. Siapkan dan pastikan, dengan memiliki kunci yang diperlukan dan menandatangani semuanya, bahwa ini benar-benar bagan Anda.

Selain itu, Klien helm mendukung TLS (bukan dalam pengertian HTTP sisi server, tetapi TLS bersama). Anda dapat menggunakan kunci server dan klien untuk berkomunikasi. Sejujurnya saya tidak menggunakan mekanisme seperti itu karena saya tidak suka sertifikat mutual. Pada dasarnya, museum grafik - alat utama untuk menyiapkan Helm Repo untuk Helm 2 - juga mendukung autentikasi dasar. Anda dapat menggunakan autentikasi dasar jika lebih nyaman dan lebih senyap.

Ada juga pluginnya helm-gcs, yang memungkinkan Anda menghosting Chart Repos di Google Cloud Storage. Ini cukup nyaman, berfungsi dengan baik dan cukup aman, karena semua mekanisme yang dijelaskan merupakan proses daur ulang.

Jika Anda mengaktifkan HTTPS atau TLS, menggunakan mTLS, dan mengaktifkan autentikasi dasar untuk mengurangi risiko lebih lanjut, Anda akan mendapatkan saluran komunikasi yang aman dengan Helm CLI dan Chart Repo.

API gRPC

Langkah selanjutnya sangat penting - untuk mengamankan Tiller, yang terletak di cluster dan, di satu sisi, adalah server, di sisi lain, ia sendiri mengakses komponen lain dan mencoba berpura-pura menjadi seseorang.

Seperti yang sudah saya katakan, Tiller adalah layanan yang mengekspos gRPC, klien Helm mengaksesnya melalui gRPC. Secara default, tentu saja TLS dinonaktifkan. Mengapa hal ini dilakukan adalah pertanyaan yang bisa diperdebatkan, menurut saya untuk menyederhanakan pengaturan di awal.

Untuk produksi dan bahkan pementasan, saya sarankan untuk mengaktifkan TLS di gRPC.

Menurut pendapat saya, tidak seperti mTLS untuk grafik, ini sesuai di sini dan dilakukan dengan sangat sederhana - buat infrastruktur PQI, buat sertifikat, luncurkan Tiller, transfer sertifikat selama inisialisasi. Setelah ini, Anda dapat menjalankan semua perintah Helm, menampilkan sertifikat dan kunci pribadi yang dihasilkan.

Dengan cara ini Anda akan melindungi diri Anda dari semua permintaan ke Tiller dari luar cluster.

Jadi, kami telah mengamankan saluran koneksi ke Tiller, kami telah membahas RBAC dan menyesuaikan hak apiserver Kubernetes, sehingga mengurangi domain yang dapat berinteraksi.

Helm yang Dilindungi

Mari kita lihat diagram terakhir. Arsitekturnya sama dengan panah yang sama.

Semua koneksi sekarang dapat digambar dengan aman dalam warna hijau:

• untuk Chart Repo kami menggunakan TLS atau mTLS dan basic auth;
• mTLS untuk Tiller, dan diekspos sebagai layanan gRPC dengan TLS, kami menggunakan sertifikat;
• cluster menggunakan akun layanan khusus dengan Role dan RoleBinding. 

Kami telah mengamankan cluster secara signifikan, tetapi seseorang yang cerdas berkata:

“Hanya ada satu solusi yang benar-benar aman – komputer dimatikan, yang terletak di dalam kotak beton dan dijaga oleh tentara.”

Ada berbagai cara untuk memanipulasi data dan menemukan vektor serangan baru. Namun, saya yakin bahwa rekomendasi ini akan mencapai standar keselamatan industri dasar.

Bonus

Bagian ini tidak berhubungan langsung dengan keamanan, tetapi juga akan bermanfaat. Saya akan menunjukkan beberapa hal menarik yang hanya diketahui sedikit orang. Misalnya cara mencari grafik - resmi dan tidak resmi.

Di repositori github.com/helm/charts Sekarang ada sekitar 300 grafik dan dua aliran: stabil dan inkubator. Siapa pun yang berkontribusi tahu betul betapa sulitnya berpindah dari inkubator ke kandang, dan betapa mudahnya terbang keluar dari kandang. Namun, ini bukan alat terbaik untuk mencari grafik untuk Prometheus dan apa pun yang Anda suka, karena satu alasan sederhana - ini bukan portal tempat Anda dapat dengan mudah mencari paket.

Tapi ada layanan hub.helm.sh, yang membuatnya lebih mudah untuk menemukan grafik. Yang terpenting, masih banyak lagi repositori eksternal dan hampir 800 charm yang tersedia. Selain itu, Anda dapat menghubungkan repositori Anda jika karena alasan tertentu Anda tidak ingin mengirim grafik Anda ke stabil.

Coba hub.helm.sh dan mari kita kembangkan bersama. Layanan ini berada di bawah proyek Helm, dan Anda bahkan dapat berkontribusi pada UI-nya jika Anda adalah pengembang front-end dan hanya ingin meningkatkan tampilan.

Saya juga ingin menarik perhatian Anda Buka integrasi API Broker Layanan. Kedengarannya rumit dan tidak jelas, tetapi ini memecahkan masalah yang dihadapi semua orang. Izinkan saya menjelaskan dengan contoh sederhana.

Ada cluster Kubernetes tempat kami ingin menjalankan aplikasi klasik - WordPress. Umumnya, database diperlukan untuk fungsionalitas penuh. Ada banyak solusi berbeda, misalnya, Anda dapat meluncurkan layanan statefull Anda sendiri. Ini sangat tidak nyaman, tetapi banyak orang yang melakukannya.

Yang lain, seperti kami di Chainstack, menggunakan database terkelola seperti MySQL atau PostgreSQL untuk server mereka. Itu sebabnya database kami terletak di suatu tempat di cloud.

Namun muncul masalah: kita perlu menghubungkan layanan kita dengan database, membuat ragam database, mentransfer kredensial, dan mengelolanya. Semua ini biasanya dilakukan secara manual oleh administrator sistem atau pengembang. Dan tidak ada masalah bila aplikasinya sedikit. Jika jumlahnya banyak, Anda perlu menggabungkannya. Ada pemanen seperti itu - itu adalah Pialang Layanan. Ini memungkinkan Anda untuk menggunakan plugin khusus untuk cluster cloud publik dan memesan sumber daya dari penyedia melalui Broker, seolah-olah itu adalah API. Anda dapat menggunakan alat asli Kubernetes untuk ini.

Ini sangat sederhana. Anda dapat melakukan kueri, misalnya, MySQL Terkelola di Azure dengan tingkat dasar (ini dapat dikonfigurasi). Dengan menggunakan Azure API, database akan dibuat dan disiapkan untuk digunakan. Anda tidak perlu ikut campur dalam hal ini, plugin bertanggung jawab untuk ini. Misalnya, OSBA (plugin Azure) akan mengembalikan kredensial ke layanan dan meneruskannya ke Helm. Anda akan dapat menggunakan WordPress dengan cloud MySQL, tidak berurusan dengan database terkelola sama sekali dan tidak mengkhawatirkan layanan statefull di dalamnya.

Kita dapat mengatakan bahwa Helm bertindak sebagai perekat yang, di satu sisi, memungkinkan Anda menyebarkan layanan, dan di sisi lain, menggunakan sumber daya penyedia cloud.

Anda dapat menulis plugin Anda sendiri dan menggunakan keseluruhan cerita ini di lokasi. Kemudian Anda cukup memiliki plugin sendiri untuk penyedia Cloud perusahaan. Saya sarankan untuk mencoba pendekatan ini, terutama jika Anda memiliki skala besar dan ingin segera menerapkan pengembangan, staging, atau seluruh infrastruktur untuk suatu fitur. Ini akan membuat operasi atau DevOps Anda lebih mudah.

Temuan lain yang telah saya sebutkan adalah plugin helm-gcs, yang memungkinkan Anda menggunakan Google-bucket (penyimpanan objek) untuk menyimpan diagram Helm.

Anda hanya memerlukan empat perintah untuk mulai menggunakannya:

1. instal pluginnya;
2. memulainya;
3. atur jalur ke bucket, yang terletak di gcp;
4. mempublikasikan grafik dengan cara standar.

Yang menarik adalah metode gcp asli akan digunakan untuk otorisasi. Anda dapat menggunakan akun layanan, akun pengembang, apa pun yang Anda inginkan. Sangat nyaman dan tidak memerlukan biaya pengoperasian. Jika Anda, seperti saya, mempromosikan filosofi opsless, maka ini akan sangat nyaman, terutama untuk tim kecil.

Alternatif

Helm bukan satu-satunya solusi manajemen layanan. Ada banyak pertanyaan tentang itu, mungkin itulah sebabnya versi ketiga muncul begitu cepat. Tentu saja ada alternatif lain.

Ini bisa berupa solusi khusus, misalnya Ksonnet atau Metaparticle. Anda dapat menggunakan alat manajemen infrastruktur klasik (Ansible, Terraform, Chef, dll.) untuk tujuan yang sama seperti yang saya bicarakan.

Akhirnya ada solusinya Kerangka Operator, yang popularitasnya semakin meningkat.

Kerangka Operator adalah alternatif Helm terbaik untuk dipertimbangkan.

Ini lebih asli pada CNCF dan Kubernetes, namun hambatan untuk masuk jauh lebih tinggi, Anda perlu memprogram lebih banyak dan mendeskripsikan manifes lebih sedikit.

Ada berbagai macam add-on, seperti Draft, Scaffold. Mereka membuat hidup lebih mudah, misalnya, menyederhanakan siklus pengiriman dan peluncuran Helm bagi pengembang untuk menerapkan lingkungan pengujian. Saya akan menyebutnya sebagai pemberdayaan.

Berikut adalah bagan visual di mana segala sesuatunya berada.

Pada sumbu x adalah tingkat kendali pribadi Anda atas apa yang terjadi, pada sumbu y adalah tingkat keaslian Kubernetes. Helm versi 2 berada di tengah-tengah. Di versi 3, tidak terlalu signifikan, namun kontrol dan tingkat keasliannya telah ditingkatkan. Solusi di level Ksonnet masih kalah bahkan dengan Helm 2. Namun, solusi tersebut layak untuk dicermati untuk mengetahui apa lagi yang ada di dunia ini. Tentu saja, manajer konfigurasi Anda akan berada di bawah kendali Anda, tetapi ini sama sekali bukan milik Kubernetes.

Kerangka Operator benar-benar asli dari Kubernetes dan memungkinkan Anda mengelolanya dengan lebih elegan dan cermat (tetapi ingat tentang level awal). Sebaliknya, ini cocok untuk aplikasi khusus dan pembuatan manajemen untuknya, daripada pemanen massal untuk mengemas aplikasi dalam jumlah besar menggunakan Helm.

Extender hanya sedikit meningkatkan kontrol, melengkapi alur kerja, atau mengambil jalan pintas pada pipeline CI/CD.

Masa depan Helm

Kabar baiknya adalah Helm 3 akan hadir, Helm 3.0.0-alpha.2 versi alpha sudah dirilis, anda bisa mencobanya. Ini cukup stabil, namun fungsinya masih terbatas.

Mengapa Anda membutuhkan Helm 3? Pertama-tama, ini adalah cerita tentang hilangnya Tiller, sebagai komponen. Ini, seperti yang sudah Anda pahami, merupakan langkah maju yang besar, karena dari sudut pandang keamanan arsitektur, semuanya disederhanakan.

Ketika Helm 2 dibuat, yaitu sekitar masa Kubernetes 1.8 atau bahkan lebih awal, banyak konsep yang belum matang. Misalnya, konsep CRD kini sedang aktif diterapkan, dan Helm akan menerapkannya menggunakan CRDuntuk menyimpan struktur. Dimungkinkan untuk hanya menggunakan bagian klien dan tidak memelihara bagian server. Oleh karena itu, gunakan perintah asli Kubernetes untuk bekerja dengan struktur dan sumber daya. Ini adalah langkah maju yang besar.

Akan muncul dukungan untuk repositori OCI asli (Inisiatif Kontainer Terbuka). Ini adalah inisiatif yang sangat besar, dan Helm terutama tertarik untuk memposting grafiknya. Misalnya, Docker Hub mendukung banyak standar OCI. Saya tidak menebak-nebak, tapi mungkin penyedia repositori Docker klasik akan mulai memberi Anda kesempatan untuk menghosting grafik Helm Anda.

Kisah kontroversial bagi saya adalah Dukungan Lua, sebagai mesin templating untuk menulis skrip. Saya bukan penggemar berat Lua, tapi ini sepenuhnya merupakan fitur opsional. Saya memeriksa ini 3 kali - tidak perlu menggunakan Lua. Oleh karena itu, mereka yang ingin dapat menggunakan Lua, mereka yang menyukai Go, bergabunglah dengan kamp besar kami dan gunakan go-tmpl untuk ini.

Akhirnya, yang pasti saya lewatkan adalah kemunculan skema dan validasi tipe data. Tidak akan ada lagi masalah dengan int atau string, tidak perlu membungkus nol dalam tanda kutip ganda. Skema JSONS akan muncul yang memungkinkan Anda menjelaskan nilai ini secara eksplisit.

Akan dikerjakan ulang secara besar-besaran model yang digerakkan oleh peristiwa. Ini telah dijelaskan secara konseptual. Lihatlah cabang Helm 3, dan Anda akan melihat berapa banyak peristiwa dan kait serta hal-hal lain yang telah ditambahkan, yang akan sangat menyederhanakan dan, di sisi lain, menambah kontrol atas proses penerapan dan reaksi terhadapnya.

Helm 3 akan lebih sederhana, aman, dan menyenangkan, bukan karena kami tidak menyukai Helm 2, tetapi karena Kubernetes menjadi lebih maju. Oleh karena itu, Helm dapat menggunakan pengembangan Kubernetes dan menciptakan manajer Kubernetes yang hebat di dalamnya.

Kabar baik lainnya adalah itu DevOpsConf Alexander Khayorov akan memberitahu Anda, apakah kontainer bisa aman? Izinkan kami mengingatkan Anda bahwa konferensi tentang integrasi proses pengembangan, pengujian, dan operasi akan diadakan di Moskow 30 September dan 1 Oktober. Anda masih bisa melakukannya hingga 20 Agustus menyampaikan laporan dan beri tahu kami pengalaman Anda dengan solusi tersebut satu dari banyak tugas pendekatan DevOps.

Ikuti pos pemeriksaan konferensi dan berita di milis и saluran telegram.

Sumber: www.habr.com