Kubernetes中的配置管理

Kubernetes处理部署的方式非常适合GitOps的工作流。例如，当一组配置更新由人工操作员进行时，Kubernetes orchestrator将继续应用这些更改，直到集群的状态收敛到人工进行的更新配置。对于任何类型的Kubernetes资源都是如此。

• Kubernetes部署具有以下特性，这些特性使它们非常适合Gitops风格的部署工作流：
  自动化：Kubernetes提供了一个用于自动化部署的内置机制。Kubernetes集群以正确的顺序和及时的方式应用一组更改。
• 收敛：Kubernetes将继续尝试进行更新，直到最终成功。
• 幂等性：多个同时收敛实例都有相同的结果。
• 确定性：假设集群有足够的可用资源，更新的集群状态将只依赖于所需的状态。

还可以使用Kubernetes自定义资源定义（CRDs）和operator模式来扩展和自动化Kubernetes部署。然后，可以使用这些代理在需要时自动检测和应用来自系统外部的配置更改，实质上创建反馈和控制循环。
管理现有的应用程序和基础设施配置，在不同的发布周期中对它们进行更改，并为所有微服务重复类似的结构–所有这些任务都可能容易出错且费力。为了解决这些不同的应用程序配置难题，有Kubernetes配置管理和打包工具可用。下面让我们来看看几个比较受欢迎的：

Helm

Helm基于参数化模板方法，其中应用程序的所有资源定义文件都被模板化，以使它们可以根据需求进行定制。如今，它被视为Kubernetes生态系统事实上的包管理器。它的作用就像APT/YUM/RPM包管理器，但对于Kubernetes来说。
它运行在掌舵图和模板的概念上，如下所示。当模板与值组合时，这些模板将有助于基于值/变量生成有效的Kubernetes清单。你可以在这里找到更多关于他们的信息。

Helm文件结构

test-chart/
├── charts #Required
├── Chart.yaml #Required
├── templates #Required
│ ├── deployment.yaml
│ ├── _helpers.tpl
│ ├── hpa.yaml
│ ├── ingress.yaml
│ ├── NOTES.txt
│ ├── serviceaccount.yaml
│ ├── service.yaml
│ └── tests
│ └── test-connection.yaml
└── values.yaml #Required

Kustomize

除了参数化模板之外，另一种管理方法是覆盖配置。Kustomize是一个基于这种方法的配置管理工具。

Kustomize提出了一个“在哪里、什么和如何”的概念来重构特定的Kubernetes显化。重构/更改的“where”是基本清单，例如，deployment.yaml。要更改的“什么”是要更改的YAML的覆盖或小片段，例如，副本计数、卷装入等。要更改的“如何”是kustomization/config文件。

├── base
│ ├── deployment.yaml
│ ├── kustomization.yaml
└── overlays
├── dev
│ ├── replica-count.yaml
│ └── kustomization.yaml
├── production
│ ├── replica-count.yaml
│ ├── kustomization.yaml
└── staging
├── kustomization.yaml
└── replica-count.yaml

Jsonnet

Jsonnet是一种由Google开源的编程语言，它提供配置管理作为其主要功能之一。它的使用并不仅仅局限于Kubernetes（尽管Kubernetes已经普及了它）。您可以将Jsonnet视为JSON和模板的组合。JSONet使您能够充分利用JSON所能做的一切。同样，它在本质上是陈述性的。
不幸的是，Jsonnet在Kubernetes社区中并没有被广泛采用，因为在过去的几年里，云本地社区对YAML的热爱占据了主导地位。