使用Helm部署Kubernetes Service时指定命名空间不生效问题咨询

从你描述的情况来看，你用Helm 2.14.x执行部署时明确指定了--namespace test，但服务还是跑到了default命名空间，结合Helm 2的特性，我整理了几个最可能的原因和对应的解决步骤：

1. Tiller（Helm 2的服务端组件）权限不足 #

Helm 2依赖运行在集群中的Tiller组件来执行部署操作，默认情况下，Tiller的ServiceAccount可能只拥有default命名空间的操作权限。当你尝试部署到test命名空间时，如果Tiller没有对应的权限，它会静默回退到自己有权限的default命名空间。

修复步骤：
给Tiller授予集群级别的管理员权限（或者至少能访问test命名空间的权限），执行以下命令：

kubectl create clusterrolebinding tiller-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:tiller

这条命令会把kube-system命名空间下的tiller ServiceAccount绑定到cluster-admin角色，让它拥有所有命名空间的操作权限。

2. Helm Chart模板中硬编码了namespace #

如果你的spacestudychart里的资源模板（比如Deployment、Service等）写死了namespace: default，那么即使你在命令行指定了--namespace test，模板里的硬编码值会覆盖命令行参数。

检查方式：
打开Chart目录下的templates文件夹，查看所有YAML文件的metadata部分，比如：

metadata:
  name: {{ .Release.Name }}
  namespace: default  # 这里如果写死了就会出问题

修复步骤：
把硬编码的namespace: default改成namespace: {{ .Release.Namespace }}（这样会使用命令行指定的命名空间），或者直接删除这一行（Kubernetes会默认使用命令行/上下文指定的命名空间）。

3. 旧的Release记录干扰 #

如果之前你在default命名空间已经部署过同名的kubekubedeploy Release，即使这次指定了--namespace test，Helm可能会优先匹配已存在的Release（尤其是在Upgrade操作时）。

检查方式：
执行以下命令查看所有Release的位置：

helm list --all

如果发现kubekubedeploy存在于default命名空间，可以选择删除旧的Release：

helm delete --purge kubekubedeploy

然后重新执行你的部署命令。

4. 用Debug模式排查细节 #

为了更清楚地看到Helm部署时的参数和逻辑，可以在命令中加上--debug参数，这样能输出详细的日志，包括实际使用的命名空间、模板渲染后的内容等：

helm upgrade --install kubekubedeploy --namespace test pipeline/spacestudychart --debug

通过日志你可以直接看到Helm是否正确识别了--namespace test参数，以及模板渲染后的资源是否使用了正确的命名空间。

最后再确认一下test命名空间确实存在：

kubectl get namespaces

确保输出里能看到test命名空间的状态是Active。

内容的提问来源于stack exchange，提问作者Mr.DevEng