## 一、先分清意图
||策略模式Strategy|装饰器模式Decorator|
|:-:|:-:|
|目的|替换算法|叠加行为|
|接口|同一个接口，多种实现|同一个接口，包一层同接口对象|
|选择时机|注册 / 构造时决定|运行时逐层包装|
|在 K8s 里|每种资源的 strategy、每种鉴权器|filter 链、storage 包装|
|代价|行为隐式，要读注册代码|调用栈深，顺序敏感|
一个实用的判断：**"换一种做法"用 Strategy，"多做一件事"用 Decorator。**
## 二、策略模式：每种资源都有自己的规矩

API Server 的 handler 和 store 是通用的，但每个资源的默认值、校验、不可变字段完全不同——这些差异全部下沉到 strategy。
![pat-1-strategy.png](https://developer.qcloudimg.com/http-save/yehe-11479707/9c236da0cff2fe949f391faaa4590176.png)

图 1：Store 只认接口，具体规矩由每种资源自己实现。

```
// staging/src/k8s.io/apiserver/pkg/registry/rest/create.go (v1.34.0)
type RESTCreateStrategy interface {
	runtime.ObjectTyper
	names.NameGenerator

	NamespaceScoped() bool
	PrepareForCreate(ctx context.Context, obj runtime.Object)
	Validate(ctx context.Context, obj runtime.Object) field.ErrorList
	Canonicalize(obj runtime.Object)
	WarningsOnCreate(ctx context.Context, obj runtime.Object) []string
}
```
每个资源实现一份：

```
// pkg/registry/core/pod/strategy.go（节选）
func (podStrategy) PrepareForCreate(ctx context.Context, obj runtime.Object) {
	pod := obj.(*api.Pod)
	pod.Status = api.PodStatus{Phase: api.PodPending}   // 状态由 kubelet 写，创建时必须清空
	...
}
```
`Store.Create` 只认接口：

```
// staging/src/k8s.io/apiserver/pkg/registry/generic/registry/store.go
rest.BeforeCreate(e.CreateStrategy, ctx, obj)   // 内部调 PrepareForCreate + Validate
```
**这就是"机制与策略分离"**：Store 负责"怎么存"，Strategy 负责"这个资源有什么规矩"。加一种资源，不需要改 Store。
同样的形状反复出现：
- `Authorizer` 接口 → RBAC / Node / Webhook / ABAC 四种策略；
- `Authenticator` 接口 → 证书 / Token / OIDC / Webhook；
- `Storage` 接口 → etcd3 / cacher；
- 调度框架的插件 → Filter / Score 都是策略。

**代价**：行为是隐式的。看 `Store.Create` 的代码，你不知道 Pod 创建时会清空 status——必须去翻 `podStrategy`。这也是为什么很多"奇怪行为"要先找对应资源的 strategy。
## 三、装饰器模式：每个请求都过一遍的横切
![pat-2-decorator.png](https://developer.qcloudimg.com/http-save/yehe-11479707/b0f1fbbe9b82f73dce7000c6a77628a2.png)

图 2：签名不变，行为叠加；执行顺序从最外层往里读。
API Server 的 filter 链是教科书级的装饰器：
```
// staging/src/k8s.io/apiserver/pkg/server/config.go
func DefaultBuildHandlerChain(apiHandler http.Handler, c *Config) http.Handler {
	handler := apiHandler
	handler = genericapifilters.WithAuthorization(handler, ...)
	handler = genericapifilters.WithAuthentication(handler, ...)
	handler = genericfilters.WithCORS(handler, ...)
	...
	handler = genericapifilters.WithAuditInit(handler)
	return handler
}
```
每个 `WithXxx` 都是 `func(http.Handler) http.Handler`——签名不变，行为叠加：

```
func WithLogging(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		start := time.Now()
		next.ServeHTTP(w, r)
		log.Printf("%s %s %v", r.Method, r.URL.Path, time.Since(start))
	})
}
```
K8s 里还有几处典型的装饰器：
- **`group.NewAuthenticatedGroupAdder`**：包住认证器，成功后往 `user.Info.Groups` 里补 `system:authenticated`——认证器完全不知道这件事；
- **`authenticator.WrapAudienceAgnosticToken`**：包住 token 认证器，加上 audience 校验；
- **`registry.DryRunnableStorage`**：包住 `storage.Interface`，dryRun 时走"不写"的分支；
- **`cacher`**：包住 etcd3 store，读走缓存、写透传。

**为什么必须用装饰器？** 因为这些是横切关注点：认证、审计、限流、日志、超时。它们不该污染 handler，也不该让每个 handler 自己实现一遍。装饰器让"加一件事"变成"包一层"，而且可以按需开关。
**代价**：调用栈深、顺序敏感。`WithAudit` 放在 `WithAuthentication` 里面还是外面，决定了认证失败时有没有审计记录——这个顺序在代码里是写死的，改动要非常小心。
## 四、四个容易混淆的模式
![pat-3-compare.png](https://developer.qcloudimg.com/http-save/yehe-11479707/a40e730dcb5e4cfb2592f100ef2bd9cb.png)

图 3：看"怎么组合"，而不是看名字。

|模式|一句话|K8s里的例子|怎么认|
|:-:|:-:|:-:|:-:|
|**Strategy**|同一接口，多种实现，选一个|`Authorizer` 的四种实现|接口 + 多个 struct，注册时决定|
|**Decorator**|同一接口，包一层，叠加行为|filter 链|`func(T) T`，可以无限嵌套|
|**Chain**|同一接口，串起来，依次询问|`union.New`|遍历列表，命中即返回|
|**Template Method**|定好骨架，把步骤留给子类|`Store.Create` 先 `BeforeCreate` 再 `Storage.Create`|父流程按固定顺序调钩子|
两个容易混淆的点：
- **`union.New` 不是装饰器**。它把多个 authorizer 组合成一个，按顺序询问、第一个表态的胜出——这是责任链；
- **`Store.Create` 调 strategy 钩子更像模板方法**。它自己定了"先准备、再校验、最后写"的骨架，具体步骤交给 strategy。

这几个模式在 K8s 里经常同时出现：`Store.Create` 是模板方法，里面调的是 strategy；strategy 里的校验可能再过一个装饰过的 client。
## 五、Go 让这两个模式特别轻

- **接口是隐式实现**的：`podStrategy` 不需要写 `implements`，只要方法签名对；
- **函数类型也能当策略**：`type ValidateFunc func(obj) field.ErrorList`，比定义一个 struct 更轻；
- **装饰器就是高阶函数**：`func(http.Handler) http.Handler`，一行就能包一层。

这也是为什么 K8s 的扩展点几乎都是"接口 + 注册"：CRI、CNI、CSI、调度插件、准入插件，本质都是策略模式的变体。
## 六、什么时候用哪个

一个很实用的判断：
- 新需求是**"另一种做法"**（另一种鉴权、另一种存储、另一种资源校验）→ Strategy；
- 新需求是**"多做一件事"**（多记一条日志、多一层限流、多一次审计）→ Decorator。

如果两者都不像，再考虑：需要"依次尝试"就是 Chain，需要"固定流程 + 可变步骤"就是 Template Method。
## 七、设计追问

**1. 为什么 K8s 大量用策略而不是 if/else？** 因为变化维度是"资源类型"，会不断新增。if/else 会把所有资源的规则堆在一个文件里，而且每加一种就要改公共代码——这正好违反开闭原则。
**2. 为什么 filter 用装饰器而不是一个大的 handler？** 因为关注点要能独立开关、独立排序、独立测试。一个巨大的 handler 里塞进认证、审计、限流，任何一处改动都可能影响全部。
**3. 装饰器链的顺序为什么不能随便调？** 因为存在语义依赖：审计必须在认证外层，否则认证失败的请求没有记录；限流必须在认证之后，否则拿不到用户身份做配额。
**4. 策略模式为什么会让行为"隐式"？** 因为调用点只看到接口。这是它换取扩展性的代价——所以 K8s 把 strategy 放在和资源同名的文件里（`pod/strategy.go`），让"这个资源的规矩"有一个固定的查找位置。

----
**一句话收尾**：Strategy 让**同一件事有多种做法**，Decorator 让**同一件事多几层包装**。K8s 用前者处理"资源之间的差异"，用后者处理"请求之间的共性"——两条线交叉，就是整个 apiserver 的骨架。

----
## 参考资料

1. Kubernetes 源码（v1.34.0）：`staging/src/k8s.io/apiserver/pkg/registry/rest/`、`pkg/registry/core/pod/strategy.go`、`staging/src/k8s.io/apiserver/pkg/server/config.go`
2. Kubernetes 文档：[Extending the Kubernetes API](https://kubernetes.io/docs/concepts/extend-kubernetes/)
3. Go 文档：[Interfaces](https://go.dev/tour/methods/9)、[Functions as values](https://go.dev/tour/moretypes/24)

>本文为原创内容，基于 Kubernetes v1.34.0 源码整理；版本号以对应 release note 为准。

一个实用的判断："换一种做法"用 Strategy，"多做一件事"用 Decorator。

kubernetes 进阶知识--设计模式：策略与装饰器，撑起 API Server 的骨架

读 Kubernetes 源码，很快会撞见两个反复出现的形状：一个是"同一个接口，多种实现"，一个是"同一个接口，包一层"。

前者是策略模式，后者是装饰器模式。它们分工很清晰：Strategy 解决"每种资源不一样"，Decorator 解决"每个请求都要过一遍"。源码基于 v1.34.0。

运维开发工程师

云计算

架构设计

后端

K8s源码解析：策略模式用接口多实现替换算法（如Pod清空状态、鉴权器），装饰器模式用同签名嵌套叠加横切行为（如认证审计Filter链）。机制与策略分离，扩展新资源不碰Store。判断：换做法用Strategy，多做事用Decorator。Go接口隐式实现，装饰器即高阶函数。

代码解释

Kubernetes

腾讯云双十一大促

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

kubernetes 进阶知识--设计模式：策略与装饰器，撑起 API Server 的骨架-腾讯云开发者社区-腾讯云

kubernetes 进阶知识--设计模式：策略与装饰器，撑起 API Server 的骨架

kubernetes 进阶知识--设计模式：策略与装饰器，撑起 API Server 的骨架

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐