一、Kubernetes 常用资源如何分层¶
Kubernetes 的核心资源大致可以分成四类：
1. 工作负载类资源¶
这类资源决定“应用如何运行”，常见包括：
Pod：最小调度单元Deployment：管理无状态应用的副本和滚动更新StatefulSet：管理有状态应用DaemonSet：让每个节点都运行一份实例Job/CronJob：管理一次性任务和定时任务
2. 服务与网络类资源¶
Service：为 Pod 提供稳定访问入口Ingress：统一管理七层流量入口NetworkPolicy：限制 Pod 之间的网络访问关系
3. 配置与存储类资源¶
ConfigMap：保存普通配置Secret：保存敏感配置PV/PVC：抽象和申请持久化存储StorageClass：定义动态供给策略
4. 集群治理类资源¶
Namespace：逻辑隔离不同环境和团队ResourceQuota/LimitRange：约束资源使用Role/RoleBinding、ClusterRole/ClusterRoleBinding：RBAC 权限控制Node：集群节点资源本身
二、以 Deployment 为中心看资源关系¶
在多数业务系统里，Deployment 往往是最常见的核心对象。
围绕 Deployment，通常会形成这样一条协作链：
- Deployment 通过 ReplicaSet 管理 Pod 副本数
- Service 为一组 Pod 提供稳定访问入口
- Ingress 再把外部流量路由到 Service
- Endpoints 维护 Service 对应的后端 Pod 列表
- HPA 根据指标自动调整副本数
- ConfigMap 和 Secret 注入配置
- PVC 和 PV 负责持久化存储
- requests 和 limits 约束 CPU、内存等资源分配
这说明 Kubernetes 并不是“一个对象管所有事”，而是通过一组彼此解耦的资源协作完成应用运行。
三、定时任务和批处理资源怎么理解¶
除了在线服务，Kubernetes 也适合管理批处理任务。
典型模式是：
CronJob负责按计划触发任务Job负责实际执行一次任务Secret可以向任务注入密钥、数据库账号、API Token 等敏感信息
因此，CronJob 更像“计划入口”，Job 才是真正的执行单元。
四、Kubernetes 的设计思想到底是什么¶
如果把 Kubernetes 的方法论提炼出来，可以归纳为三点：
1. 分层抽象¶
通过统一接口解耦基础设施与业务逻辑，让上层应用不用直接处理底层差异。
2. 声明式驱动¶
用户只需要描述目标状态，系统通过控制器不断收敛现实状态。
3. 面向分布式系统设计¶
Kubernetes 默认假设故障一定会发生，因此围绕自愈、扩缩、调度、重建和流量切换来组织平台能力。
这也是为什么它适合云原生：它天然服务于异构资源、动态扩缩和复杂依赖。
五、调度资源和服务发布可以怎么理解¶
不同业务形态，对应的调度资源也不同：
- 无状态应用一般使用
Deployment - 有状态服务一般使用
StatefulSet - 节点级守护进程一般使用
DaemonSet - 备份和定时任务一般使用
Job、CronJob
服务发布则可以理解成一条清晰链路：
Ingress Controller -> Service -> Pod
其中：
- Ingress Controller 负责接收外部 HTTP/HTTPS 请求
- Service 负责在集群内部提供稳定入口并做流量分发
- Pod 负责真正处理业务请求
六、配置管理和资源隔离为什么重要¶
Kubernetes 还把“配置”和“隔离”提升成了一级能力。
通过 ConfigMap 和 Secret，应用配置不再和镜像强耦合，环境切换和密钥管理都会更规范。
通过 Namespace，还可以把开发、SIT、UAT、生产以及公共服务等资源做逻辑隔离，例如：
- 开发环境：
project-dev - 测试环境：
project-sit - 验收环境：
project-uat - 生产环境：
project-prod - 公共基础服务：
public-service
当配置管理、资源模型和隔离边界都统一之后，Kubernetes 才真正从“编排工具”升级成“平台底座”。