谈谈 Kubernetes Operator

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

简介

你可能听过Kubernetes中Operator的概念，Operator可以帮助我们扩展Kubernetes功能，包括管理任何有状态应用程序。我们看到了它被用于有状态基础设施应用程序的许多可能性，包括版本升级、节点恢复、调整集群大小等。

本文我们将揭开Operator的神秘面纱，为如何构建可应用于实际的自定义Operator打下坚实的基础。

operator到底是什么？

为了说明operator到底是什么，让我们回到Kubernetes的架构上来，Kubernetes本质上是理想的状态管理器。你为你的应用程序提供了所需的状态（实例数，磁盘空间，使用的镜像等），并且如果任何事情失控，它都会尝试保持该状态。Kubernetes在Master节点上使用控制面，控制面包含许多控制器，这些控制器的工作是按照下面的方式与期望的状态进行协调（Reconcile）:

监视现有的K8S对象（pods,deployments等）去确定他们的状态
比较该对象和它的K8s yaml配置
如果状态和配置不同，控制器将尝试进行修复（remedy）

进行协调的一个常见的场景是：

一个pod被定义了三个副本，当一个挂了，K8s控制器的监视（watching）下，它意识到应该运行三个pod,而不是两个，然后，它将创建一个新的pod实例。

下图简单展示了控制器在K8s架构中的作用：

kubectl CLI发送一个对象配置(Pod,Deployment等)到Master Node的API Server以便在集群运行
Master Node将调度（schedule）对象去运行
一旦运行，一个控制器将持续件事这个对象并根据它的配置不断协调（Reconcile）

通过这种方式，Kubernetes方便的代替了大量手动工作，以维护运行时的无状态应用。然而，它仅限于K8S预定义的对象类型（Pod，Deployment,Namespace,Service,DaemonSet等），这些对象类型中的每一个都具有预定的行为和方式，如果它们和配置发生了偏离，他们就会与配置相协调（Reconcile），以达到所期望的配置。

现在，如果您的应用程序有更多复杂性，那么你需要自定义Operator以将达到期望的运行状态。

我们考虑一个有状态的应用程序，有一个运行在多个节点上的数据库应用程序。如果大多数节点出现故障，则需要按照特定步骤从指定快照重新加载数据库。使用Kubernetes中现有的对象类型和控制器，这是不可能实现的。再考虑节点扩容，升级新版本，或为我们的有状态应用程序进行灾难恢复。这些类型的操作通常需要非常具体的步骤，并且通常需要手动干预。

Kubernetes Operators允许你定义一个自定义控制器来watch你的应用程序并根据其状态执行自定义任务，从而扩展了Kubernetes（这是使我们上述的有状态应用程序自动维护的完美选择）。

你想要watch的应用程序在Kubernetes中被定义为一个新对象，一个CR（Custom Resource），它有自己的yaml spec和被API Server理解的对象类型（kind）。这样，你可以在自定义spec中定义任何需要关注的特定标准，并在实例与期望不匹配时进行协调。虽然Operator Controller主要使用自定义组件，但是它的spec和本地Kubernetes的控制器非常相似。