首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >用Kubebuilder开发Operator ,写一个会自己运维的监控应用!

用Kubebuilder开发Operator ,写一个会自己运维的监控应用!

作者头像
希里安
发布2025-12-25 14:59:03
发布2025-12-25 14:59:03
2280
举报
文章被收录于专栏:希里安希里安

希里安近日见闻

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 日的故障事件之后,我们再次让互联网用户失望了。我们将在下周发布详细信息,介绍我们正在采取的措施,以防止此类事件再次发生。

Operator快速开发指南

上一篇文章介绍了什么是Kubernetes Operator,有什么用,今天就来给各位读者介绍一下,如何使用Kubebuilder去开发一个只需部署一个自定义资源就能同时启动prometheus和grafana的示例Operator,希里安也是学习者,边学边用,写的有问题的,欢迎各位读者一起交流!

简单来说:

  • 传统方式:手动运行命令或者helm分别部署 Prometheus 和 Grafana
  • Operator 方式:定义一个 YAML 文件描述你想要什么,Operator 自动帮你完成

之前已经详细介绍如何部署一个示例的 monitor operator了,这里再简单回顾下:

快速体验

如果已经有相关经验的读者,可以直接拉取仓库代码进行优化或者部署这个示例Opertaor到自己的集群尝试一下再交流!仓库地址如下: https://github.com/ciliverse/monitor-operator

代码语言:javascript
复制
# 添加 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
查看状态
查看状态

查看状态

代码语言:javascript
复制
# kubectl -f simple-monitoring.yaml
# 详细文件内容在后面章节
访问Grafana界面
访问Grafana界面

访问Grafana界面

环境准备

  • • go 语言环境
  • • 一个可用的k8s集群
  • • docker(可选,本地测试集群需要)
  • • kubectl 安装[2]
  • • kubebuilder
代码语言:javascript
复制
# 安装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

K8s集群安装

这一部分,我想对我文章感兴趣的同学应该都是从事这个行业的,应该都有自己喜欢的安装的方式(如果完全不会安装,可以后台私信我),官方推荐安装工具[3]有以下几种

  • • kind (推荐用于开发) Kind (Kubernetes in Docker) 是在 Docker 中运行Kubernetes 的工具,非常适合本地开发,是用容器模拟node节点,所以不是真实的节点,pod 网络也在容器网络之上运行,网络行为不等同于真实机器网络,但是kind 启动集群时,其实是使用 kubeadm 做初始化,只不过节点是容器
  • • minikube 定位更加轻量,是简化的K8s发行版,默认启动单节点集群,但也可选多节点模式,启动比kind要慢一些,资源占用较高,但比kind更接近正式环境的本地集群,使用虚拟机或容器运行“真实节点”,本质都会创建一个独立 Linux
  • • kubeadm 生产级别的正式集群安装工具,是在真实服务器上安装,也是官方推荐生产环境使用的工具,不是模拟器,不会创建虚拟机,不会创建容器

希里安这里已经有现成的集群了,如果大家不想手动,直接在如上环境准备内容中安装kind后一键式创建,执行以下命令快速创建一个测试集群吧!

代码语言:javascript
复制
# 创建本地测试集群
kind create cluster --name monitor-operator-dev

# 验证集群
kubectl cluster-info --context kind-monitor-operator-dev

项目初始化

代码语言:javascript
复制
# 创建项目目录
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和控制器
创建API和控制器

创建API和控制器

目录结构

初始化后的项目结构,这里只列出主要的目录,其实kubebuilder(v4.9.0)初始化以及创建api和控制器后目前会有19个目录,共计46个文件,详细的大家可以初始化生成后看一下:

代码语言:javascript
复制
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/                        # 测试代码
└── ...

具体生成的详细内容,各位读者还是直接看代码吧,东西还是不少

项目配置和生成代码

代码语言:javascript
复制
# 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设计

CRD 定义自定义资源的 schema、版本与行为入口(用户与系统交互的对象),允许你在 Kubernetes 中定义自己的资源类型。在这次讲解中,我们定义了 MonitorStack 这个自定义资源,CRD 最关键的一点:定义一种结构(Schema)

核心概念
  • 自定义资源(Custom Resource):通过CRD定义的新的资源类型
  • CR(Custom Resource Instance):自定义资源的实例
MonitorStack CRD结构
代码语言:javascript
复制
// 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 实例
代码语言:javascript
复制
# 这就是一个 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:9090
设计阶段要考虑那些事?
  • • 明确操作对象(API):CR 的职责是什么?包含哪些字段(spec)?哪些字段应属于 status?
  • • 错误与回滚策略:如何处理失败?重试策略?是否带 finalizer 做清理?
  • • 版本策略:如何做 CRD 的版本演进(v1alpha1 → v1beta1 → v1)?
  • • 安全与权限:需要的 ClusterRole/Role、哪些 API 需要访问(configmaps, secrets, deployments...)
  • • 可观察性:日志、事件、Prometheus metrics、健康探针(/healthz)?
  • • 操作接口:是否需要 Webhook(验证、默认、转换)?
CRD字段
  • spec = 用户能控制/配置的内容,只放配置,不放状态,如上面示例
  • status = 系统实际情况,由控制器填写,用户不能写 status
代码语言:javascript
复制
apiVersion: 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.preserveUnknownFields
资源层次结构
代码语言:javascript
复制
MonitorStack (自定义资源)
├── Spec (期望状态)
│   ├── Prometheus 配置
│   └── Grafana 配置
└── Status (观察状态)
    ├── 整体状态
    ├── Prometheus 状态
    └── Grafana 状态
CRD 本质
  • • 就是一个“结构定义”
  • • 只负责告诉 APIServer:"我多了一种新的资源类型"
  • • 完全不包含业务逻辑

控制器设计

什么是 Kubernetes 控制器?

控制器是 Kubernetes 的核心概念,它是一个控制循环,持续监控集群状态,并努力将当前状态调整为期望状态,简单来说,控制器就像一个"管家",随时关注着你的资源情况,确保按照你的期望运行。

它并不关心 YAML,也不关心 CRD,它只干一件事:不停观察某种资源 → 如果发现状态不符合预期 → 自动修正

控制器的结构通常是: Start → List/Watch → 接收事件 → 放入队列 → Reconcile → 更新状态

知道基础概念之后,我们看看Monitor-Operator 控制器有哪些核心组件

代码语言:javascript
复制
MonitorStackReconciler (主控制器)
├── Reconcile Loop (协调循环)
├── Resource Builders (资源构建器)
├── Helpers (辅助函数)
└── Status Manager (状态管理器)
控制器结构
代码语言:javascript
复制
type MonitorStackReconciler struct {
    client.Client  // Kubernetes 客户端
    Scheme *runtime.Scheme  // 资源类型注册表
}
协调循环 (Reconcile Loop)

这是控制器的心脏,每当 MonitorStack 资源发生变化时就会被触发

什么样的变化会触发?

  1. 1. 资源创建:创建新的MonitorStack资源
  2. 2. 资源更新:修改MonitorStack的Spec
  3. 3. 资源删除:删除MonitorStack资源
  4. 4. 子资源变化:Controller创建的Deployment、Service等发生变化
  5. 5. 定期同步:Controller定期重新协调

monitorstack_controller.go - 主控制器逻辑

代码太长,这里就不贴了,只说一下代码流程

代码语言:javascript
复制
// 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实例
  • • Finalizer 管理
    • • 处理删除逻辑 (如果资源被标记为删除)
  • • 添加Finalizer
  • • 初始化状态
    • • 如果Status.Phase为空,说明这是新创建的资源
  • • 协调 Prometheus
    • • 创建/更新 ConfigMap (配置)
    • • 创建/更新 PVC (数据存储)
    • • 创建/更新 Deployment
    • • 创建/更新 Service
  • • 协调 Grafana
    • • 创建/更新 ConfigMap (数据源)
    • • 创建/更新 Deployment
    • • 创建/更新 Service
  • • 更新状态
    • • 检查组件健康状态
    • • 更新 Phase
    • • 更新组件 Status

协调流程图如下

MonitorStack协调流程图
MonitorStack协调流程图

MonitorStack协调流程图

控制器的核心设计:期望状态 vs 实际状态

在 K8s,每个资源都有:

  • • Spec(期望状态):用户想要什么
  • • Status(实际状态):系统现在是什么样

Controller 做的事非常简单:

代码语言:javascript
复制
if spec != status:
    reconcile()

这个 reconcile(调和)就是 Operator 的核心算法

Reconcile 的设计要点
  • • 幂等(调用多次不出错,结果一致)
  • • 必须只关心 spec(期望状态)
  • • 超时、失败要能重试
  • • 不要永远循环,必须 return(让下次事件触发)
  • • 逻辑必须清晰:读取 → 对比 → 修复

Operator 如何工作的

有了上一篇的的基础概念以及上内容的介绍,我们再来回顾下,核心工作流程

1、用户创建一个自定义资源monitorstack

代码语言:javascript
复制
kubectl apply -f simple-monitoring.yaml

这个对象进入 etcd,被 APIServer 保存 2、Controller 通过 List/Watch 得到事件 控制器会:

  • • List:第一次获得所有MonitorStack对象
  • • Watch:持续监听新增/修改/删除事件

3、控制器收到事件 → 放入工作队列(workqueue)

  • • 不直接处理事件
  • • 而是放入队列
  • • 多 worker 并发处理,自动重试

这就是k8s设计的经典之处,保证稳定、幂等

4、worker 调用你的 reconcile()

  • • 读取当前 CR(MonitorStack)对象
  • • 查看 spec(用户需求)从 MonitorStack.Spec 读取
  • • 查看实际资源(Pod/Service/Secret)
  • • 对比两者,计算差异 (Diff)
  • • 自动创建/更新/删除底层资源,让它们状态一致

5、将系统状态调和到 spec

  • • 没有 Pod → 创建 Pod
  • • Pod 少了 → 补齐
  • • Pod 挂了 → 重建
  • • 配置变更 → 滚动升级
  • • 删除对象 → 清理所有资源

CRD 负责告诉 Kubernetes“存在一种新资源” Controller 负责盯着这种东西,一旦发现不符合 spec,就自动修复整个系统 Operator = 应用自动化 + 自愈机制 + 生命周期管理

本地测试运行

代码语言:javascript
复制
# 安装CRD到集群
make install

# 验证CRD安装
kubectl get crd monitorstacks.monitoring.cillian.website

# 在后台运行控制器
make run &

# 等待控制器启动(约30秒)
sleep 30

部署运行

代码语言:javascript
复制
# 创建简单的监控栈
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

验证

代码语言:javascript
复制
# 查看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

MonitorStack

自定义资源修改
自定义资源修改

自定义资源修改

可以通过面板增删改查自定义资源MonitorStack,是不是比较方便,快去看下吧! cilikube仓库[4]: https://github.com/ciliverse/cilikube

访问服务

访问Prometheus
代码语言:javascript
复制
# 获取Prometheus访问地址
echo "Prometheus: http://localhost:30090"

# 在浏览器中打开或使用curl测试
curl http://localhost:30090/api/v1/query?query=up
访问Grafana
代码语言:javascript
复制
# 获取Grafana访问地址
echo "Grafana: http://localhost:30300"
echo "用户名: admin"
echo "密码: admin123"

# 在浏览器中打开Grafana
# 登录后应该能看到已配置的Prometheus数据源
查看控制器日志
代码语言:javascript
复制
# 如果控制器在前台运行,查看输出
# 如果在后台运行,可以查看进程
ps aux | grep "go run"

# 或者部署到集群后查看日志
make deploy
kubectl logs -f deployment/controller-manager -n monitor-operator-system
构建Docker镜像
代码语言:javascript
复制
# 构建镜像
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

问题排查

遇到问题时,按以下顺序检查

  1. 1. 检查集群连接
  2. 2. 检查CRD状态
  3. 3. 检查Operator Deployment
  4. 4. 检查Controller Pod状态
  5. 5. 检查RBAC权限
  6. 6. 检查MonitorStack实例
  7. 7. 检查资源使用
  8. 8. 检查Events
  9. 9. 查看日志 以上编写为一个脚本文件,就可以方便排查自己开发operator遇到的问题,限于篇幅,就放在仓库里各位自取啦!

总结

写着写着发现如果只是初始化的开发倒是可以,但要一步一步讲明白具体实现代码的话,一篇文章根本不够写,所以先把基础概念和知识分享给大家,后期再把每一部分的具体内容拆开分享,总结下就是这几个内容:

  • • 如何用 Kubebuilder 初始化项目
  • • 如何设计 CRD
  • • 如何编写 Reconcile
  • • 如何部署 CRD 和 Controller
  • • 如何实现“自动调和”

但如果要实现生产可用级别的内容还要学习这些进阶内容

  • • 用 StatefulSet 替代直接创建 Pod(需要稳定持久性和有序启动/终止的有状态应用必须用)
  • • 支持滚动升级(保证有状态应用在升级期间仍可用,避免数据丢失和大范围宕机)
  • • 资源删除保护与回收(防止资源被直接删除)
  • • 写 Webhook 做校验(Validating)与默认(Mutating)
  • • 加备份恢复子控制器(生产环境必须有可靠的备份恢复策略以应对数据损坏或灾难恢复)
  • • 事件(Events)+ 日志规范(Operator 需要给用户可观测性)
  • • 把 Operator 的功能拆成若干模块(当 operator 复杂(多个子控制器、备份/restore、webhook、metrics)时,模块化提高可维护性、测试性、团队并行开发能力)
  • • 性能优化 (大量 CR / 高频事件会给 apiserver 与 operator 带来压力)

拓展开发

虽然目前只能部署prometheus和grafana,但是后期还可以很多扩展开发

进行组件的扩展:

  • • AlertManager
  • • Node Exporter
  • • Loki
  • • ...等等

功能扩展:

  • • 多集群监控
  • • 自动扩缩容
  • • 备份恢复

安全增强:

  • • RBAC精细化控制
  • • 认证集成

可视化:

  • • trace
  • • 业务指标监控

相信本项目作为学习入门应该是一个较好的例子,欢迎各位读者来参与开源交流以及贡献,开源更多的不是为了完成一个项目而去做,而是为了让参与的每个人包括希里安收获到、学习到才是最终的目的! 安装使用只是第一步,通过工具的学习使用,让他人受益才能发挥工具的价值!

仓库地址[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

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2025-12-11,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 希里安 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 希里安近日见闻
  • Operator快速开发指南
    • 快速体验
    • 环境准备
    • K8s集群安装
    • 项目初始化
    • 目录结构
    • 项目配置和生成代码
    • 开发前需要知道的基础概念
    • CRD设计
    • 控制器设计
    • Operator 如何工作的
    • 本地测试运行
    • 部署运行
    • 验证
    • 访问服务
    • 问题排查
    • 总结
    • 拓展开发
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档