
12月到了,迎来今年最后一个月,马上2025年要过去了,希望各位读者身体健康,一切顺利!
说起最近的见闻应该就是React高风险漏洞的事情比较引人关注,具体内容是这样的:React Server Components 被披露其存在远程代码执行漏洞,漏洞编号CVE-2025-55182。并且影响使用 App Router 的 Next.js 应用程序,其漏洞编号CVE-2025-66478。两个漏洞均可导致未经身份验证的远程攻击者执行任意代码等危害。
官方公告:React 的服务器组件库 (React Server Components,即 RSC)中,由于 React 在解码发送至服务器函数端点的请求负载时存在安全缺陷,导致未经身份验证的远程攻击者可以通过向任何服务器函数端点发送特制的恶意 HTTP 请求,当该请求被 React 反序列化处理时,即可在服务器上实现远程代码执行,从而完全控制服务器。
官方已发布漏洞补丁及修复版本,需要评估业务是否受影响后,升级至安全版本漏洞参考[1]
还有一个就是2025年12月5日Cloudflare服务又再次中断了,源头不是威胁,而是 Cloudflare 为应对 React Server Components 暴露的严重漏洞所做的加固操作,所以这两件事是有关联的
任何系统中断都是不可接受的,继 11 月 18 日的故障事件之后,我们再次让互联网用户失望了。我们将在下周发布详细信息,介绍我们正在采取的措施,以防止此类事件再次发生。
上一篇文章介绍了什么是Kubernetes Operator,有什么用,今天就来给各位读者介绍一下,如何使用Kubebuilder去开发一个只需部署一个自定义资源就能同时启动prometheus和grafana的示例Operator,希里安也是学习者,边学边用,写的有问题的,欢迎各位读者一起交流!
简单来说:
之前已经详细介绍如何部署一个示例的 monitor operator了,这里再简单回顾下:
如果已经有相关经验的读者,可以直接拉取仓库代码进行优化或者部署这个示例Opertaor到自己的集群尝试一下再交流!仓库地址如下: https://github.com/ciliverse/monitor-operator
# 添加 Ciliverse Charts 仓库
helm repo add ciliverse https://charts.cillian.website
# 更新仓库
helm repo update
# 搜索可用的 Charts
helm search repo ciliverse
# 基础安装
helm install monitor-operator ciliverse/monitor-operator \
--namespace monitoring \
--create-namespace
# 应用配置
kubectl apply -f simple-monitoring.yaml
# 查看状态
kubectl get monitorstack simple-monitoring
查看状态
# kubectl -f simple-monitoring.yaml
# 详细文件内容在后面章节
访问Grafana界面
# 安装Go 1.21+
# 根据不同系统安装吧,我这里是ubuntu
apt install go --classic
go version
# 输出应该是: go version go1.21.x
# 安装Kubebuilder
curl -L -o kubebuilder https://go.kubebuilder.io/dl/latest/$(go env GOOS)/$(go env GOARCH)
chmod +x kubebuilder && sudo mv kubebuilder /usr/local/bin/
# 安装后可以查看版本信息
root@node1:~# kubebuilder version
Version: cmd.version{KubeBuilderVersion:"4.9.0", KubernetesVendor:"1.34.0", GitCommit:"5e331e74c7a25c8e8fc0d9d5c33c319b7268f395", BuildDate:"2025-09-22T10:53:21Z", GoOs:"linux", GoArch:"amd64"}
可选:
# 安装Docker
docker version
# 确保Docker daemon正在运行,运行kind需要,还有一个需要构建和运行容器镜像
# 安装kubectl
sudo apt/yum install kubectl
kubectl version --client
# 安装kind (本地测试Kubernetes集群)
go install sigs.k8s.io/kind@latest
这一部分,我想对我文章感兴趣的同学应该都是从事这个行业的,应该都有自己喜欢的安装的方式(如果完全不会安装,可以后台私信我),官方推荐安装工具[3]有以下几种
希里安这里已经有现成的集群了,如果大家不想手动,直接在如上环境准备内容中安装kind后一键式创建,执行以下命令快速创建一个测试集群吧!
# 创建本地测试集群
kind create cluster --name monitor-operator-dev
# 验证集群
kubectl cluster-info --context kind-monitor-operator-dev# 创建项目目录
mkdir monitor-operator
cd monitor-operator
# 初始化Kubebuilder项目
kubebuilder init --domain cillian.website --repo github.com/ciliverse/monitor-operator
# 创建API和控制器
kubebuilder create api --group monitoring --version v1 --kind MonitorStack --resource --controller
初始化项目

创建API和控制器
初始化后的项目结构,这里只列出主要的目录,其实kubebuilder(v4.9.0)初始化以及创建api和控制器后目前会有19个目录,共计46个文件,详细的大家可以初始化生成后看一下:
monitor-operator/
├── api/v1/ # CRD 定义
│ ├── monitorstack_types.go # MonitorStack 资源定义
│ └── groupversion_info.go # API 组和版本信息
├── internal/controller/ # Controller 实现
│ ├── monitorstack_controller.go # 主控制器逻辑
│ ├── monitorstack_controller_test.go # 控制器测试
│ └── suite_test.go # 测试套件设置
├── cmd/main.go # 程序入口
├── config/ # 部署配置
│ ├── crd/ # CRD YAML 文件
│ ├── samples/ # 示例资源
│ ├── manager/ # Manager 部署配置
│ └── rbac/ # 权限配置
| └── default/ # 默认配置
| └── prometheus/ # Prometheus 监控配置
└── test/ # 测试代码
└── ...具体生成的详细内容,各位读者还是直接看代码吧,东西还是不少
# Go依赖
go mod tidy
# 下载依赖
go mod download
# 如果go mod download很慢,可以配置Go代理
go env -w GOPROXY=https://goproxy.cn,direct
# 生成深拷贝代码(Kubernetes 需要)
make generate
# 生成CRD和RBAC配置
make manifests概念 | 通俗解释 |
|---|---|
CRD | 自定义资源模板,告诉集群有一种新资源 |
Custom Resource | 按模板填写的一份具体申请单 |
Controller | 自动执行的处理流程 |
Reconcile | 调和,核心逻辑:如果不一致就修正 |
Informer | 推送事件的监听器(底层基于watch) |
Workqueue | 串行、有重试、安全的工作任务队列 |
Status | 实际情况的记录,让控制器知道系统现在状态 |
Finalizer | 删除资源前做清理工作的钩子 |
Operator | 应用自动化整体流程(CRD + 控制器 + 业务逻辑) |
CRD 定义自定义资源的 schema、版本与行为入口(用户与系统交互的对象),允许你在 Kubernetes 中定义自己的资源类型。在这次讲解中,我们定义了
MonitorStack这个自定义资源,CRD 最关键的一点:定义一种结构(Schema)
// MonitorStack是监控栈的Schema定义
// 包含TypeMeta、ObjectMeta、Spec和Status四个核心部分
type MonitorStack struct {
// TypeMeta包含API版本和Kind信息
metav1.TypeMeta `json:",inline"`
// ObjectMeta包含名称、命名空间、标签等元数据
metav1.ObjectMeta `json:"metadata,omitempty"`
// Spec定义期望状态 - 用户定义的配置
Spec MonitorStackSpec `json:"spec,omitempty"`
// Status定义观察状态 - 控制器维护的实际状态
Status MonitorStackStatus `json:"status,omitempty"`
}
// MonitorStackSpec定义MonitorStack的期望状态
// 包含Prometheus和Grafana两个核心组件的配置
type MonitorStackSpec struct {
// Prometheus配置
// +kubebuilder:validation:Required - 必填字段
Prometheus PrometheusSpec `json:"prometheus"`
// Grafana配置
// +kubebuilder:validation:Required - 必填字段
Grafana GrafanaSpec `json:"grafana"`
// 可选的通用配置
// 目标命名空间,如果为空则使用当前命名空间
Namespace string `json:"namespace,omitempty"`
// 资源标签 - 会应用到所有创建的资源上
Labels map[string]string `json:"labels,omitempty"`
}# 这就是一个 MonitorStack 资源示例
apiVersion: monitoring.cillian.website/v1
kind: MonitorStack
metadata:
name: my-monitor
spec:
prometheus:
enabled: true
image: prom/prometheus
tag: latest
grafana:
enabled: true
image: grafana/grafana
tag: latest
datasources:
- name: Prometheus
type: prometheus
url: http://my-monitor-prometheus:9090apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
spec.names(plural, singular, kind)
spec.group(api group)
spec.versions(schema, served, storage)
spec.scope(Namespaced | Cluster)
spec.validation(OpenAPI v3 schema)
spec.subresources.status(是否支持 status 子资源)
spec.conversion(版本转换策略)
spec.preserveUnknownFieldsMonitorStack (自定义资源)
├── Spec (期望状态)
│ ├── Prometheus 配置
│ └── Grafana 配置
└── Status (观察状态)
├── 整体状态
├── Prometheus 状态
└── Grafana 状态控制器是 Kubernetes 的核心概念,它是一个控制循环,持续监控集群状态,并努力将当前状态调整为期望状态,简单来说,控制器就像一个"管家",随时关注着你的资源情况,确保按照你的期望运行。
它并不关心 YAML,也不关心 CRD,它只干一件事:不停观察某种资源 → 如果发现状态不符合预期 → 自动修正
控制器的结构通常是: Start → List/Watch → 接收事件 → 放入队列 → Reconcile → 更新状态
知道基础概念之后,我们看看Monitor-Operator 控制器有哪些核心组件
MonitorStackReconciler (主控制器)
├── Reconcile Loop (协调循环)
├── Resource Builders (资源构建器)
├── Helpers (辅助函数)
└── Status Manager (状态管理器)type MonitorStackReconciler struct {
client.Client // Kubernetes 客户端
Scheme *runtime.Scheme // 资源类型注册表
}这是控制器的心脏,每当 MonitorStack 资源发生变化时就会被触发
什么样的变化会触发?
monitorstack_controller.go - 主控制器逻辑
代码太长,这里就不贴了,只说一下代码流程
// MonitorStackReconciler 负责协调 MonitorStack 资源
type MonitorStackReconciler struct {
client.Client // Kubernetes 客户端,用于操作资源
Scheme *runtime.Scheme // 资源类型注册表
}
// Reconcile 是核心的协调函数
// 每当 MonitorStack 资源变化时被调用
func (r *MonitorStackReconciler) Reconcile(
ctx context.Context,
req ctrl.Request,
) (ctrl.Result, error) {
// 1. 获取 MonitorStack 实例
// 2. 处理删除逻辑
// 3. 添加 Finalizer
// 4. 协调 Prometheus
// 5. 协调 Grafana
// 6. 更新状态
// 7. 返回结果(是否重试)
}那么我们MonitorStack的协调主流程大致是这样的
协调流程图如下

MonitorStack协调流程图
在 K8s,每个资源都有:
Controller 做的事非常简单:
if spec != status:
reconcile()这个 reconcile(调和)就是 Operator 的核心算法
有了上一篇的的基础概念以及上内容的介绍,我们再来回顾下,核心工作流程
1、用户创建一个自定义资源monitorstack
kubectl apply -f simple-monitoring.yaml这个对象进入 etcd,被 APIServer 保存 2、Controller 通过 List/Watch 得到事件 控制器会:
3、控制器收到事件 → 放入工作队列(workqueue)
这就是k8s设计的经典之处,保证稳定、幂等
4、worker 调用你的 reconcile()
5、将系统状态调和到 spec
CRD 负责告诉 Kubernetes“存在一种新资源” Controller 负责盯着这种东西,一旦发现不符合 spec,就自动修复整个系统 Operator = 应用自动化 + 自愈机制 + 生命周期管理
# 安装CRD到集群
make install
# 验证CRD安装
kubectl get crd monitorstacks.monitoring.cillian.website
# 在后台运行控制器
make run &
# 等待控制器启动(约30秒)
sleep 30# 创建简单的监控栈
cat <<EOF | kubectl apply -f -
apiVersion: monitoring.cillian.website/v1
kind: MonitorStack
metadata:
name: demo-monitoring
namespace: default
spec:
prometheus:
enabled: true
service:
type: NodePort
port: 9090
nodePort: 30090
grafana:
enabled: true
adminPassword: "admin123"
service:
type: NodePort
port: 3000
nodePort: 30300
datasources:
- name: prometheus
type: prometheus
url: http://demo-monitoring-prometheus:9090
EOF# 查看MonitorStack状态
kubectl get monitorstacks
# 查看创建的资源
kubectl get deployments,services,configmaps -l app.kubernetes.io/managed-by=monitor-operator
# 查看Pod状态
kubectl get pods -l app.kubernetes.io/managed-by=monitor-operator
# 等待Pod就绪
kubectl wait --for=condition=ready pod -l app.kubernetes.io/component=prometheus --timeout=300s
kubectl wait --for=condition=ready pod -l app.kubernetes.io/component=grafana --timeout=300s如果你觉得命令行查看不方便,就用希里安开源的cilikube查看吧,cilikube是什么?就是一个k8s多集群管理平台,直白点就是可视化面板

资源面板
这里就可以看到希里安部署的CRD资源啦

自定义资源管理

MonitorStack

自定义资源修改
可以通过面板增删改查自定义资源MonitorStack,是不是比较方便,快去看下吧!
cilikube仓库[4]:
https://github.com/ciliverse/cilikube
# 获取Prometheus访问地址
echo "Prometheus: http://localhost:30090"
# 在浏览器中打开或使用curl测试
curl http://localhost:30090/api/v1/query?query=up# 获取Grafana访问地址
echo "Grafana: http://localhost:30300"
echo "用户名: admin"
echo "密码: admin123"
# 在浏览器中打开Grafana
# 登录后应该能看到已配置的Prometheus数据源# 如果控制器在前台运行,查看输出
# 如果在后台运行,可以查看进程
ps aux | grep "go run"
# 或者部署到集群后查看日志
make deploy
kubectl logs -f deployment/controller-manager -n monitor-operator-system# 构建镜像
make docker-build IMG=monitor-operator:v1.0.0
# 加载到kind集群
kind load docker-image monitor-operator:v1.0.0 --name monitor-operator-dev
# 部署到集群
make deploy IMG=monitor-operator:v1.0.0遇到问题时,按以下顺序检查
写着写着发现如果只是初始化的开发倒是可以,但要一步一步讲明白具体实现代码的话,一篇文章根本不够写,所以先把基础概念和知识分享给大家,后期再把每一部分的具体内容拆开分享,总结下就是这几个内容:
但如果要实现生产可用级别的内容还要学习这些进阶内容
虽然目前只能部署prometheus和grafana,但是后期还可以很多扩展开发
进行组件的扩展:
功能扩展:
安全增强:
可视化:
相信本项目作为学习入门应该是一个较好的例子,欢迎各位读者来参与开源交流以及贡献,开源更多的不是为了完成一个项目而去做,而是为了让参与的每个人包括希里安收获到、学习到才是最终的目的! 安装使用只是第一步,通过工具的学习使用,让他人受益才能发挥工具的价值!
仓库地址[5]:
https://github.com/ciliverse/monitor-operator
能看到末尾的你已经赢了大部分人了,就剩行动了,纸上得来终觉浅,冲冲冲!!!
[1] 漏洞参考: https://github.com/facebook/react/security/advisories/GHSA-fv66-9v8q-g76r
[2] 安装: https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/
[3] 安装工具: https://kubernetes.io/docs/tasks/tools/
[4] cilikube仓库: https://github.com/ciliverse/cilikube
[5] 仓库地址: https://github.com/ciliverse/monitor-operator