Helm: 作用域将名称发布到命名空间

我不确定我是否理解你。 您想部署到多个命名空间而只有一个发布名称？

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

我在我的图表模板中使用我的发布名称，所以我所有的服务和 pod 名称都包含所有这些额外的东西。 我已经将命名空间传递给模板，所以如果我愿意，我可以轻松地将它包含在名称中，但现在的方式是，通过使用默认的 helm 脚手架，它是我所有资源名称的一部分。

K8s 命名空间已经为我们提供了命名空间，当命名空间旨在帮助防止冲突时，我真的不喜欢必须用命名空间前缀我所有的东西。

明确地说，如果我能用与命名空间相关的掌舵图做与服务和其他 k8s 本机类型相同的事情，那就太好了。

例如，我希望能够执行以下操作：

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

@Janpot @bcorijn上面

没有命名空间的第三方资源呢？ 或者 RBAC，其中“命名空间”是一个策略属性，而不是一个位置 (https://kubernetes.io/docs/admin/authorization/)？

我知道我已经在别处多次说过，但我们的最终目标是可以将资源从同一个图表部署到多个命名空间中。 （用例：应用程序具有控制平面和数据平面，您希望将它们分别部署到单独的命名空间中以创建安全边界）

如果我们将发布绑定到命名空间，我们将失去以下能力：

1. 直接管理命名空间
2. 管理 RBAC 和服务帐户
3. 管理 TPR（和任何其他非命名空间对象）
4. 最终支持多命名空间图表。

我知道这让命名问题对您来说有点困难，但它允许 Helm 对​​更广泛的 Kubernetes 资源进行操作。

是否可以同时支持命名空间和非命名空间版本？

@technosophos总结一下有两个主要驱动因素：
1) 管理未命名空间的资源
2) 允许图表跨命名空间安装的未来计划

我确实理解您的观点，但我不确定这是否是坚持当前实施的理由，因为我的印象是您还需要稍微强迫一下来解决这些问题？

为了让多命名空间图表很好地/本地工作，您很可能需要对命名空间系统进行彻底改革，因为 Helm 将版本放入命名空间的当前概念不起作用？ _编辑：刚刚意识到如果发布实际上是命名空间的，多命名空间图表可能只是一个包含两个具有不同命名空间的发布的伞形图表？_

用于管理非命名空间资源； 我没有个人经验，所以很难判断，但我再次觉得这迫使 Helm 现在采用一种不太完美的工作方式，作为管理命名空间的 Release，RBAC 或 TPR 将有一个命名空间但只是忽略它？
由于没有使用它们的经验，我可能只是遗漏了一些东西，但不会限定名称并忽略名称空间具有相同的最终结果，只会让用户承担更多责任来验证他的发布名称和选择器是处理这些资源时正确/独特。 （我同意这是相当的责任）

因此，也许仅仅限定发布版本不是可行的方法，但是再看看它们在 Helm 中的处理方式以及将来会被处理的方式是否值得？ @Janpot提到的两个选项都可以工作，“全局”版本和命名空间版本？
我_very personal_的意见也是部署的方式@ kylebyerly马力，@chancez和我上面描述是很多比两个usecases防止这种工作方式更加普遍。

首先，让我重申主要观点：Helm Chart 在全局级别上运行，而不是在命名空间级别上运行。 所以他们的名字是全球唯一的。

对于多命名空间图表，我们需要修复的是 Tiller 跨命名空间查询的能力。 （您现在实际上可以_安装_多命名空间图表。您只是无法可靠地升级或删除它们，因为 Tiller 无法可靠地查询它们）。

对于非命名空间的项目，事情会变得非常复杂。 我们会使用命名空间版本来管理未命名空间的事物，而这些事物反过来可能会影响其他命名空间。 请看一下 RBAC 和 TPR 是如何工作的。 这些不是 Helm 可以简单决定不支持的事情，“伪造”命名空间会导致比其价值更多的问题，尤其是对于 RBAC。

我仍然没有看到一个很好的理由来命名发布名称。 您最初的抱怨是基于一种误解，即 Kubernetes 中的所有（重要）事物都被限定在一个命名空间内。 但是像 TPR 和 RBAC 这样重要的东西不是。 大部分其他抱怨似乎更多是关于他们使用的 _ad hoc_ 命名方案对 Helm 来说“不漂亮”。 通过创建一个巨大的破坏兼容性的更改来解决这个问题，该更改将版本错误地表示为“在命名空间中”似乎是错误的方法。

@technosophos

您现在实际上可以安装多命名空间图表

如何？ 关于命名空间的概念应该放在配置中的什么地方？

您是否计划正式支持多命名空间版本？

我们不打算在 Helm 3.0 之前完全支持多命名空间版本，因为这样做会破坏向后兼容性，并且需要对 Helm/Tiller 的大部分 Kubernetes 代码进行重大重构。

不幸的是，我们无法使用 helm 部署和管理多个命名空间是一个交易破坏者。

我们的计划是创建一个伞形图表，它将我们所有的应用程序（例如较小的图表）作为依赖项。 我们所有的应用程序都位于自己的命名空间中，这是设计使然（将来我们希望每个命名空间都有 RBAC）。 使用总括图，我们可以一次安装和升级整个集群的不同微服务，只要一个values.yml ，这真的很方便。

@technosophos ，谢谢。 注意到对上述内容的支持不会很快到来，至少要等到 Helm 3.0。

在 Helm/Tiller 中究竟需要重构什么来支持多个命名空间，是否有一个大致的想法？ 还是3.0太远了？

我们已经将 helm name视为更多的 UUID，使用--name-template并让它生成一个简单但随机的名称。 我不能说我更喜欢这一点而不是尊重命名空间本身，但我确实看到了这两点，对我们来说，这足以减少开销。

例如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您将如何在您的应用程序中找到 redis (uvtiwh) 的名称以连接到它？

我正在考虑在我们的集群中使用的模式是：

• kube-system一个 Tiller 实例，供集群管理员使用
• 每个命名空间一个 Tiller 实例，具有更有限的 RBAC 权限，供拥有该命名空间的开发团队使用

“Helm 版本名称是全球唯一的”设计原则对于像我们这样的软多租户部署来说是一个令人头疼的问题，所以我有兴趣了解更多关于推荐方法的信息！

当我发现 Helm 不遵守基于名称和命名空间识别版本的概念时，我感到非常失望。 在我看来，这不符合 Kubernetes 的设计原则，其中资源在其各自的命名空间中是唯一的（一些全局资源除外）。

正如其他海报在此线程中评论的那样，我们为不同的应用程序组提供了多个环境后缀的命名空间。 我们在三个或四个环境中分别有数百种不同的部署。 我们严重依赖命名空间内的唯一 DNS 名称，以便我们可以在不同的命名空间内引用具有相同名称的服务； 例如。 我们的 redis 服务可以通过tcp://redis在a-test和a-prod两个命名空间中访问，其中两个命名空间都部署了 redis 版本。

将此作为 helm 3 的讨论点。似乎对此有大量需求。

反点：

我们几乎所有的图表树都在沿着持久性/API/Level7 ALB(+static) 行拆分的多个命名空间中部署工件。 从这个角度来看，喜欢helm 版本名称是全球性的这一事实。

从组装多层应用程序的角度来看，发现helm存在的--namespace选项是半无用的，其中基础层可以被红色/蓝色部署的上层重用。 我们没有将{{ .Release.Name }}派生的字符串注入到工件的名称中，而是为每个部署创建一个新的命名空间。 这允许我们通过链接的配置（ same_service_name.some_product_release20171102a.svc.cluster.local > same_service_name.some_product_release20171105c.svc.cluster.local ）传播确定性形成的服务 URL。

由于自动生成的发布名称无论如何都是 gobbledygook - 不忠实于helm list背后的内容，我们使用从产品/堆栈名称和单调递增发布派生的字符串硬覆盖--name / 构建版本 ( "appname-v20171103xyz" ) 希望能够在图表中的某处定义--name-template值，并让它使用图表名称 + 日期时间派生或显式构建 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.的使用，这些值在命令行中被覆盖一次，并干净地应用于所有子图表。

使用这种方法，由于目标命名空间值有时是 ReleaseName 的偏导数，有时是半固定的，我们几乎依赖 ReleaseName 是全局的，因此如果我们尝试创建具有相同全局 ReleaseName 的堆栈，系统会抱怨。

拥有和使用命名空间的好处之一是其中的对象名称（包括 DNS 名称）是本地的，不必在命名空间之间更改。 特别是在上面的@dvdotsenko示例中， REDIS_SERVER_HOSTNAME 应该是相同的（例如，只是redis ）并且不需要注入全球化的值。 原因是避免重复。

从简单性的角度来看（撇开一些自然复杂的情况，比如多命名空间部署和非命名空间对象），理想的情况是命名空间“组装”了你的堆栈并且只包含你的应用程序的一个实例。

这允许堆栈中的名称是本地的、简单的，最重要的是，因为它们是相对于命名空间的，所以是固定的。

一种可能的方法是让 helm 或多或少像今天一样支持简单的情况（同时避免使用命名空间为对象添加前缀）； 这将产生合理、安全的最佳实践默认值，对于大多数用途来说都是开箱即用的。 它还可以具有高级命名空间模式，这将允许更多的自由（以复杂性为代价），以允许用例@dvdotsenko和@bcorijn describe。

我的 $.02

我必须同意@pnickolov ，这对我们来说是一个主要的

没有在兄弟图表中配置服务端点的简单方法......纯粹通过值......

我也觉得这很混乱。 正如@technosophos所写：

版本不绑定到命名空间。 （这就是发布本身可以包含命名空间定义的原因）。 事实上，应该可以（虽然我不能说我个人尝试过）部署一个在多个命名空间中创建多个对象的图表。

我正在努力理解这一点。 我查看了文档，并查看了 GH 上的几个问题，但我仍然感到困惑：

• 一方面，我可以使用helm install --namespace来指定我想要定位的命名空间
• 另一方面，我的图表可以在其元数据对象中指定它想要的任何命名空间。

所以，我的问题：

• 如果helm install --namespace指定的命名空间不存在，Helm 是否会创建它？ 然后它是否在它从 chrt 创建的所有资源上设置该命名空间？
• 如果资源模板在其元数据中指定了一个命名空间， helm 是否会覆盖它？

这些问题让我连玩--namespace都犹豫不决，太不清楚了。 如果有人能帮助我理解它，我将不胜感激。 谢谢！

f helm install --namespace 指定的命名空间不存在，Helm 会创建吗？

是的。 如果命名空间尚不存在， --namespace将为图表创建指定的命名空间。

如果资源模板在其元数据中指定了一个命名空间， helm 是否会覆盖它？

不会。如果你碰巧在--namespace提供了相同的命名空间以及图表中的 Namespace 资源，则会发生冲突，因为命名空间将首先由 Tiller 安装，然后在图表尝试安装时 bork再次重新安装相同的命名空间。

对于进一步的上下文， helm 的想法是在helm install --namespace提供的命名空间中安装所有资源。 对图表中的命名空间进行“硬编码”的用户通常希望在多个命名空间中安装一个图表。

这与 OP 的建议有点偏离主题，但如果您有其他问题，请随时打开新票或加入我们的 Slack！ :)

不确定我是否想参与这个讨论😄请善待🙏

helm --namespace 参数实际上是 --default-namespace

阅读堆栈和相关内容，围绕--namespace选项似乎有很多混乱，因为人们（相当合理地）认为它就像他们习惯的 kubectl --namespace ，这有效地将活动限制在该命名空间（通过解析错误的副作用，实际上不是安全性）。 helm的情况并非如此，因为tiller是在整个集群上运行的集群服务。 该选项最好命名为--default-namespace ，即。 如果您的资源没有指定特定的命名空间，则这是您的资源将使用的命名空间。

也需要多命名空间发布

我已经依赖于将每个版本的不同组件部署到多个命名空间中的图表，我期待着 helm 3.0 中的增强支持。 👍 🎉

具有 helm 和命名空间限制的多租户已经成为可能

我还看到了人们想要多租户、受命名空间限制的安装的用例。 恕我直言，限定或限制对命名空间的发布不是helm / tiller应该关注的强制执行，这是 RBAC 的工作。 至少有两种模型可以实现这一点，一种是现在可能的：

1. 使用仅允许在该命名空间中进行操作的服务帐户和 RBAC 部署每个命名空间tiller 。 这现在有效，我看到有人在使用它。 非常适合多租户集群。
2. 为了tiller支持k8s 用户模拟，因此将每个版本部署为helm用户。 这正在为未来的helm版本进行讨论，并且似乎存在一些实施挑战。 但这将允许集群服务tiller强制执行 RBAC 命名空间限制，同时仍然支持跨命名空间的发布。

不同命名空间中不同版本的同名资源已经成为可能

对于想要将相同图表安装到不同命名空间但具有相同资源名称（例如 redis）的人。 这是完全可能的，这取决于您如何编写图表模板。 您不需要在资源名称前加上发布名称，这只是许多图表遵循的默认/约定。 最近的图表已经有.fullnameOverride值，可以让您取消发布名称前缀。 如果您愿意，您可以将您的redis部署为redis以及每个helm install 。

我们与@gmile处于类似的情况，我们想知道这样做的最佳实践是什么。 我们的核心应用程序ingestion-service依赖于kafka ，而后者又依赖于zookeeper 。 但是，我们希望所有三个都在自己的命名空间中，但希望通过单个 helm install 。 我们计划在kafka的requirements.yaml中添加ingestion-service 。 但是，得到kafka在其自己的命名空间不会看起来与简单helm所以我们就从被删除requirements.yaml并且具有不同的helm install两个部署.

仅供参考，这是在第 3 节：状态管理下列出的 Helm 3 提案的一部分。 欢迎反馈！

这是个好消息@bacongobbler 😄🎉

@bacongobbler Helm 3 是否希望支持在requirements.yaml 中为依赖图表指定单独的命名空间，如@prat0318所述？

来自提案文档（读一读！: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-testing、kubernetes/test-infra 和/或fejta发送反馈。
/生命周期陈旧

看来这个功能请求可以通过helmfile来完成。 从自述文件中的内容来看，应该可以指定范围为它们自己的命名空间的不同版本。

@gmile我 99% 确定 helmfile 维护者没有在 helmfile.xml 中修复这个特定问题。 如果您在 helmfile.yaml 中使用不同的命名空间声明两个名为vault的版本并运行helmfile sync ，它将失败，因为版本名称vault已被第一个版本声明。

免责声明：我没有使用 helmfile 测试过这个，所以我很想被告知我错了。 😄

以防万一最后一条评论被遗漏，我们将在 Helm 3 中解决这个问题，改变 Helm 处理发布的方式。 :)

@steven-sheehy 可以通过沙盒模型通过扩展子图以部署到特定命名空间而不是定义的命名空间来修复特定问题。

/删除生命周期陈旧

相关： 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输出中的第一列是否有意义。 所以前两列唯一标识版本？

默认排序可以按命名空间和发行版进行，以便同一命名空间中的发行版组合在一起，例如，所有kube-system发行版将组合在一起。

当然。

现在，我只是使用

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

是的，目前的工作方式很糟糕，但是，您只需要管理全局唯一的名称，并且没有理由不为发布的名称创建复合键。

好的，听起来有 3 种基本场景（每个场景都有各种排列组合的潜力）：

1. 单个命名空间的图表。
2. 不可命名空间的资源。
3. 多命名空间图表。

这是否是解决不同情况的合理方法：

1. 在提供--namespace标志时注入/覆盖命名空间。
2. 与 1 相同，但忽略那些缺少命名空间的资源的命名空间。
3. 退出引用“无法覆盖多命名空间”资源或类似内容。

旁白：我不使用分蘖，更喜欢helm template所以不确定这会改变多少挑战。

@technosophos

我试图了解 Helm v2 如何与命名空间交互以及 v3 将有何不同，您在此线程中的旧评论之一让我感到困惑：

首先，让我重申主要观点：Helm Chart 在全局级别上运行，而不是在命名空间级别上运行。 所以他们的名字是全球唯一的。

....

对于非命名空间的项目，事情会变得非常复杂。 我们会使用命名空间版本来管理未命名空间的事物，而这些事物反过来可能会影响其他命名空间。 请看一下 RBAC 和 TPR 是如何工作的。 这些不是 Helm 可以简单决定不支持的事情，“伪造”命名空间会导致比其价值更多的问题，尤其是对于 RBAC。

听起来好像从 Helm v3 部署的版本实际上是命名空间的； 那是对的吗？ 你知道RBAC问题是如何解决的吗？ 我能想到的唯一解决方案是避免您指出的问题是 Helm v3 图表不支持修改 RBAC 对象，但我没有在各种博客文章中找到任何关于 v3 的内容，表明 v3 图表是否支持管理RBAC 对象与否。

我们真正需要的是我们能够使用命名空间参数和
name 参数作为复合键来标识发布而不是附加
名称上的命名空间。

我还没有阅读 helm v3 的提案，但明智的做法是
采用 k8s 已经使用的选择器模式，不需要
支持任何特定领域。

在星期二，2019年6月25日，上午11时01 BatmanAoD [email protected]写道：

@technosophos https://github.com/technosophos

我试图了解 Helm v2 如何与命名空间交互以及 v3 如何
会有所不同，您在此线程中的旧评论之一让我感到困惑：

首先，让我重申一下要点：Helm Chart 在全局范围内运行
级别，而不是命名空间级别。 所以他们的名字是全球唯一的......

对于非命名空间的项目，事情会变得非常复杂。 我们会有
命名空间版本管理未命名空间的东西，反过来，可以
影响其他命名空间。 请看一下 RBAC 和 TPR 是如何工作的。
这些不是 Helm 可以简单决定不支持的事情，而且
“伪造”命名空间会导致比其价值更多的问题，尤其是
与 RBAC。

听起来好像从 Helm v3 部署的版本实际上是命名空间的；
那是对的吗？ 你知道RBAC问题是如何解决的吗？ 唯一的
我能想到的解决方案可以避免您指出的问题
Helm v3 图表不支持修改 RBAC 对象，但我还没有找到
各种博客文章中的任何内容以及关于 v3 的内容，表明 v3
图表将支持或不支持管理 RBAC 对象。

—
您收到此消息是因为您发表了评论。
直接回复本邮件，在GitHub上查看
https://github.com/helm/helm/issues/2060?email_source=notifications&email_token=AACFHREXHFSKFSB7FXQ5VPTP4JMP3A5CNFSM4DCII7X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJLOORPDN50000000000000000000000000000000000000000000000000000000000000000000003
或静音线程
https://github.com/notifications/unsubscribe-auth/AACFHRH2JPXPKMX23WVQLCDP4JMP3ANCNFSM4DCII7XQ
.

@BatmanAoD @gyndick在 Helm v3 中，图表安装在用户上下文中。 这意味着它安装在该用户命名空间中，并将使用用户的 RBAC。 发布名称也是基于命名空间的。

您可以尝试使用 Alpha.1 版本： https : dev-v3分支构建。

我不会使用 helm v3。 每个运营团队都有不同的
限制条件和做事方式。 操作工具要简单，
单一用途的实用程序，即兼容 Unix 哲学。

我的脚本、逻辑等位于我的包管理器之外。

TLDR；

与 Unix 哲学兼容的最重要方面是
在步骤之间提供逃生舱口的能力。

拥有一个长期的、自动化的工作流程，负责从
从摇篮到坟墓都很棒，直到它破裂。 如果未向用户提供
能够手动执行所需流程的每一步，自动化
变成潘多拉的盒子。

为 v3 提出的复杂性会招致许多错误和坏事
设计来自没有 25 年经验的人。

增加的复杂性只会让事情变得更难做，因为总是，
成为自己唯一的开发环境的操作工具
放慢分流速度。

一个完美的例子是当有人编入一个庞大的、可怕的
写好的剧本。 发生中断，需要运行部分脚本，
其他部分需要严格避免，但这些部分是不可或缺的
主要逻辑。 那你到底在做什么？ 坐在那里疯狂地尝试
重构你没有很好的调试方法的代码。

考虑进入生态系统以支持的所有工具
以任何特定语言开发和操作软件。 你不
将能够在相当长的一段时间内为掌舵人提供这些服务。

因此，负责如何管理不同版本之间的迁移
软件与开发正在部署的软件的人员。

包管理器应该简单轻便，只需几个
责任。

1. 交付工件
2. 删除工件
3. 运行工件中提供的脚本
4. 跟踪它认为交付的工件
5. 最重要的是，KISS

其他任何事情都是在要求痛苦。 坦率地说，helm v2 几乎是完美的
如果它只是修复了它如何跟踪发布。

2019 年 6 月 26 日，星期三，上​​午 1:31，Martin Hickey通知@ github.com
写道：

@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=AACFHREUTX77SJCPWZLQKATP4MSNRA5CNFSM4DCII7X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJLOTDNR55CNFSM4DCII7X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LN5MVXHJLQ7SYPDN500000000007SJCPWZLQKATP4MSNRA5CNFSM4DCII7X2YY3PNVWWK3
或静音线程
https://github.com/notifications/unsubscribe-auth/AACFHRCAQLWUYHH6RJSUYF3P4MSNRANCNFSM4DCII7XQ
.

@hickeyma感谢您的回复！ 实际上，我不太想知道 Helm 的操作将如何受到访问控制（尽管这是一个相关的问题），因为 Helm 本身是否仍然能够执行全局操作，例如在 v3 中创建 ClusterRoles。

@BatmanAoD这应该可以工作，因为它们是集群范围的资源。 如果有机会，可能值得一试。