Deployment 是 Kubernetes 三个常用工作负载中最常用的。Deployment 用于管理应用的部署情况，可以实现应用的滚动升级和回滚，还能实现应用的扩缩容。

Deployment 通过 ReplicaSet 来管理 Pod。一个完整的 Deployment 创建到 Pod 被拉起的流程由多个控制器协同完成：

UpgradeAwareHandler 是 Kubernetes 里很重要的一个代码组件，在 Kubernetes 中用于代理和转发请求。

只要是有转发请求的地方都可以见到他的身影：

1. kubectl 的命令 exec/attach/log/port-forward 等需要连接到容器的长连接；
2. APIServer Aggregation 功能，需要将请求转发到外部 APIServer。

第三方的集群网关组件也会利用这个组件来实现转发代理，如：Karmada、KubeVela Cluster Gateway 等。

为什么都使用这个组件来转发请求？本文通过阅读源码，深入研究这个组件的实现原理以及使用方式。

Kubernetes 是一个声明式的系统。我们在使用 Kubernetes 管理应用、部署服务时，通常会使用一个 YAML 格式的文件去描述期望应用部署后的最终状态。

当这个文件被提交到 Kubernetes 后，我们神奇地发现 Kubernetes 在不停地创建各种资源，直到达到我们所描述的状态。实现这个功能的组件就是我们今天讨论的 kube-controller-manager，Kubernetes 集群的大脑。

我们平时所见到的 Kubernetes 集群中的节点（Node）、Pod、服务（Service）、端点（Endpoint）、命名空间（Namespace）、服务账户（ServiceAccount）、资源定额（ResourceQuota） 等资源都是由 kube-controller-manager 管理的。

当把硬盘从 PVE 主机直接拆除而没提前从 PVE 面板中删除，会在存储面板显示错误图标，这时手动删除存储会直接报 not a valid block device 的错。

很多人觉得 PVE 复杂的原因主要就是因为 PVE 有很多操作需要用命令去完成，就比如上面这个删除失效存储的情况，可以简单地提示个强制删除就能解决问题，而 PVE 却产生了一个不明所以的错误提示。

其实此时要想正常完成删除动作，只需要执行几条命令就行，但这个错误提示让人没有头绪，我还是在官方论坛找到的解决方法。

家中 HomeLab 的主力是一台自组的 AMD 机器（以下简称 PRD 主机），使用 PVE 作为虚拟化系统，在系统中装黑群和 PCDN 的虚机，同时使用 PVE 中的 lxc 容器来装服务。

作为主力机器，我给机器配了致态的 TiPlus 7100 做系统盘，并且用 TiPlus 5000 做虚拟机系统数据盘。

最近 618 国产长江存储颗粒的 NVMe 的固态价格实在是非常便宜，而且个个都是 PCIe4.0 的满速盘。从认识 SSD 以来就没见过这么香的价格，所以我也在活动期间买了几块。主要是 2TB 的爱国者 P7000z、2 TB 的梵想 S790 和 4TB 的 HP FX900 Plus。

到货后都在 Windows 中使用 CDI 进行了检测，都是全新盘，没什么问题。接着将硬盘插到 PRD 主机中启动后发生了很诡异的事，P7000z 在 PVE 中无法识别出来。

继去年 HomeLab PRD 节点全面使用 lxc 容器运行应用后，最近兴趣使然，又开始折腾主机的网络。主要折腾的内容是 vlan、SR-IOV 和万兆，等整理完再把折腾笔记发出来，本文主要解决折腾过程中遇到的一个问题。

为方便管理容器，我为每个 lxc 里的容器（docker in lxc）创建一个 Network，分配独立的网段。在主路由中将该子网的请求路由到该 lxc 上，就可以实现通过子网 IP 直接访问容器。

配置好后发现，在 lxc 之外根本 ping 不通容器，请求始终到不了容器。

当代码中在多个线程中访问一个数据时，该数据就需要进行保护，保证在查询和修改时不会因为其它线程的操作而产生不可预料的异常。

下面简单总结了 Java 多线程开发中几个不同场景下的线程安全类和锁的使用样例。

KubeVela 中使用用户伪装功能的主要有两个模块：KubeVela Controller 和 KubeVela API Server。

• KubeVela Controller：实现了 KubeVela 的主要逻辑；
• KubeVela API Server：提供 API 接口给 VelaUX。

在 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 处理流程如下：