Keselamatan Helm

Intipati cerita tentang pengurus pakej paling popular untuk Kubernetes boleh digambarkan menggunakan emoji:

• kotak itu ialah Helm (yang merupakan perkara yang paling hampir dengan keluaran Emoji terkini);
• kunci - keselamatan;
• lelaki kecil adalah penyelesaian kepada masalah.

Malah, segala-galanya akan menjadi lebih rumit, dan ceritanya penuh dengan butiran teknikal Bagaimana untuk membuat Helm selamat.

• Secara ringkas apa itu Helm sekiranya anda tidak tahu atau terlupa. Apakah masalah yang diselesaikan dan di mana ia terletak dalam ekosistem.
• Mari kita lihat seni bina Helm. Tiada perbualan tentang keselamatan dan cara menjadikan alat atau penyelesaian lebih selamat tidak lengkap tanpa memahami seni bina komponen.
• Mari kita bincangkan komponen Helm.
• Persoalan yang paling hangat ialah masa depan - versi baharu Helm 3. 

Segala-galanya dalam artikel ini terpakai untuk Helm 2. Versi ini sedang dalam pengeluaran dan kemungkinan besar adalah versi yang sedang anda gunakan, dan versi ini mengandungi risiko keselamatan.

Mengenai pembesar suara: Alexander Khayorov (alexx) telah berkembang selama 10 tahun, membantu meningkatkan kandungan Moscow Python Conf++ dan menyertai jawatankuasa itu Kemuncak Helm. Kini dia bekerja di Chainstack sebagai peneraju pembangunan - ini adalah gabungan antara pengurus pembangunan dan orang yang bertanggungjawab untuk menyampaikan keluaran akhir. Iaitu, ia terletak di medan perang, di mana segala-galanya berlaku dari penciptaan produk hingga operasinya.

Chainstack ialah syarikat permulaan yang kecil dan sedang berkembang secara aktif yang misinya adalah untuk membolehkan pelanggan melupakan infrastruktur dan kerumitan pengendalian aplikasi terdesentralisasi; pasukan pembangunan terletak di Singapura. Jangan minta Chainstack menjual atau membeli mata wang kripto, tetapi tawarkan untuk bercakap tentang rangka kerja blockchain perusahaan, dan mereka dengan senang hati akan menjawab anda.

Helm

Ini ialah pengurus pakej (carta) untuk Kubernetes. Cara paling intuitif dan universal untuk membawa aplikasi ke gugusan Kubernetes.

Kami, sudah tentu, bercakap tentang pendekatan yang lebih berstruktur dan perindustrian daripada mencipta manifes YAML anda sendiri dan menulis utiliti kecil.

Helm adalah yang terbaik yang ada dan popular pada masa ini.

Kenapa Helm? Terutama kerana ia disokong oleh CNCF. Cloud Native ialah sebuah organisasi besar dan merupakan syarikat induk untuk projek Kubernetes, etcd, Fluentd dan lain-lain.

Satu lagi fakta penting ialah Helm adalah projek yang sangat popular. Apabila saya mula bercakap tentang cara menjadikan Helm selamat pada Januari 2019, projek itu mempunyai seribu bintang di GitHub. Menjelang Mei terdapat 12 ribu daripadanya.

Ramai orang berminat dengan Helm, jadi walaupun anda belum menggunakannya, anda akan mendapat manfaat daripada mengetahui tentang keselamatannya. Keselamatan adalah penting.

Pasukan Helm teras disokong oleh Microsoft Azure dan oleh itu merupakan projek yang agak stabil, tidak seperti yang lain. Pengeluaran Helm 3 Alpha 2 pada pertengahan bulan Julai menunjukkan bahawa terdapat ramai orang yang bekerja pada projek itu, dan mereka mempunyai keinginan dan tenaga untuk membangun dan menambah baik Helm.

Helm menyelesaikan beberapa masalah akar pengurusan aplikasi dalam Kubernetes.

• Pembungkusan aplikasi. Malah aplikasi seperti "Hello, World" di WordPress sudah terdiri daripada beberapa perkhidmatan, dan anda ingin membungkusnya bersama-sama.
• Menguruskan kerumitan yang datang dengan mengurus aplikasi ini.
• Kitaran hayat yang tidak berakhir selepas aplikasi dipasang atau digunakan. Ia terus hidup, ia perlu dikemas kini, dan Helm membantu dengan ini dan cuba membawa langkah dan dasar yang betul untuk ini.

Membonceng ia disusun dengan cara yang jelas: terdapat metadata sepenuhnya mengikut kerja pengurus pakej biasa untuk Linux, Windows atau MacOS. Iaitu, repositori, kebergantungan pada pelbagai pakej, maklumat meta untuk aplikasi, tetapan, ciri konfigurasi, pengindeksan maklumat, dll. Helm membolehkan anda mendapatkan dan menggunakan semua ini untuk aplikasi.

Pengurusan Kerumitan. Jika anda mempunyai banyak aplikasi daripada jenis yang sama, maka parameterisasi diperlukan. Templat datang daripada ini, tetapi daripada perlu menghasilkan cara anda sendiri untuk mencipta templat, anda boleh menggunakan apa yang Helm tawarkan di luar kotak.

Pengurusan Kitaran Hayat Aplikasi - pada pendapat saya, ini adalah soalan yang paling menarik dan tidak dapat diselesaikan. Inilah sebabnya saya datang ke Helm pada hari itu. Kami perlu memerhatikan kitaran hayat aplikasi dan mahu mengalihkan kitaran CI/CD dan aplikasi kami ke paradigma ini.

Helm membolehkan anda:

• menguruskan penempatan, memperkenalkan konsep konfigurasi dan semakan;
• berjaya melaksanakan rollback;
• gunakan cangkuk untuk acara yang berbeza;
• tambah semakan aplikasi tambahan dan balas keputusan mereka.

Lebih-lebih lagi Helm mempunyai "bateri" - sejumlah besar perkara lazat yang boleh disertakan dalam bentuk pemalam, memudahkan hidup anda. Pemalam boleh ditulis secara bebas, ia agak terpencil dan tidak memerlukan seni bina yang harmoni. Jika anda ingin melaksanakan sesuatu, saya syorkan melakukannya sebagai pemalam, dan kemudian mungkin memasukkannya ke huluan.

Helm adalah berdasarkan tiga konsep utama:

• Repo Carta — perihalan dan tatasusunan parameterisasi yang mungkin untuk manifes anda. 
• config —iaitu, nilai yang akan digunakan (teks, nilai angka, dll.).
• Lepaskan mengumpulkan dua komponen atas, dan bersama-sama ia bertukar menjadi Keluaran. Keluaran boleh dibuat versi, dengan itu mencapai kitaran hayat yang teratur: kecil pada masa pemasangan dan besar pada masa naik taraf, turun taraf atau rollback.

Seni bina helm

Gambar rajah secara konsep menggambarkan seni bina peringkat tinggi Helm.

Biar saya ingatkan anda bahawa Helm adalah sesuatu yang berkaitan dengan Kubernetes. Oleh itu, kita tidak boleh melakukannya tanpa gugusan Kubernetes (segi empat tepat). Komponen kube-apiserver berada pada induk. Tanpa Helm kita mempunyai Kubeconfig. Helm membawa satu binari kecil, jika anda boleh memanggilnya, utiliti Helm CLI, yang dipasang pada komputer, komputer riba, kerangka utama - pada apa-apa sahaja.

Tetapi ini tidak mencukupi. Helm mempunyai komponen pelayan yang dipanggil Tiller. Ia mewakili kepentingan Helm dalam kelompok; ia adalah aplikasi dalam kelompok Kubernetes, sama seperti yang lain.

Komponen seterusnya Carta Repo ialah repositori dengan carta. Terdapat repositori rasmi, dan mungkin terdapat repositori peribadi syarikat atau projek.

Interaksi

Mari lihat bagaimana komponen seni bina berinteraksi apabila kita ingin memasang aplikasi menggunakan Helm.

• Kita bercakap Helm install, akses repositori (Chart Repo) dan dapatkan carta Helm.

• Utiliti Helm (Helm CLI) berinteraksi dengan Kubeconfig untuk mengetahui kelompok mana yang hendak dihubungi. 
• Setelah menerima maklumat ini, utiliti merujuk kepada Tiller, yang terletak dalam kelompok kami, sebagai aplikasi. 
• Tiller memanggil Kube-apiserver untuk melakukan tindakan dalam Kubernetes, mencipta beberapa objek (perkhidmatan, pod, replika, rahsia, dll.).

Seterusnya, kami akan merumitkan gambar rajah untuk melihat vektor serangan yang keseluruhan seni bina Helm boleh didedahkan. Dan kemudian kami akan cuba melindunginya.

Vektor serangan

Titik lemah potensi pertama ialah API istimewa-pengguna. Sebagai sebahagian daripada skim ini, ini adalah penggodam yang telah mendapat akses pentadbir kepada Helm CLI.

Pengguna API yang tidak mempunyai hak istimewa juga boleh mendatangkan bahaya jika berada di suatu tempat yang berdekatan. Pengguna sedemikian akan mempunyai konteks yang berbeza, contohnya, dia boleh diperbaiki dalam satu ruang nama kelompok dalam tetapan Kubeconfig.

Vektor serangan yang paling menarik mungkin merupakan proses yang berada dalam kelompok di suatu tempat berhampiran Tiller dan boleh mengaksesnya. Ini boleh menjadi pelayan web atau perkhidmatan mikro yang melihat persekitaran rangkaian kluster.

Varian serangan yang eksotik, tetapi semakin popular, melibatkan Repo Carta. Carta yang dibuat oleh pengarang yang tidak bertanggungjawab mungkin mengandungi sumber yang tidak selamat, dan anda akan melengkapkannya dengan mengambilnya berdasarkan kepercayaan. Atau ia boleh menggantikan carta yang anda muat turun daripada repositori rasmi dan, sebagai contoh, mencipta sumber dalam bentuk dasar dan meningkatkan aksesnya.

Mari cuba menangkis serangan dari keempat-empat pihak ini dan cari tahu di mana terdapat masalah dalam seni bina Helm, dan di mana, mungkin, tidak ada.

Mari besarkan gambar rajah, tambah lebih banyak elemen, tetapi simpan semua komponen asas.

CLI Helm berkomunikasi dengan Repo Carta, berinteraksi dengan Kubeconfig, dan kerja dipindahkan ke kluster ke komponen Tiller.

Tiller diwakili oleh dua objek:

• Tiller-deploy svc, yang mendedahkan perkhidmatan tertentu;
• Tiller-deploy pod (dalam rajah dalam satu salinan dalam satu replika), di mana keseluruhan beban dijalankan, yang mengakses kluster.

Protokol dan skema yang berbeza digunakan untuk interaksi. Dari sudut keselamatan, kami paling berminat dengan:

• Mekanisme yang digunakan oleh Helm CLI mengakses repo carta: apakah protokol, adakah terdapat pengesahan dan apa yang boleh dilakukan dengannya.
• Protokol yang menggunakan Helm CLI, menggunakan kubectl, berkomunikasi dengan Tiller. Ini ialah pelayan RPC yang dipasang di dalam kluster.
• Tiller sendiri boleh diakses oleh perkhidmatan mikro yang berada dalam kelompok dan berinteraksi dengan pelayan Kube-api.

Mari kita bincangkan semua bidang ini mengikut urutan.

RBAC

Tidak ada gunanya bercakap tentang sebarang keselamatan untuk Helm atau mana-mana perkhidmatan lain dalam kelompok melainkan RBAC didayakan.

Nampaknya ini bukan cadangan terkini, tetapi saya pasti ramai yang masih belum mendayakan RBAC walaupun dalam pengeluaran, kerana ia adalah banyak kekecohan dan banyak perkara yang perlu dikonfigurasikan. Walau bagaimanapun, saya menggalakkan anda untuk melakukan ini.

https://rbac.dev/ — peguam laman web untuk RBAC. Ia mengandungi sejumlah besar bahan menarik yang akan membantu anda menyediakan RBAC, menunjukkan sebab ia bagus dan bagaimana untuk hidup dengannya dalam pengeluaran.

Saya akan cuba menerangkan cara Tiller dan RBAC berfungsi. Tiller berfungsi di dalam kelompok di bawah akaun perkhidmatan tertentu. Biasanya, jika RBAC tidak dikonfigurasikan, ini akan menjadi pengguna super. Dalam konfigurasi asas, Tiller akan menjadi pentadbir. Itulah sebabnya sering dikatakan bahawa Tiller ialah terowong SSH kepada kluster anda. Sebenarnya, ini adalah benar, jadi anda boleh menggunakan akaun perkhidmatan khusus yang berasingan dan bukannya Akaun Perkhidmatan Lalai dalam rajah di atas.

Apabila anda memulakan Helm dan memasangnya pada pelayan buat kali pertama, anda boleh menetapkan akaun perkhidmatan menggunakan --service-account. Ini akan membolehkan anda menggunakan pengguna dengan set hak minimum yang diperlukan. Benar, anda perlu mencipta "garland" sedemikian: Peranan dan Pengikat Peranan.

Malangnya, Helm tidak akan melakukan ini untuk anda. Anda atau pentadbir kluster Kubernetes anda perlu menyediakan satu set Peranan dan Pengikat Peranan untuk akaun perkhidmatan terlebih dahulu untuk lulus Helm.

Timbul persoalan - apakah perbezaan antara Role dan ClusterRole? Perbezaannya ialah ClusterRole berfungsi untuk semua ruang nama, tidak seperti RoleBindings dan RoleBinding biasa, yang hanya berfungsi untuk ruang nama khusus. Anda boleh mengkonfigurasi dasar untuk keseluruhan kluster dan semua ruang nama, atau diperibadikan untuk setiap ruang nama secara individu.

Perlu dinyatakan bahawa RBAC menyelesaikan satu lagi masalah besar. Ramai orang mengadu bahawa Helm, malangnya, bukan multitenancy (tidak menyokong multitenancy). Jika beberapa pasukan menggunakan kluster dan menggunakan Helm, pada asasnya mustahil untuk menyediakan dasar dan mengehadkan akses mereka dalam kluster ini, kerana terdapat akaun perkhidmatan tertentu di bawahnya Helm berjalan, dan ia mencipta semua sumber dalam kluster dari bawahnya , yang kadangkala sangat menyusahkan. Ini benar - seperti fail binari itu sendiri, seperti proses, Helm Tiller tidak mempunyai konsep multitenancy.

Walau bagaimanapun, terdapat cara yang hebat yang membolehkan anda menjalankan Tiller beberapa kali dalam kelompok. Tiada masalah dengan ini, Tiller boleh dilancarkan di setiap ruang nama. Oleh itu, anda boleh menggunakan RBAC, Kubeconfig sebagai konteks dan mengehadkan akses kepada Helm khas.

Ia akan kelihatan seperti ini.

Contohnya, terdapat dua Kubeconfig dengan konteks untuk pasukan yang berbeza (dua ruang nama): Pasukan X untuk pasukan pembangunan dan kelompok pentadbir. Kelompok pentadbir mempunyai Tiller lebarnya sendiri, yang terletak dalam ruang nama sistem Kube, akaun perkhidmatan lanjutan yang sepadan. Dan ruang nama yang berasingan untuk pasukan pembangunan, mereka akan dapat menggunakan perkhidmatan mereka ke ruang nama khas.

Ini adalah pendekatan yang boleh dilaksanakan, Tiller tidak terlalu haus kuasa sehingga ia akan mempengaruhi belanjawan anda. Ini adalah salah satu penyelesaian yang cepat.

Jangan ragu untuk mengkonfigurasi Tiller secara berasingan dan menyediakan Kubeconfig dengan konteks untuk pasukan, untuk pembangun tertentu atau untuk persekitaran: Pembangun, Pementasan, Pengeluaran (adalah keraguan bahawa semuanya akan berada pada kelompok yang sama, bagaimanapun, ini boleh dilakukan).

Meneruskan cerita kami, mari beralih daripada RBAC dan bercakap tentang ConfigMaps.

ConfigMaps

Helm menggunakan ConfigMaps sebagai stor datanya. Apabila kita bercakap tentang seni bina, tiada pangkalan data di mana-mana sahaja yang akan menyimpan maklumat tentang keluaran, konfigurasi, rollback, dll. ConfigMaps digunakan untuk ini.

Masalah utama dengan ConfigMaps diketahui - ia tidak selamat pada dasarnya; adalah mustahil untuk menyimpan data sensitif. Kami bercakap tentang segala-galanya yang tidak sepatutnya melampaui perkhidmatan, sebagai contoh, kata laluan. Cara paling asli untuk Helm sekarang ialah beralih daripada menggunakan ConfigMaps kepada rahsia.

Ini dilakukan dengan sangat mudah. Gantikan tetapan Tiller dan tentukan bahawa storan akan menjadi rahsia. Kemudian untuk setiap penempatan anda tidak akan menerima ConfigMap, tetapi rahsia.

Anda boleh berhujah bahawa rahsia itu sendiri adalah konsep yang pelik dan tidak begitu selamat. Walau bagaimanapun, perlu difahami bahawa pembangun Kubernetes sendiri melakukan ini. Bermula dari versi 1.10, i.e. Untuk beberapa lama sekarang, adalah mungkin, sekurang-kurangnya dalam awan awam, untuk menyambungkan storan yang betul untuk menyimpan rahsia. Pasukan kini sedang mengusahakan cara untuk mengedarkan akses kepada rahsia, pod individu atau entiti lain dengan lebih baik.

Adalah lebih baik untuk memindahkan Helm Penyimpanan kepada rahsia, dan mereka, seterusnya, diamankan secara berpusat.

Sudah tentu ia akan kekal had storan data 1 MB. Helm di sini menggunakan etcd sebagai storan teragih untuk ConfigMaps. Dan di sana mereka menganggap bahawa ini adalah bahagian data yang sesuai untuk replikasi, dsb. Terdapat perbincangan menarik tentang ini di Reddit, saya cadangkan mencari bacaan lucu ini untuk hujung minggu atau membaca ekstrak di sini.

Repos Carta

Carta adalah yang paling terdedah dari segi sosial dan boleh menjadi sumber "Man in the middle", terutamanya jika anda menggunakan penyelesaian saham. Pertama sekali, kita bercakap tentang repositori yang terdedah melalui HTTP.

Anda pastinya perlu mendedahkan Helm Repo melalui HTTPS - ini adalah pilihan terbaik dan tidak mahal.

Beri perhatian kepada mekanisme tandatangan carta. Teknologinya sangat mudah. Ini adalah perkara yang sama yang anda gunakan pada GitHub, mesin PGP biasa dengan kunci awam dan peribadi. Sediakan dan pastikan, mempunyai kunci yang diperlukan dan menandatangani segala-galanya, bahawa ini benar-benar carta anda.

Tambahan pula, Pelanggan Helm menyokong TLS (bukan dalam pengertian HTTP sebelah pelayan, tetapi TLS bersama). Anda boleh menggunakan kunci pelayan dan klien untuk berkomunikasi. Sejujurnya, saya tidak menggunakan mekanisme sedemikian kerana saya tidak suka sijil bersama. Pada asasnya, chartmuseum - alat utama untuk menyediakan Helm Repo untuk Helm 2 - turut menyokong pengesahan asas. Anda boleh menggunakan pengesahan asas jika ia lebih mudah dan lebih senyap.

Terdapat juga pemalam helm-gcs, yang membolehkan anda mengehoskan Carta Repos pada Storan Awan Google. Ini agak mudah, berfungsi dengan baik dan agak selamat, kerana semua mekanisme yang diterangkan dikitar semula.

Jika anda mendayakan HTTPS atau TLS, menggunakan mTLS dan mendayakan pengesahan asas untuk mengurangkan lagi risiko, anda akan mendapat saluran komunikasi selamat dengan Helm CLI dan Carta Repo.

API gRPC

Langkah seterusnya adalah sangat penting - untuk mengamankan Tiller, yang terletak dalam kelompok dan, dalam satu pihak, pelayan, sebaliknya, ia sendiri mengakses komponen lain dan cuba berpura-pura menjadi seseorang.

Seperti yang telah saya katakan, Tiller ialah perkhidmatan yang mendedahkan gRPC, pelanggan Helm datang kepadanya melalui gRPC. Secara lalai, sudah tentu, TLS dilumpuhkan. Mengapa ini dilakukan adalah soalan yang boleh dipertikaikan, nampaknya saya memudahkan persediaan pada mulanya.

Untuk pengeluaran dan juga pementasan, saya syorkan untuk mendayakan TLS pada gRPC.

Pada pendapat saya, tidak seperti mTLS untuk carta, ini sesuai di sini dan dilakukan dengan sangat mudah - menjana infrastruktur PQI, mencipta sijil, melancarkan Tiller, memindahkan sijil semasa permulaan. Selepas ini, anda boleh melaksanakan semua arahan Helm, mempersembahkan diri anda dengan sijil yang dijana dan kunci peribadi.

Dengan cara ini anda akan melindungi diri anda daripada semua permintaan kepada Tiller dari luar kluster.

Jadi, kami telah mendapatkan saluran sambungan ke Tiller, kami telah membincangkan RBAC dan melaraskan hak pelayan api Kubernetes, mengurangkan domain yang boleh berinteraksi dengannya.

Helm Dilindungi

Mari lihat gambarajah akhir. Ia adalah seni bina yang sama dengan anak panah yang sama.

Semua sambungan kini boleh ditarik dengan selamat dalam warna hijau:

• untuk Repo Carta kami menggunakan TLS atau mTLS dan pengesahan asas;
• mTLS untuk Tiller, dan ia didedahkan sebagai perkhidmatan gRPC dengan TLS, kami menggunakan sijil;
• kluster menggunakan akaun perkhidmatan khas dengan Role dan RoleBinding. 

Kami telah memperoleh kluster dengan ketara, tetapi seseorang yang bijak berkata:

"Hanya ada satu penyelesaian yang benar-benar selamat - komputer yang dimatikan, yang terletak di dalam kotak konkrit dan dikawal oleh tentera."

Terdapat pelbagai cara untuk memanipulasi data dan mencari vektor serangan baharu. Walau bagaimanapun, saya yakin bahawa cadangan ini akan mencapai standard industri asas untuk keselamatan.

Bonus

Bahagian ini tidak berkaitan secara langsung dengan keselamatan, tetapi juga berguna. Saya akan menunjukkan kepada anda beberapa perkara menarik yang tidak ramai orang tahu. Contohnya, cara mencari carta - rasmi dan tidak rasmi.

Dalam repositori github.com/helm/charts Kini terdapat kira-kira 300 carta dan dua aliran: stabil dan inkubator. Sesiapa yang menyumbang tahu betul betapa sukarnya untuk pergi dari inkubator ke stabil, dan betapa mudahnya untuk terbang keluar dari kandang. Walau bagaimanapun, ini bukan alat terbaik untuk mencari carta untuk Prometheus dan apa sahaja yang anda suka, atas satu sebab mudah - ia bukan portal yang membolehkan anda mencari pakej dengan mudah.

Tetapi ada perkhidmatan hub.helm.sh, yang menjadikannya lebih mudah untuk mencari carta. Paling penting, terdapat banyak lagi repositori luaran dan hampir 800 azimat tersedia. Selain itu, anda boleh menyambungkan repositori anda jika atas sebab tertentu anda tidak mahu menghantar carta anda ke stabil.

Cuba hub.helm.sh dan mari membangunkannya bersama-sama. Perkhidmatan ini berada di bawah projek Helm, dan anda juga boleh menyumbang kepada UInya jika anda seorang pembangun bahagian hadapan dan hanya mahu menambah baik penampilan.

Saya juga ingin menarik perhatian anda Penyepaduan API Broker Perkhidmatan Terbuka. Kedengarannya rumit dan tidak jelas, tetapi ia menyelesaikan masalah yang dihadapi oleh semua orang. Biar saya terangkan dengan contoh mudah.

Terdapat gugusan Kubernetes di mana kami ingin menjalankan aplikasi klasik - WordPress. Secara amnya, pangkalan data diperlukan untuk kefungsian penuh. Terdapat banyak penyelesaian yang berbeza, sebagai contoh, anda boleh melancarkan perkhidmatan statefull anda sendiri. Ini tidak begitu mudah, tetapi ramai orang melakukannya.

Orang lain, seperti kami di Chainstack, menggunakan pangkalan data terurus seperti MySQL atau PostgreSQL untuk pelayan mereka. Itulah sebabnya pangkalan data kami terletak di suatu tempat di awan.

Tetapi masalah timbul: kami perlu menyambungkan perkhidmatan kami dengan pangkalan data, mencipta rasa pangkalan data, memindahkan kelayakan dan entah bagaimana menguruskannya. Semua ini biasanya dilakukan secara manual oleh pentadbir sistem atau pembangun. Dan tiada masalah apabila terdapat sedikit aplikasi. Apabila terdapat banyak, anda memerlukan gabungan. Terdapat penuai sedemikian - ia adalah Broker Perkhidmatan. Ia membolehkan anda menggunakan pemalam khas untuk kluster awan awam dan memesan sumber daripada pembekal melalui Broker, seolah-olah ia adalah API. Untuk melakukan ini, anda boleh menggunakan alatan Kubernetes asli.

Ia sangat mudah. Anda boleh bertanya, sebagai contoh, MySQL Terurus dalam Azure dengan peringkat asas (ini boleh dikonfigurasikan). Menggunakan API Azure, pangkalan data akan dibuat dan disediakan untuk digunakan. Anda tidak perlu mengganggu ini, pemalam bertanggungjawab untuk ini. Contohnya, OSBA (pemalam Azure) akan mengembalikan bukti kelayakan kepada perkhidmatan dan menyerahkannya kepada Helm. Anda akan dapat menggunakan WordPress dengan cloud MySQL, tidak berurusan dengan pangkalan data terurus sama sekali dan tidak bimbang tentang perkhidmatan statefull di dalamnya.

Kita boleh mengatakan bahawa Helm bertindak sebagai gam yang, di satu pihak, membolehkan anda menggunakan perkhidmatan, dan di sisi lain, menggunakan sumber penyedia awan.

Anda boleh menulis pemalam anda sendiri dan menggunakan keseluruhan cerita ini di premis. Kemudian anda hanya akan mempunyai pemalam anda sendiri untuk pembekal Cloud korporat. Saya mengesyorkan mencuba pendekatan ini, terutamanya jika anda mempunyai skala yang besar dan ingin menggunakan pembangun, pementasan atau keseluruhan infrastruktur dengan cepat untuk sesuatu ciri. Ini akan menjadikan kehidupan lebih mudah untuk operasi atau DevOps anda.

Satu lagi penemuan yang telah saya nyatakan ialah pemalam helm-gcs, yang membolehkan anda menggunakan baldi Google (storan objek) untuk menyimpan carta Helm.

Anda hanya memerlukan empat arahan untuk mula menggunakannya:

1. pasang pemalam;
2. memulakannya;
3. tetapkan laluan ke baldi, yang terletak di gcp;
4. menerbitkan carta dengan cara standard.

Yang menariknya ialah kaedah gcp asli akan digunakan untuk kebenaran. Anda boleh menggunakan akaun perkhidmatan, akaun pembangun, apa sahaja yang anda mahukan. Ia sangat mudah dan tiada kos untuk beroperasi. Jika anda, seperti saya, mempromosikan falsafah opsless, maka ini akan menjadi sangat mudah, terutamanya untuk pasukan kecil.

Alternatif

Helm bukan satu-satunya penyelesaian pengurusan perkhidmatan. Terdapat banyak persoalan mengenainya, itulah sebabnya mengapa versi ketiga muncul begitu cepat. Sudah tentu ada alternatif.

Ini boleh menjadi penyelesaian khusus, contohnya, Ksonnet atau Metaparticle. Anda boleh menggunakan alatan pengurusan infrastruktur klasik anda (Ansible, Terraform, Chef, dsb.) untuk tujuan yang sama yang saya bincangkan.

Akhirnya ada penyelesaian Rangka Kerja Operator, yang popularitinya semakin meningkat.

Rangka Kerja Operator ialah alternatif Helm teratas untuk dipertimbangkan.

Ia lebih asli kepada CNCF dan Kubernetes, tetapi halangan untuk masuk jauh lebih tinggi, anda perlu memprogramkan lebih banyak dan kurang menerangkan manifes.

Terdapat pelbagai tambahan, seperti Draf, Scaffold. Mereka menjadikan hidup lebih mudah, contohnya, mereka memudahkan kitaran penghantaran dan pelancaran Helm untuk pembangun menggunakan persekitaran ujian. Saya akan memanggil mereka empowerers.

Berikut ialah carta visual di mana segala-galanya berada.

Pada paksi-x ialah tahap kawalan peribadi anda terhadap perkara yang berlaku, pada paksi-y ialah tahap keaslian Kubernetes. Helm versi 2 terletak di suatu tempat di tengah. Dalam versi 3, tidak terlalu banyak, tetapi kedua-dua kawalan dan tahap keaslian telah dipertingkatkan. Penyelesaian di peringkat Ksonnet masih lebih rendah walaupun berbanding Helm 2. Walau bagaimanapun, ia patut dilihat untuk mengetahui apa lagi yang ada di dunia ini. Sudah tentu, pengurus konfigurasi anda akan berada di bawah kawalan anda, tetapi ia sama sekali bukan asli Kubernetes.

Rangka Kerja Operator sememangnya asli dari Kubernetes dan membolehkan anda mengurusnya dengan lebih elegan dan teliti (tetapi ingat tentang peringkat kemasukan). Sebaliknya, ini sesuai untuk aplikasi khusus dan penciptaan pengurusan untuknya, bukannya penuai besar-besaran untuk membungkus sejumlah besar aplikasi menggunakan Helm.

Extenders hanya menambah baik sedikit kawalan, melengkapkan aliran kerja atau memotong sudut pada saluran paip CI/CD.

Masa depan Helm

Berita baiknya ialah Helm 3 akan datang. Versi alpha Helm 3.0.0-alpha.2 telah pun dikeluarkan, anda boleh mencubanya. Ia agak stabil, tetapi fungsi masih terhad.

Mengapa anda memerlukan Helm 3? Pertama sekali, ini adalah cerita tentang kehilangan Tiller, sebagai komponen. Ini, seperti yang anda sudah faham, adalah satu langkah besar ke hadapan, kerana dari sudut pandangan keselamatan seni bina, semuanya dipermudahkan.

Apabila Helm 2 dicipta, iaitu sekitar zaman Kubernetes 1.8 atau lebih awal, banyak konsep yang tidak matang. Sebagai contoh, konsep CRD kini sedang giat dilaksanakan, dan Helm akan melakukannya guna CRDuntuk menyimpan struktur. Anda boleh menggunakan hanya klien dan tidak mengekalkan bahagian pelayan. Sehubungan itu, gunakan arahan Kubernetes asli untuk bekerja dengan struktur dan sumber. Ini adalah satu langkah besar ke hadapan.

Akan muncul sokongan untuk repositori OCI asli (Inisiatif Kontena Terbuka). Ini adalah satu inisiatif yang besar, dan Helm berminat terutamanya untuk menyiarkan cartanya. Ia sampai pada tahap bahawa, sebagai contoh, Docker Hub menyokong banyak piawaian OCI. Saya tidak meneka, tetapi mungkin pembekal repositori Docker klasik akan mula memberi anda peluang untuk mengehoskan carta Helm anda.

Kisah kontroversi bagi saya ialah Sokongan Lua, sebagai enjin templat untuk menulis skrip. Saya bukan peminat besar Lua, tetapi ini akan menjadi ciri pilihan sepenuhnya. Saya menyemak ini 3 kali - menggunakan Lua tidak diperlukan. Oleh itu, mereka yang ingin dapat menggunakan Lua, mereka yang suka Go, sertai kem besar kami dan gunakan go-tmpl untuk ini.

Akhirnya, apa yang saya pasti hilang adalah kemunculan skema dan pengesahan jenis data. Tidak akan ada lagi masalah dengan int atau rentetan, tidak perlu membalut sifar dalam petikan berganda. Skema JSONS akan muncul yang membolehkan anda menerangkan ini secara eksplisit untuk nilai.

Akan banyak diolah semula model dipacu peristiwa. Ia telah pun diterangkan secara konsep. Lihatlah cawangan Helm 3, dan anda akan melihat berapa banyak acara dan cangkuk dan perkara lain telah ditambah, yang akan sangat memudahkan dan, sebaliknya, menambah kawalan ke atas proses penggunaan dan tindak balas kepada mereka.

Helm 3 akan menjadi lebih ringkas, selamat dan lebih menyeronokkan, bukan kerana kami tidak menyukai Helm 2, tetapi kerana Kubernetes semakin maju. Sehubungan itu, Helm boleh menggunakan perkembangan Kubernetes dan mencipta pengurus yang sangat baik untuk Kubernetes padanya.

Satu lagi berita baik ialah DevOpsConf Alexander Khayorov akan memberitahu anda, bolehkah bekas selamat? Marilah kami mengingatkan anda bahawa persidangan mengenai penyepaduan proses pembangunan, ujian dan operasi akan diadakan di Moscow 30 September dan 1 Oktober. Anda masih boleh melakukannya sehingga 20 Ogos mengemukakan laporan dan beritahu kami tentang pengalaman anda dengan penyelesaiannya satu daripada banyak tugas pendekatan DevOps.

Ikuti pusat pemeriksaan dan berita persidangan di senarai mel и saluran telegram.

Sumber: www.habr.com