在接触K8s时，如何理解自定义资源困扰了我很久，在项目上部署nacos时，发现有使用自定义对象，因此进行了一定的研究，并撰写本文用于交流一下K8s中的CRD概念理解。
首先从nacos部署开始
为了实现在集群上进行服务注册、发现的功能，部署一个nacos是一个比较通用的方案；
nacos官方的建议推荐使用Nacos Operator在Kubernetes部署Nacos Server.
部署过程为首先使用helm部署operator
# 直接使用helm方式安装operator
helm install nacos-operator ./chart/nacos-operator
然后启动单实例，standalone模式
kubectl apply -f config/samples/nacos.yaml
测试：
使用 kubectl port-forward（临时调试）
这种方法无需更改任何服务配置，非常适合快速临时访问。
kubectl port-forward service/nacos 8848:8848
这样就实现了通过operator在K8s集群上部署nacos；
验证
输入命令
kubectl get nacos
可以注意到，这个get命令区别于经常使用的 get pods, get deployments，而是以nacos命名的；
这就涉及到K8s中的自定义资源概念了；
自定义资源(CR)
kubectl get nacos
这条命令查询的是 Kubernetes 集群中的 Nacos 自定义资源对象（Custom Resource），它既不是直接查询 Pod，也不是直接查询 Deployment。下面这个表格能帮你快速理解核心概念：
| 概念 | 说明 | 在命令中的体现 |
|---|---|---|
| 自定义资源 (CR) | 一种扩展 Kubernetes API 的方式，用于描述和管理 Kubernetes 原生不支持的特定应用（如 Nacos）。 | kubectl get nacos 中的 nacos 就是一种自定义资源类型。 |
| 自定义资源定义 (CRD) | 定义了自定义资源的“数据结构”，相当于创建了一个新的 API 对象类型。 | 你的集群中必然存在一个名为 nacos 的 CRD，否则命令无法执行。 |
| Operator | 一个特定的控制器，它监听自定义资源的变化，并根据资源描述（如你的 YAML 文件）来创建和管理真实的 Kubernetes 资源（如 StatefulSet, Service）。 | 你所在的 nacos-k8s\operator 目录暗示了这可能是在使用 Nacos Operator。 |
🔄 Nacos 与 Deployment 的关系
Nacos 服务本身并不直接“属于”Deployment。在更为复杂的部署场景（尤其是集群模式）下，Operator 通常会使用 StatefulSet 来管理 Nacos Pod。
StatefulSet 与 Deployment 的关键区别在于：
StatefulSet：更适合管理有状态应用（如 Nacos、数据库）。它能提供稳定的网络标识符（如 pod-name-0, pod-name-1）和持久化存储，这对于需要稳定身份和持久化数据的集群应用至关重要。
Deployment：更适合部署和扩展无状态应用（如 Web 前端、无状态 API 服务），通常不提供稳定的网络标识和独立的持久化存储。
所以，虽然你的 Nacos 当前是单机模式（standalone），但背后的控制器（Operator）很可能也是通过一个 StatefulSet（即使副本数为1）来保证其数据持久性，而非 Deployment。
为什么nacos operator采用自定义资源的方式进行部署？
Nacos Operator 采用自定义资源（Custom Resource）的方式进行部署，这背后是云原生领域管理复杂有状态应用的通用模式和深刻考量。简单来说，它通过扩展 Kubernetes 的 API，让你能用声明式的方式像管理原生资源一样管理 Nacos，从而大大简化和自动化了运维工作。
总而言之，Nacos Operator 选择自定义资源的方式，是为了遵循 Kubernetes 的“控制器模式”最佳实践，将专家的运维知识编码到 Operator 中，让用户能够以 Kubernetes 原生、声明式、自动化 的方式来管理这个有状态的中件间服务。这不仅是技术上的最佳路径，也代表了云原生应用管理的未来趋势。
