Operator 是 Kubernetes 用来拓展其 API 的一种开发范式（Pattern），其核心是定义若干的自定义资源及其对应的资源控制器，当这些资源发生变化时其对应的控制器对变化进行调解（Reconcile），最终使得实际状态与预期状态达成一致。K8s-sigs 推出的 kubebuilder 是一个用于构建 Operator 应用的框架，和 Operator-SDK 一样都依赖了 controller-runtime，提供了高级 API 和抽象，让开发者更直观地编写操作逻辑，并提供用于快速启动新项目的脚手架和代码生成工具。

截至目前我已经参与了两个 Operator 项目的搭建和维护，均采用了 kubebuilder 做基础脚手架。我目前对 CRD 的设计生成、Webhook 的校验机制和、Controller 的控制循环机制有了一定认识，接触时间稍长后在日常开发 Operator 项目时难免出现缺乏新意的情况，Operator 模式看久了和 CURD 之于后端有些许相似。但我乐观地估计通过观察下层实现可以收获一些启发。既然 kubebuilder 和 Operator-SDK 都依赖了 controller-runtime，那么就先从它出发吧。

翻译自 What happens when … Kubernetes edition!。我认为这篇文章写得生动有趣，且在关键位置都给出了有价值的链接，引导进一步的阅读学习，让我有了重读并翻译的冲动。

如果我希望往 Kubernetes 集群当中部署 nginx，我大概率会在命令行输入下面这样的命令并敲下回车键：

1

kubectl create deployment nginx --image=nginx --replicas=3

几秒之后，我应该能看到三个 nginx 的 pod 散布在集群的工作节点上。这很神奇！但这个过程背后究竟发生了什么？

关于 Kubernetes 的惊人的特点是，它通过用户友好的 API 处理工作负载的部署。其中的复杂性被简单的抽象隐藏起来。但为了充分理解它所提供的价值，了解其内部工作原理也是很有用的。本指南将引导您了解从客户端 kubectl 到 kubelet 的请求的完整生命周期，并在必要时链接到源代码（或者相关文档和博客）来进一步说明正在发生的事情。

这是一份不断修订的文档。如果您发现可以改进或重写的地方，欢迎贡献！

摘要

论文描述的方法简称 RBAC，基于角色的访问控制，是目前非常主流的访问控制方法。用户（User）、角色（Role）和权限（Permission）是论文中最主要的三个概念。角色和用户组这个概念很像，但是用户组仅仅只是一个用户集合，而角色则联系着用户和权限。说到底都是为了让用户获取权限来执行相应的操作，不管是加入角色还是用户组，都只是一个中间态。

RBAC0 是基础模型，是任何系统实现 RBAC 的最低要求。RBAC1 和 RBAC2 都包含了 RBAC0，但是分别加入了不同的特性。RBAC1 加入了角色层级特性，即角色 A 可以通过继承角色 B 获取角色 B 拥有的权限。RBAC2 加入了约束特性，控制用户对 RBAC 中不同资源、组件的权限。而 RBAC3 包括了角色层级和约束。示意图如下所示，其中基础模型 RBAC0 是实线部分。