1. 概述
在 Kubernetes 中，命名空间（Namespace） 用于隔离集群内的资源，使得工作负载的管理更加清晰高效。虽然我们可以通过 kubectl 手动创建命名空间，但使用 Helm 模板可以带来更高的一致性、可重复性，并更好地支持基础设施即代码（Infrastructure as Code）的实践。
在小型环境中，手动创建命名空间或许可行，但随着集群规模扩大、多个团队共同部署应用时，手动方式难以维持一致性。Helm 允许我们将配置定义为可复用的模板，集成到 CI/CD 流水线中，实现跨环境的统一部署。
本教程将介绍如何使用 Helm 模板创建命名空间，从而在 Kubernetes 部署中实现一致性和可复用性。
2. 理解 Helm 模板中的命名空间
Helm 是 Kubernetes 的包管理器，它通过 Chart（图表） 来简化应用程序的部署。一个 Helm Chart 本质上是一组模板，用于以可重用和可定制的方式定义 Kubernetes 资源。
通过在 Helm 模板中定义命名空间，我们可以自动化部署流程并确保一致性。Helm 模板使用 Go 的模板语法来动态生成 YAML 文件，这让我们可以设置参数，如命名空间名称，并根据需要修改其他资源定义。这使部署更加灵活、易于管理。
3. 在 Helm 模板中定义命名空间
要使用 Helm 创建命名空间，我们可以定义一个包含必要模板的 Helm Chart。Helm 模板允许我们参数化配置，使得在不同环境中部署 Kubernetes 资源时无需修改核心 YAML 文件。
3.1 创建 Helm Chart
在定义命名空间之前，第一步是创建一个 Helm Chart 来存储模板。我们可以在命令行中生成一个名为 baeldung-namespace-chart 的新 Helm Chart：
$ helm create baeldung-namespace-chart
Creating baeldung-namespace-chart
这将创建一个目录结构，其中包含一个 templates 目录，我们将在该目录中定义 Kubernetes 资源。不过，默认情况下，templates 目录中不会包含 namespace.yaml 文件，我们需要手动创建它来定义所需的命名空间。
3.2 编写命名空间模板
要定义命名空间资源，我们手动在 templates 目录下创建一个名为 namespace.yaml 的新 Helm 模板文件。文件路径应为 baeldung-namespace-chart/templates/namespace.yaml，内容如下：
apiVersion: v1
kind: Namespace
metadata:
name: {{ .Values.namespace.name }}
labels:
environment: {{ .Values.namespace.environment }}
app: {{ .Values.namespace.app }}
在这个模板中，{{ .Values.namespace.name }}、{{ .Values.namespace.environment }} 和 {{ .Values.namespace.app }} 是占位符，它们将从 values.yaml 文件中动态填充。这种做法允许我们在不直接修改模板的情况下自定义命名空间。
添加如 environment 和 app 的标签是可选的，但属于最佳实践。它有助于更好地组织资源并在集群中进行过滤。
3.3 更新 values.yaml 文件
为了给模板提供值，我们将配置添加到 Helm Chart 目录中的 values.yaml 文件中。文件路径是 baeldung-namespace-chart/values.yaml：
namespace:
name: baeldung-ops
environment: dev
app: ops-app
此配置确保 Helm Chart 在部署时创建一个名为 baeldung-ops 的命名空间，并带有指定的环境和应用标签。通过将这些值与模板分离，我们提高了灵活性、可复用性，并简化了跨多个环境和部署的更新。
4. 使用 Helm 部署命名空间
有了 Helm Chart 和 values.yaml 配置后，我们现在可以将命名空间部署到 Kubernetes 集群中。Helm 简化了这一过程，通过高效渲染模板并无缝应用生成的清单，确保一致性并避免手动配置错误。
4.1 安装 Helm Chart
要部署命名空间，运行以下 helm install 命令：
$ helm install my-namespace baeldung-namespace-chart
在此命令中，my-namespace 是发布名称，baeldung-namespace-chart 是 Chart 目录。Helm 会从 values.yaml 中获取值，处理 namespace.yaml 模板，并将生成的清单应用到集群中。
4.2 验证命名空间
Chart 安装完成后，我们使用 kubectl 命令验证命名空间是否创建成功：
$ kubectl get namespaces
NAME STATUS AGE
baeldung-ops Active 10s
default Active 50m
kube-system Active 50m
kube-public Active 50m
输出显示了新创建的 baeldung-ops 命名空间以及已有的命名空间。
5. 卸载命名空间
当我们想要删除命名空间及其内部所有部署的资源时，最有效的方式是卸载 Helm 发布。这将确保 Helm 正确清理 Chart 中定义的所有资源。
要卸载发布，运行以下 helm uninstall 命令：
$ helm uninstall my-namespace
此命令会触发 Helm 删除与该发布相关的所有资源，包括如果在 Chart 中定义了命名空间，则会一并删除。
但是，Helm 只会删除由 Chart 管理的资源。如果在命名空间中手动创建了外部资源（例如持久卷），它们将不会被删除。因此，最好验证命名空间是否已被完全删除：
$ kubectl get namespaces
如果 baeldung-ops 命名空间不再出现在输出中，说明 Helm 已成功将其删除。否则，如果命名空间仍然存在，可能表示存在未被管理的资源。在这种情况下，我们需要手动删除命名空间：
$ kubectl delete namespace baeldung-ops
通过这种方式处理，我们可以避免留下孤立资源，从而避免在未来的部署中出现问题。
6. Helm 使用最佳实践
有效地使用 Helm 管理 Kubernetes 命名空间，需要遵循一些最佳实践，以提高效率并防止配置错误。通过关注这些策略，我们可以维护一个更稳定、可扩展的集群：
| 实践 | 关键要点 |
|---|---|
| 为命名空间 Chart 使用版本控制 | 将命名空间相关的 Helm Chart 存储在 Git 仓库中，有助于跟踪变更、保持一致性，并在需要时回滚配置。 |
| 参数化命名空间值 | 在 values.yaml 中定义命名空间名称和标签，允许在不同环境中部署时无需修改 Chart 本身。 |
| 应用前验证命名空间模板 | 使用 helm template 可以预览生成的清单，并在应用更改到集群之前捕获潜在的语法错误。 |
| 在命名空间级别实施 RBAC | 在命名空间内实施基于角色的访问控制（RBAC）可防止未经授权的访问，增强安全边界。 |
| 将命名空间管理与应用资源分离 | 将命名空间作为单独的 Helm 发布进行部署，避免在升级 Chart 时意外删除。 |
| 自动清理未使用的命名空间 | 使用 Helm Hook 或自动化脚本，在 Helm 发布删除后清理未使用的命名空间，防止资源膨胀并优化集群管理。 |
通过遵循这些最佳实践，我们可以充分发挥 Helm 在管理 Kubernetes 命名空间方面的优势。这种方法简化了命名空间的创建，减少了配置错误的可能性，并增强了安全边界。最终，它确保我们的集群在环境演进过程中保持组织良好、易于扩展。
7. 总结
在本文中，我们探讨了 Helm 如何简化 Kubernetes 资源管理，特别是在创建命名空间方面。通过在 Helm Chart 中定义资源，我们可以简化部署流程并更好地控制集群。
我们还涵盖了关键的最佳实践，如在 values.yaml 中管理值、在应用前验证模板、以及实施 RBAC 以增强安全性。这些策略有助于防止常见错误并提高集群稳定性。
最终，Helm 使我们能够高效地管理 Kubernetes 资源，并适应不同的部署环境。通过遵循本文中介绍的最佳实践，我们可以维护一个干净、有组织的集群，随着工作负载的增长而轻松扩展，使 Kubernetes 的使用体验更加顺畅。