Helm: Scoping merilis nama ke namespaces

Saya tidak yakin apakah saya memahami Anda. Anda ingin menerapkan ke beberapa ruang nama sementara hanya memiliki satu nama rilis?

@21stio Tepat. dari dokumen Kubernetes:

Kubernetes mendukung beberapa kluster virtual yang didukung oleh kluster fisik yang sama. Cluster virtual ini disebut namespace.

dan

Namespace menyediakan ruang lingkup untuk nama. Nama sumber daya harus unik di dalam namespace, tetapi tidak di seluruh namespace.

Secara pribadi, saya tidak bisa memikirkan alasan bagus mengapa helm tidak menghormati konsep ruang nama ini.

Saya setuju. Semua ruang nama saya dalam bentuk ${site}-${environment} , tetapi rilis saya adalah ${site}-${environment}-${description} . Di mana site mungkin internal atau www dan environment mungkin dev , staging , atau team-a , team-b , dan description dapat berupa nginx , migrations , cache dll.

Tetapi ${site}-${environment} sangat berlebihan:

NAMESPACE                    NAME
www-dev                     www-dev-redis-1234567890-cj241
www-dev                     www-dev-proxy-1234567890-kfd44
www-staging                 www-staging-redis-1234567890-cj241
www-staging                 www-staging-proxy-9876543210-kfd44
internal-team-b             internal-team-b-redis-1234567890-cj241
internal-team-b             internal-team-b-nginx-1234567890-cj241

Itulah yang akhirnya saya dapatkan, tetapi saya lebih suka podnya hanya redis-1234567890.. atau proxy-9876543210..

Saya menggunakan nama rilis saya di templat bagan saya, jadi semua layanan dan nama pod saya menyertakan semua hal tambahan ini. Saya sudah memberikan namespace ke template, jadi jika saya mau, saya bisa dengan mudah memasukkannya ke dalam nama jika saya mau, tapi seperti sekarang, itu adalah bagian dari semua nama sumber daya saya dengan menggunakan perancah helm default.

Ruang nama K8 sudah menjadi ruang nama bagi kami, saya sangat tidak suka harus mengawali semua barang saya dengan ruang nama ketika ruang nama dirancang untuk membantu mencegah bentrokan.

Secara eksplisit, Akan sangat menyenangkan jika saya dapat melakukan hal yang sama seperti yang dapat saya lakukan dengan layanan dan tipe asli k8s lainnya dengan diagram kemudi yang berkaitan dengan namespace.

Misalnya, saya ingin dapat melakukan hal berikut:

helm install --namespace abc --name redis stable/redis
helm install --namespace def --name redis stable/redis

@Janpot @bcorijn Asumsi yang dibuat di atas adalah bahwa bagan Helm hanya berfungsi dengan objek yang dienkapsulasi di dalam ruang nama. Kami tidak ingin membatasi Helm hanya pada jenis sumber daya tersebut.

Bagaimana dengan Sumber Daya Pihak Ketiga, yang tidak diberi namespace? Atau RBAC, di mana "namespace" adalah atribut kebijakan, bukan lokasi (https://kubernetes.io/docs/admin/authorization/)?

Saya tahu saya telah mengatakannya beberapa kali di tempat lain, tetapi tujuan utama kami adalah memungkinkan untuk menyebarkan sumber daya ke beberapa ruang nama dari bagan yang sama. (Kasus penggunaan: Aplikasi memiliki bidang kontrol dan bidang data, dan Anda ingin menerapkannya masing-masing ke dalam ruang nama terpisah untuk membuat batas keamanan)

Jika kita mengikat rilis ke namespace, kita kehilangan kemampuan untuk:

1. Kelola ruang nama secara langsung
2. Kelola RBAC dan akun layanan
3. Kelola TPR (dan objek non-namespace lainnya)
4. Akhirnya mendukung bagan multi-namespace.

Saya mengerti bahwa ini membuat masalah penamaan sedikit lebih sulit bagi Anda, tetapi ini memungkinkan Helm untuk beroperasi pada sumber daya Kubernetes yang jauh lebih luas.

apakah mungkin untuk mendukung rilis dengan namespace dan non-namespace?

@technosophos jadi untuk meringkas ada dua driver utama:
1) Mengelola sumber daya yang tidak diberi namespace
2) Rencana masa depan yang memungkinkan bagan dipasang di seluruh namespace

Saya mengerti maksud Anda, tetapi saya tidak yakin apakah itu alasan untuk tetap berpegang pada implementasi saat ini, karena saya memiliki kesan Anda juga perlu sedikit memaksanya untuk mengatasi masalah ini?

Agar bagan multi-namespace berfungsi dengan baik/asli, kemungkinan besar Anda memerlukan perombakan besar pada sistem namespace, karena konsep Helm saat ini yang memasukkan rilis ke dalam namespace tidak akan berfungsi? _EDIT: Baru sadar jika rilis sebenarnya memiliki namespace, bagan multi-namespace bisa saja menjadi bagan payung yang berisi dua rilis dengan namespace yang berbeda?_

Untuk mengelola sumber daya non-namespace; Saya tidak memiliki pengalaman pribadi dengannya sehingga agak sulit untuk menilai, tetapi sekali lagi saya merasa ini memaksa Helm menjadi cara kerja yang kurang sempurna saat ini, karena Rilis yang mengelola ruang nama, RBAC atau TPR akan memiliki ruang nama tapi abaikan saja?
Saya mungkin kehilangan sesuatu karena tidak memiliki pengalaman dengan mereka, tetapi tidak akan melingkupi nama dan mengabaikan namespace memiliki hasil akhir yang sama, itu hanya akan memberi lebih banyak tanggung jawab pada pengguna untuk memverifikasi bahwa nama rilis dan penyeleksinya adalah benar/unik ketika berhadapan dengan sumber daya ini. (yang saya setuju adalah tanggung jawab yang cukup besar)

Jadi mungkin hanya pelingkupan rilis bukanlah cara yang harus dilakukan, tetapi melihat lagi cara mereka ditangani di Helm dan akan ditangani di masa depan layak dilakukan? Memiliki kedua opsi seperti yang disebutkan @Janpot dapat berfungsi, rilis "global" dan rilis dengan namespace?
Pendapat _sangat pribadi_ saya juga adalah bahwa penerapan dengan cara @kylebyerly-hp, @chancez dan saya jelaskan di atas jauh lebih umum daripada dua kasus penggunaan yang mencegah cara kerja ini.

Pertama, izinkan saya mengulangi poin utama: Bagan helm beroperasi pada tingkat global, bukan pada tingkat ruang nama. Jadi nama mereka unik secara global.

Untuk bagan multi-namespace, yang perlu kita perbaiki adalah kemampuan Tiller untuk melakukan kueri di seluruh namespace. (Anda sebenarnya dapat _memasang_ bagan multi-namespace sekarang. Anda hanya tidak dapat meningkatkan atau menghapusnya dengan andal, karena Tiller tidak dapat mengkuerinya dengan andal).

Untuk item yang tidak diberi namespace, semuanya akan menjadi sangat rumit. Kami akan memiliki rilis namespace yang mengelola hal-hal yang tidak memiliki namespace yang, pada gilirannya, dapat memengaruhi ruang nama lainnya. Silakan lihat bagaimana RBAC dan TPR bekerja. Ini bukan hal-hal yang Helm bisa putuskan untuk tidak mendukung, dan "memalsukan" namespace akan menyebabkan lebih banyak masalah daripada nilainya, terutama dengan RBAC.

Saya masih belum melihat alasan yang baik untuk namespace nama rilis. Keluhan awal Anda didasarkan pada kesalahpahaman bahwa semua (penting) di Kubernetes tercakup dalam namespace. Tetapi hal-hal penting seperti TPR dan RBAC tidak. Sebagian besar keluhan lain tampaknya lebih tentang fakta bahwa skema penamaan _ad hoc_ yang mereka gunakan "tidak cantik" dengan Helm. Mengatasinya dengan membuat perubahan besar yang melanggar kompatibilitas yang salah mengartikan rilis sebagai "dalam namespace" sepertinya merupakan pendekatan yang salah untuk diambil.

@technosophos

Anda benar-benar dapat menginstal grafik multi-namespace sekarang

Bagaimana? Di mana gagasan tentang ruang nama harus dimasukkan ke dalam konfigurasi?

Apakah Anda berencana untuk secara resmi mendukung rilis multi-namespace?

Kami tidak berencana untuk sepenuhnya mendukung rilis multi-namespace sampai Helm 3.0 karena hal itu akan merusak kompatibilitas ke belakang dan memerlukan refactor utama sebagian besar kode Kubernetes Helm/Tiller.

Sayangnya bagi kami tidak dapat menyebarkan & mengelola beberapa ruang nama menggunakan helm adalah pemecah kesepakatan.

Rencana kami adalah membuat bagan payung, yang akan memiliki semua aplikasi kami (misalnya bagan yang lebih kecil) sebagai dependensi. Semua aplikasi kami hidup di ruang nama mereka sendiri, ini dirancang (di masa depan kami ingin memiliki RBAC per ruang nama). Dengan bagan payung, kami dapat menginstal & meningkatkan seluruh cluster layanan mikro yang berbeda sekaligus, hanya dengan satu values.yml , yang akan sangat nyaman.

@technosophos , terima kasih. Tercatat pada fakta bahwa dukungan untuk hal di atas tidak akan segera tiba, setidaknya sampai Helm 3.0.

Apakah ada gagasan umum tentang apa yang sebenarnya perlu difaktorkan ulang di Helm/Tiller untuk mendukung banyak ruang nama? Atau 3.0 itu terlalu jauh?

Kami terpaksa memperlakukan helm name sebagai lebih dari UUID, menggunakan --name-template dan membiarkannya menghasilkan nama yang sederhana namun acak. Saya tidak bisa mengatakan saya lebih suka ini daripada menghormati namespace itu sendiri tetapi saya melihat kedua poin dan bagi kami ini akan cukup dengan sedikit overhead.

misalnya https://github.com/kubernetes/helm/pull/1015#issuecomment -237309305

> helm install --namespace www-dev --name-template "{{randAlpha 6 | lower}}" stable/redis

> kubectl --namespace www-dev get pods
NAME                                    READY     STATUS    RESTARTS   AGE
uvtiwh-redis-4101942544-qdvtw           1/1       Running   0          14m

> helm list --namespace www-dev
NAME    REVISION        UPDATED    STATUS          CHART                   NAMESPACE
uvtiwh  1               ...        DEPLOYED        redis-0.8.0             www-dev

@icereval bagaimana Anda akan menemukan nama untuk redis (uvtiwh) di aplikasi Anda untuk menghubungkannya?

Pola yang saya pertimbangkan untuk digunakan dalam cluster kami adalah:

• Satu instance Tiller di kube-system , untuk digunakan oleh admin cluster
• Satu instance Tiller per namespace, dengan izin RBAC yang lebih terbatas, untuk digunakan oleh tim pengembang yang memiliki namespace tersebut

Prinsip desain "Nama rilis helm unik secara global" membuat pusing penerapan multitenant lunak seperti kami, jadi saya tertarik untuk mendengar lebih banyak tentang pendekatan yang direkomendasikan!

Saya sangat kecewa ketika mengetahui bahwa Helm tidak mematuhi konsep mengidentifikasi rilis berdasarkan nama dan namespace mereka. Menurut pendapat saya, ini tidak mengikuti prinsip desain Kubernetes di mana sumber daya unik dalam namespace masing-masing (dengan pengecualian beberapa sumber daya global).

Seperti yang telah dikomentari oleh poster lain di utas ini, kami memiliki beberapa ruang nama dengan sufiks lingkungan untuk berbagai grup aplikasi. Kami memiliki ratusan penerapan berbeda masing-masing dalam tiga atau empat lingkungan. Kami sangat bergantung pada nama DNS unik dalam ruang nama sehingga kami dapat merujuk ke layanan dengan nama yang sama dalam ruang nama yang berbeda; misalnya. layanan redis kami dapat diakses melalui tcp://redis di kedua namespace a-test dan a-prod , di mana kedua namespace memiliki versi redis yang disebarkan.

Menargetkan ini sebagai titik diskusi untuk helm 3. Tampaknya ada sejumlah besar permintaan untuk ini.

Poin yang berlawanan:

Hampir semua pohon bagan kami menyebarkan artefak di beberapa ruang nama yang dibagi di sepanjang garis kegigihan / API / Level7 ALB(+statis). Dari sudut pandang itu CINTA fakta bahwa nama rilis helm bersifat global.

Ditemukan adanya opsi --namespace di helm semi-useless dari sudut pandang perakitan aplikasi berlapis-lapis, di mana lapisan dasar dapat digunakan kembali oleh lapisan atas yang dikerahkan merah/biru. Alih-alih menyuntikkan {{ .Release.Name }} -string yang diturunkan ke dalam nama artefak, kami membuat namespace baru untuk setiap penerapan. Ini memungkinkan kita untuk menyebarkan URL layanan yang dibentuk secara deterministik melalui konfigurasi berantai ( same_service_name.some_product_release20171102a.svc.cluster.local > same_service_name.some_product_release20171105c.svc.cluster.local ).

Karena nama rilis yang dibuat secara otomatis adalah gobbledygook - tidak ada kesetiaan tentang apa yang ada di balik hal itu di helm list , kami mengganti --name dengan string yang berasal dari nama produk/stack dan rilis yang meningkat secara monoton / versi build ( "appname-v20171103xyz" ) Akan senang jika dapat menentukan nilai --name-template di suatu tempat di bagan dan gunakan saja Nama bagan + turunan datetime atau nilai ID build eksplisit.

Contoh

Lapisan persistensi dasar

apiVersion: v1
kind: Service
metadata:
  name: redis
  namespace: {{ .Values.global.product }}-persistence-{{ .Values.global.tier }}
  labels:
    app: redis
    chart: "{{ .Chart.Name }}-{{ .Chart.Version }}"
    release: "{{ .Release.Name }}"
    heritage: "{{ .Release.Service }}"
...

Dikonsumsi dari namespace lain seperti:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: {{ .Values.global.product }}
  namespace: {{ .Release.Name }}
  labels:
    app: {{ .Values.global.product }}
    chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
spec:
...
          env:
            - name: REDIS_SERVER_HOSTNAME
----->      value: "redis.{{ .Values.global.product }}-persistence-{{ .Values.global.tier }}.svc.cluster.local"

2 template di atas adalah bagian dari 2 bagan terpisah (bagan persistensi dan bagan API) dan dapat dijalankan secara terpisah atau bersama-sama melalui bagan menyeluruh ke-3. Dalam kedua kasus, karena penggunaan .global. , nilainya ditimpa sekali pada baris perintah dan diterapkan dengan bersih ke semua sub-bagan.

Dengan pendekatan ini, karena nilai namespace tujuan terkadang merupakan turunan parsial dari ReleaseName dan terkadang semi-tetap, kami cukup mengandalkan ReleaseName untuk menjadi global sehingga sistem akan mengeluh jika kami mencoba membuat tumpukan dengan ReleaseName global yang sama.

Salah satu manfaat memiliki dan menggunakan namespace adalah nama objek (termasuk nama DNS) di dalamnya bersifat lokal dan tidak harus berubah dari namespace ke namespace. Khususnya dalam contoh @dvdotsenko di atas, REDIS_SERVER_HOSTNAME harus sama (misalnya, hanya redis ) dan tidak perlu disuntikkan dengan nilai global. Alasannya adalah menghindari pengulangan.

Dari sudut pandang kesederhanaan (dan mengesampingkan beberapa kasus yang kompleks secara alami, seperti penyebaran multi-namespace dan objek non-namespace), kasus yang ideal adalah namespace "merakit" tumpukan Anda dan berisi tepat satu instance aplikasi Anda.

Ini memungkinkan nama dalam tumpukan menjadi lokal, sederhana dan, yang paling penting, diperbaiki karena relatif namespace.

Pendekatan yang mungkin adalah untuk helm untuk mendukung kasus sederhana kurang lebih seperti yang dilakukan hari ini (sambil menghindari objek awalan dengan namespace); ini akan menghasilkan standar praktik terbaik yang masuk akal dan aman yang akan bekerja di luar kotak untuk sebagian besar penggunaan. Hal ini juga dapat memiliki modus namespace canggih yang akan memungkinkan lebih banyak kebebasan (dengan mengorbankan kompleksitas), untuk memungkinkan kasus penggunaan @dvdotsenko dan @bcorijn menjelaskan.

$0,02 saya

Saya harus setuju dengan @pnickolov , ini adalah penghalang utama bagi kami. Dalam kasus penggunaan kami, kami memiliki lebih dari 150 lingkungan, dan beberapa cluster, yang harus menjalankan varian dari tumpukan aplikasi yang sama. Namespaces memecahkan masalah ini memungkinkan pemisahan lingkungan dan kesederhanaan konfigurasi, terutama yang berkaitan dengan penemuan layanan.

Tanpa cara mudah untuk mengonfigurasi titik akhir layanan di bagan saudara... Murni melalui nilai...

Saya menemukan ini membingungkan juga. Seperti yang ditulis @technosophos :

Rilis tidak terikat ke namespace. (Itulah mengapa rilis itu sendiri dapat berisi definisi namespace). Faktanya, seharusnya mungkin (meskipun saya tidak bisa mengatakan bahwa saya telah mencoba secara pribadi) untuk menggunakan satu bagan yang membuat banyak objek di beberapa ruang nama.

Saya berjuang untuk memahami hal ini dengan tepat. Saya telah melihat dokumentasi dan saya telah melihat beberapa masalah di sini di GH dan saya masih bingung:

• Di satu sisi, saya dapat menggunakan helm install --namespace untuk menentukan namespace yang ingin saya targetkan
• Di sisi lain, bagan saya dapat menentukan ruang nama apa pun yang diinginkannya di dalam objek metadatanya.

Jadi, pertanyaan saya:

• Jika namespace yang ditentukan oleh helm install --namespace tidak ada, apakah Helm membuatnya? Apakah kemudian mengatur namespace itu pada semua sumber daya yang dibuatnya dari chrt?
• Jika templat sumber daya menentukan ruang nama dalam metadatanya, apakah helm menimpanya?

Pertanyaan-pertanyaan ini membuat saya ragu untuk bermain dengan --namespace , sangat tidak jelas. Jika ada yang bisa membantu saya memahaminya, saya akan sangat menghargainya. Terima kasih!

f namespace yang ditentukan oleh helm install --namespace tidak ada, apakah Helm membuatnya?

Ya. Jika namespace belum ada, --namespace membuat namespace yang ditentukan untuk bagan.

Jika templat sumber daya menentukan ruang nama dalam metadatanya, apakah helm menimpanya?

Tidak. Jika Anda memberikan namespace yang sama di --namespace serta sumber Namespace di bagan, akan ada konflik karena namespace akan pertama kali diinstal oleh tiller, dan kemudian bork saat bagan mencoba instal ulang namespace yang sama lagi.

Untuk konteks lebih lanjut, ide untuk helm adalah menginstal semua sumber daya di namespace yang disediakan oleh helm install --namespace . Pengguna yang "mengkodekan keras" namespace di bagan biasanya ingin memasang bagan di beberapa ruang nama.

Ini sedikit di luar topik dari apa yang disarankan OP, tetapi silakan buka tiket baru atau bergabunglah dengan kami di Slack jika Anda memiliki pertanyaan lebih lanjut! :)

Tidak yakin saya ingin mengarungi diskusi ini Mohon berbaik hati 🙏

Parameter helm --namespace benar-benar --default-namespace

Membaca tumpukan dan terkait tampaknya ada banyak kebingungan di sekitar opsi --namespace karena orang (cukup masuk akal) menganggap itu seperti kubectl --namespace mereka lakukan, yang secara efektif membatasi aktivitas ke namespace itu (oleh efek samping dari kesalahan penguraian, bukan keamanan sebenarnya). Itu tidak berlaku untuk helm karena tiller adalah layanan cluster yang beroperasi di seluruh cluster. Opsi akan lebih baik bernama --default-namespace , yaitu. ini adalah namespace yang akan digunakan sumber daya Anda jika mereka tidak menentukan namespace tertentu.

Rilis multi-namespace juga diperlukan

Saya sudah mengandalkan bagan yang menyebarkan komponen berbeda dari setiap rilis ke beberapa ruang nama, dan saya menantikan dukungan yang ditingkatkan di helm 3.0. 👍

Multi-tenant dengan batasan helm dan namespace sudah dimungkinkan

Saya juga melihat kasus penggunaan di mana orang menginginkan instalasi multi-penyewa, terbatas namespace. Pelingkupan IMHO atau membatasi rilis ke ruang nama bukanlah sesuatu yang helm / tiller harus memperhatikan penegakannya, itu adalah tugas RBAC. Setidaknya ada dua model untuk mencapai ini, satu mungkin sekarang:

1. Deploy per-namespace tiller dengan Service Account dan RBAC yang hanya mengizinkan operasi di namespace tersebut. Ini berfungsi sekarang dan saya melihat orang menggunakannya. Ideal untuk cluster multi-penyewa.
2. Untuk tiller untuk mendukung peniruan identitas pengguna k8s , jadi gunakan setiap rilis sebagai helm user . Ini sedang dibahas untuk versi helm , dan tampaknya memiliki beberapa tantangan implementasi. Tapi ini akan memungkinkan layanan cluster tiller untuk menegakkan pembatasan namespace RBAC, sementara masih mendukung rilis multi-namespace-spanning.

Sumber daya dengan nama yang sama untuk rilis yang berbeda di ruang nama yang berbeda sudah dimungkinkan

Untuk orang yang ingin memasang bagan yang sama ke dalam ruang nama yang berbeda tetapi dengan nama sumber daya yang sama (misalnya redis). Itu sangat mungkin, itu tergantung bagaimana Anda menulis template bagan Anda. Anda tidak perlu mengawali nama sumber daya dengan nama rilis, itu hanya default/konvensi yang diikuti banyak bagan. Bagan terbaru sudah memiliki nilai .fullnameOverride yang memungkinkan Anda mengubah awalan nama rilis. Anda dapat menerapkan redis sebagai redis dengan setiap helm install jika Anda mau.

Kami berada dalam situasi yang sama dengan @gmile dan kami ingin tahu apa praktik terbaik untuk melakukannya. Aplikasi inti kami, ingestion-service memiliki ketergantungan pada kafka yang pada gilirannya memiliki ketergantungan pada zookeeper . Tapi, kami ingin ketiganya di ruang nama mereka sendiri tetapi ingin mengelola melalui satu helm install . Kami berencana untuk menambahkan kafka di requirements.yaml dari ingestion-service . Tetapi mendapatkan kafka di namespacenya sendiri tidak terlihat mudah dengan helm jadi yang kami lakukan adalah menghapus dari requirements.yaml dan memiliki helm install untuk kedua penerapan .

Sekedar FYI bahwa ini dicatat dan bagian dari proposal Helm 3 yang tercantum di bawah Bagian 3: Manajemen Negara . Umpan balik selamat datang!

Itu fantastis @bacongobbler berita 😄🎉

@bacongobbler Apakah Helm 3 mencari dukungan untuk menentukan ruang nama terpisah untuk bagan dependen di requirements.yaml seperti yang dijelaskan @prat0318 ?

Dari proposal doc (coba baca! :senyum:):

$ helm install -n foo bar --namespace=dynamite
# installs release, releaseVersion, and un-namespaced charts into dynamite namespace.

Seperti Helm 2, jika sumber daya secara eksplisit mendeklarasikan namespacenya sendiri (misalnya dengan metadata.namespace=something), maka Helm akan menginstalnya ke dalam namespace tersebut. Tetapi karena referensi pemilik tidak memiliki ruang nama, sumber daya semacam itu pada dasarnya akan menjadi tidak terkelola.

@bacongobbler Saya membacanya, tetapi saya masih tidak melihatnya mendukungnya. Maksud saya bukan metadata.namespace yang di-hardcode dalam bagan yang saya kendalikan, itu selalu didukung. Maksud saya adalah menentukan namespace untuk bagan pihak ketiga yang tidak dapat saya edit. Sebagai contoh, di requirements.yaml saya, saya bergantung pada stable/kubernetes-dashboard dan ingin menginstalnya ke dalam sistem kube, tetapi bagan saya untuk masuk ke namespace pengembangan.

Masalah menjadi basi setelah 90 hari tidak aktif.
Tandai masalah sebagai baru dengan /remove-lifecycle stale .
Masalah basi membusuk setelah 30 hari tambahan tidak aktif dan akhirnya ditutup.

Jika masalah ini aman untuk ditutup sekarang, silakan lakukan dengan /close .

Kirim umpan balik ke sig-testing, kubernetes/test-infra dan/atau fejta .
/siklus hidup basi

Tampaknya permintaan fitur ini dapat dipenuhi oleh helmfile . Dari apa yang ada di readme, seharusnya dimungkinkan untuk menentukan rilis berbeda yang dicakup ke ruang nama mereka sendiri.

@gmile Saya 99% yakin pengelola helmfile belum memperbaiki masalah khusus ini di helmfile. Jika Anda mendeklarasikan dua rilis bernama vault dengan ruang nama berbeda di helmfile.yaml Anda dan menjalankan helmfile sync , itu akan gagal karena nama rilis vault diklaim oleh rilis pertama.

penafian: Saya belum menguji ini menggunakan helmfile, jadi saya ingin diberi tahu bahwa saya salah. 😄

Untuk berjaga-jaga jika komentar terakhir terlewatkan, kami menangani ini di Helm 3 dengan perubahan cara Helm menangani releases . :)

@steven-sheehy masalah khusus itu mungkin bisa diperbaiki melalui model kotak pasir dengan memperluas subchart untuk disebarkan ke namespace tertentu daripada yang ditentukan.

/hapus siklus hidup basi

Terkait: https://discuss.kubernetes.io/t/timeline-for-helm-3/2776

Diimplementasikan di Helm 3. Mengubah konteks namespace mengacu pada instance yang berbeda sama sekali.

><> ./bin/helm version
version.BuildInfo{Version:"v3.0+unreleased", GitCommit:"5eb48f4471ac3aa9a3c87a07ee6f9e5bbc60a0e1", GitTreeState:"clean"}
><> ./bin/helm list --all-namespaces
NAME            REVISION    UPDATED                                 STATUS      CHART               NAMESPACE
chartmuseum     1           2019-02-08 08:56:29.566393188 -0800 PST deployed    chartmuseum-1.9.0   default  
chartmuseum     1           2019-02-08 09:14:01.978866327 -0800 PST deployed    chartmuseum-1.9.0   foo

Berita bagus @bacongobbler

Dengan adanya perubahan ini, apakah masuk akal jika kolom namespace dipindahkan ke kolom pertama dalam output list . Sehingga dua kolom pertama secara unik mengidentifikasi rilis?

Pengurutan default bisa berdasarkan namespace dan rilis, sehingga rilis dalam namespace yang sama dikelompokkan bersama, misalnya semua rilis kube-system akan digabungkan.

Tentu.

untuk saat ini, saya hanya menggunakan

helm install --name <namespace>-<name> ...

Ya, cara kerja saat ini memang menyebalkan, tetapi, yang Anda butuhkan hanyalah nama unik global untuk dikelola, dan tidak ada alasan Anda tidak bisa membuat kunci majemuk untuk nama rilis.

Ok jadi sepertinya ada 3 skenario mendasar (dengan potensi berbagai permutasi yang masing-masing bercampur):

1. bagan namespace tunggal.
2. sumber daya yang tidak dapat diberi nama.
3. bagan multi-namespace.

Apakah ini akan menjadi pendekatan yang masuk akal untuk mengatasi skenario yang berbeda:

1. menyuntikkan/mengganti namespace ketika disertakan dengan flag --namespace .
2. sama dengan 1 tetapi abaikan namespace untuk sumber daya yang tidak memiliki namespace.
3. keluar dengan mengutip sumber daya "tidak dapat mengganti multi-namespace" atau yang serupa.

Selain: Saya tidak menggunakan tiller, lebih memilih helm template jadi tidak yakin seberapa besar perubahan tantangannya.

@technosophos

Saya mencoba memahami bagaimana Helm v2 berinteraksi dengan ruang nama dan bagaimana v3 akan berbeda, dan salah satu komentar lama Anda di utas ini membingungkan saya:

Pertama, izinkan saya mengulangi poin utama: Bagan helm beroperasi pada tingkat global, bukan pada tingkat ruang nama. Jadi nama mereka unik secara global.

....

Untuk item yang tidak diberi namespace, semuanya akan menjadi sangat rumit. Kami akan memiliki rilis namespace yang mengelola hal-hal yang tidak memiliki namespace yang, pada gilirannya, dapat memengaruhi ruang nama lainnya. Silakan lihat bagaimana RBAC dan TPR bekerja. Ini bukan hal-hal yang Helm bisa putuskan untuk tidak mendukung, dan "memalsukan" namespace akan menyebabkan lebih banyak masalah daripada nilainya, terutama dengan RBAC.

Kedengarannya seperti rilis yang disebarkan dari Helm v3 sebenarnya akan diberi namespace; Apakah itu benar? Apakah Anda tahu bagaimana masalah RBAC telah diselesaikan? Satu-satunya resolusi yang dapat saya pikirkan yang akan menghindari masalah yang Anda tunjukkan adalah untuk grafik Helm v3 tidak mendukung modifikasi objek RBAC, tetapi saya belum menemukan apa pun di berbagai posting blog dan semacamnya tentang v3 yang menunjukkan apakah grafik v3 akan mendukung pengelolaan objek RBAC atau tidak.

Yang kami butuhkan hanyalah kami dapat menggunakan parameter namespace dan
nama parameter sebagai kunci majemuk untuk mengidentifikasi rilis daripada pembubuhan
namespace ke nama.

Saya belum membaca proposal untuk helm v3, tetapi hal yang masuk akal untuk dilakukan adalah
mengadopsi pola pemilih yang sudah digunakan k8s dan tidak perlu
mendukung bidang tertentu.

Pada Selasa, 25 Juni 2019, 11:01 BatmanAoD [email protected] menulis:

@technosophos https://github.com/technosophos

Saya mencoba memahami bagaimana Helm v2 berinteraksi dengan ruang nama dan bagaimana v3
akan berbeda, dan salah satu komentar lama Anda di utas ini membingungkan saya:

Pertama, izinkan saya mengulangi poin utama: Bagan helm beroperasi pada global
level, bukan pada level namespace. Jadi nama mereka unik secara global....

Untuk item yang tidak diberi namespace, semuanya akan menjadi sangat rumit. Kami akan
rilis namespaced mengelola hal-hal un-namespaced yang, pada gilirannya, bisa
mempengaruhi namespace lainnya. Silakan lihat bagaimana RBAC dan TPR bekerja.
Ini bukan hal-hal yang Helm bisa putuskan untuk tidak mendukungnya, dan
"memalsukan" namespace akan menyebabkan lebih banyak masalah daripada nilainya, terutama
dengan RBAC.

Kedengarannya seperti rilis yang disebarkan dari Helm v3 sebenarnya akan diberi namespace;
Apakah itu benar? Apakah Anda tahu bagaimana masalah RBAC telah diselesaikan? Satu-satunya
resolusi yang dapat saya pikirkan itu akan menghindari masalah yang Anda tunjukkan untuk
Bagan helm v3 tidak mendukung modifikasi objek RBAC, tetapi saya belum menemukannya
apa pun di berbagai posting blog dan semacamnya tentang v3 yang menunjukkan apakah v3
grafik akan mendukung pengelolaan objek RBAC atau tidak.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/helm/helm/issues/2060?email_source=notifications&email_token=AACFHREXHFSKFSB7FXQ5VPTP4JMP3A5CNFSM4DCII7X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVX3issuesGOZDYRC-50PW55Z3
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AACFHRH2JPXPKMX23WVQLCDP4JMP3ANCNFSM4DCII7XQ
.

@BatmanAoD @gyndick Di Helm v3, bagan dipasang dalam konteks pengguna. Ini berarti itu diinstal di ruang nama pengguna itu dan akan menggunakan RBAC pengguna. Nama rilis juga berdasarkan namespace.

Anda dapat mencobanya dengan rilis Alpha.1: https://github.com/helm/helm/releases/tag/v3.0.0-alpha.1 atau membangun dari cabang dev-v3 .

Saya tidak akan menggunakan helm v3. Setiap tim operasi memiliki perbedaan
kendala dan cara melakukan sesuatu. Alat operasional harus sederhana,
utilitas tujuan tunggal yaitu filosofi Unix yang kompatibel.

Skrip, logika, dll saya hidup di luar manajer paket saya.

TLDR;

Aspek terpenting agar filosofi Unix kompatibel adalah
kemampuan untuk menyediakan pintu keluar di antara langkah-langkah.

Memiliki alur kerja otomatis yang panjang yang menangani logistik dari
cradle to grave luar biasa, sampai rusak. Jika pengguna tidak diberikan
kemampuan untuk secara manual melakukan setiap langkah aliran yang dibutuhkan, otomatisasi
menjadi kotak Pandora.

Kompleksitas yang diusulkan untuk v3 akan mengundang banyak kesalahan dan keburukan
desain dari orang-orang yang tidak memiliki manfaat dari 25 tahun pengalaman.

Kompleksitas tambahan hanya akan membuat segalanya lebih sulit untuk dilakukan karena selalu,
alat operasional yang menjadi lingkungan pengembangannya sendiri
memperlambat triase.

Contoh sempurna adalah ketika seseorang mengkodifikasi menjadi satu besar, mengerikan
naskah tertulis. Pemadaman terjadi dan bagian dari skrip perlu dijalankan,
bagian lain harus benar-benar dihindari, namun bagian itu merupakan bagian integral dari
logika utama. Apa yang kamu lakukan? Duduk di sana dengan panik mencoba
untuk refactor kode yang Anda tidak benar-benar memiliki cara debugging yang baik.

Pikirkan tentang semua alat yang digunakan untuk mendukung ekosistem
mengembangkan dan mengoperasikan perangkat lunak dalam bahasa tertentu. Kamu bukan
akan dapat menyediakan itu untuk helm untuk beberapa waktu.

Jadi, tetap bertanggung jawab tentang cara mengelola migrasi antar versi
perangkat lunak dengan orang-orang yang mengembangkan perangkat lunak yang digunakan.

Manajer paket harus sederhana dan ringan hanya dengan beberapa
tanggung jawab.

1. Kirim artefak
2. Hapus artefak
3. Jalankan skrip yang disediakan di artefak
4. Pantau artefak yang menurutnya dikirimkan
5. Yang terpenting, KISS

Ada lagi yang meminta rasa sakit. Terus terang, helm v2 hampir sempurna
jika itu hanya memperbaiki cara melacak rilis.

Pada Wed, 26 Jun 2019 01:31 Martin Hickey [email protected]
menulis:

@BatmanAoD https://github.com/BatmanAoD @gyndick Di Helm v3, grafiknya
diinstal dalam konteks pengguna. Ini berarti sudah terpasang di pengguna itu
namespace dan akan menggunakan RBAC pengguna. Nama rilis ada di a
dasar namespace juga.

Anda dapat mencobanya dengan rilis Alpha.1:
https://github.com/helm/helm/releases/tag/v3.0.0-alpha.1 atau buat dari
cabang dev-v3.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/helm/helm/issues/2060?email_source=notifications&email_token=AACFHREUTX77SJCPWZLQKATP4MSNRA5CNFSM4DCII7X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXH3JKTDN5W76
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AACFHRCAQLWUYHH6RJSUYF3P4MSNRANCNFSM4DCII7XQ
.

@hickeyma Terima kasih atas jawabannya! Saya sebenarnya tidak terlalu bertanya-tanya tentang bagaimana operasi Helm akan dikontrol aksesnya (meskipun itu masalah terkait) seperti apakah Helm itu sendiri masih dapat melakukan operasi global seperti membuat ClusterRoles di v3.

@BatmanAoD Itu seharusnya berfungsi karena mereka adalah sumber daya