Kubernetes 架构与声明式资源 Hands-on
验证：未记录
- 适用版本
- 未记录
- 验证范围
- 尚未登记验证记录。
本文缩写（英文全称与中文含义）
| 缩写 | 英文全称／名称 | 中文含义 |
|---|---|---|
| API | Application Programming Interface | 应用程序编程接口 |
| CNI | Container Network Interface | 容器网络接口 |
| CRI | Container Runtime Interface | 容器运行时接口 |
| CSI | Container Storage Interface | 容器存储接口 |
| GitOps | GitOps | 以 Git 保存期望状态、由自动化持续协调实际状态的运维方式 |
| HPA | Horizontal Pod Autoscaler | Pod 水平自动扩缩容器 |
| PDB | Pod Disruption Budget | Pod 中断预算，约束自愿驱逐 |
| SLO | Service Level Objective | 服务等级目标 |
| UID | Unique Identifier | 唯一标识符；Linux 权限语境中为 User ID（用户标识） |
前置：实践约定、预生产 orders-api。理解一次 apply 的路径：客户端→认证/授权→准入→API 存储→控制器调谐→调度器选节点→kubelet/CRI 启动→CNI/CSI 提供网络和卷。API Server 不直接启动容器；etcd 不保存卷里的业务数据。
1. 观察期望状态与实际状态#
kubectl -n orders get deployment orders-api -o json | jq '{spec:.spec.replicas,status:.status,owners:.metadata.ownerReferences}'
kubectl -n orders get rs -l app.kubernetes.io/name=orders-api
kubectl -n orders get pods -l app.kubernetes.io/name=orders-api -o wide
kubectl -n orders get events --sort-by=.metadata.creationTimestamp
kubectl -n orders get endpointslices -l kubernetes.io/service-name=orders-api记录 Deployment→ReplicaSet→Pod 的 ownerReferences、Pod 的 nodeName、EndpointSlice 的 ready 条件。generation 与 observedGeneration 有差异时，先确认控制器是否已处理新配置。
2. 观察控制循环#
只在至少三副本、PDB 与业务验证均就绪的隔离环境执行：
POD=$(kubectl -n orders get pod -l app.kubernetes.io/name=orders-api -o jsonpath='{.items[0].metadata.name}')
kubectl -n orders get pod "$POD" -o jsonpath='{.metadata.uid}{"\n"}'
kubectl -n orders delete pod "$POD" --wait=true
kubectl -n orders rollout status deployment/orders-api --timeout=5m
kubectl -n orders get pods -l app.kubernetes.io/name=orders-api -o wide直接删除 Pod 不受 PDB 的 eviction 保护；本步仅用于观察控制循环，不是生产排空方式。预期新 Pod UID 不同，副本数恢复，业务仍满足 SLO；StatefulSet 的稳定名字也不代表 UID 不变。
3. 检查字段所有权#
kubectl -n orders get deployment orders-api --show-managed-fields -o yaml
kubectl explain deployment.spec.strategy
kubectl explain pod.spec.terminationGracePeriodSeconds
kubectl api-resources --verbs=list --namespaced=true明确 replicas 由 HPA 或 GitOps 中的一方维护。Server-Side Apply 冲突先定位 manager 和字段；不默认用 --force-conflicts 抢所有权。删除上层对象前检查 ownerReferences、级联策略及外部资源 finalizer。
验收：能解释“apply 成功但 Pod Pending”“Pod Running 但 Service 无 ready 后端”“删除 Pod 后又出现”三种情况。清理仅删除本次独立演练对象，不删业务 namespace。
参考：组件、Server-Side Apply。