Kubernetes资源管理的四种方式

【编者的话】本文将介绍4种管理Kubernetes资源的方法和工具，每一种方法和工具都是为处于Kubernetes旅程不同阶段的组织准备的。

Kubectl，新的ssh

当我开始接触Linux系统时，我首先要了解的工具是ssh。天啊，这是一个多么美妙和强大的软件啊。你不仅可以登录到你的服务器，复制文件，还可以创建vpn，省略SOCKS代理和端口转发规则的防火墙，等等。但是，对于Kubernetes，这个工具主要用于节点维护，前提是你仍然需要管理它们，并且没有切换到CoreOS或不可变节点类型的另一种变体。对于其他情况，可以使用kubectl，它是新的ssh。如果你不直接使用API调用，那么你可能会以某种形式使用它，并为它提供大量的yaml文件。让我们面对现实吧——这就是如今管理Kubernetes环境的样子。你用Kubernetes的资源定义创建了那些漂亮的、冗长的文本文件，然后神奇的事情发生了，你成了今天的英雄。除非你想用不同的配置创建几十个甚至上百个。这就是事情变得复杂的时候。

简单vs灵活

对于基本场景，简单的yaml文件就足够了。然而，随着环境的增长，资源和配置的数量也在增长。你可能会开始注意到创建应用程序的新实例、重新配置已经运行的应用程序、与社区或希望根据需要自定义应用程序的客户共享应用程序所花费的时间更多。目前，我发现以下是最常用的方法:

• 纯yaml文件
• Kustomize
• Helm图表
• 自动化Operator

它们都可以用来管理你的资源，而且它们在许多方面也有所不同。其中一个明显的因素是复杂性，这也意味着需要花费很多精力来学习、使用和维护一个特定的方法。另一方面，当你真正想要创建复杂的配置时，从长远来看，这样做可能会有好处。你可以在下图中观察到这种关系:
[attach]27053[/attach]
所以在灵活性和简单性之间存在权衡。对一些人来说，简单是可以取胜的，但对另一些人来说，这还远远不够。让我们仔细看看这四种方法，看看它们在哪些情况下最适合。

1、使用纯yaml文件保持简单

我总是告诉参加我的课程的人，通过学习Kubernetes，他们可以成为yaml程序员。这可能听起来很傻，但实际上，Kubernetes的基本用法归根结底就是用yaml编写一些对象的定义。当然，你必须知道两件事——第一件是你想要创建什么，第二件是关于Kubernetes API的知识，它是这些yaml文件的基础。

在你学习了如何编写yaml文件之后，你可以使用kubectl将其发送到Kubernetes，这样你的工作就完成了。没有参数，没有模板，也不知道如何改变它。如果你想创建应用程序或整个环境的附加实例，只需复制和粘贴即可。当然，这里会有一些重复，但这是为了简单所付出的代价。此外，在一些情况下，这不是什么大问题，大多数组织可能可以接受这个不完美的解决方案，至少在他们旅途不尽如人意的时候是可以的。

何时使用：

• 对于应用程序或环境的配置/实例少于4个的项目
• 对于小型创业公司
• 大公司开始他们的第一个Kubernetes项目（例如作为PoC的一部分）
• 学习Kubernetes API的个人

何时避免：

• 发布针对Kubernetes环境的产品或服务的组织和项目
• 在项目中，每个实例都有很大的差异，需要大量的调整

2、使用Kustomize

Kustomize是Kubernetes官方团体之一的一个项目。它定义了基于继承的Kubernetes资源的概念，yaml文件，没错——你逃不掉的。但是，这一次，使用Kustomize，你可以对已经存在的资源集应用任何你想要的更改。简单地说，Kustomize可以看作是一个Kubernetes特有的补丁工具。它让你覆盖所有部分的yaml文件与其他功能，包括以下：

• 更改容器镜像的存储库、名称和标记
• 直接从文件生成ConfigMap对象，并生成散列，确保部署在发生更改时触发新的rollout
• 使用kustomize cli动态修改配置（在CI/CD管道中非常有用）

从1.14版开始，它就内置在kubectl二进制文件中，这使它很容易开始。不幸的是，在独立的kustomize项目中添加新特性的速度要快得多，而且它的发布周期与kubectl二进制文件的官方版本不同步。因此，我强烈建议使用它的独立版本，而不是kubectl的内置功能。

根据其创建者的说法，它鼓励你直接使用Kubernetes API，而无需创建另一个人工抽象层。

何时使用：

• 对于不需要太多参数的少于10个配置/实例的项目
• 对于开始成长但仍在内部使用Kubernetes的初创公司（即不需要将清单作为其产品的一部分）
• 对于任何知道Kubernetes API的人来说，都可以直接使用它

何时避免：

• 如果你的环境或实例最多变化30-50%，因为你只需通过添加补丁来重写大部分清单
• 与普通yamls的情况相同

3、进阶，强大的Helm图表

如果你还没有见过Helm Hub，那么我建议你去做，并寻找你最喜欢的软件，特别是如果它是一个流行的开源项目，我非常确定它在那里。随着Helm 3的发布，它的大部分缺陷都得到了修复。实际上，最大的组件是不再需要的Tiller组件，这使其成为你部署的绝佳工具。对于OpenShift用户来说，这也是一种解脱，因为它的模板系统太简单了（我尽量避免使用“糟糕”这个词，但它确实很简单）。

大多数已经开始使用Helm部署这些就绪服务的人常常开始为应用程序编写自己的图表，以及在Kubernetes上部署的几乎所有东西。对于非常复杂的配置来说，这可能是一个好主意，但是在大多数情况下，这是多余的。如果你没有将图表发布到某个注册表（甚至很快也会发布到容器注册表），而只是使用它们的模板特性（在Helm 3中，最终可以不下载图表的源代码），那么使用Kustomize可能会更好。

然而，对于高级场景，Helm才是正确的选择。它可以是你用来发布应用程序以供其他团队将其部署到其环境中的单一工具。你的客户也可以使用一个简单的命令——字面上就是掌舵升级你的图表——来部署你的应用程序的一个新版本。

• 以能够处理所有这些情况和配置变量的方式编写图表模板
• 使用CI/CD管道、测试和发布来创建和维护整个发布过程

Helm Hub上的许多示例显示了如何将复杂的软件打包到一个图表中，从而使安装过程变得非常简单，并使定制变得更容易访问，特别是对于不想深入了解太多细节的最终用户。我自己也使用许多Helm Charts来安装软件，并将其视为Kubernetes生态系统中最重要的项目之一。

何时使用：

• 对于拥有超过10个配置/实例的大型项目，这些配置/实例有许多变量和参数
• 用于在Internet上发布以使其易于安装的项目

何时避免：

• 如果你的应用程序不是那么复杂，并且你不需要在任何地方发布它们
• 如果你不打算为发布过程维护CI/CD，因为维护没有管道的图表是非常耗时的
• 如果你对Kubernetes API还没有深入的了解

4、自动化机器人（Operator）为你服务

最后一个，最复杂的，也是最强大的。实际上，这是CoreOS（现在的Red Hat）提出的一种设计模式，它只是利用Kubernetes的一些特性，比如自定义资源定义和内嵌在直接运行在Kubernetes上的软件中的自定义逻辑，并利用其称为controller的内部API。它在OpenShift生态系统中得到了广泛的应用，并且自从OpenShift 4发布以来，红帽公司一直在推广它，认为它是在OpenShift上创建服务的最佳方式。他们甚至提供了一个定制OpenShift web界面的操作符。这就是我所说的抽象层！这里的一切都由几十个自定义操作符处理yaml来控制，因为整个逻辑都嵌入在这里。

简单地说，什么是Operator，我想说Operator是一个等价的云服务，如亚马逊RDS，GCP云发布/订阅或Azure Cosmos数据库。你可以构建一个操作符来提供一种一致的、简单的方法来安装和维护（包括升级）你的应用程序，在任何Kubernetes平台上都可以使用其本机API以“即服务”的方式安装和维护应用程序。它不仅提供了最高级别的自动化，而且还允许包括复杂的逻辑，如内置监视、无缝升级、自修复和自动标度。同样，你需要做的只是提供一个yaml格式的定义，其余的将由操作符处理。

“它看起来太棒了！有人会说。许多人认为它应该而且将是交付应用程序的首选方式。我不同意这种说法。我认为，如果你是一个软件供应商，为数百个客户（甚至是内部客户）提供你的应用程序，这就是该走的路。否则，编写操作符可能过于复杂和耗时。特别是如果你想要遵循最佳实践，使用Golang并提供一个简单的升级路径（它可能会变得棘手）。

我发现以下项目对Operator的开发和维护非常有帮助：

• kubebuilder：第一个面向Go开发者的操作框架，最强大、最复杂的一个
• kopf：用于在Python KUDO中开发操作符的kopf框架——以声明的方式编写操作符
• operator-sdk：来自CoreOSRed Hat的框架，用于在Go和Ansible中编写操作符
• operator-lifecycle：对于任何有兴趣认真对待操作器及其lifrecycle（安装、维护、升级）的人来说，这是必须的。

何时使用：

• 如果你需要在Kubernetes上创建自己的服务（例如，你的产品即服务）
• 如果你计划为你的服务添加额外的功能（例如监视、自动缩放、自动愈合、分析）
• 如果你是为Kubernetes平台提供软件的软件供应商
• 如果你想开发安装在OpenShift上的软件，并成为OpenShift生态系统的一部分（例如，在他们的“应用市场”上发布你的软件——operatorhu.io）

何时避免：

• 对于简单的应用程序
• 对于其他应用时，舵轮图用一些半复杂的模板就可以了
• 当不需要额外的自动化时，或者可以通过现有组件的简单配置来实现

总结

我所描述的每一种方法和工具都是为处于Kubernetes旅程不同阶段的组织准备的。对于标准用例，简单的yamls可能就足够了，随着更多的应用，Kustomize可以极大地增强这种方法。当事情变得严重和应用程序变得更复杂时，Helm Chart在复杂性和灵活性之间提供了一个完美的平衡。对于在Kubernetes中以类似于云服务的方式交付应用程序的供应商，以及那些计划使用OpenShift为企业客户提供应用程序的供应商，我可以推荐Operator。

原文链接：4 ways to manage Kubernetes resources