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 多集群管理必不可少的一个组件。
Kubernetes 是容器编排引擎，用来对容器进行自动化部署、扩缩和管理。Kubernetes 更像是一个对资源进行管理和分配的系统，只负责把工作负载进行合理调度，最大化利用集群资源。
在实践中 Kubernetes 集群往往是部署很多套的，不同的业务线、不同部门或子公司都是使用的独立的集群，甚至常见的同一个服务会部署在不同区域的集群中以实现用户就近服务。要想实现将服务同时部署到多个集群单纯靠 Kubernetes 是不行的。严格来讲，在 Kubernetes 中是没有这里所说的应用这个维度的。
在应用的整个生命周期中，应用是可以存在多个集群，多个环境的。如在开发中可以把应用部署在开发测试集群，在上线后可以同时部署到生产和容灾集群，这很显然是一种超越 Kubernetes 集群的概念。
由于 Kubernetes 无法完成对应用的管理，所以业界诞生了多种方案来解决应用管理的需求，常见的有 OCM、Karmada 和 KubeVela，本文将对这几种方案进行总体介绍并基于使用需求进行选型。
在 Kubernetes 中，kube-apiserver 是整个集群的大脑和心脏，是控制集群的入口，所有模块都是通过其提供的 HTTP REST API 接口来操作集群的。
由于是所有模块的数据交互和通信的枢纽，大量组件直接通过 HTTP 请求 apiserver 带来的访问压力是非常大的。一但 apiserver 出现异常，整个集群就会受到影响，甚至崩溃。
所以尽可能降低 apiserver 的访问压力是很有必要的，Informer 机制就是 Kubernetes 解决这个问题的方案。Informer 本质就是 client-go 提供的一种本地缓存机制：
通过 Informer 机制，大大降低了 Kubernetes 各个组件跟与 API Server 的通信压力，同时 ETCD 的查询压力也同样得到缓解。