Keamanan Helm

Inti dari cerita tentang pengelola paket paling populer untuk Kubernetes dapat diwakili dengan bantuan emoji:

• kotaknya adalah Helm (ini adalah yang paling cocok yang ada di rilis terbaru Emoji);
• kunci - keamanan;
• manusia adalah solusi untuk masalah tersebut.

Faktanya, semuanya akan sedikit lebih rumit, dan ceritanya penuh dengan rincian teknis tentang cara membuat Helm aman .

• Secara singkat, apa itu Helm jika Anda tidak tahu atau lupa. Masalah apa yang dipecahkan dan di mana letaknya di ekosistem.
• Pertimbangkan arsitektur Helm. Tidak ada satu percakapan tentang keamanan dan bagaimana membuat alat atau solusi lebih aman dapat dilakukan tanpa memahami arsitektur komponen.
• Mari kita bahas komponen Helm.
• Masalah paling membara adalah masa depan - versi baru dari Helm 3.

Segala sesuatu dalam artikel ini berkaitan dengan Helm 2. Versi ini sekarang dalam produksi dan kemungkinan besar Anda yang menggunakannya sekarang, dan di sanalah ada risiko keamanan.


Tentang pembicara: Alexander Khayorov ( allexx ) telah berkembang selama 10 tahun, membantu meningkatkan konten Moscow Python Conf ++, dan bergabung dengan komite Helm Summit . Saat ini bekerja di Chainstack dalam posisi pemimpin pengembangan - ini adalah hibrida antara manajer pengembangan dan orang yang bertanggung jawab atas pengiriman rilis final. Artinya, terletak di situs permusuhan, di mana semuanya terjadi dari penciptaan produk hingga operasinya.

Chainstack adalah startup kecil yang tumbuh aktif, yang tugasnya adalah untuk memberikan pelanggan kesempatan untuk melupakan infrastruktur dan kesulitan mengoperasikan aplikasi terdesentralisasi, tim pengembangan berlokasi di Singapura. Jangan meminta Chainstack untuk menjual atau membeli cryptocurrency, tetapi tawarkan untuk berbicara tentang kerangka kerja blockchain perusahaan, dan mereka akan dengan senang hati menjawab Anda.

Helm

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



Ini, tentu saja, adalah tentang pendekatan yang lebih struktural dan industri daripada membuat manifestasi YAML Anda sendiri dan menulis utilitas kecil.

Helm adalah yang terbaik yang tersedia dan populer saat ini.

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

Fakta penting lainnya, Helm adalah proyek yang sangat populer. Ketika pada Januari 2019 saya hanya berencana untuk berbicara tentang cara membuat Helm aman, proyek ini memiliki seribu bintang di GitHub. Pada Mei ada 12 ribu dari mereka.

Banyak orang tertarik pada Helm, oleh karena itu, bahkan jika Anda masih tidak menggunakannya, Anda akan membutuhkan pengetahuan tentang keamanannya. Keamanan itu penting.

Tim inti Helm didukung oleh Microsoft Azure, dan oleh karena itu ini adalah proyek yang cukup stabil tidak seperti yang lain. Rilis Helm 3 Alpha 2 pada pertengahan Juli menunjukkan bahwa cukup banyak orang yang mengerjakan proyek ini, dan mereka memiliki keinginan dan kekuatan untuk mengembangkan dan meningkatkan Helm.



Helm memecahkan beberapa masalah manajemen aplikasi root di Kubernetes.

• Kemasan aplikasi. Bahkan aplikasi seperti "Hello, World" di WordPress sudah terdiri dari beberapa layanan, dan saya ingin mengemasnya bersama.
• Pengelolaan kompleksitas yang muncul dengan pengelolaan aplikasi ini.
• Siklus hidup yang tidak berakhir setelah instalasi atau penyebaran aplikasi. Itu terus hidup, perlu diperbarui, dan Helm membantu dalam hal ini dan berusaha untuk membawa langkah-langkah dan kebijakan yang tepat untuk ini.

Pengemasan diatur dengan cara yang dapat dimengerti: ada metadata sesuai sepenuhnya dengan pekerjaan manajer paket reguler untuk Linux, Windows atau MacOS. Yaitu, repositori, tergantung pada berbagai paket, meta-informasi untuk aplikasi, pengaturan, fitur konfigurasi, pengindeksan informasi, dll. Semua Helm ini memungkinkan Anda untuk mendapatkan dan menggunakan untuk aplikasi.

Manajemen kompleksitas . Jika Anda memiliki banyak aplikasi serupa, maka Anda perlu parameterisasi. Templat mengikuti dari ini, tetapi agar tidak muncul dengan cara Anda sendiri membuat templat, Anda dapat menggunakan apa yang ditawarkan Helm di luar kotak.

Manajemen siklus hidup aplikasi - menurut pendapat saya, ini adalah masalah yang paling menarik dan belum terselesaikan. Inilah sebabnya saya datang ke Helm tepat waktu. Kami perlu memantau siklus hidup aplikasi, kami ingin mentransfer CI / CD dan siklus aplikasi ke paradigma ini.

Helm memungkinkan Anda untuk:

• mengelola penyebaran, memperkenalkan konsep konfigurasi dan revisi;
• berhasil mengembalikan;
• gunakan kait untuk acara yang berbeda;
• Tambahkan cek aplikasi tambahan dan tanggapi hasilnya.

Selain itu , Helm memiliki "baterai" - sejumlah besar hal lezat yang dapat dimasukkan dalam bentuk plug-in, menyederhanakan hidup Anda. Plugin dapat ditulis secara independen, mereka cukup terisolasi dan tidak memerlukan arsitektur yang ramping. Jika Anda ingin mengimplementasikan sesuatu, saya sarankan melakukannya sebagai plugin, dan kemudian dimungkinkan untuk memasukkannya ke dalam upstream.

Helm didasarkan pada tiga konsep utama:

• Repo Bagan - deskripsi dan berbagai parameterisasi yang mungkin untuk manifes Anda.
• Konfigurasi - yaitu , nilai-nilai yang akan diterapkan (teks, nilai numerik, dll.).
• Rilis menyatukan dua komponen teratas, dan bersama-sama mereka berubah menjadi Rilis. Rilis dapat versi, sehingga mencapai organisasi siklus hidup: kecil pada saat instalasi dan besar pada saat upgrade, downgrade atau rollback.

Arsitektur Helm

Diagram secara konseptual mencerminkan arsitektur Helm tingkat tinggi.



Biarkan saya mengingatkan Anda bahwa Helm adalah sesuatu yang terhubung dengan Kubernetes. Karena itu, kita tidak bisa melakukannya tanpa Kubernetes-cluster (persegi panjang). Komponen kubus-apiserver ada di wisaya. Tanpa Helm, kami memiliki Kubeconfig. Helm membawa satu biner kecil, sehingga bisa dikatakan, utilitas Helm CLI, yang diinstal pada komputer, laptop, mainframe - untuk apa pun.

Tetapi ini tidak cukup. Helm memiliki komponen server Tiller. Ia mewakili kepentingan Helm di dalam sebuah cluster, itu adalah aplikasi yang sama dalam sebuah cluster Kubernetes, seperti yang lainnya.

Komponen berikutnya dari Grafik Repo adalah repositori grafik. Ada repositori resmi, dan mungkin ada repositori pribadi perusahaan atau proyek.

Interaksi

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

• Kami mengatakan Helm install , pergi ke repositori (Grafik Repo) dan dapatkan grafik Helm.

• Helm Utility (Helm CLI) berinteraksi dengan Kubeconfig untuk mencari tahu cluster mana yang harus dihubungi.
• Setelah menerima informasi ini, utilitas beralih ke Tiller, yang ada di cluster kami, sudah sebagai aplikasi.
• Tiller beralih ke Kube-apiserver untuk melakukan tindakan di Kubernetes, untuk membuat beberapa objek (layanan, pod, replika, rahasia, dll.).

Lebih lanjut, kami akan memperumit skema untuk melihat vektor serangan yang dapat digunakan oleh seluruh arsitektur Helm secara keseluruhan. Dan kemudian kita akan mencoba melindunginya.

Serang Vektor

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

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

Vektor serangan yang paling menarik mungkin adalah proses yang terletak di dalam cluster di suatu tempat dekat Tiller dan dapat mengaksesnya. Ini bisa berupa server web atau microservice yang melihat lingkungan jaringan cluster.

Opsi serangan yang eksotis namun populer, dikaitkan dengan Chart Repo. Bagan yang dibuat oleh penulis yang tidak bermoral mungkin mengandung sumber daya yang tidak aman, dan Anda akan mengeksekusinya, dengan keyakinan. Atau dapat mengganti grafik yang Anda unduh dari repositori resmi, dan, misalnya, membuat sumber daya dalam bentuk kebijakan dan meningkatkan akses Anda.



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

Mari memperbesar skema, menambahkan lebih banyak elemen, tetapi simpan semua komponen dasar.



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

Anakan diwakili oleh dua objek:

• Tiller-deploy svc, yang memaparkan layanan tertentu;
• Pod Tiller-deploy (pada diagram dalam satu salinan dalam satu replika), yang menjalankan seluruh beban yang mengakses cluster.

Untuk interaksi, berbagai protokol dan skema digunakan. Dari sudut pandang keamanan, kami paling tertarik pada:

• Mekanisme dimana Helm CLI mengakses grafik repo: protokol apa, apakah ada otentikasi dan apa yang dapat dilakukan tentang hal itu.
• Protokol yang digunakan Helm CLI, menggunakan kubectl, berkomunikasi dengan Tiller. Ini adalah server RPC yang diinstal di dalam cluster.
• Tiller sendiri tersedia untuk layanan microser yang ada di cluster dan berinteraksi dengan Kube-apiserver.

Kami akan membahas semua petunjuk ini secara berurutan.

RBAC

Tidak ada gunanya berbicara tentang keamanan Helm atau layanan lain di dalam kluster jika RBAC tidak diaktifkan.

Tampaknya ini bukan rekomendasi baru sendiri, tetapi saya yakin bahwa sejauh ini banyak yang belum memasukkan RBAC bahkan dalam produksi, karena ini banyak rewel dan Anda perlu mengkonfigurasi banyak hal. Namun demikian, saya mendesak ini untuk dilakukan.



https://rbac.dev/ adalah situs pengacara untuk RBAC. Itu mengumpulkan sejumlah besar bahan menarik yang akan membantu mengatur RBAC, menunjukkan mengapa itu baik dan bagaimana hidup dengannya secara prinsip dalam produksi.

Saya akan mencoba menjelaskan cara kerja Tiller dan RBAC. Tiller bekerja di dalam sebuah cluster di bawah akun layanan tertentu. Biasanya, jika RBAC tidak dikonfigurasi, ini akan menjadi superuser. Dalam konfigurasi dasar, Tiller akan menjadi admin. Itulah sebabnya sering dikatakan bahwa Anakan adalah terowongan SSH ke kluster Anda. Ini sebenarnya masalahnya, sehingga Anda dapat menggunakan akun layanan khusus yang terpisah alih-alih Akun Layanan Default pada diagram di atas.

Ketika Anda menginisialisasi Helm, instal terlebih dahulu di server, Anda dapat mengatur akun layanan menggunakan --service-account . Ini akan memungkinkan Anda untuk menggunakan pengguna dengan seperangkat hak minimum yang diperlukan. Benar, Anda harus membuat "karangan bunga" seperti itu: Peran dan RoleBinding.



Sayangnya, Helm tidak akan melakukan ini untuk Anda. Anda atau administrator kluster Kubernetes Anda perlu menyiapkan satu set Peran, Peran untuk akun layanan terlebih dahulu untuk mentransfer Helm.

Pertanyaannya adalah - apa perbedaan antara Peran dan ClusterRole? Perbedaannya adalah bahwa ClusterRole berlaku untuk semua ruang nama, tidak seperti Peran reguler dan RoleBinding, yang hanya berfungsi untuk ruang nama khusus. Anda dapat mengonfigurasi kebijakan untuk seluruh cluster dan semua ruang nama, serta dipersonalisasi untuk setiap ruang nama secara terpisah.

Perlu disebutkan bahwa RBAC memecahkan masalah besar lainnya. Banyak yang mengeluh bahwa Helm, sayangnya, bukan multitenancy (tidak mendukung multi-tenancy). Jika beberapa tim mengkonsumsi sebuah cluster dan menggunakan Helm, pada prinsipnya tidak mungkin untuk mengkonfigurasi kebijakan dan untuk membedakan akses mereka dalam cluster ini, karena ada beberapa akun layanan di mana Helm bekerja, dan itu menciptakan semua sumber daya dalam cluster dari bawahnya, yang terkadang sangat tidak nyaman. Ini benar - sebagai biner itu sendiri, sebagai suatu proses, Helm Tiller tidak memiliki petunjuk tentang multitenancy .

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

Ini akan terlihat sebagai berikut.



Misalnya, ada dua Kubeconfig dengan konteks untuk tim yang berbeda (dua namespace): Tim X untuk tim pengembangan dan admin cluster. Cluster admin memiliki anakan lebar sendiri, yang terletak di namespace sistem Kube, masing-masing akun layanan canggih. Dan namespace terpisah untuk tim pengembangan, mereka akan dapat menggunakan layanan mereka dalam namespace khusus.

Ini adalah pendekatan yang berhasil, Tiller tidak terlalu rakus sehingga bisa sangat mempengaruhi anggaran Anda. Ini adalah salah satu perbaikan cepat.

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

Melanjutkan kisah kami, beralih dari RBAC dan berbicara tentang ConfigMaps.

Configmaps

Helm menggunakan ConfigMaps sebagai gudang data. Ketika kita berbicara tentang arsitektur, tidak ada database di mana informasi tentang rilis, konfigurasi, kembalikan, dll disimpan. Untuk ini, ConfigMaps digunakan.

Masalah utama dengan ConfigMaps diketahui - mereka pada prinsipnya tidak aman, tidak mungkin untuk menyimpan data sensitif di dalamnya. Kami berbicara tentang segala sesuatu yang tidak boleh melampaui layanan, misalnya, kata sandi. Cara paling asli untuk Helm sekarang adalah beralih dari menggunakan ConfigMaps ke rahasia.

Ini dilakukan dengan sangat sederhana. Tetapkan ulang pengaturan Tiller dan tentukan bahwa penyimpanan akan menjadi rahasia. Kemudian untuk setiap penyebaran Anda tidak akan menerima ConfigMap, tetapi sebuah rahasia.



Anda mungkin berpendapat bahwa rahasia itu sendiri adalah konsep yang aneh, dan itu tidak terlalu aman. Namun, perlu dipahami bahwa para pengembang Kubernet melakukan ini. Mulai dari versi 1.10, mis. cukup lama, ada kemungkinan, setidaknya di awan publik, untuk menghubungkan penyimpanan yang benar untuk menyimpan rahasia. Sekarang tim bekerja lebih baik dalam membagikan akses ke rahasia, pengiriman individu atau entitas lainnya.

Storage Helm lebih baik diterjemahkan menjadi rahasia, dan mereka, pada gilirannya, aman terpusat.

Tentu saja, akan tetap ada batas untuk penyimpanan data sebesar 1 MB . Helm di sini menggunakan etcd sebagai repositori didistribusikan untuk ConfigMaps. Dan di sana mereka mengira itu adalah potongan data yang cocok untuk replikasi, dll. Ada diskusi yang menarik tentang Reddit tentang ini, saya sarankan mencari bahan bacaan yang menyenangkan ini untuk akhir pekan atau membaca perasan di sini .

Bagan repo

Grafik adalah yang paling rentan secara sosial dan dapat menjadi sumber "Manusia di tengah", terutama jika Anda menggunakan solusi stok. Pertama-tama, kita berbicara tentang repositori yang diekspos melalui HTTP.

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

Perhatikan mekanisme tanda tangan grafik . Teknologi ini sederhana untuk dipermalukan. Ini adalah hal yang sama yang Anda gunakan pada GitHub, mesin PGP biasa dengan kunci publik dan pribadi. Atur dan pastikan, memiliki kunci yang diperlukan dan menandatangani semuanya, ini benar-benar bagan Anda.

Selain itu, klien Helm mendukung TLS (bukan dalam arti HTTP dari sisi server, tetapi TLS bersama). Anda dapat menggunakan kunci server dan klien untuk berkomunikasi. Terus terang, saya tidak menggunakan mekanisme seperti itu karena tidak suka untuk sertifikat bersama. Pada prinsipnya, chartmuseum - alat utama paparan Helm Repo untuk Helm 2 - juga mendukung auth dasar. Anda dapat menggunakan auth dasar jika lebih nyaman dan lebih tenang.

Ada juga plugin helm-gcs yang memungkinkan Anda meng-host Repos Chart di Google Cloud Storage. Ini cukup nyaman, berfungsi dengan baik dan cukup aman, karena semua mekanisme yang dijelaskan digunakan.



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

API gRPC

Langkah selanjutnya sangat bertanggung jawab - untuk mengamankan Tiller, yang ada di cluster dan, di satu sisi, server, di sisi lain, mengakses komponen lain dan mencoba memperkenalkan diri sebagai seseorang.

Seperti yang saya katakan, Tiller adalah layanan yang mengekspos gRPC, klien Helm datang ke sana melalui gRPC. Secara default, tentu saja, TLS tidak aktif. Mengapa ini dilakukan adalah pertanyaan yang bisa diperdebatkan, menurut saya untuk menyederhanakan pengaturan di awal.

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

Menurut pendapat saya, tidak seperti mTLS untuk grafik, ini sesuai di sini dan dilakukan dengan sangat sederhana - menghasilkan infrastruktur PQI, membuat sertifikat, meluncurkan Tiller, mentransfer sertifikat selama inisialisasi. Setelah itu, Anda dapat menjalankan semua perintah Helm, yang tampaknya merupakan sertifikat dan kunci pribadi yang dihasilkan.



Dengan demikian, Anda akan melindungi diri dari semua permintaan untuk Anakan dari luar cluster.

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

Helm yang Dilindungi

Mari kita lihat diagram terakhir. Ini adalah arsitektur yang sama dengan panah yang sama.



Semua koneksi sekarang dapat dicat dengan aman dalam warna hijau:

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

Kami telah mengamankan cluster, tetapi seseorang yang pintar mengatakan:

"Hanya ada satu solusi yang benar-benar aman - komputer dimatikan, yang ada 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 memungkinkan penerapan standar keselamatan industri dasar.

Bonus

Bagian ini tidak terkait langsung dengan keamanan, tetapi juga bermanfaat. Saya akan menunjukkan kepada Anda beberapa hal menarik yang sedikit orang ketahui. Misalnya, cara mencari grafik - resmi dan tidak resmi.

Repositori github.com/helm/charts sekarang memiliki sekitar 300 grafik dan dua aliran: stabil dan inkubator. Kontributor tahu betapa sulitnya untuk beralih dari inkubator ke kandang, dan betapa mudahnya terbang keluar dari kandang. Namun, ini bukan alat terbaik untuk mencari bagan untuk Prometheus dan semua yang Anda suka karena satu alasan sederhana bukanlah portal tempat yang nyaman untuk mencari paket.

Tetapi ada layanan hub.helm.sh yang dengannya jauh lebih nyaman untuk menemukan grafik. Yang paling penting, ada lebih banyak repositori eksternal dan hampir 800 karakter tersedia. Plus, 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 dalam UI-nya jika Anda adalah vendor front-end dan hanya ingin meningkatkan tampilannya.

Saya juga ingin menarik perhatian Anda pada integrasi API Broker Layanan Terbuka . Kedengarannya rumit dan tidak bisa dipahami, tetapi ini memecahkan masalah yang dihadapi semua orang. Saya akan jelaskan dengan contoh sederhana.



Ada Kubernetes-cluster di mana kami ingin menjalankan aplikasi klasik - WordPress. Sebagai aturan, sebuah database diperlukan untuk fungsionalitas penuh. Ada banyak solusi berbeda, misalnya, Anda dapat memulai layanan statefull Anda. Ini sangat tidak nyaman, tetapi banyak yang melakukannya.

Yang lain, seperti kami di Chainstack, menggunakan database yang dikelola, seperti MySQL atau PostgreSQL, untuk server. Oleh karena itu, basis data kami terletak di suatu tempat di awan.

Tetapi muncul masalah: Anda perlu menghubungkan layanan kami dengan database, membuat database rasa, lulus kredensial dan entah bagaimana mengelolanya. Semua ini biasanya dilakukan secara manual oleh administrator sistem atau pengembang. Dan tidak ada masalah ketika ada beberapa aplikasi. Ketika ada banyak, Anda perlu kombinasi. Ada semacam gabungan - ini adalah Broker Layanan. Ini memungkinkan Anda untuk menggunakan plug-in khusus ke cloud cluster publik dan memesan sumber daya dari penyedia melalui Broker, seolah-olah itu adalah API. Anda dapat menggunakan alat Kubernetes asli untuk ini.

Ini sangat sederhana. Anda dapat meminta, misalnya, MySQL yang Dikelola di Azure dengan tingkat dasar (ini dapat dikustomisasi). Menggunakan Azure API, basis akan dibuat dan disiapkan untuk digunakan. Anda tidak perlu mengganggu ini, plugin bertanggung jawab untuk ini. Misalnya, OSBA (plugin Azure) akan mengembalikan kredensial ke layanan, meneruskannya ke Helm. Anda dapat menggunakan WordPress dengan MySQL yang keruh, tidak berurusan dengan database yang dikelola sama sekali, dan jangan khawatir tentang layanan statefull di dalamnya.

Kita dapat mengatakan bahwa Helm bertindak sebagai lem, yang di satu sisi memungkinkan Anda untuk menyebarkan layanan, dan di sisi lain, ia menghabiskan sumber daya penyedia cloud.

Anda dapat menulis plugin sendiri dan menggunakan seluruh cerita di tempat ini. Maka Anda hanya memiliki plugin Anda sendiri untuk penyedia Cloud perusahaan. Saya menyarankan Anda untuk mencoba pendekatan ini, terutama jika Anda memiliki skala besar dan Anda ingin cepat menggunakan dev, staging atau seluruh infrastruktur untuk fitur. Ini akan membuat hidup Anda lebih mudah untuk operasi atau DevOps Anda.

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



Hanya dibutuhkan empat perintah untuk mulai menggunakannya:

1. instal plugin;
2. memulai itu;
3. setel path ke bucket, yang terletak di gcp;
4. menerbitkan bagan dengan cara standar.

Keindahannya adalah bahwa metode gcp asli untuk otorisasi akan digunakan. Anda dapat menggunakan akun layanan, akun pengembang - apa pun. Sangat nyaman dan tidak ada biaya untuk beroperasi. Jika Anda, seperti saya, menganjurkan filosofi opsless, maka ini akan sangat nyaman, terutama untuk tim kecil.

Alternatif

Helm bukan satu-satunya solusi manajemen layanan. Ada banyak pertanyaan kepadanya, yang mungkin mengapa versi ketiga muncul begitu cepat. Tentu ada alternatifnya.

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

Akhirnya, ada solusi Operator Framework , yang popularitasnya semakin meningkat.

Kerangka Operator adalah alternatif Helm utama yang harus Anda perhatikan.

Ini lebih asli untuk CNCF dan Kubernetes, tetapi ambang entri jauh lebih tinggi , Anda perlu memprogram lebih banyak dan menggambarkan manifes kurang.

Ada berbagai addons, seperti Draft, Scaffold. Mereka sangat menyederhanakan kehidupan, misalnya, pengembang menyederhanakan siklus pengiriman dan peluncuran Helm untuk menyebarkan lingkungan pengujian. Saya akan menyebut mereka sebagai perpanjangan peluang.

Berikut ini adalah grafik visual dari mana yang berada.



Pada sumbu x, tingkat kendali pribadi Anda atas apa yang terjadi, pada sumbu y, tingkat keaslian Kubernetes. Helm versi 2 ada di suatu tempat di tengah. Dalam versi 3, ini bukan kolosal, tetapi kontrol dan tingkat keaslian ditingkatkan. Solusi tingkat Ksonnet masih lebih rendah daripada Helm 2. Namun, mereka patut dilihat untuk mengetahui apa lagi yang ada di dunia ini. Tentu saja, manajer konfigurasi Anda akan berada di bawah kendali Anda, tetapi sama sekali bukan asli Kubernetes.

Kerangka Operator benar-benar asli untuk Kubernetes dan memungkinkan Anda untuk mengelolanya jauh lebih elegan dan cermat (tapi ingat tentang tingkat entri). Sebaliknya, ini cocok untuk aplikasi khusus dan menciptakan manajemen untuk itu, daripada pemanen massal untuk mengemas sejumlah besar aplikasi menggunakan Helm.

Extender hanya meningkatkan kontrol sedikit, melengkapi alur kerja atau memotong sudut pipa CI / CD.

Masa depan Helm

Berita baiknya adalah bahwa Helm 3 muncul. Versi alpha dari Helm 3.0.0-alpha.2 telah dirilis, Anda dapat mencoba. Ini cukup stabil, tetapi fungsi masih terbatas.

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

Ketika Helm 2 dibuat, yang selama Kubernetes 1.8 atau bahkan sebelumnya, banyak konsep yang belum matang. Misalnya, konsep CRD sedang diterapkan secara aktif, dan Helm akan menggunakan CRD untuk menyimpan struktur. Ini akan mungkin untuk hanya menggunakan klien dan tidak menjaga sisi server. Dengan demikian, gunakan perintah Kubernet asli untuk bekerja dengan struktur dan sumber daya. Ini adalah langkah besar ke depan.

Dukungan untuk repositori OCI asli (Open Container Initiative) akan muncul. Ini adalah inisiatif besar, dan Helm menarik terutama untuk memposting grafiknya. Sampai pada titik di mana, misalnya, Docker Hub mendukung banyak standar OCI. Saya tidak heran, tetapi mungkin penyedia repositori Docker klasik akan mulai memberi Anda kesempatan untuk menempatkan grafik Helm mereka untuk Anda.

Kisah kontroversial bagi saya adalah dukungan Lua sebagai mesin templating untuk menulis skrip. Saya bukan penggemar berat Lua, tetapi ini akan menjadi fitur yang sepenuhnya opsional. Saya memeriksanya 3 kali - menggunakan Lua tidak perlu. Karena itu, siapa pun yang ingin dapat menggunakan Lua, seseorang yang suka Go, bergabunglah dengan kamp besar kami dan gunakan go-tmpl untuk ini.

, — . int string, . JSONS-, values.

event-driven model . . Helm 3, , , , , .

Helm 3 , , Helm 2, Kubernetes . , Helm Kubernetes Kubernetes.

Berita baik lainnya adalah bahwa di DevOpsConf Alexander Khayorov akan memberi tahu Anda apakah wadah bisa aman? Ingat, sebuah konferensi tentang integrasi pengembangan, pengujian dan proses operasi akan diadakan di Moskow pada 30 September dan 1 Oktober . Hingga 20 Agustus, Anda masih dapat mengirimkan laporan dan berbicara tentang pengalaman Anda dalam menyelesaikan salah satu dari banyak tugas pendekatan DevOps.

Ikuti pos pemeriksaan konferensi dan berita di buletin dan saluran telegram .