M

MLOG

中文

深入探讨 Kubernetes Operator，解释其如何简化和自动化复杂应用及自定义资源的管理。学习如何构建和部署您自己的 Operator。

Kubernetes Operator：自动化自定义资源管理

Kubernetes 彻底改变了我们部署和管理应用程序的方式。然而，管理复杂的有状态应用程序仍然可能具有挑战性。这就是 Kubernetes Operator 发挥作用的地方，它提供了一种强大的方式来自动化应用程序管理并扩展 Kubernetes 的能力。

什么是 Kubernetes Operator？

Kubernetes Operator 是一种特定于应用程序的控制器，它扩展了 Kubernetes API 以管理复杂的应用程序。可以把它想象成一个自动化的系统管理员，专门为某个特定应用程序量身定制。Operator 封装了操作特定应用程序的领域知识，使您能够以声明式、自动化和可重复的方式对其进行管理。

与管理 Pod 和 Service 等核心资源的传统 Kubernetes 控制器不同，Operator 管理通过自定义资源定义 (CRD) 定义的自定义资源。这使您可以定义自己的特定于应用程序的资源，并让 Kubernetes 自动管理它们。

为何使用 Kubernetes Operator？

Operator 为管理复杂应用程序提供了几个关键优势：

理解自定义资源定义 (CRD)

自定义资源定义 (CRD) 是 Kubernetes Operator 的基础。CRD 允许您通过定义自己的自定义资源类型来扩展 Kubernetes API。这些资源被视为像 Pod 或 Service 一样的任何其他 Kubernetes 资源，并且可以使用 `kubectl` 和其他 Kubernetes 工具进行管理。

CRD 的工作原理如下：

  1. 您定义一个 CRD，为您的自定义资源指定模式和验证规则。
  2. 您将 CRD 部署到您的 Kubernetes 集群。
  3. 您创建自定义资源的实例，并指定所需的配置。
  4. Operator 监视这些自定义资源的更改，并采取行动协调期望状态与实际状态。

例如，假设您想使用 Operator 管理一个数据库应用程序。您可以定义一个名为 `Database` 的 CRD，其中包含 `name`、`version`、`storageSize` 和 `replicas` 等字段。然后，Operator 将监视 `Database` 资源的更改，并相应地创建或更新底层的数据库实例。

Kubernetes Operator 的工作原理

Kubernetes Operator 通过将自定义资源定义 (CRD) 与自定义控制器相结合来工作。控制器监视自定义资源的更改，并采取行动来协调期望状态与实际状态。此过程通常涉及以下步骤：

  1. 监视事件：Operator 监视与自定义资源相关的事件，例如创建、删除或更新。
  2. 协调状态：当事件发生时，Operator 会协调应用程序的状态。这包括将期望状态（在自定义资源中定义）与实际状态进行比较，并采取行动使它们保持一致。
  3. 管理资源：Operator 创建、更新或删除 Kubernetes 资源（Pod、Service、Deployment 等）以达到期望状态。
  4. 处理错误：Operator 处理错误并重试失败的操作，以确保应用程序保持一致状态。
  5. 提供反馈：Operator 提供有关应用程序状态的反馈，例如健康检查和资源利用率。

协调循环 (reconcile loop) 是 Operator 逻辑的核心。它持续监控应用程序的状态，并采取行动以维持期望状态。这个循环通常通过一个执行必要操作的协调函数来实现。

构建您自己的 Kubernetes Operator

有几种工具和框架可以帮助您构建 Kubernetes Operator：

以下是使用 Operator Framework 构建 Operator 所涉及步骤的简化概述：

  1. 定义自定义资源定义 (CRD)：创建一个 CRD 来描述您应用程序的期望状态。这将为您的自定义资源定义模式和验证规则。
  2. 生成 Operator 代码：使用 Operator SDK 基于您的 CRD 生成初始的 Operator 代码。这将创建必要的控制器和资源定义。
  3. 实现协调逻辑：实现协调逻辑，将期望状态（在自定义资源中定义）与实际状态进行比较，并采取行动使它们保持一致。这是您 Operator 功能的核心。
  4. 构建和部署 Operator：构建 Operator 镜像并将其部署到您的 Kubernetes 集群。
  5. 测试和迭代：彻底测试您的 Operator，并对代码进行迭代以提高其功能和可靠性。

让我们用一个使用 Operator Framework 的基本示例来说明。假设您想创建一个 Operator 来管理一个简单的 `Memcached` 部署。

1. 定义 CRD：

创建一个包含以下 CRD 定义的 `memcached.yaml` 文件：


apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: memcacheds.cache.example.com
spec:
  group: cache.example.com
  versions:
    - name: v1alpha1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                size:
                  type: integer
                  description: Size 是 Memcached 实例的数量
              required: ["size"]
  scope: Namespaced
  names:
    plural: memcacheds
    singular: memcached
    kind: Memcached
    shortNames: ["mc"]

此 CRD 定义了一个 `Memcached` 资源，带有一个 `size` 字段，用于指定要运行的 Memcached 实例的数量。

2. 生成 Operator 代码：

使用 Operator SDK 生成初始的 Operator 代码：


operator-sdk init --domain=example.com --repo=github.com/example/memcached-operator
operator-sdk create api --group=cache --version=v1alpha1 --kind=Memcached --resource --controller

这将为您的 Operator 生成必要的文件和目录，包括控制器代码和资源定义。

3. 实现协调逻辑：

编辑 `controllers/memcached_controller.go` 文件以实现协调逻辑。该函数将根据 `Memcached` 资源中定义的期望状态来创建、更新或删除 Memcached 部署。


func (r *MemcachedReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
	log := r.Log.WithValues("memcached", req.NamespacedName)

	// 获取 Memcached 实例
	memcached := &cachev1alpha1.Memcached{}
	err := r.Get(ctx, req.NamespacedName, memcached)
	if err != nil {
		if errors.IsNotFound(err) {
			// 请求对象未找到，可能在协调请求后已被删除。
			// 所拥有的对象会自动进行垃圾回收。对于额外的清理逻辑，请使用 finalizer。
			// 返回且不重新入队
			log.Info("Memcached 资源未找到。由于对象必须被删除，因此忽略")
			return ctrl.Result{}, nil
		}
		// 读取对象时出错 - 重新将请求入队。
		log.Error(err, "获取 Memcached 失败")
		return ctrl.Result{}, err
	}

	// 定义一个新的 Deployment 对象
	deployment := &appsv1.Deployment{
		ObjectMeta: metav1.ObjectMeta{
			Name:      memcached.Name,
			Namespace: memcached.Namespace,
		},
		Spec: appsv1.DeploymentSpec{
			Replicas: &memcached.Spec.Size,
			Selector: &metav1.LabelSelector{
				MatchLabels: map[string]string{
					"app": memcached.Name,
				},
			},
			Template: corev1.PodTemplateSpec{
				ObjectMeta: metav1.ObjectMeta{
					Labels: map[string]string{
						"app": memcached.Name,
					},
				},
				Spec: corev1.PodSpec{
					Containers: []corev1.Container{
						{
							Name:  "memcached",
							Image: "memcached:1.6.17-alpine",
							Ports: []corev1.ContainerPort{
								{
									ContainerPort: 11211,
								},
							},
						},
					},
				},
			},
		},
	}

	// 将 Memcached 实例设置为所有者和控制器
	if err := ctrl.SetControllerReference(memcached, deployment, r.Scheme);
		err != nil {
			log.Error(err, "设置控制器引用失败")
			return ctrl.Result{}, err
	}

	// 检查此 Deployment 是否已存在
	found := &appsv1.Deployment{}
	err = r.Get(ctx, types.NamespacedName{
		Name:      deployment.Name,
		Namespace: deployment.Namespace,
	}, found)
	if err != nil && errors.IsNotFound(err) {
		log.Info("正在创建一个新的 Deployment", "Deployment.Namespace", deployment.Namespace, "Deployment.Name", deployment.Name)
		err = r.Create(ctx, deployment)
		if err != nil {
			log.Error(err, "创建新 Deployment 失败", "Deployment.Namespace", deployment.Namespace, "Deployment.Name", deployment.Name)
			return ctrl.Result{}, err
		}

		// Deployment 创建成功 - 返回并重新入队
		return ctrl.Result{Requeue: true}, nil
	} else if err != nil {
		log.Error(err, "获取 Deployment 失败")
		return ctrl.Result{}, err
	}

	// 确保部署的副本数量与 spec 中的一致
	size := memcached.Spec.Size
	if *found.Spec.Replicas != size {
		log.Info("正在更新 Deployment", "Deployment.Namespace", deployment.Namespace, "Deployment.Name", deployment.Name)
		found.Spec.Replicas = &size
		err = r.Update(ctx, found)
		if err != nil {
			log.Error(err, "更新 Deployment 失败", "Deployment.Namespace", deployment.Namespace, "Deployment.Name", deployment.Name)
			return ctrl.Result{}, err
		}
		// Spec 已更新 - 返回并重新入队
		return ctrl.Result{Requeue: true}, nil
	}

	// Deployment 已存在 - 不重新入队
	log.Info("跳过协调：Deployment 已存在", "Deployment.Namespace", deployment.Namespace, "Deployment.Name", deployment.Name)
	return ctrl.Result{}, nil
}

这个例子是协调逻辑的一个非常简化的版本。一个生产就绪的 Operator 将需要更强大的错误处理、日志记录和配置选项。

4. 构建和部署 Operator：

使用 `make deploy` 构建 Operator 镜像并将其部署到您的 Kubernetes 集群。

5. 创建一个 Memcached 资源：

创建一个包含以下内容的 `memcached-instance.yaml` 文件：


apiVersion: cache.example.com/v1alpha1
kind: Memcached
metadata:
  name: memcached-sample
spec:
  size: 3

使用 `kubectl apply -f memcached-instance.yaml` 将此文件应用到您的集群。

Operator 现在将创建一个包含 3 个 Memcached 实例的 Deployment。

开发 Kubernetes Operator 的最佳实践

开发高效的 Kubernetes Operator 需要周密的规划和执行。以下是一些需要牢记的最佳实践：

Kubernetes Operator 的真实世界案例

许多组织正在使用 Kubernetes Operator 来管理生产中的复杂应用程序。以下是一些例子：

这些只是众多可用的 Kubernetes Operator 中的几个例子。随着 Kubernetes 的采用率持续增长，我们可以预期会涌现出更多的 Operator，从而简化更广泛应用程序的管理。

Kubernetes Operator 的安全注意事项

Kubernetes Operator 与在 Kubernetes 集群中运行的任何应用程序一样，需要仔细考虑安全性。由于 Operator 通常具有管理集群资源的高级权限，因此实施适当的安全措施以防止未经授权的访问和恶意活动至关重要。

以下是 Kubernetes Operator 的一些关键安全注意事项：

通过实施这些安全措施，您可以显著降低安全漏洞的风险，并保护您的 Kubernetes Operator 免受恶意活动的侵害。

Kubernetes Operator 的未来

Kubernetes Operator 正在迅速发展，并日益成为 Kubernetes 生态系统中越来越重要的一部分。随着 Kubernetes 的采用率持续增长，我们可以预期在 Operator 领域看到更多的创新。

以下是塑造 Kubernetes Operator 未来的一些趋势：

结论

Kubernetes Operator 提供了一种强大的方式来自动化复杂应用程序的管理并扩展 Kubernetes 的能力。通过定义自定义资源和实现自定义控制器，Operator 使您能够以声明式、自动化和可重复的方式管理应用程序。随着 Kubernetes 的采用率持续增长，Operator 将成为云原生领域中日益重要的一部分。

通过采用 Kubernetes Operator，组织可以简化应用程序管理，减少运维开销，并提高其应用程序的整体可靠性和可伸缩性。无论您是管理数据库、监控系统还是其他复杂应用程序，Kubernetes Operator 都能帮助您简化操作并释放 Kubernetes 的全部潜力。

这是一个不断发展的领域，因此，要有效地在您的组织中利用 Kubernetes Operator，与最新的发展和最佳实践保持同步至关重要。围绕 Operator 的社区充满活力且乐于支持，提供了丰富的资源和专业知识来帮助您取得成功。