Helm: スコープは名前空間に名前を解放します

私があなたを理解しているかどうかはわかりません。 リリース名を1つだけにして、複数の名前空間にデプロイしたいですか？

@ 21stioその通り。 Kubernetesドキュメントから：

Kubernetesは、同じ物理クラスターに支えられた複数の仮想クラスターをサポートします。 これらの仮想クラスターは名前空間と呼ばれます。

と

名前空間は、名前のスコープを提供します。 リソースの名前は、名前空間内で一意である必要がありますが、名前空間間で一意である必要はありません。

個人的には、helmがこの名前空間の概念を尊重しない理由は考えられません。

同意します。 私の名前空間はすべて${site}-${environment}の形式ですが、私のリリースは${site}-${environment}-${description}です。 siteがinternalまたはwwwあり、 environmentがdev 、 staging 、またはteam-a 、 team-b 、およびdescriptionは、 nginx 、 migrations 、 cacheなどのようになります。

しかし、 ${site}-${environment}は非常に冗長です。

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

私が最終的に得たものですが、ポッドはredis-1234567890..またはproxy-9876543210..だけであることが望ましいです

チャートテンプレートでリリース名を使用しているので、すべてのサービス名とポッド名にこれらすべての余分なものが含まれています。 すでに名前空間をテンプレートに渡しているので、必要に応じて名前に名前空間を簡単に含めることができますが、現在のように、デフォルトのヘルムスキャフォールディングを使用することで、すべてのリソース名の一部になっています。

K8s名前空間はすでに私たちの名前空間です。名前空間が衝突を防ぐように設計されている場合、すべてのものに名前空間のプレフィックスを付ける必要はありません。

明示的に、名前空間に関連するヘルムチャートを使用してサービスや他のk8sネイティブタイプで実行できるのと同じことができれば、本当に素晴らしいでしょう。

たとえば、次のことができるようにしたいと思います。

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

@Janpot @bcorijn上記の前提は、Helmチャートは、名前空間内にカプセル化されたオブジェクトでのみ機能するということです。 Helmをこれらのリソースの種類だけに限定することは望んでいません。

名前空間が設定されていないサードパーティのリソースについてはどうですか？ または、「名前空間」が場所ではなくポリシー属性であるRBAC（https://kubernetes.io/docs/admin/authorization/）？

他の場所で何度か言ったことは知っていますが、私たちの最終的な目標は、同じチャートから複数の名前空間にリソースをデプロイできるようにすることです。 （ユースケース：アプリにはコントロールプレーンとデータプレーンがあり、セキュリティ境界を作成するためにそれぞれを別々の名前空間にデプロイする必要があります）

リリースを名前空間にバインドすると、次の機能が失われます。

1. 名前空間を直接管理する
2. RBACとサービスアカウントを管理する
3. TPR（およびその他の名前空間のないオブジェクト）を管理する
4. 最終的に、マルチ名前空間チャートをサポートします。

これにより、名前付けの問題が少し難しくなることは理解していますが、Helmははるかに幅広いKubernetesリソースを操作できます。

名前空間付きリリースと名前空間なしリリースの両方をサポートすることは可能でしょうか？

@technosophos要約すると、2つの主要な要因があります。
1）名前空間が設定されていないリソースの管理
2）チャートを名前空間全体にインストールできるようにする将来の計画

私はあなたの主張を理解していますが、それが現在の実装に固執する理由であるかどうかはわかりません。これらの懸念に対処するために少し強制する必要があるという印象があるからです。

マルチ名前空間チャートがうまく/自然に機能するためには、リリースを名前空間に入れるHelmの現在の概念が機能しないため、名前空間システムのかなりのオーバーホールが必要になる可能性がありますか？ _EDIT：リリースが実際に名前空間化されている場合、マルチ名前空間チャートは、異なる名前空間を持つ2つのリリースを含む包括的なチャートになりますか？_

名前空間のないリソースを管理するため。 私は個人的な経験がないので判断するのは少し難しいですが、名前空間を管理するリリース、RBACまたはTPRには名前空間が含まれるため、Helmは今のところ完璧ではない作業方法になっていると思いますしかし、それを無視しますか？
経験がないために何かが足りないかもしれませんが、名前をスコーピングせず、名前空間を無視しても同じ結果になります。リリース名とセレクターがこれらのリソースを扱うときは、正しい/一意です。 （私が同意するのはかなりの責任です）

したがって、リリースをスコープするだけではうまくいかないかもしれませんが、Helmでの処理方法と、将来処理される方法をもう一度確認する価値はありますか？ @Janpotが言及しているように、「グローバル」リリースと名前空間リリースの両方のオプションが
マイ_veryのpersonal_意見は@の方法で展開することもkylebyerly馬力、@chancezであると私は、上記の多くの一般的な作業のこの方法を防ぐ2つのユースケースよりもです。

まず、要点を繰り返します。ヘルムチャートは、名前空間レベルではなく、グローバルレベルで動作します。 したがって、それらの名前はグローバルに一意です。

複数の名前空間のグラフの場合、修正する必要があるのは、名前空間間でクエリを実行するTillerの機能です。 （実際には、複数の名前空間のチャートを実際に_インストール_できます。Tillerはそれらを確実に照会できないため、それらを確実にアップグレードまたは削除することはできません）。

名前空間のないアイテムの場合、状況は非常に複雑になります。 名前空間のないものを管理する名前空間のリリースがあり、それが他の名前空間に影響を与える可能性があります。 RBACとTPRがどのように機能するかをご覧ください。 これらは、Helmが単にサポートしないことを決定できるものではなく、名前空間を「偽造」すると、特にRBACの場合、その価値よりも多くの問題が発生します。

リリース名に名前空間を付ける正当な理由はまだわかりません。 最初の苦情は、Kubernetesのすべての（重要な）ものが名前空間にスコープされているという誤解に基づいています。 しかし、TPRやRBACのような重要なものはそうではありません。 他の不満の大部分は、彼らが使用する_アドホック_命名スキームがHelmでは「きれいではない」という事実に関するもののようです。 リリースを「名前空間内」として誤って表現する巨大な互換性を破る変更を作成することによってそれを回避することは、取るべき間違ったアプローチのように思われます。

@technosophos

マルチネームスペースチャートを実際にインストールできるようになりました

どのように？ 名前空間に関する概念を構成のどこに置くべきですか？

複数の名前空間のリリースを公式にサポートする予定はありますか？

Helm 3.0までは、マルチ名前空間リリースを完全にサポートする予定はありません。これを行うと、下位互換性が失われ、Helm / TillerのKubernetesコードの多くを大幅にリファクタリングする必要があります。

残念ながら、helmを使用して複数の名前空間をデプロイおよび管理できないことは、大きな問題です。

私たちの計画は、すべてのアプリ（小さなグラフなど）を依存関係として持つ包括的なグラフを作成することでした。 すべてのアプリは独自の名前空間に存在します。これは仕様によるものです（将来的には、名前空間ごとにRBACを使用したいと考えています）。 アンブレラチャートを使用すると、 values.yml 1つしかない場合に、さまざまなマイクロサービスのクラスター全体を一度にインストールおよびアップグレードできます。これは非常に便利です。

@technosophos 、ありがとう。 上記のサポートは、少なくともHelm 3.0までは、すぐには届かないことに注意してください。

複数の名前空間をサポートするためにHelm / Tillerで正確にリファクタリングする必要があるものについての一般的な考え方はありますか？ それとも3.0は遠すぎますか？

ヘルムnameをより多くのUUIDとして扱い、 --name-templateを使用して、単純だがランダムな名前を生成できるようにしました。 名前空間自体を尊重するよりもこれを好むとは言えませんが、両方の点がわかります。私たちにとっては、最小限のオーバーヘッドでこれで十分です。

例： https ：

> 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接続するアプリでredis（uvtiwh）の名前をどのように見つけますか？

クラスターでの使用を検討しているパターンは次のとおりです。

• kube-system内の1つのTillerインスタンス、クラスター管理者が使用
• 名前空間ごとに1つのTillerインスタンス、より制限されたRBAC権限で、その名前空間を所有する開発者チームが使用します

「ヘルムのリリース名は世界的にユニーク」な設計原則は、私たちのようなソフトマルチテナント展開にとって頭痛の種であるため、推奨されるアプローチについてもっと知りたいと思います。

Helmが名前と名前空間に基づいてリリースを識別するという概念に準拠していないことを知ったとき、私は非常に失望しました。 私の意見では、これは、リソースがそれぞれの名前空間内で一意であるKubernetesの設計原則に準拠していません（一部のグローバルリソースを除く）。

他の投稿者がこのスレッドでコメントしているように、アプリケーションのさまざまなグループに対して、環境に接尾辞が付けられた複数の名前空間があります。 それぞれ3つまたは4つの環境に数百の異なる展開があります。 異なる名前空間内で同じ名前のサービスを参照できるように、名前空間内の一意のDNS名に大きく依存しています。 例えば。 私たちのredisサービスは、名前空間a-testとa-prod両方でtcp：// redisを介してアクセスできます。ここで、両方の名前空間にはredisのデプロイ済みバージョンがあります。

これをヘルム3の議論のポイントとしてターゲットにしています。これには膨大な需要があるようです。

反対の点：

ほとんどすべてのチャートツリーは、永続性/ API /レベル7のALB（+ static）ラインに沿って分割された複数の名前空間にアーティファクトをデプロイします。 そのスタンドポイントloveからヘルムリリース名がグローバルであるという事実。

見出さ存在--namespaceでオプションhelmベース層は、赤/青の展開上層により再利用することができる多層アプリケーションの組み立てのスタンドポイントから半役に立ちません。 アーティファクトの名前に{{ .Release.Name }}派生した文字列を挿入する代わりに、デプロイごとに新しい名前空間を作成します。 これにより、決定論的に形成されたサービスURLをチェーン構成（ same_service_name.some_product_release20171102a.svc.cluster.local > same_service_name.some_product_release20171105c.svc.cluster.local ）を介して伝播できます。

とにかく自動生成されたリリース名はgobbledygookであるため、 helm listでその背後にあるものに忠実ではないため、製品/スタック名から派生した文字列と単調に増加するリリースで--nameをハードオーバーライドします/ビルドバージョン（ "appname-v20171103xyz" ）チャートのどこかに--name-template値を定義し、チャート名+日時から派生したビルドID値または明示的なビルドID値を使用できるようにしたいと考えています。

例

ベース永続層

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 }}"
...

次のような別の名前空間から消費されます。

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つのテンプレートは、2つの別個のチャート（永続性チャートとAPIチャート）の一部であり、3番目の包括的なチャートを介して別々にまたは共同で実行できます。 どちらの場合も、 .global.を使用しているため、値はコマンドラインで1回オーバーライドされ、すべてのサブチャートにきれいに適用されます。

このアプローチでは、宛先名前空間の値がReleaseNameの偏導関数である場合もあれば、半固定である場合もあるため、同じグローバルReleaseNameでスタックを作成しようとするとシステムが文句を言うように、ReleaseNameがグローバルであることにほとんど依存しています。

名前空間を使用する利点の1つは、名前空間内のオブジェクト名（DNS名を含む）がローカルであり、名前空間から名前空間に変更する必要がないことです。 特に上記の@dvdotsenkoの例では、REDIS_SERVER_HOSTNAMEは同じである必要があり（たとえば、 redis ）、グローバル化された値を挿入する必要はありません。 その理由は、繰り返しを避けるためです。

単純さの観点から（そして、複数の名前空間のデプロイや名前空間のないオブジェクトなど、自然に複雑なケースは別として）、理想的なケースは、名前空間がスタックを「アセンブル」し、アプリケーションのインスタンスを1つだけ含むことです。

これにより、スタック内の名前をローカルで単純にし、最も重要なことに、名前空間に相対的であるため固定することができます。

考えられるアプローチは、helmが今日のように単純なケースを多かれ少なかれサポートすることです（オブジェクトに名前空間を付けることを避けます）。 これにより、ほとんどの用途ですぐに使用できる、合理的で安全なベストプラクティスのデフォルトが生成されます。 また、 @ dvdotsenkoと@bcorijnが説明するユースケースを可能にするために、（複雑さを犠牲にして）より多くの自由を可能にする高度な名前空間モードを持つこともできます。

私の$ .02

@pnickolovに同意する必要があり障害です。 このユースケースでは、150を超える環境と複数のクラスターがあり、同じアプリケーションスタックのバリアントを実行する必要があります。 名前空間はこの問題を解決し、特にサービスディスカバリに関連して、環境の分離と構成の簡素化を可能にします。

サービスエンドポイントを兄弟チャートで構成する簡単な方法がない場合...純粋に値を介して...

これも紛らわしいと思います。 @technosophosが書いているように：

リリースは名前空間にバインドされていません。 （そのため、リリース自体に名前空間定義を含めることができます）。 実際、（個人的に試したとは言えませんが）複数の名前空間に複数のオブジェクトを作成する単一のグラフを展開することは可能であるはずです。

私はこれを正確に理解するのに苦労しています。 私はドキュメントを見て、ここGHでいくつかの問題を調べましたが、まだ混乱しています。

• 一方では、 helm install --namespaceを使用して、ターゲットにする名前空間を指定できます
• 一方、私のチャートでは、メタデータオブジェクト内で必要な名前空間を指定できます。

だから、私の質問：

• helm install --namespace指定された名前空間が存在しない場合、Helmはそれを作成しますか？ 次に、chrtから作成するすべてのリソースにその名前空間を設定しますか？
• リソーステンプレートがメタデータで名前空間を指定している場合、helmはそれを上書きしますか？

これらの質問により、私は--namespaceで遊ぶことさえ躊躇しました、それはとても不明確です。 誰かが私がそれを理解するのを手伝ってくれるなら、私はそれを本当に感謝します。 ありがとう！

f helm install --namespaceで指定された名前空間が存在しない場合、Helmはそれを作成しますか？

はい。 名前空間がまだ存在しない場合、 --namespaceはチャートに指定された名前空間を作成します。

リソーステンプレートがメタデータで名前空間を指定している場合、helmはそれを上書きしますか？

いいえ。チャートの名前空間リソースと同様に--namespace同じ名前空間を指定した場合、名前空間は最初に耕うん機によってインストールされ、チャートが同じネームスペースを再インストールします。

さらにコンテキストを説明すると、helmのアイデアは、 helm install --namespaceによって提供される名前空間にすべてのリソースをインストールすることです。 チャートの名前空間を「ハードコーディング」しているユーザーは、通常、複数の名前空間にチャートをインストールしたいと考えています。

これはOPが提案していることから少し外れたトピックですが、さらに質問がある場合は、新しいチケットを開くか、Slackに参加してください。 :)

この議論に参加したいのかわからない😄親切にしてください🙏

helm--namespaceパラメーターは実際には--default-namespaceです

スタックを読んで関連する--namespaceオプションについては、多くの混乱が見られます。これは、人々が（かなり合理的に）慣れているkubectl --namespaceに似ていると想定しているためです。これにより、アクティビティがその名前空間に効果的に制限されます（解析エラーの副作用であり、実際にはセキュリティではありません）。 tillerはクラスター全体で動作するクラスターサービスであるため、 helmの場合はそうではありません。 このオプションは、 --default-namespaceという名前の方が適切です。 これは、リソースが特定の名前空間を指定しない場合にリソースが移動する名前空間です。

複数の名前空間のリリースも必要です

私はすでに、各リリースのさまざまなコンポーネントを複数の名前空間にデプロイするチャートに依存しており、helm3.0でのサポートの強化を楽しみにしています。 👍🎉

ヘルムと名前空間の制限があるマルチテナントはすでに可能です

また、マルチテナントで名前空間が制限されたインストールが必要なユースケースもあります。 IMHOのスコープまたは名前空間へのリリースの制限は、 helm / tillerが強制に関係するものではありません。これは、RBACの仕事です。 これを実現するためのモデルは少なくとも2つあり、現在1つが可能です。

1. 名前空間ごとのtillerを、その名前空間での操作のみを許可するサービスアカウントとRBACを使用して展開します。 これは現在機能しており、人々がそれを使用しているのを目にします。 マルチテナントクラスターに最適です。
2. tiller場合、 をhelmユーザーとしてデプロイし将来のhelmバージョンでtillerは、複数の名前空間にまたがるリリースをサポートしながら、RBAC名前空間の制限を適用できます。

異なる名前空間の異なるリリースの同じ名前のリソースはすでに可能です

同じチャートを異なる名前空間にインストールしたいが、同じリソース名（redisなど）を使用したい場合。 それは完全に可能です、それはあなたがあなたのチャートテンプレートを書く方法にかかっています。 リソース名の前にリリース名を付ける必要はありません。これは、多くのチャートが従うデフォルト/規則です。 最近のチャートには、リリース名のプレフィックスを追加できる.fullnameOverride値がすでに含まれています。 必要に応じて、 redisをredisとしてすべてのhelm installデプロイできます。

私たちは@gmileと同様の状況にあり、それを行うためのベストプラクティスを知りたかったのです。 コアアプリケーションであるingestion-serviceはkafka依存しており、 zookeeper依存しています。 ただし、3つすべてを独自の名前空間に配置する必要がありますが、単一のヘルムinstall介して管理する必要があります。 kafkaのrequirements.yamlにingestion-service kafkaを追加することを計画していました。 しかし、取得kafka独自の名前空間ではないと、簡単に見えるんhelm我々はから削除されたために行ってきましたどのようなので、 requirements.yamlと異なる持つhelm installの両方の展開に。

これが注目されているFYIであり、セクション3：状態管理の下にリストされているHelm3提案の一部です。 フィードバックを歓迎します！

それは素晴らしいニュースです@bacongobbler😄🎉

@bacongobbler Helm 3は、 @ prat0318で説明されているように、requirements.yamlで依存チャートに個別の名前空間を指定することをサポート

提案文書から（読んでください！：smile :)：

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

Helm 2と同様に、リソースが独自の名前空間を明示的に宣言している場合（たとえば、metadata.namespace = somethingを使用）、Helmはそれをその名前空間にインストールします。 ただし、所有者参照は名前空間を保持しないため、そのようなリソースは基本的に管理されなくなります。

@bacongobbler読んだのですが、それをサポートしているとは思えません。 私が制御するチャートにハードコードされたmetadata.namespaceを意味するのではなく、常にサポートされています。 つまり、編集する機能がないサードパーティのグラフの名前空間を指定することです。 たとえば、requirements.yamlでは、stable / kubernetes-dashboardに依存しており、kube-systemにインストールしたいのですが、チャートは開発名前空間に入ります。

90日間操作がないと、問題は古くなります。
/remove-lifecycle staleして、問題を新規としてマークします。
古い問題は、さらに30日間非アクティブになると腐敗し、最終的には閉じます。

この問題を今すぐ解決できる場合は、 /close 。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/ lifecycle stale

この機能要求はhelmfileによってです。 readmeの内容から、独自の名前空間をスコープとするさまざまなリリースを指定できるはずです。

@gmile私は、helmfileメンテナがhelmfileのこの特定の問題を修正していないと99％確信しています。 helmfile.yamlで異なる名前空間を持つvaultという名前の2つのリリースを宣言し、 helmfile syncを実行すると、リリース名vaultが最初のリリースで要求されたため、失敗します。

免責事項：私はhelmfileを使用してこれをテストしていないので、私は間違っていると言われたいと思います。 😄

最後のコメントを見逃した場合に備えて、Helm 3では、Helmがリリースを処理する方法を変更してこれに対処しています。 :)

@ steven-sheehyその特定の問題は、定義されているものよりも特定の名前空間にデプロイするようにサブチャートを拡張することによりておそらく修正される可能性があります。

/ remove-lifecycle stale

関連： https ：

Helm 3に実装されています。名前空間コンテキストの変更は、まったく別のインスタンスを参照します。

><> ./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

素晴らしいニュース@bacongobbler

この変更を考えると、名前空間列をlist出力の最初の列に移動することは理にかなっていますか。 最初の2列がリリースを一意に識別するように？

デフォルトの並べ替えは、名前空間とリリースによるものである可能性があるため、同じ名前空間内のリリースはグループ化されます。たとえば、すべてのkube-systemリリースは一緒になります。

もちろん。

今のところ、私はただ使用します

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

はい、現在の動作は悪臭を放ちますが、必要なのは管理するグローバルに一意の名前だけであり、リリースの名前の複合キーを作成できない理由はありません。

わかりました。3つの基本的なシナリオがあるようです（それぞれにさまざまな順列が混在する可能性があります）。

1. 単一の名前空間のチャート。
2. 名前を付けることができないリソース。
3. 複数の名前空間のチャート。

これは、さまざまなシナリオに対処するための合理的なアプローチでしょうか。

1. --namespaceフラグが指定されている場合、名前空間を挿入/オーバーライドします。
2. 1と同じですが、名前空間がないリソースの名前空間は無視してください。
3. 「マルチネームスペースをオーバーライドできない」リソースなどを引用して終了します。

余談ですが、私は耕うん機を使用せず、 helm templateを好むので、それが課題をどれだけ変えるかはわかりません。

@technosophos

Helm v2が名前空間とどのように相互作用し、v3がどのように異なるかを理解しようとしていますが、このスレッドの古いコメントの1つで混乱します。

まず、要点を繰り返します。ヘルムチャートは、名前空間レベルではなく、グローバルレベルで動作します。 したがって、それらの名前はグローバルに一意です。

...。

名前空間のないアイテムの場合、状況は非常に複雑になります。 名前空間のないものを管理する名前空間のリリースがあり、それが他の名前空間に影響を与える可能性があります。 RBACとTPRがどのように機能するかをご覧ください。 これらは、Helmが単にサポートしないことを決定できるものではなく、名前空間を「偽造」すると、特にRBACの場合、その価値よりも多くの問題が発生します。

HelmV3からデプロイされたリリースは実際には名前空間が付けられているようです。 あれは正しいですか？ RBACの問題がどのように解決されたか知っていますか？ あなたが指摘した問題を回避するために私が考えることができる唯一の解決策は、Helm v3チャートがRBACオブジェクトの変更をサポートしないことですが、v3チャートが管理をサポートするかどうかを示すv3に関するさまざまなブログ投稿などには何も見つかりませんでしたRBACオブジェクトかどうか。

本当に必要なのは、名前空間パラメーターを使用できるようにすることだけです。
接辞ではなくリリースを識別するための複合キーとしての名前パラメーター
名前空間を名前に。

私はhelmv3の提案を読んでいませんが、賢明なことは
k8sがすでに使用しているセレクターパターンを採用する必要はありません
特定のフィールドをサポートします。

火、2019年6月25日には、午前11時01分AM BatmanAoDの[email protected]は書きました：

@technosophos https://github.com/technosophos

Helm v2が名前空間とどのように相互作用し、v3がどのように相互作用するかを理解しようとしています
異なるでしょう、そしてこのスレッドのあなたの古いコメントの1つは私を混乱させます：

まず、要点を繰り返します。ヘルムチャートはグローバルで動作します
名前空間レベルではなく、レベル。 したがって、それらの名前はグローバルに一意です。

名前空間のないアイテムの場合、状況は非常に複雑になります。 私たちは持っているだろう
名前空間が設定されたリリースは、名前空間が設定されていないものを管理します。
他の名前空間に影響を与えます。 RBACとTPRがどのように機能するかをご覧ください。
これらは、Helmが単にサポートしないことを決定できるものではありません。
名前空間を「偽造」すると、特にその価値よりも多くの問題が発生します。
RBACを使用します。

HelmV3からデプロイされたリリースは実際には名前空間が付けられているようです。
あれは正しいですか？ RBACの問題がどのように解決されたか知っていますか？ 唯一の
私が考えることができる解決策は、あなたが指摘した問題を回避するでしょう
Helm v3チャートはRBACオブジェクトの変更をサポートしていませんが、見つかりませんでした
さまざまなブログ投稿などのv3に関するものは、v3かどうかを示します
チャートは、RBACオブジェクトの管理をサポートするかどうかをサポートします。

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/helm/helm/issues/2060?email_source=notifications&email_token=AACFHREXHFSKFSB7FXQ5VPTP4JMP3A5CNFSM4DCII7X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2Z
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AACFHRH2JPXPKMX23WVQLCDP4JMP3ANCNFSM4DCII7XQ
。

@BatmanAoD @gyndick Helm v3では、チャートはユーザーコンテキストにインストールされます。 これは、そのユーザー名前空間にインストールされ、ユーザーのRBACを使用することを意味します。 リリース名も名前空間に基づいています。

Alpha.1リリース（ https://github.com/helm/helm/releases/tag/v3.0.0-alpha.1）で試すか、 dev-v3ブランチからビルドできます。

helmv3は使用しません。 運用チームごとに異なります
制約と物事のやり方。 操作ツールはシンプルである必要があります、
単一目的のユーティリティ、つまりUnix哲学と互換性があります。

スクリプトやロジックなどは、パッケージマネージャーの外部にあります。

TLDR;

Unix哲学と互換性があることの最も重要な側面は
ステップ間にエスケープハッチを提供する機能。

からのロジスティクスを処理する、長く自動化されたワークフローを持つ
それが壊れるまで、墓へのゆりかごは素晴らしいです。 ユーザーに提供されていない場合
必要な自動化のフローのすべてのステップを手動で実行する機能
パンドラの箱になります。

v3で提案された複雑さは、多くの多くの間違いや悪いことを招きます
25年の経験の恩恵を受けていない人々からのデザイン。

追加された複雑さは、常に、物事を行うのを難しくします。
独自の開発環境となる運用ツール
トリアージを遅くします。

完璧な例は、誰かが1つの巨大で恐ろしいことに成文化するときです
書かれたスクリプト。 停止が発生し、スクリプトの一部を実行する必要があります。
他の部分は厳密に避ける必要がありますが、それらの部分は
メインロジック。 では、一体何をしますか？ 必死になってそこに座る
デバッグの良い方法が本当にないコードをリファクタリングします。

サポートするためにエコシステムに組み込まれるすべてのツールについて考えてください
特定の言語でのソフトウェアの開発と運用。 あなたではない
かなり長い間、ヘルムにそれを提供できるようになるでしょう。

したがって、バージョン間の移行を管理する方法の責任を負ってください
展開されているソフトウェアを開発している人々とのソフトウェア。

パッケージマネージャーは、シンプルで軽量で、
責任。

1. アーティファクトを配信する
2. アーティファクトを削除する
3. アーティファクトで提供されているスクリプトを実行します
4. 配信されたと思われるアーティファクトを追跡します
5. 最も重要なのは、KISS

他の何かが痛みを求めています。 率直に言って、helmV2はほぼ完璧です
リリースを追跡する方法を修正しただけの場合。

2019年6月26日水曜日、午前1時31分マーティンヒッキー[email protected]
書きました：

@BatmanAoD https://github.com/BatmanAoD @gyndick Helm v3では、グラフは
ユーザーコンテキストにインストールされます。 これは、そのユーザーにインストールされていることを意味します
名前空間であり、ユーザーのRBACを使用します。 リリース名は
名前空間ベースも。

Alpha.1リリースで試すことができます。
https://github.com/helm/helm/releases/tag/v3.0.0-alpha.1またはビルド元
dev-v3ブランチ。

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/helm/helm/issues/2060?email_source=notifications&email_token=AACFHREUTX77SJCPWZLQKATP4MSNRA5CNFSM4DCII7X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2Z
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AACFHRCAQLWUYHH6RJSUYF3P4MSNRANCNFSM4DCII7XQ
。

@hickeyma返信ありがとうございます！ 実際、Helm自体がv3でClusterRolesを作成するなどのグローバル操作を実行できるかどうかほど、Helmの操作がアクセス制御される方法（これは関連する問題ですが）についてはあまり疑問に思っていません。

@BatmanAoDクラスタースコープのリソースであるため、これは機能するはずです。 機会があれば試してみる価値があるかもしれません。