认识Kapitan 。 它可以帮助您为Kubernetes配置带来美感和秩序。
Kapitan从满意的用户评论中赢得声誉，因此免除了广泛的文档和昂贵的营销。 Kubernetes博客和传教士对我们有足够的评价和提及。 卡皮坦甚至成为本书整章的主角。 最重要的是，他吸引了几家有前途的公司的注意力，因为Kapitan和其他公司一样，能够解开与海结有关的配置 。
在kubernetes.slack.com上，＃ kapitan设法聚集了一个小而敬业的社区（加入！），所以我们为我们的工作感到自豪：）
许多人仍然认为Kapitan是jsonnet和jinja的混合体，但他们没有指出要点。
在这篇文章中，我将告诉您Kapitan如何管理Kubernetes部署，但总的来说，它还具有更多功能。 这很重要：Kapitan是通用的，并且不固定在一个Kubernetes上。 Kubernetes只是众多用途之一。
这不是指南（尽管我也承诺提供指南）。 我只想告诉您我们为什么这样做，以及它应该解决的Kubernetes配置部署有哪些问题。
我不喜欢的
我从2015年开始尝试Kubernetes，并立即坠入爱河。
确实，我不想忍受几个缺点：
- 语境 。 对我来说，这是理解Kubernetes的最困难的概念之一，也是最危险的概念之一。 上下文是指客户端，这很难理解，在运行kubectl命令时会被混淆地调用并造成混乱。 我讨厌kubectl中的上下文！
- 详细的嵌套配置（yaml！） 。 我不得不出汗以找出清单中每个Yaml配置级别。 在几个地方重复标签两到三遍的意义何在？
- 与命令性和声明性团队混为一谈 。 尽管很明显普通人不使用Kubernetes，但鼓励命令团队学习新手。 我认为，要使Kubernetes适应您公司的正确部署策略就更困难了。 破坏者：没有单一的“正确策略”。
- 运行时配置 。 Jesse Suen 建议不要将配置参数传递给helm命令行（或kubectl等类似命令）时是正确的。 使用参数，同一命令每次可以不同地执行。
- 应用配置 我们了解了如何在Kubernetes中管理Yaml清单，我们很棒。 这就是部署和部署-这是一个空碗。 它仍然必须使用所有配置浮动应用程序。
- 开发人员希望度过一个假期 ，而Kubernetes的工作流程仍然有些混乱。 Kubernetes的拥护者迫使所有人都去那里做。 有必要吗？ 服从Kelsey Hightower！
- 经营者 我对他们有不同的感觉，所以现在就离开这个话题:)我只能说他们经常被滥用。
- 幂等 。 而是她的缺席。 如果我们总结以上所有缺点，我们将得到幂等的工作流，这对于Kubernetes来说是可悲的。
怎么办
我试图解决这些问题，并建立了一个小型模板系统，该系统使用j2cli和几个bash脚本来管理Kubernetes配置。
系统将所有内容都放入environmentA.yaml文件中，并在Jinja2模板中使用了它。 使用一个简单的命令就可以从几个组件部署微服务风格的应用程序：
bin/apply.sh environments/environmentA.yaml
好酷！ Yaml与部署有关。 这非常方便，因为我可以将同一文件用作其他信息的来源。 说... bash脚本 ！
我想出了如何将yaml中的值导入脚本以执行类似的命令：
bin/create_kafka_topics.sh environments/environmentA.yaml
然后，一切立即失去控制 ：
- 我无法对yaml文件中的结构进行任何操作。 它是相同字段，值和混乱配置的混搭。
- 尝试之前，您永远不会知道如何在环境中进行行为部署。 通常这是由于在没有定义此功能的环境中无法使用的新清单值（例如，feature_X）导致jinja2模板发生了更改。
- 脚本也有同样的麻烦：如果不尝试，就会不知道。
- 有时Kubernetes更改如此之快，以至于困扰我不断地更改不同版本的清单，尤其是弄乱了值的注释。
- 外部因素 ：开发团队从配置文件切换到命令行参数。 这种微小的变化使我们感到困惑，因此我们不得不考虑一种新的解决方案。
- 最重要的是 ：用Jinja（或Go模板）来模板yaml并不有趣！ 然后，我们有一个谜语：“ 是什么看起来像文本，读起来像文本，闻起来像文本，而不是文本？ ”。 或者，正如李·布里格斯（Lee Briggs）恰当地指出的那样：“ 为什么我们要模板yaml？ ”
Kapitan：成为
我们收集了所有痛苦的经验，并与Ricardo Amaro一起幻想着理想的配置管理系统。 那时我们仍然没有清晰的画面，但是我们知道我们爱过，我们不爱过。
爱 ：
- 吉特
- 常规模式：数据/值与模式分开。
- 不同方面（应用程序，Kubernetes，运行时...）的单独值。
- 面向对象的方法。
- 简化的yaml作为隐藏Kubernetes复杂性的接口。
- 清楚了解正在发生的事情以及原因。
- 在不同组件中重复使用值。
- 并且脚本应该有权访问值。
我们不喜欢 ：
- Kubectl上下文
- 用于创建Yaml的文本模板引擎。
- 缩进计数：
{{ toYaml .Values.resources | indent 10 }} {{ toYaml .Values.resources | indent 10 }} 。 - 魔术：一切都应该清晰明了。 没有技巧
- 手动管理应用程序的密码和机密。
- 分iller方式：我们想控制清单的使用。
- Git-crypt方法：磁盘上的机密未加密。
- 模板管道直接到kubectl。
- 传递命令行选项。
然后发生了两件事 ：
- 我们发现了戴夫·坎宁安（Dave Cunningham）的jsonnet ，以一种面向对象的语言来模板化yaml / json。
- 古斯塔沃·布里奥拉（Gustavo Buriola）向我们展示了重新分类 ，没有他，我们就不会走得太远。
里卡多·阿玛罗（Ricardo Amaro）开始工作，很快整个团队就坐在Kapitan上-一些人从事基本功能的工作，其他人则在我们内部项目中的使用。 秘密管理，gpg \ kms支持，用户定义的功能：现在，Kapitan是功能完善的产品，其功能超出了预期。
谁是卡皮丹？
Kapitan试图解决我所谈论的所有（或几乎所有）问题。
从技术角度来看， Kapitan非常简单：
- 库存 ：描述基于yaml的部署的值的分层集合。 基于重分类。 像希拉。
- 模板引擎 ：现在是Jinja2，Jsonnet，Kadet。 他们盘点并创建文件（yaml，json，文档或bash脚本）。
- 机密 ：模板机密，Kapitan将对其进行处理。
我们正在使用jsonnet来制作宣言模板，而Jinja来完成其余工作。
有时人们会抱怨jsonnet文件与同一个Yaml完全不同，因此他们很难切换到jsonnet。
我们试图通过用python封装yaml来解决Kadet的问题。 以您最喜欢的yaml为基础，并向其中添加Python。
认为这是yaml的Python外骨骼 ！ 我会以某种方式谈论这个。
在工作流程中， Kapitan立即显示以下字符：
- 自由选择 ：我们不强加任何工作流程和技术，但通常会按照以下描述的原则进行工作。 实际上，可以根据需要使用Kapitan。 您不需要使用git，也不必在其中编译文件，甚至可以不用jsonnet！ 做你想做的。
- 骨头骨髓的GitOps ：一切都在git中，一切都在主光下反映了我们的意图。
- 可声明性 ：Kapitan欢迎以特定表示形式的清单模板的编译。 然后您编译脚本。
- 受控上下文 ：例如，在设置上下文和配置集群时，我们使用编译脚本来简化工作。
Kubernetes配置： compiled/target_A/setup/setup.sh
应用更改： compiled/target_A/setup/apply.sh - 幂等性 ：Kapitan允许您更改模板和代码重构工具。 没有命令，编译的清单和代码将不会更改，因此重构时无需担心。
- 原因和结果 ：我们的工作流程是在一个合并请求中包含对清单或模板的更改以及已编译文件的更改。 因此，审阅者将能够评估您的更改及其实际后果。 很高兴知道模板的更改是否会影响一个，两个或多个目标。
- 最后 ：Kapitan不隶属于Kubernetes。 它只是创建文件。 部署变更涉及到kubectl 。 我们只为以一致的方式执行命令提供外壳。
我需要吗？
让我们说清楚 ：您可能还不需要Kapitan。
但这完全取决于您要执行的操作以及系统的复杂程度。
Kapitan是强大的投资工具 。 在必须在一堆群集上部署一堆应用程序的复杂场景中使用它。
如果您具有标准应用程序，那么您只是在学习Kubernetes或已经对您的工作流程感到满意，那么Helm或它的当前替代品将起作用。
我想Helm是Kubernetes的最佳选择 ，而Kapitan就像Puppet一样。
在下一篇文章中，我将给出具体示例并详细描述清单。 在这篇文章中写出您想知道的内容或您同意/不同意的内容。
感谢Jacek Gruzewski 。