什么是 Kubernetes Operator？原理、优势与开发实战 – wiki大全

作者： /

Kubernetes Operator：原理、优势与开发实战

在云原生时代，Kubernetes 已成为容器编排的事实标准。然而，Kubernetes 本身是通用平台，对于管理复杂有状态应用（如数据库、消息队列等）的生命周期，它所提供的原生资源（如 Deployment、StatefulSet）有时显得力不从心。这时，Kubernetes Operator 应运而生，为解决这一痛点提供了强大的扩展机制。

1. 什么是 Kubernetes Operator？

Kubernetes Operator 是由 CoreOS 提出的一种自动化和管理 Kubernetes 上复杂有状态应用的方法。简单来说，Operator 是一种将人类运维知识编码化、自动化到 Kubernetes 扩展中的软件。它扩展了 Kubernetes API 的功能，允许用户定义和管理自定义资源类型（Custom Resource Definitions, CRDs），并通过自定义控制器（Custom Controller）来持续监控这些自定义资源，并采取相应的操作，使集群的实际状态与期望状态保持一致。

Operator 的核心思想是实现“Day 2”运维自动化，即应用程序部署之后的日常管理任务，例如：

  • 部署和扩缩容：自动化部署应用，并根据负载进行弹性伸缩。
  • 备份与恢复：管理应用数据的备份策略和灾难恢复。
  • 升级与回滚：自动化应用版本的升级和在必要时的回滚。
  • 故障检测与自愈：监控应用状态，并在出现问题时自动修复。
  • 安全与合规：管理访问控制、加密和审计。

它将特定应用的运维智慧从操作手册、脚本和人工干预中解放出来，转化为可由 Kubernetes 自动执行的逻辑。

2. 原理

Kubernetes Operator 的工作原理可以概括为以下几个核心组件及其相互作用：

2.1. 自定义资源定义 (Custom Resource Definitions, CRDs)

CRD 是 Kubernetes 1.7+ 引入的功能，允许用户在 Kubernetes 集群中定义自己的 API 对象，即自定义资源（Custom Resources, CRs）。例如，一个数据库 Operator 可能会定义一个 MySQLInstance 的 CRD。当你创建一个 MySQLInstance 类型的 CR 时，Kubernetes API Server 会将其存储起来，就像对待 Pod 或 Deployment 一样。

CRD 扮演的角色是：
* 扩展 Kubernetes API：为特定应用引入新的对象类型。
* 声明式 API：用户通过 YAML 或 JSON 声明其期望的应用状态。
* 状态存储：CRs 的期望状态和实际状态都可以存储在 etcd 中，通过 API Server 进行管理。

2.2. 自定义控制器 (Custom Controller)

控制器是 Operator 的“大脑”。它是一个运行在 Kubernetes 集群内部的应用程序，其核心职责是：

  1. 观察 (Watch)：持续监控特定类型资源的创建、更新和删除事件（包括原生资源如 Pods、Services，以及自定义资源 CRs）。
  2. 比较 (Reconcile)：当观察到事件发生时，控制器会比较集群的实际状态（Actual State）与自定义资源中定义的期望状态（Desired State）。
  3. 行动 (Act)：如果实际状态与期望状态不符，控制器会采取一系列行动，调用 Kubernetes API 创建、更新或删除原生资源（如 Deployment、StatefulSet、Service、PersistentVolume等），直到实际状态与期望状态匹配。

例如，当用户创建一个 MySQLInstance CR 时，MySQL Operator 的控制器会观察到这个事件。然后，它会根据 MySQLInstance 的定义（例如版本、存储大小、副本数），自动创建或配置一系列 Kubernetes 原生资源，如：
* 一个 StatefulSet 来运行 MySQL Pods。
* 一个 Service 来提供 MySQL 访问。
* 一个 PersistentVolumeClaim 来为 MySQL 数据库提供持久化存储。
* 相关的 ConfigMaps 和 Secrets 来存储配置和凭证。

2.3. 控制循环 (Control Loop)

自定义控制器的工作方式是经典的“控制循环”模式。它不断地执行“观察-比较-行动”的周期，确保自定义资源所代表的应用始终处于健康且符合期望的状态。这种模式是 Kubernetes 声明式 API 的核心，Operator 只是将其扩展到了更复杂的应用层面。

2.4. 核心组件交互流程

  1. 用户通过 kubectl apply -f my-mysql-instance.yaml 创建一个 MySQLInstance 自定义资源。
  2. Kubernetes API Server 接收请求，将 CR 存储在 etcd 中。
  3. MySQL Operator (自定义控制器) 通过 Kubernetes API 持续“观察”MySQLInstance 类型的资源。
  4. 当控制器检测到新的 MySQLInstance CR 时，它会读取其期望状态。
  5. 控制器开始“协调”（Reconcile）过程：
    • 检查集群中是否存在运行 MySQL 所需的 StatefulSet、Service 等原生资源。
    • 如果不存在或状态不匹配，控制器会通过 Kubernetes API 创建或修改这些原生资源。
  6. Kubernetes 调度器 调度 Pods 到合适的节点上运行。
  7. kubelet 在节点上启动容器。
  8. 控制器持续监控这些原生资源的状态，确保它们健康运行，并使整个 MySQL 实例符合 MySQLInstance CR 中定义的期望状态。例如，如果某个 MySQL Pod 失败，控制器会尝试修复它，或者在扩容时增加 Pod 副本。

3. 优势

Kubernetes Operator 带来了显著的优势，特别是在管理复杂云原生应用方面：

3.1. 自动化运维，降低人力成本

  • “Day 2”运维自动化：将备份、恢复、升级、故障转移、监控等复杂且重复的运维任务自动化。
  • 减少人为错误：通过代码实现运维逻辑，减少了手动操作可能引入的错误。

3.2. 封装专业领域知识

  • 将专家知识产品化：数据库管理员、消息队列专家等领域专家的知识和最佳实践被编码到 Operator 中，使得任何用户都能以一致且可靠的方式部署和管理这些复杂应用。
  • 提高可移植性：一旦 Operator 开发完成，它可以在任何 Kubernetes 集群中部署和使用，提供了高度可移植的解决方案。

3.3. 声明式管理复杂应用

  • 保持 Kubernetes 风格：Operator 遵循 Kubernetes 的声明式 API 范式，用户只需声明期望状态，Operator 负责实现它。
  • 一致的用户体验：用户可以通过熟悉的 kubectl 命令和 YAML 配置来管理复杂应用，就像管理原生 Kubernetes 资源一样。

3.4. 提高可靠性和弹性

  • 自愈能力：Operator 可以持续监控应用状态，并在检测到故障时自动触发恢复机制，提高应用的韧性。
  • 最佳实践落地：Operator 强制执行特定的架构和配置最佳实践，确保应用以高可用、高性能的方式运行。

3.5. 扩展 Kubernetes 能力

  • 弥补原生资源不足：对于有状态应用的管理，Kubernetes 原生资源（如 StatefulSet）提供了基础能力，但 Operator 进一步抽象和自动化了特定应用的复杂逻辑。
  • 构建云原生生态：Operator 使得第三方供应商能够为他们的产品提供官方的 Kubernetes 管理接口，丰富了云原生生态系统。

4. 开发实战

开发一个 Kubernetes Operator 通常需要使用特定的框架和工具，以简化 CRD、控制器和相关逻辑的实现。目前最流行的 Operator 开发框架是 Operator SDK 和 Kubebuilder。这两个工具的功能非常相似，都提供了脚手架、代码生成和库，帮助开发者快速构建 Operator。

下面以一个简单的 Go 语言 Operator 为例，简述开发实战的关键步骤（假设使用 Operator SDK 或 Kubebuilder）：

4.1. 准备开发环境

  • 安装 Go 语言环境。
  • 安装 Docker 或其他容器运行时。
  • 安装 kubectl。
  • 安装 operator-sdk 或 kubebuilder 工具。
  • 安装 kustomize (通常由上述工具自动安装)。

4.2. 创建 Operator 项目

使用脚手架工具初始化一个新项目：

“`bash

使用 Operator SDK

operator-sdk init –domain example.com –group app –version v1 –kind MyApp –repo github.com/your/my-app-operator

或者使用 Kubebuilder

kubebuilder init –domain example.com –repo github.com/your/my-app-operator
kubebuilder create api –group app –version v1 –kind MyApp
“`

这会生成一个基本的项目结构，包括 main.go、Dockerfile、CRD 定义文件、API 类型定义文件和控制器文件等。

4.3. 定义自定义资源 (CRD)

编辑 api/v1/myapp_types.go (或类似路径) 文件，定义自定义资源 MyApp 的 Spec（期望状态）和 Status（实际状态）。

“`go
// api/v1/myapp_types.go
package v1

import (
metav1 “k8s.io/apimachinery/pkg/apis/meta/v1”
)

// MyAppSpec defines the desired state of MyApp
type MyAppSpec struct {
// Size defines the number of MyApp instances.
// The default is 1.
Size int32 json:"size,omitempty"
// Image defines the container image for MyApp.
// The default is “my-app:latest”.
Image string json:"image,omitempty"
}

// MyAppStatus defines the observed state of MyApp
type MyAppStatus struct {
// PodNames are the names of the Pods running MyApp.
PodNames []string json:"podNames"
// Add other status fields as needed, e.g., current version, ready replicas.
}

// +kubebuilder:object:root=true
// +kubebuilder:subresource:status

// MyApp is the Schema for the myapps API
type MyApp struct {
metav1.TypeMeta json:",inline"
metav1.ObjectMeta json:"metadata,omitempty"

Spec   MyAppSpec   `json:"spec,omitempty"`
Status MyAppStatus `json:"status,omitempty"`

}

// +kubebuilder:object:root=true

// MyAppList contains a list of MyApp
type MyAppList struct {
metav1.TypeMeta json:",inline"
metav1.ListMeta json:"metadata,omitempty"
Items []MyApp json:"items"
}

func init() {
SchemeBuilder.Register(&MyApp{}, &MyAppList{})
}
“`

运行 make generate 和 make manifests 来生成 CRD YAML 文件和相关的 Go 代码。

4.4. 实现自定义控制器逻辑

编辑 controllers/myapp_controller.go (或类似路径) 文件，实现 Reconcile 方法。这是 Operator 的核心逻辑所在。

在 Reconcile 方法中，你需要：

  1. 获取自定义资源 (CR)：根据 ReconcileRequest 中的名称和命名空间，从 Kubernetes API 中获取 MyApp 实例。
  2. 定义期望状态：根据 CR 的 Spec（例如 Size、Image），定义你希望在集群中存在的原生资源（如 Deployment、Service）的期望状态。
  3. 获取实际状态：查询 Kubernetes API，获取当前集群中与该 MyApp 实例相关的原生资源的实际状态。
  4. 比较并采取行动：
    • 如果 Deployment 不存在，则创建它。
    • 如果 Deployment 的副本数或镜像与 MyApp.Spec 不符，则更新它。
    • 如果需要，创建或更新 Service。
    • 更新 MyApp.Status 字段，以反映集群的实际状态（例如，记录 Pod 的名称）。
  5. 错误处理与重试：在协调过程中，如果发生错误，返回 reconcile.Result{RequeueAfter: someDuration} 来告诉控制器稍后重试。

“`go
// controllers/myapp_controller.go (简化示例)
package controllers

import (
“context”
“reflect”

appv1 "github.com/your/my-app-operator/api/v1"
appsv1 "k8s.io/api/apps/v1"
corev1 "k8s.io/api/core/v1"
"k8s.io/apimachinery/pkg/api/errors"
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
"k8s.io/apimachinery/pkg/types"
ctrl "sigs.k8s.io/controller-runtime"
"sigs.k8s.io/controller-runtime/pkg/log"

)

// MyAppReconciler reconciles a MyApp object
type MyAppReconciler struct {
// client.Client, Scheme, etc.
}

// +kubebuilder:rbac:groups=app.example.com,resources=myapps,verbs=get;list;watch;create;update;patch;delete
// +kubebuilder:rbac:groups=app.example.com,resources=myapps/status,verbs=get;update;patch
// +kubebuilder:rbac:groups=apps,resources=deployments,verbs=get;list;watch;create;update;patch;delete
// +kubebuilder:rbac:groups=core,resources=pods,verbs=get;list;watch

func (r *MyAppReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
_ = log.FromContext(ctx)

// 1. 获取 MyApp 实例
myapp := &appv1.MyApp{}
err := r.Client.Get(ctx, req.NamespacedName, myapp)
if err != nil {
    if errors.IsNotFound(err) {
        log.Log.Info("MyApp resource not found. Ignoring since object must be deleted.")
        return ctrl.Result{}, nil
    }
    log.Log.Error(err, "Failed to get MyApp")
    return ctrl.Result{}, err
}

// 2. 检查 Deployment 是否存在，如果不存在则创建
foundDeployment := &appsv1.Deployment{}
err = r.Client.Get(ctx, types.NamespacedName{Name: myapp.Name, Namespace: myapp.Namespace}, foundDeployment)
if err != nil && errors.IsNotFound(err) {
    // 定义新的 Deployment
    dep := r.deploymentForMyApp(myapp)
    log.Log.Info("Creating a new Deployment", "Deployment.Namespace", dep.Namespace, "Deployment.Name", dep.Name)
    err = r.Client.Create(ctx, dep)
    if err != nil {
        log.Log.Error(err, "Failed to create new Deployment", "Deployment.Namespace", dep.Namespace, "Deployment.Name", dep.Name)
        return ctrl.Result{}, err
    }
    // Deployment 创建成功，重新入队处理
    return ctrl.Result{Requeue: true}, nil
} else if err != nil {
    log.Log.Error(err, "Failed to get Deployment")
    return ctrl.Result{}, err
}

// 3. 检查 Deployment 的 Size 和 Image 是否与 MyApp Spec 匹配，如果不匹配则更新
size := myapp.Spec.Size
if size == 0 {
    size = 1 // default size
}
image := myapp.Spec.Image
if image == "" {
    image = "nginx:latest" // default image
}

if *foundDeployment.Spec.Replicas != size || foundDeployment.Spec.Template.Spec.Containers[0].Image != image {
    log.Log.Info("Updating Deployment", "Deployment.Namespace", foundDeployment.Namespace, "Deployment.Name", foundDeployment.Name)
    foundDeployment.Spec.Replicas = &size
    foundDeployment.Spec.Template.Spec.Containers[0].Image = image
    err = r.Client.Update(ctx, foundDeployment)
    if err != nil {
        log.Log.Error(err, "Failed to update Deployment", "Deployment.Namespace", foundDeployment.Namespace, "Deployment.Name", foundDeployment.Name)
        return ctrl.Result{}, err
    }
    return ctrl.Result{Requeue: true}, nil
}

// 4. 更新 MyApp 状态 (Status)
podList := &corev1.PodList{}
listOpts := []client.ListOption{
    client.InNamespace(myapp.Namespace),
    client.MatchingLabels(labelsForMyApp(myapp.Name)),
}
if err = r.Client.List(ctx, podList, listOpts...); err != nil {
    log.Log.Error(err, "Failed to list pods", "MyApp.Namespace", myapp.Namespace, "MyApp.Name", myapp.Name)
    return ctrl.Result{}, err
}
podNames := getPodNames(podList.Items)

// 如果 Status 中的 PodNames 不一致，则更新
if !reflect.DeepEqual(podNames, myapp.Status.PodNames) {
    myapp.Status.PodNames = podNames
    err := r.Client.Status().Update(ctx, myapp)
    if err != nil {
        log.Log.Error(err, "Failed to update MyApp status")
        return ctrl.Result{}, err
    }
}

return ctrl.Result{}, nil

}

// deploymentForMyApp returns a myapp Deployment object
func (r MyAppReconciler) deploymentForMyApp(m appv1.MyApp) *appsv1.Deployment {
ls := labelsForMyApp(m.Name)
replicas := m.Spec.Size
if replicas == 0 {
replicas = 1
}
image := m.Spec.Image
if image == “” {
image = “nginx:latest”
}

dep := &appsv1.Deployment{
    ObjectMeta: metav1.ObjectMeta{
        Name:      m.Name,
        Namespace: m.Namespace,
        OwnerReferences: []metav1.OwnerReference{
            *metav1.NewControllerRef(m, appv1.GroupVersion.WithKind("MyApp")),
        },
    },
    Spec: appsv1.DeploymentSpec{
        Replicas: &replicas,
        Selector: &metav1.LabelSelector{
            MatchLabels: ls,
        },
        Template: corev1.PodTemplateSpec{
            ObjectMeta: metav1.ObjectMeta{
                Labels: ls,
            },
            Spec: corev1.PodSpec{
                Containers: []corev1.Container{{
                    Name:  "my-app",
                    Image: image,
                }},
            },
        },
    },
}
return dep

}

// labelsForMyApp returns the labels for selecting the resources
// belonging to the given MyApp CR name.
func labelsForMyApp(name string) map[string]string {
return map[string]string{“app”: “my-app”, “my-app-cr”: name}
}

// getPodNames returns the pod names of the array of pods passed in
func getPodNames(pods []corev1.Pod) []string {
var podNames []string
for _, pod := range pods {
podNames = append(podNames, pod.Name)
}
return podNames
}

// SetupWithManager sets up the controller with the Manager.
func (r *MyAppReconciler) SetupWithManager(mgr ctrl.Manager) error {
return ctrl.NewControllerManagedBy(mgr).
For(&appv1.MyApp{}).
Owns(&appsv1.Deployment{}). // Operator 负责管理 Deployment 资源
Complete(r)
}
“`

4.5. 构建和部署 Operator

  1. 构建 Docker 镜像：
    bash
    make docker-build IMG="your-registry/my-app-operator:v1.0.0"
  2. 推送 Docker 镜像：
    bash
    docker push your-registry/my-app-operator:v1.0.0
  3. 部署 CRD 到集群：
    bash
    make install
  4. 部署 Operator 到集群：
    bash
    make deploy IMG="your-registry/my-app-operator:v1.0.0"

4.6. 创建自定义资源实例

创建 config/samples/app_v1_myapp.yaml (或类似路径) 文件，定义你的 MyApp 实例。

yaml
apiVersion: app.example.com/v1
kind: MyApp
metadata:
name: myapp-sample
spec:
size: 3
image: "nginx:1.21.6"

然后，在集群中创建这个实例：

bash
kubectl apply -f config/samples/app_v1_myapp.yaml

你的 Operator 将会观察到这个 MyApp 实例的创建，并自动创建一个包含 3 个 Nginx 容器的 Deployment。

你可以通过以下命令查看 Operator 的工作：

bash
kubectl get myapps
kubectl get deployments
kubectl get pods
kubectl logs deployment/my-app-operator-controller-manager -c manager

总结

Kubernetes Operator 是云原生领域一项强大的技术，它将领域专家知识和运维智慧融入自动化逻辑，极大地简化了复杂有状态应用在 Kubernetes 上的部署和管理。通过 CRD 定义期望状态，自定义控制器持续协调实际状态与期望状态，Operator 实现了应用程序生命周期的全自动化，从而降低了运维成本，提高了可靠性，并扩展了 Kubernetes 的核心能力。对于任何希望在 Kubernetes 上高效运行和管理复杂应用的组织来说，掌握 Operator 的原理和开发实战都将是至关重要的。

滚动至顶部