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 管理的。
当把硬盘从 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 核心组件里有两个和用户伪装相关的功能：应用认证和 ServiceAccount 伪装。VelaUX 由于自身带了一套用户权限相关的功能，当开启用户伪装后，会注入登录的用户信息作为伪装用户。
用户伪装是 Kubernetes 原生提供的 User impersonation 功能，这个功能在管理集群时非常有用。
通常在管理系统中管理集群时，使用的都是集群管理员（cluster-admin）这样的高权限用户。当用户使用系统进行操作集群时，实际操作身份和集群权限并不匹配，这样很容易造成安全问题。
比如用户实际权限只有 Namespace 的操作，但通过集群管理系统部署 Helm 时，由于管理系统使用的集群管理员用户，如果 Chart 包里创建多个 Namespace 甚至是 ServiceAccount 就会造成越权。
通常会考虑在管理系统中做权限，但相当于有两套权限，很难保证做得面面具到，如果使用 Kubernetes 的用户伪装功能就可以完美解决这个问题。