Helm Keamanan

Inti saka crita babagan manajer paket paling populer kanggo Kubernetes bisa digambarake nggunakake emoji:

• kothak iku Helm (sing paling cedhak karo release Emoji paling anyar);
• kunci - keamanan;
• wong cilik iku solusi kanggo masalah.

Nyatane, kabeh bakal dadi luwih rumit, lan critane kebak rincian teknis Carane nggawe Helm aman.

• Sedhela apa Helm yen sampeyan ora ngerti utawa lali. Masalah apa sing dirampungake lan ing ngendi lokasine ing ekosistem.
• Ayo ndeleng arsitektur Helm. Ora ana obrolan babagan keamanan lan carane nggawe alat utawa solusi sing luwih aman tanpa mangerteni arsitektur komponen kasebut.
• Ayo ngrembug komponen Helm.
• Pitakonan sing paling kobong yaiku masa depan - versi anyar Helm 3. 

Kabeh ing artikel iki ditrapake kanggo Helm 2. Versi iki lagi ing produksi lan paling kamungkinan sing lagi nggunakake, lan iku versi sing ngemot risiko keamanan.

Babagan speaker: Alexander Khayorov (alexx) wis berkembang suwene 10 taun, mbantu nambah konten Moscow Python Conf++ lan melu panitia Helm Puncak. Saiki dheweke kerja ing Chainstack minangka pimpinan pangembangan - iki minangka hibrida ing antarane manajer pangembangan lan wong sing tanggung jawab ngirim rilis pungkasan. Yaiku, dumunung ing medan perang, ing ngendi kabeh kedadeyan saka nggawe produk nganti operasi.

Chainstack minangka startup cilik sing aktif berkembang sing misi kanggo ngaktifake klien lali babagan infrastruktur lan kerumitan ngoperasikake aplikasi desentralisasi; tim pangembangan dumunung ing Singapura. Aja takon Chainstack kanggo ngedol utawa tuku cryptocurrency, nanging nawarake kanggo pirembagan bab framework blockchain perusahaan, lan padha bakal seneng njawab sampeyan.

Helm

Iki minangka manajer paket (bagan) kanggo Kubernetes. Cara paling intuisi lan universal kanggo nggawa aplikasi menyang kluster Kubernetes.

Kita, mesthi, ngomong babagan pendekatan sing luwih struktural lan industri tinimbang nggawe manifests YAML dhewe lan nulis keperluan cilik.

Helm paling apik sing saiki kasedhiya lan populer.

Kenapa Helm? Utamane amarga didhukung dening CNCF. Cloud Native minangka organisasi gedhe lan dadi perusahaan induk kanggo proyek Kubernetes, etcd, Fluentd lan liya-liyane.

Kasunyatan penting liyane yaiku Helm minangka proyek sing populer banget. Nalika aku miwiti ngomong babagan carane nggawe Helm aman ing Januari 2019, proyek kasebut duwe sewu lintang ing GitHub. Ing Mei ana 12 ewu wong.

Akeh wong sing kasengsem ing Helm, dadi sanajan sampeyan durung nggunakake, sampeyan bakal entuk manfaat saka ngerti babagan keamanane. Safety iku penting.

Tim Helm inti didhukung dening Microsoft Azure lan mulane minangka proyek sing cukup stabil, ora kaya akeh liyane. Rilis Helm 3 Alpha 2 ing pertengahan Juli nuduhake yen ana cukup akeh wong sing nggarap proyek kasebut, lan dheweke duwe kepinginan lan energi kanggo ngembangake lan nambah Helm.

Helm ngatasi sawetara masalah root manajemen aplikasi ing Kubernetes.

• Packaging aplikasi. Malah aplikasi kaya "Hello, World" ing WordPress wis kalebu sawetara layanan, lan sampeyan pengin ngemas bebarengan.
• Ngatur kerumitan sing ana karo ngatur aplikasi kasebut.
• Siklus urip sing ora mungkasi sawise aplikasi diinstal utawa disebarake. Terus urip, kudu dianyari, lan Helm mbantu karo iki lan nyoba kanggo njupuk langkah lan kawicaksanan tengen kanggo iki.

Bagging diatur kanthi cetha: ana metadata kanthi lengkap karo karya manajer paket biasa kanggo Linux, Windows utawa MacOS. Yaiku, gudang, dependensi ing macem-macem paket, informasi meta kanggo aplikasi, setelan, fitur konfigurasi, indeksasi informasi, etc. Helm ngidini sampeyan entuk lan nggunakake kabeh iki kanggo aplikasi.

Manajemen Kompleksitas. Yen sampeyan duwe akeh aplikasi saka jinis sing padha, parameterisasi dibutuhake. Cithakan teka saka iki, nanging supaya ora duwe cara dhewe nggawe cithakan, sampeyan bisa nggunakake apa Helm nawakake metu saka kothak.

Manajemen Lifecycle Aplikasi - ing mratelakake panemume, iki pitakonan paling menarik lan unresolved. Iki kok aku teka Helm bali ing dina. Kita kudu njaga siklus urip aplikasi lan pengin mindhah siklus CI/CD lan aplikasi menyang paradigma iki.

Helm ngijini sampeyan kanggo:

• ngatur penyebaran, ngenalake konsep konfigurasi lan revisi;
• kasil nindakake rollback;
• nggunakake pancingan kanggo macem-macem acara;
• nambah mriksa aplikasi tambahan lan nanggapi asil.

Kajaba iku Helm duwe "baterei" - pirang-pirang barang sing enak sing bisa kalebu ing bentuk plugin, nyederhanakake urip sampeyan. Plugin bisa ditulis kanthi mandiri, cukup terisolasi lan ora mbutuhake arsitektur sing harmonis. Yen sampeyan pengin ngleksanakake soko, aku nyaranake nindakake minangka plugin, banjur bisa uga kalebu ing hulu.

Helm adhedhasar telung konsep utama:

• Bagan Repo - katrangan lan macem-macem parameterisasi sing bisa ditrapake kanggo manifes sampeyan. 
• config - yaiku, nilai sing bakal ditrapake (teks, angka, lsp).
• release ngumpulake loro komponen ndhuwur, lan bebarengan padha nguripake menyang Release. Rilis bisa versi, saéngga entuk siklus urip sing diatur: cilik nalika instalasi lan gedhe nalika upgrade, downgrade utawa rollback.

Arsitektur helm

Diagram kasebut kanthi konsep nggambarake arsitektur tingkat dhuwur Helm.

Ayo kula ngelingake yen Helm ana hubungane karo Kubernetes. Mulane, kita ora bisa nindakake tanpa kluster Kubernetes (persegi panjang). Komponen kube-apiserver dumunung ing master. Tanpa Helm kita duwe Kubeconfig. Helm ndadekke siji binar cilik, yen sampeyan bisa nelpon iku, Helm CLI sarana, kang diinstal ing komputer, laptop, mainframe - ing apa wae.

Nanging iki ora cukup. Helm nduweni komponen server sing diarani Tiller. Iku nggambarake kapentingan Helm ing kluster; iku aplikasi ing kluster Kubernetes, kaya liyane.

Komponen sabanjure Chart Repo yaiku repositori kanthi grafik. Ana gudang resmi, lan bisa uga ana gudang pribadi saka perusahaan utawa proyek.

Interaksi

Ayo ndeleng carane komponen arsitektur sesambungan nalika pengin nginstal aplikasi nggunakake Helm.

• Kita ngomong Helm install, ngakses repositori (Chart Repo) lan entuk grafik Helm.

• Utilitas Helm (Helm CLI) sesambungan karo Kubeconfig kanggo nemtokake klompok sing kudu dikontak. 
• Sawise nampa informasi kasebut, sarana kasebut nuduhake Tiller, sing ana ing kluster kita, minangka aplikasi. 
• Tiller nelpon Kube-apiserver kanggo nindakake tumindak ing Kubernetes, nggawe sawetara obyek (layanan, pods, replika, rahasia, etc.).

Sabanjure, kita bakal complicate diagram kanggo ndeleng vektor serangan sing kabeh arsitektur Helm minangka kabèh bisa kapapar. Banjur kita bakal nyoba kanggo nglindhungi dheweke.

Vektor serangan

Titik lemah potensial pisanan yaiku API hak istimewa-pangguna. Minangka bagéan saka skema, iki minangka peretas sing entuk akses admin menyang Helm CLI.

Pangguna API sing ora duwe hak istimewa uga bisa nyebabake bebaya yen ana ing cedhak. Pangguna kasebut bakal duwe konteks sing beda, contone, bisa didandani ing siji ruang jeneng klompok ing setelan Kubeconfig.

Vektor serangan sing paling menarik bisa uga minangka proses sing manggon ing kluster ing endi wae ing cedhak Tiller lan bisa ngakses. Iki bisa dadi server web utawa layanan mikro sing ndeleng lingkungan jaringan kluster.

Varian serangan sing eksotis, nanging tambah populer, kalebu Chart Repo. Bagan sing digawe dening penulis sing ora sopan bisa ngemot sumber daya sing ora aman, lan sampeyan bakal ngrampungake kanthi nggunakake iman. Utawa bisa ngganti grafik sing diundhuh saka gudang resmi lan, contone, nggawe sumber daya ing wangun kawicaksanan lan escalate akses.

Ayo dadi nyoba kanggo fend serangan saka kabeh papat sisih iki lan tokoh metu ngendi ana masalah ing arsitektur Helm, lan ngendi, mbok menawa, ora ana.

Ayo nggedhekake diagram, nambah unsur liyane, nanging tetep kabeh komponen dhasar.

Helm CLI komunikasi karo Chart Repo, sesambungan karo Kubeconfig, lan karya ditransfer menyang kluster kanggo komponen Tiller.

Tiller diwakili dening rong obyek:

• Tiller-deploy svc, sing nyedhiyakake layanan tartamtu;
• Tiller-deploy pod (ing diagram ing salinan siji ing siji tiron), kang mbukak kabeh mbukak, kang ngakses kluster.

Protokol lan skema sing beda digunakake kanggo interaksi. Saka sudut pandang keamanan, kita paling kasengsem ing:

• Mekanisme sing Helm CLI ngakses repo grafik: protokol apa, ana otentikasi lan apa sing bisa ditindakake.
• Protokol sing Helm CLI, nggunakake kubectl, komunikasi karo Tiller. Iki minangka server RPC sing diinstal ing kluster.
• Tiller dhewe bisa diakses kanggo microservices sing manggon ing kluster lan sesambungan karo Kube-apiserver.

Ayo dirembug kabeh wilayah kasebut kanthi urut.

RBAC

Ora ana gunane ngomong babagan keamanan kanggo Helm utawa layanan liyane ing kluster kajaba RBAC diaktifake.

Iku misale jek sing iki ora Rekomendasi paling anyar, nanging aku yakin sing akeh wong isih durung ngaktifake RBAC malah ing produksi, amarga iku akeh fuss lan akeh iku kudu diatur. Nanging, aku ngajak sampeyan nindakake iki.

https://rbac.dev/ — pengacara situs web kanggo RBAC. Isine jumlah ageng saka bahan menarik sing bakal mbantu nyiyapake RBAC, nuduhake apa iku apik lan carane Sejatine manggon karo ing produksi.

Aku bakal nyoba kanggo nerangake carane Tiller lan RBAC bisa. Tiller dianggo nang kluster ing akun layanan tartamtu. Biasane, yen RBAC ora dikonfigurasi, iki bakal dadi pangguna super. Ing konfigurasi dhasar, Tiller bakal dadi admin. Mulane asring diarani Tiller minangka trowongan SSH menyang kluster sampeyan. Nyatane, iki bener, supaya sampeyan bisa nggunakake akun layanan khusus sing kapisah tinimbang Akun Layanan Default ing diagram ing ndhuwur.

Nalika sampeyan miwiti Helm lan nginstal ing server kanggo pisanan, sampeyan bisa nyetel akun layanan nggunakake --service-account. Iki bakal ngidini sampeyan nggunakake pangguna kanthi set hak minimal sing dibutuhake. Bener, sampeyan kudu nggawe "garland" kasebut: Role lan RoleBinding.

Sayange, Helm ora bakal nindakake iki kanggo sampeyan. Sampeyan utawa administrator kluster Kubernetes kudu nyiapake sakumpulan Peran lan RoleBindings kanggo akun layanan luwih dhisik supaya bisa ngliwati Helm.

Pitakonan muncul - apa bedane Role lan ClusterRole? Bentenane yaiku ClusterRole bisa digunakake kanggo kabeh ruang jeneng, ora kaya Peran lan RoleBindings biasa, sing mung bisa digunakake kanggo ruang jeneng khusus. Sampeyan bisa ngatur kawicaksanan kanggo kabeh kluster lan kabeh namespaces, utawa pribadi kanggo saben namespace individu.

Perlu dicathet yen RBAC ngrampungake masalah gedhe liyane. Akeh wong sambat yen Helm, sayangé, ora multitenancy (ora ndhukung multitenancy). Yen sawetara tim nganggo kluster lan nggunakake Helm, Sejatine mokal kanggo nyiyapake kawicaksanan lan matesi akses ing kluster iki, amarga ana akun layanan tartamtu kang Helm mlaku, lan nggawe kabeh sumber daya ing kluster saka ngisor. , sing kadhangkala ora trep banget. Iki bener - kaya file binar dhewe, kaya proses, Helm Tiller ora duwe konsep multitenancy.

Nanging, ana cara sing apik sing ngidini sampeyan mbukak Tiller kaping pirang-pirang ing kluster. Ora ana masalah karo iki, Tiller bisa diluncurake ing saben papan jeneng. Mangkono, sampeyan bisa nggunakake RBAC, Kubeconfig minangka konteks, lan matesi akses menyang Helm khusus.

Bakal katon kaya iki.

Contone, ana loro Kubeconfigs karo konteks kanggo tim beda (rong namespaces): X Team kanggo tim pangembangan lan klompok admin. Kluster admin duwe Tiller sing amba dhewe, sing ana ing ruang jeneng sistem Kube, akun layanan sing cocog. Lan papan jeneng sing kapisah kanggo tim pangembangan, dheweke bakal bisa nyebarake layanan menyang ruang jeneng khusus.

Iki minangka pendekatan sing bisa ditindakake, Tiller ora keluwen kekuwatan sing bakal mengaruhi anggaran sampeyan. Iki minangka salah sawijining solusi cepet.

Bebas bae kanggo ngatur Tiller dhewe lan nyedhiyani Kubeconfig karo konteks kanggo tim, kanggo pangembang tartamtu utawa kanggo lingkungan: Dev, Staging, Produksi (iku mamang sing kabeh bakal ing kluster padha, Nanging, iki bisa rampung).

Nerusake crita, ayo ngalih saka RBAC lan ngomong babagan ConfigMaps.

ConfigMaps

Helm nggunakake ConfigMaps minangka nyimpen data. Nalika kita ngomong babagan arsitektur, ora ana database ing ngendi wae sing bakal nyimpen informasi babagan rilis, konfigurasi, rollbacks, etc. ConfigMaps digunakake kanggo iki.

Masalah utama karo ConfigMaps dikenal - padha ora aman ing asas; ora bisa nyimpen data sensitif. Kita ngomong babagan kabeh sing ora kudu ngluwihi layanan, contone, sandhi. Cara paling asli kanggo Helm saiki yaiku ngalih saka nggunakake ConfigMaps menyang rahasia.

Iki rampung banget prasaja. Override setelan Tiller lan nemtokake manawa panyimpenan bakal dadi rahasia. Banjur kanggo saben panyebaran sampeyan ora bakal nampa ConfigMap, nanging rahasia.

Sampeyan bisa mbantah manawa rahasia kasebut minangka konsep sing aneh lan ora aman. Nanging, kudu dingerteni manawa pangembang Kubernetes dhewe nindakake iki. Miwiti saka versi 1.10, i.e. Kanggo sawetara wektu saiki, bisa, paling ora ing awan umum, nyambungake panyimpenan sing bener kanggo nyimpen rahasia. Tim saiki nggarap cara kanggo nyebarake akses menyang rahasia, pod individu, utawa entitas liyane.

Iku luwih apik kanggo nransfer Storage Helm kanggo rahasia, lan padha, ing siji, wis aman tengah.

Mesthi bakal tetep watesan panyimpenan data 1 MB. Helm ing kene nggunakake etcd minangka panyimpenan sing disebarake kanggo ConfigMaps. Lan ing kana dheweke nganggep manawa iki minangka potongan data sing cocog kanggo replikasi, lsp. Ana diskusi sing menarik babagan iki ing Reddit, aku nyaranake golek maca lucu iki kanggo akhir minggu utawa maca ekstrak kene.

Repos Bagan

Bagan sing paling rawan sosial lan bisa dadi sumber "Man in the middle", utamane yen sampeyan nggunakake solusi saham. Kaping pisanan, kita ngomong babagan repositori sing kapapar liwat HTTP.

Sampeyan mesthi kudu mbukak Helm Repo liwat HTTPS - iki minangka pilihan sing paling apik lan murah.

nggatekake mekanisme teken grafik. Teknologi punika prasaja minangka neraka. Iki padha karo sing sampeyan gunakake ing GitHub, mesin PGP biasa kanthi kunci umum lan pribadi. Nyiyapake lan manawa, duwe tombol sing dibutuhake lan mlebu kabeh, yen iki pancen grafik sampeyan.

Salajengipun, Klien Helm ndhukung TLS (ora ing pangertèn HTTP sisih server, nanging TLS bebarengan). Sampeyan bisa nggunakake tombol server lan klien supaya bisa komunikasi. Jujur, aku ora nggunakake mekanisme kasebut amarga aku ora seneng sertifikat bebarengan. pokoke, chartmuseum - alat utama kanggo nyetel Helm Repo kanggo Helm 2 - uga ndhukung auth dhasar. Sampeyan bisa nggunakake auth dhasar yen luwih trep lan luwih tenang.

Ana uga plugin helm-gcs, sing ngidini sampeyan dadi tuan rumah Chart Repos ing Google Cloud Storage. Iki cukup trep, kerjane apik lan cukup aman, amarga kabeh mekanisme sing diterangake didaur ulang.

Yen sampeyan ngaktifake HTTPS utawa TLS, gunakake mTLS, lan ngaktifake auth dhasar kanggo nyuda resiko, sampeyan bakal entuk saluran komunikasi sing aman karo Helm CLI lan Chart Repo.

gRPC API

Langkah sabanjure penting banget - kanggo ngamanake Tiller, sing dumunung ing kluster lan, ing tangan siji, server, ing tangan liyane, iku dhewe ngakses komponen liyane lan nyoba kanggo ndalang dadi wong.

Kaya sing wis dakkandhakake, Tiller minangka layanan sing nyedhiyakake gRPC, klien Helm teka liwat gRPC. Kanthi gawan, mesthi, TLS dipateni. Apa iki rampung pitakonan debatable, misale jek kula kanggo menakake persiyapan ing wiwitan.

Kanggo produksi lan malah pementasan, aku nyaranake ngaktifake TLS ing gRPC.

Mratelakake panemume, ora kaya mTLS kanggo grafik, iki cocog lan ditindakake kanthi gampang - ngasilake infrastruktur PQI, nggawe sertifikat, miwiti Tiller, transfer sertifikat sajrone wiwitan. Sawise iki, sampeyan bisa nglakokake kabeh perintah Helm, nampilake sertifikat sing digawe lan kunci pribadi.

Kanthi cara iki sampeyan bakal nglindhungi dhewe saka kabeh panjalukan kanggo Tiller saka njaba kluster.

Dadi, kita wis ngamanake saluran sambungan menyang Tiller, kita wis ngrembug RBAC lan nyetel hak apiserver Kubernetes, nyuda domain sing bisa sesambungan.

Helm sing dilindhungi

Ayo katon ing diagram pungkasan. Iku arsitektur padha karo panah padha.

Kabeh sambungan saiki bisa ditarik kanthi aman nganggo warna ijo:

• kanggo Chart Repo kita nggunakake TLS utawa mTLS lan auth dhasar;
• mTLS kanggo Tiller, lan kapapar minangka layanan gRPC karo TLS, kita nggunakake sertifikat;
• kluster nggunakake akun layanan khusus karo Role lan RoleBinding. 

Kita wis ngamanake kluster kasebut kanthi signifikan, nanging ana sing pinter ujar:

"Mung ana siji solusi sing aman - komputer sing dipateni, sing ana ing kothak beton lan dijaga dening prajurit."

Ana macem-macem cara kanggo ngapusi data lan nemokake vektor serangan anyar. Nanging, aku yakin manawa rekomendasi kasebut bakal entuk standar industri dhasar kanggo safety.

Bonus

Bagian iki ora ana hubungane langsung karo keamanan, nanging uga migunani. Aku bakal nuduhake sampeyan sawetara perkara menarik sing sawetara wong ngerti. Contone, carane nggoleki grafik - resmi lan ora resmi.

Ing repositori github.com/helm/charts Saiki ana udakara 300 denah lan rong aliran: stabil lan inkubator. Sapa wae sing nyumbang ngerti banget carane angel kanggo pindhah saka inkubator menyang stabil, lan carane gampang kanggo fly metu saka stabil. Nanging, iki dudu alat sing paling apik kanggo nggoleki grafik kanggo Prometheus lan apa wae sing sampeyan senengi, kanthi alesan sing gampang - dudu portal sing bisa nelusuri paket kanthi gampang.

Nanging ana layanan hub.helm.sh, sing nggawe luwih trep kanggo nemokake grafik. Sing paling penting, ana akeh repositori eksternal lan meh 800 pesona sing kasedhiya. Kajaba iku, sampeyan bisa nyambungake repositori yen ana alesan sampeyan ora pengin ngirim grafik dadi stabil.

Coba hub.helm.sh lan ayo dikembangake bebarengan. Layanan iki ana ing sangisore proyek Helm, lan sampeyan bisa uga nyumbang kanggo UI yen sampeyan minangka pangembang ngarep lan mung pengin nambah tampilan.

Aku uga pengin narik kawigaten sampeyan Open Service Broker integrasi API. Iku muni cumbersome lan ora cetha, nanging solves masalah sing saben wong ngadhepi. Ayo kula nerangake karo conto prasaja.

Ana kluster Kubernetes ing ngendi kita pengin mbukak aplikasi klasik - WordPress. Umumé, basis data dibutuhake kanggo fungsi lengkap. Ana macem-macem solusi, contone, sampeyan bisa miwiti layanan statefull dhewe. Iki ora trep banget, nanging akeh wong sing nindakake.

Liyane, kaya kita ing Chainstack, nggunakake database sing dikelola kaya MySQL utawa PostgreSQL kanggo server. Pramila database kita ana ing endi wae ing awan.

Nanging ana masalah: kita kudu nyambungake layanan kita karo database, nggawe rasa database, nransfer kredensial lan piye wae ngatur. Kabeh iki biasane ditindakake kanthi manual dening administrator sistem utawa pangembang. Lan ora ana masalah nalika ana sawetara aplikasi. Nalika ana akeh, sampeyan kudu gabungke. Ana pemanen kuwi - iku Service Broker. Ngidini sampeyan nggunakake plugin khusus kanggo kluster awan umum lan sumber daya saka panyedhiya liwat Broker, kaya-kaya API. Kanggo nindakake iki, sampeyan bisa nggunakake alat Kubernetes asli.

Iku banget prasaja. Sampeyan bisa takon, contone, Ngatur MySQL ing Azure kanthi tingkat dhasar (iki bisa dikonfigurasi). Nggunakake API Azure, database bakal digawe lan disiapake kanggo nggunakake. Sampeyan ora perlu ngganggu iki, plugin tanggung jawab kanggo iki. Contone, OSBA (Azure plugin) bakal bali kredensial kanggo layanan lan pass menyang Helm. Sampeyan bakal bisa nggunakake WordPress nganggo MySQL awan, ora ngurus database sing dikelola lan ora kuwatir babagan layanan statefull ing njero.

Kita bisa ujar manawa Helm minangka lem sing, ing tangan siji, ngidini sampeyan nyebarake layanan, lan ing sisih liya, nggunakake sumber daya panyedhiya awan.

Sampeyan bisa nulis plugin dhewe lan nggunakake kabeh crita iki ing lokasi. Banjur sampeyan bakal duwe plugin dhewe kanggo panyedhiya Cloud perusahaan. Aku nyaranake nyoba pendekatan iki, utamane yen sampeyan duwe skala gedhe lan pengin cepet nyebarake dev, pementasan, utawa kabeh infrastruktur kanggo fitur. Iki bakal nggawe urip luwih gampang kanggo operasi utawa DevOps.

Temokake liyane sing wis dakcritakake yaiku plugin helm-gcs, sing ngidini sampeyan nggunakake Google-buckets (panyimpenan obyek) kanggo nyimpen grafik Helm.

Sampeyan mung butuh papat printah kanggo miwiti nggunakake:

1. nginstal plugin;
2. miwiti;
3. nyetel path menyang ember, sing dumunung ing gcp;
4. nerbitake grafik kanthi cara standar.

Kaendahane yaiku metode gcp asli bakal digunakake kanggo wewenang. Sampeyan bisa nggunakake akun layanan, akun pangembang, apa wae sing dikarepake. Iku trep banget lan ora ana biaya kanggo operate. Yen sampeyan, kaya aku, promosi filosofi opsless, mula iki bakal trep banget, utamane kanggo tim cilik.

Pilihan

Helm ora mung solusi manajemen layanan. Ana akeh pitakonan babagan iki, sing mbokmenawa kok versi katelu muncul kanthi cepet. Mesthi ana alternatif.

Iki bisa dadi solusi khusus, contone, Ksonnet utawa Metapartikel. Sampeyan bisa nggunakake alat manajemen infrastruktur klasik (Ansible, Terraform, Chef, etc.) kanggo tujuan sing padha karo sing dakkandhakake.

Akhire ana solusi Kerangka Operator, kang popularitas saya akeh.

Kerangka Operator minangka alternatif Helm sing paling apik kanggo dipikirake.

Iku luwih asli saka CNCF lan Kubernetes, nanging alangi kanggo mlebu luwih dhuwur, sampeyan kudu program liyane lan njlèntrèhaké manifests kurang.

Ana macem-macem addons, kayata Draft, Scaffold. Dheweke nggawe urip luwih gampang, contone, nyederhanakake siklus ngirim lan ngluncurake Helm kanggo pangembang kanggo nyebarake lingkungan tes. Aku bakal nyebut wong-wong mau pemberdayaan.

Iki minangka grafik visual babagan kabeh.

Ing sumbu-x yaiku tingkat kontrol pribadi sampeyan babagan apa sing kedadeyan, ing sumbu-y yaiku tingkat kewarganegaraan Kubernetes. Versi Helm 2 tiba nang endi wae ing tengah. Ing versi 3, ora enormously, nanging loro kontrol lan tingkat native wis apik. Solusi ing tingkat Ksonnet isih rodok olo malah kanggo Helm 2. Nanging, padha worth dipikir kanggo ngerti apa liyane ing donya iki. Mesthine, manajer konfigurasi sampeyan bakal dikontrol, nanging pancen ora asli saka Kubernetes.

Kerangka Operator pancen asli saka Kubernetes lan ngidini sampeyan ngatur kanthi luwih elegan lan teliti (nanging elinga babagan level entri). Luwih, iki cocog kanggo aplikasi khusus lan nggawe manajemen, tinimbang pemanen massal kanggo ngemas akeh aplikasi nggunakake Helm.

Extenders mung nambah kontrol sethitik, nglengkapi workflow, utawa Cut sudhut ing CI / CD pipelines.

Masa depan Helm

Kabar apik yaiku teka Helm 3. Versi alpha Helm 3.0.0-alpha.2 wis dirilis, sampeyan bisa nyoba. Iku cukup stabil, nanging fungsi isih winates.

Napa sampeyan kudu Helm 3? Kaping pisanan, iki crita babagan ilang Tiller, minangka komponen. Iki, kaya sing wis dingerteni, minangka langkah maju, amarga saka sudut pandang keamanan arsitektur, kabeh wis disederhanakake.

Nalika Helm 2 digawe, sing ana ing sekitar Kubernetes 1.8 utawa malah sadurunge, akeh konsep sing durung dewasa. Contone, konsep CRD saiki lagi aktif dileksanakake, lan Helm bakal nggunakake CRDkanggo nyimpen struktur. Sampeyan mung bisa nggunakake klien lan ora njaga bagean server. Mula, gunakake perintah Kubernetes asli kanggo nggarap struktur lan sumber daya. Iki minangka langkah maju sing gedhe.

Bakal katon dhukungan kanggo repositori OCI asli (Open Container Initiative). Iki inisiatif ageng, lan Helm kasengsem utamané kanggo ngirim denah sawijining. Dadi, contone, Docker Hub ndhukung akeh standar OCI. Aku ora ngira, nanging bisa uga panyedhiya repositori Docker klasik bakal menehi sampeyan kesempatan kanggo ngatur grafik Helm sampeyan.

Crita kontroversial kanggo aku yaiku Dhukungan Lua, minangka mesin template kanggo nulis skrip. Aku ora penggemar gedhe saka Lua, nanging iki bakal dadi fitur rampung opsional. Aku mriksa iki kaping 3 - nggunakake Lua ora perlu. Mula, sing pengin bisa nggunakake Lua, sing seneng Go, gabung karo kemah gedhe kita lan gunakake go-tmpl kanggo iki.

Pungkasane, sing mesthi aku ilang munculé skema lan validasi jinis data. Ora bakal ana maneh masalah karo int utawa senar, ora perlu kanggo mbungkus nul ing kuotasi pindho. Skema JSONS bakal katon sing ngidini sampeyan njlèntrèhaké iki kanthi jelas kanggo nilai.

Bakal akeh digarap maneh model acara-driven. Iku wis diterangake konseptual. Deleng ing Helm 3 cabang, lan sampeyan bakal weruh carane akeh acara lan pancingan lan liyane iku wis ditambahake, kang bakal nemen menakake lan, ing tangan liyane, nambah kontrol liwat pangolahan penyebaran prajurit lan reaksi kanggo wong-wong mau.

Helm 3 bakal luwih prasaja, luwih aman, lan luwih nyenengake, ora amarga kita ora seneng Helm 2, nanging amarga Kubernetes dadi luwih maju. Mula, Helm bisa nggunakake pangembangan Kubernetes lan nggawe manajer sing apik kanggo Kubernetes.

Kabar apik liyane yaiku DevOpsConf Alexander Khayorov bakal pitutur marang kowe, kontainer bisa aman? Ayo kita ngelingake yen konferensi babagan integrasi proses pembangunan, pengujian lan operasi bakal dianakake ing Moskow 30 September lan 1 Oktober. Sampeyan isih bisa nindakake nganti 20 Agustus ngirim laporan lan marang kita bab pengalaman karo solusi siji saka akeh tugas saka pendekatan DevOps.

Tindakake checkpoints konferensi lan warta ing milis и saluran telegram.

Source: www.habr.com