Kubernetes 1.7 版本以来就引入了自定义控制器的概念，该功能可以让开发人员扩展添加新功能，更新现有的功能，并且可以自动执行一些管理任务。
Operator 是由 CoreOS 开发的，用来扩展 Kubernetes API 的控制器框架，它用来创建、配置和管理复杂的有状态应用，如数据库、缓存和监控系统。
Operator 基于 Kubernetes 的资源和控制器概念之上构建，但同时又包含了应用程序特定的领域知识。
这些自定义的控制器就像 Kubernetes 原生的组件一样，Operator 直接使用 Kubernetes API 进行开发，也就是说可以根据这些控制器内部编写的自定义规则来监控集群、更改 Pods/Services、对正在运行的应用进行扩缩容。
创建 Operator 的关键是 CRD（自定义资源）的设计。本文将通过虚拟需求，设计 CRD 并实现 CRD 的控制逻辑，以体验 Operator 的开发过程。
Deployment 是 Kubernetes 三个常用工作负载中最常用的。Deployment 用于管理应用的部署情况，可以实现应用的滚动升级和回滚，还能实现应用的扩缩容。
Deployment 通过 ReplicaSet 来管理 Pod。一个完整的 Deployment 创建到 Pod 被拉起的流程由多个控制器协同完成：
UpgradeAwareHandler 是 Kubernetes 里很重要的一个代码组件，在 Kubernetes 中用于代理和转发请求。
只要是有转发请求的地方都可以见到他的身影：
第三方的集群网关组件也会利用这个组件来实现转发代理，如：Karmada、KubeVela Cluster Gateway 等。
为什么都使用这个组件来转发请求？本文通过阅读源码，深入研究这个组件的实现原理以及使用方式。
Kubernetes 是一个声明式的系统。我们在使用 Kubernetes 管理应用、部署服务时，通常会使用一个 YAML 格式的文件去描述期望应用部署后的最终状态。
当这个文件被提交到 Kubernetes 后，我们神奇地发现 Kubernetes 在不停地创建各种资源，直到达到我们所描述的状态。实现这个功能的组件就是我们今天讨论的 kube-controller-manager，Kubernetes 集群的大脑。
我们平时所见到的 Kubernetes 集群中的节点（Node）、Pod、服务（Service）、端点（Endpoint）、命名空间（Namespace）、服务账户（ServiceAccount）、资源定额（ResourceQuota） 等资源都是由 kube-controller-manager 管理的。
继去年 HomeLab PRD 节点全面使用 lxc 容器运行应用后，最近兴趣使然，又开始折腾主机的网络。主要折腾的内容是 vlan、SR-IOV 和万兆，等整理完再把折腾笔记发出来，本文主要解决折腾过程中遇到的一个问题。
为方便管理容器，我为每个 lxc 里的容器（docker in lxc）创建一个 Network，分配独立的网段。在主路由中将该子网的请求路由到该 lxc 上，就可以实现通过子网 IP 直接访问容器。
配置好后发现，在 lxc 之外根本 ping 不通容器，请求始终到不了容器。
KubeVela 中使用用户伪装功能的主要有两个模块：KubeVela Controller 和 KubeVela API Server。
在 KubeVela 核心组件里有两个和用户伪装相关的功能：应用认证和 ServiceAccount 伪装。VelaUX 由于自身带了一套用户权限相关的功能，当开启用户伪装后，会注入登录的用户信息作为伪装用户。
用户伪装是 Kubernetes 原生提供的 User impersonation 功能，这个功能在管理集群时非常有用。
通常在管理系统中管理集群时，使用的都是集群管理员（cluster-admin）这样的高权限用户。当用户使用系统进行操作集群时，实际操作身份和集群权限并不匹配，这样很容易造成安全问题。
比如用户实际权限只有 Namespace 的操作，但通过集群管理系统部署 Helm 时，由于管理系统使用的集群管理员用户，如果 Chart 包里创建多个 Namespace 甚至是 ServiceAccount 就会造成越权。
通常会考虑在管理系统中做权限，但相当于有两套权限，很难保证做得面面具到，如果使用 Kubernetes 的用户伪装功能就可以完美解决这个问题。
KubeVela 是多集群应用管理组件，所以在使用之前需要将集群纳管到 KubeVela 中，让 KubeVela 能感知并维护集群信息。在应用下发到指定集群时，KubeVela 能知道如何连接到目标集群并进行操作。
KubeVela 使用的是 Secret 来保存集群信息的，和 Cluster Gateway 共享的同一套 Secret 进行集群管理。当进行集群纳管时，KubeVela 会创建名字和集群名相同的 Secret，用于存储集群的连接信息。
当请求从 APIServer 转发到 Cluster Gateway 时，使用路径中提供的集群名去查询 Secret 并获取到纳管集群的连接信息。
Cluster Gateway 处理流程如下：
在 Kubernetes 中，负载指的是 Deployment、StatefulSet 和 DaemonSet 这三种资源：
如何确定哪些 Pod 是由哪个负载进行管理的？这些 Pod 是怎么与负载进行关联的？
KubeVela 的多集群管理依赖于 Cluster Gateway 组件，在 KubeVela 的 Helm Chart 中会自动安装。KubeVela 并不会直连集群，而是必须通过 Cluster Gateway 连接集群进行管理。
包括集群管理在内的功能都是依赖于 Cluster Gateway 实现的，所以 Cluster Gateway 是 KubeVela 多集群管理必不可少的一个组件。
