Kubernetes (K8s) 和 Operator 介绍
引言
随着容器技术的发展，终结了应用交付、部署过程中的因环境、配置和相关依赖等造成的不同部署配置的困境，从而诞生了一种应用交付的新形态：通过容器打包程序、环境和依赖等，从而实现“一次构建到处部署”。于是，运维工程师无需过多关注编程语言、环境配置，业务本身逻辑，只需掌握容器管理单一工具链即可。
然后在真实生产环境中，一个系统往往由多个容器构成，部署环境也往往由多台主机构成，如何合理、高效的在在一组主机上编排运行便成了另外一个问题。举个例子：现在又50台机器，500个容器需要运行，如果用docker run去管理会是一个巨大的工作量。此时，Kubernetes（简称K8s）这样的容器编排工具就成了一个大杀器，k8s可以很好的解决这样的问题。目前，k8s已经成为容器编排的事实标准，它能够自动化部署、扩展和管理容器化应用。
Kubernetes 概述
Kubernetes是一个开源平的移植性、扩展性良好的容器化工作负载和服务管理平台，用于自动部署、扩展和管理容器化应用程序。
k8s架构图：
CONTROL PLANE（控制平面组件）
控制平面组件会为集群做出全局决策，比如资源的调度。 以及检测和响应集群事件，例如当不满足 Deployment 的 replicas 字段时，要启动新的 Pod）。
- Kube-apiserver：API 服务器是 Kubernetes 控制平面的组件， 该组件负责公开了 Kubernetes API，负责处理接受请求的工作。 API 服务器是 Kubernetes 控制平面的前端。
- etcd：一致且高可用的键值存储，用作 Kubernetes 所有集群数据的后台数据库。
- kube-scheduler：是控制平面的组件， 负责监视新创建的、未指定运行节点（node）的 Pods， 并选择节点来让 Pod 在上面运行。
- kube-controller-manager：是控制平面的组件， 负责运行控制器进程，负责集群内资源对象的管理，比如：pod，service，node，namespace。
Node（节点组件）
节点组件会在每个节点上运行，负责维护运行的 Pod 并提供 Kubernetes 运行时环境。
- kubelet：kubelet 会在集群中每个节点（node）上运行。 它保证容器（containers）都运行在 Pod 中。
- kube-proxy（可选）：kube-proxy 是集群中每个节点（node）上所运行的网络代理， 实现 Kubernetes 服务（Service） 概念的一部分。
Kubernetes工作流程
- 运维根据业务编写部署配置，集群中业务状态的声明式描述（比如yamll文件）
- 运维通过
kubectl apply -f xx.yaml提交到k8s集群中 - k8s集群响应配置接收
- k8s集群收到配置后，控制器根据配置创建修改资源对象
例子：一个安装空调的房子中，首先通过遥控器设置温度后，相当于告诉空调期望状态，房间当前实际的温度是当前状态，房间空调检测到当前实际温度高于设置温度，空调就会工作，调节温度到设置的期望文档。
空调是控制器，温度是资源对象
基本概念
前边提到两个比较重要的概念就是：1.资源对象（Resources；2. 控制器（Controler）; ）：
资源对象（Resources）
在 Kubernetes 中，资源对象（如 Pod、Service、Namespace）是集群状态的声明式描述，而 Controller 则负责监听这些资源的变化，并不断调整实际状态以匹配期望状态，从而实现自动化运维管理。
Kubernetes 将集群中的各种元素抽象为“资源对象”，常见的包括：
- Pod：最小可部署单元
- Service：定义一组 Pod 的访问策略
- Deployment：管理应用副本，支持滚动更新
- Namespace：逻辑隔离不同项目/团队
- Node：集群中的计算节点
这些资源对象构成了集群的状态描述。
Controller：资源对象的管理者
在 Kubernetes 中，Controller 是 Kubernetes 控制平面的核心组件之一，每种 Controller 负责监控某类资源的状态，并根据变化做出响应，以确保集群的实际状态始终与用户定义的期望状态一致。
Kubernetes 内部有一系列 **Controller（控制器）**，每种 Controller 负责一类资源的管理，持续观察其状态并进行调整，以确保集群始终处于用户期望的状态。正是通过这种机制，Kubernetes 实现了高度自动化的集群管理能力。
常见 Controller 及其职责：
| Controller 类型 | 负责的资源类型 | 功能说明 |
|---|---|---|
| ReplicaSet Controller | ReplicaSet | 确保指定数量的 Pod 副本始终在运行 |
| Deployment Controller | Deployment | 实现无状态应用的滚动更新、版本回滚等高级功能 |
| StatefulSet Controller | StatefulSet | 管理有状态应用的副本集 |
| DaemonSet Controller | DaemonSet | 确保每个节点上都运行一个 Pod 副本 |
| Node Controller | Node | 监控节点健康状态，标记并处理故障节点 |
| Namespace Controller | Namespace | 管理命名空间的创建、删除等生命周期 |
| ServiceAccount Controller | ServiceAccount | 自动创建默认的 ServiceAccount 和相关 Secret |
| Job Controller | Job | 确保一次性任务成功完成 |
| CronJob Controller | CronJob | 按照设定时间周期性执行任务 |
| Ingress Controller | Ingress | 根据 Ingress 规则配置外部 HTTP/HTTPS 访问路由 |
| PersistentVolume Controller | PV / PVC | 管理存储卷的动态供给、绑定和释放 |
核心资源的概念及其作用说明：
- Pod: 最小的可部署单元，包含一个或多个共享资源的容器。
- Service: 定义一组 Pod 的访问策略，提供稳定的 IP 和 DNS 名称，并实现负载均衡。
- Deployment: 描述应用的期望状态并管理副本集，支持滚动更新和版本回滚。
- Namespace: 用于逻辑隔离不同项目、团队或环境的资源。
- ConfigMap: 存储非敏感的配置数据，供 Pod 使用。
- DaemonSet: 确保每个节点运行一个 Pod 副本，常用于节点级服务。
- Secret: 存储敏感信息（如密码、token、密钥）。
- StatefulSet: 管理有状态应用，提供稳定的网络标识和持久化存储。
- Job: 执行一次性任务，确保任务成功完成。
- CronJob: 按照时间计划周期性地执行任务。
- Ingress: 提供基于 HTTP/HTTPS 的路由规则，将外部流量转发到 Service。
- PersistentVolume (PV): 集群中的一块存储资源。
- PersistentVolumeClaim (PVC): 用户对存储资源的请求，绑定 PV 后供 Pod 使用。
- Role / ClusterRole: 定义权限规则，用于基于角的访问控制（RBAC）。
- RoleBinding / ClusterRoleBinding: 将角绑定到用户、组或服务账户。
Operator概述
Operator 是一种基于 Kubernetes CRD资源（CRD）和控制器模式的软件扩展，用于封装特定应用的运维知识，并实现其全生命周期的自动化管理。
背景
- 自动化运维的需求
- 很多有状态服务（如 MySQL、Redis、Elasticsearch、Kafka）需要复杂的配置、主从切换、备份恢复等操作。
- 这些逻辑很难用原生资源描述，也无法完全自动化。
- 缺乏对领域知识的封装
- 原生 K8s 资源无法表达特定应用的运维知识（如 PostgreSQL 集群的 HA 策略、分片机制等）。
- 每个团队重复实现类似的运维逻辑，效率低且容易出错。
- 扩展 Kubernetes API 的需求
- Kubernetes 控制器只负责同步资源状态到期望状态（desired state），但不具备处理复杂业务逻辑的能力。
- Operator 可以实现更高级别的控制器逻辑，比如自动故障转移、滚动升级、版本兼容性检查等。
**备注：**Controller 和 Operator 没有太大区别，一般称对 k8s原生资源的控制叫为 Controller，对于CRD资源（CRD）的控制器为 Operator
CRD资源定义 (CRD)
在 Kubernetes 中一切都可视为资源，Kubernetes 1.7 之后增加了对 CRD CRD资源二次开发能力来扩 展 Kubernetes API，通过 CRD 我们可以向 Kubernetes API 中增加新资源类型，而不需要修改 Kubernetes 源码来创建CRD的 API server，该功能大大提高了 Kubernetes 的扩展能力。一旦定义了 CRD 并将其添加到集群中，你就可以像操作内置资源（如 Pods、Services 等）一样操作这些CRD资源。
CRD使用
-
定义 Custom Resource（CRD）：
- 创建一个CRD资源类型（例如
EthereumNode），用户通过 YAML 声明应用的期望状态。 - 示例：
apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: myresources.example.com spec: group: example.com versions: - name: v1 served: true storage: true schema: openAPIV3Schema: type: object properties: spec: type: object properties: size: type: integer scope: Namespaced names: plural: myresources singular: myresource kind: MyResource shortNames: - mr
- 创建一个CRD资源类型（例如
-
开发 Controller：
- 监听该资源的变化，对比 当前状态 和 期望状态，调用 Kubernetes API 调整实际资源（如创建 Pod、Service）。
- 闭环控制（Reconcile Loop）
-
创建CRD资源实例
- 例如：用户创建一个
MyResource，Controller 自动生成对应的Deployment和Service。
apiVersion: "example.com/v1" kind: MyResource metadata: name: myresource-sample spec: size: 3 - 例如：用户创建一个
Operator典型使用场景
- 管理有状态应用：数据库、消息队列等
| 应用 | Operator 名称 | 功能描述 |
|---|---|---|
| PostgreSQL | Crunchy Postgres Operator | 提供高可用的 PostgreSQL 集群管理，包括主从复制、自动故障转移、备份恢复等 |
| MongoDB | MongoDB Enterprise Operator | 用于在 Kubernetes 上部署和管理 MongoDB 集群 |
| Redis | Redis Operator by OT-CONTAINER-KIT | 支持 Redis 主从、哨兵及集群模式的自动化管理 |
| Elasticsearch | Elastic Cloud Operator | 在 Kubernetes 上部署和管理 Elastic Stack（Elasticsearch、Kibana、Logstash 等） |
| Kafka | Strimzi Kafka Operator | 自动化部署和管理 Kafka 集群，支持 Zookeeper、Kafka Connect、MirrorMaker 等组件 |
- 实现自动化运维
- 一键部署：通过一个 YAML 文件拉起整个应用栈（如以nginx + 监控）。
- 自愈能力：检测到 Pod 崩溃时自动重启。
- 灰度升级：控制节点版本升级的前后顺序和个性化需求。
### 流程图
