C#不参与Kubernetes编排逻辑，仅通过KubernetesClient调用API间接操作；真正编排由K8s控制平面完成，C#只负责发指令、读状态、响应事件。
直接上结论：C#本身不参与Kubernetes编排逻辑，它只是通过 KubernetesClient 库调用 K8s API 实现“间接编排”；真正做编排的是 K8s 控制平面（Controller Manager、Scheduler 等），C#代码只负责发指令、读状态、响应事件——别指望用 C# 写个 Deployment 就自动调度 Pod，那是误解。
为什么 KubernetesClient 调用失败常卡在配置加载
最常见现象是 BuildConfigFromConfigFile() 报 FileNotFoundException 或连接超时，不是代码写错，而是环境没对齐：
-
~/.kube/config文件不存在或权限不对（Linux/macOS 下需chmod 600 ~/.kube/config） - Minikube 未启动或
minikube status显示非Running状态 - 使用远程集群但未正确设置 context：
kubectl config use-context my-remote-cluster，否则BuildConfigFromConfigFile()默认读当前 context，可能指向已失效的本地 minikube - Windows 上若用 WSL2 开发，
~/.kube/config在 WSL 中，但 C# 进程若跑在 Windows 原生 .NET SDK 下，会去查%USERPROFILE%\.kube\config——路径根本不同
ListNamespacedPodAsync 返回空列表但 kubectl 能看到 Pod
这不是客户端 bug，而是命名空间错配或 RBAC 权限不足：
- 硬编码
"default"但实际 Pod 在"prod"或自定义命名空间里，应先用ListNamespaceAsync()确认可用命名空间 - ServiceAccount 没绑 RoleBinding，即使 Pod 运行在集群内，
KubernetesClient默认用defaultSA，而该 SA 默认只有极低权限（仅能访问自身命名空间的 Secret） - 本地调试时用
kubeconfig，但该 config 对应的 user 可能没被授予list pods权限（检查kubectl auth can-i list pods -n default）
滚动更新时 C# 监听不到 Deployment 状态变化
因为 Deployment 的“更新完成”不是原子事件，Watch 接口监听的是底层 ReplicaSet 和 Pod 事件，不是 Deployment 的 high-level 状态：
- 不要监听
Deployment的status.updatedReplicas == spec.replicas字段变化——这个字段更新有延迟，且 watch 机制不保证顺序 - 正确做法是监听
ReplicaSet事件，等新 RS 的status.availableReplicas达到预期，同时旧 RS 的status.replicas归零 - 或者更稳妥：轮询
ReadNamespacedDeploymentAsync()，解析status.conditions数组，找type=="Progressing"且status=="True"+reason=="NewReplicaSetAvailable"的条目 - 注意：.NET 客户端的
Watch是基于 HTTP long-polling 的，超时默认 30 秒，需手动处理 reconnect 逻辑，不能假设连接永续
真正的坑不在代码怎么写，而在你是否清楚每条 API 调用背后触发的是哪个控制器、更新的是 etcd 哪个 key、以及那个 key 的变更又会触发哪些下游反应——比如改了 Deployment.spec.replicas，是 Deployment Controller 拉起新 ReplicaSet，再由 ReplicaSet Controller 创建 Pod，最后 Scheduler 分配节点。C# 只管发第一个请求，后面全是 K8s 自己的事。
