Kubernetes：容器集群编排¶

Kubernetes（K8s）是管理容器化工作负载和服务的平台。你提交的不是“在节点 A 执行 docker run”，而是期望状态，例如“运行 3 个副本、使用这个镜像、每个副本需要多少资源、通过哪个 Service 访问”。Kubernetes 的控制器持续观察实际状态，并尽量把它调整到期望状态。

期望状态：3 个应用副本
  → 当前只有 2 个
  → 控制器创建 1 个 Pod
  → 调度器选择合适 Node
  → kubelet 拉取镜像并启动容器
  → Readiness 通过
  → Service 将流量转发给新 Pod

为什么 Docker 之后还需要 Kubernetes¶

Docker 可以在一台主机上运行容器，但生产集群还需要统一解决：

问题	Kubernetes 的处理方式
应用放在哪台服务器	Scheduler 根据资源、亲和性、污点等选择 Node
容器退出怎么办	控制器和 kubelet 重新创建或重启工作负载
需要多个副本	Deployment/StatefulSet 维护期望副本数
Pod IP 变化	Service 提供稳定虚拟地址和 DNS
怎样滚动发布	Deployment 逐步替换 ReplicaSet/Pod，可查看状态和回滚
配置如何外置	ConfigMap、Secret、环境变量和 Volume 挂载
数据怎样持久化	PVC 申请由 StorageClass/PV 提供的存储
流量增加怎么办	手工或 HPA 调整副本；资源调度分布到节点
如何隔离团队	Namespace、RBAC、NetworkPolicy、Quota 等共同实现

Kubernetes 不会替你构建代码和镜像，也不自动提供完整日志、监控、数据库备份和发布审批。这些能力需要 GitLab、镜像仓库、Prometheus/VictoriaMetrics、日志系统、Helm、Argo CD 和存储方案配合。

最重要的对象¶

Deployment ──管理──> ReplicaSet ──创建──> Pod ──运行──> Container
                                              ↑
Service ──通过 Label Selector 选择────────────┘

ConfigMap / Secret ──注入配置──> Pod
PVC ──申请存储──> PV / StorageClass ──挂载──> Pod
Ingress / Gateway ──入口路由──> Service ──转发──> Pod

对象	作用	运维理解
Pod	Kubernetes 最小可调度运行单元	短暂实体，重建后名称/IP 可变化
Deployment	管理无状态应用副本与滚动发布	最常用的业务工作负载
StatefulSet	管理稳定名称和独立存储的有状态副本	不等于自动做好数据库高可用
DaemonSet	在每个或指定节点运行一个 Pod	日志、监控、网络 Agent
Job/CronJob	一次性和定时任务	需设置并发、重试与历史保留
Service	给一组就绪 Pod 提供稳定访问入口	selector 必须与 Pod label 匹配
ConfigMap/Secret	外部配置和敏感数据引用	Secret 默认不是完整密钥系统
PVC	工作负载对持久存储的申请	删除前确认回收策略与备份
Namespace	资源逻辑分组	不是绝对安全隔离，仍需 RBAC/NetworkPolicy

一份 Deployment 怎样生效¶

kubectl / Helm / Argo CD
  → kube-apiserver 接收并校验对象
  → 数据保存到 etcd
  → Deployment Controller 创建 ReplicaSet
  → ReplicaSet Controller 创建 Pod
  → Scheduler 为 Pod 选择 Node
  → Node 上 kubelet 调用容器运行时启动容器
  → CNI 配置 Pod 网络，CSI 挂载存储
  → Readiness 成功后 EndpointSlice 加入后端
  → Service 开始向 Pod 转发流量

任何一步失败都会留下状态、Condition 或 Event。排障不是一上来只看应用日志，而是顺着这条链判断失败发生在哪一层。

声明式资源示例¶

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
  namespace: order
spec:
  replicas: 3
  selector:
    matchLabels:
      app: order-service
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
        - name: app
          image: registry.example.com/order-service:1.4.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 200m
              memory: 512Mi
            limits:
              cpu: "1"
              memory: 1Gi
          readinessProbe:
            httpGet:
              path: /actuator/health/readiness
              port: 8080

kubectl apply -f deployment.yaml
kubectl rollout status deployment/order-service -n order
kubectl get pods -n order -l app=order-service -o wide

学习与排障地图¶

建议按下面顺序学习。前半部分理解对象怎样运行，后半部分学习怎样让生产集群可控、可用、可排障。

顺序	主题	要解决的问题
1	架构、组件与 kubectl	请求怎样进入集群，各组件负责什么，如何正确查看资源
2	API 对象与 Manifest	YAML 的结构、标签、状态、声明式变更和对象归属
3	工作负载	Deployment、StatefulSet、DaemonSet、Job/CronJob 怎样选择
4	资源、调度与驱逐	requests/limits、亲和性、污点、QoS 和节点压力
5	Pod 生命周期与健康检查	启动、就绪、存活、优雅退出和 CrashLoop
6	网络模型与 CNI	Pod 网络由谁创建，跨节点数据包怎样传输
7	Service、DNS 与入口	稳定服务发现、集群内转发和外部流量入口
8	NetworkPolicy	怎样限制 Pod 间和出站访问
9	存储与 CSI	临时卷、PV/PVC、动态制备、扩容、快照与故障定位
10	配置与密钥	配置外置、更新行为、Secret 安全和发布联动
11	身份、RBAC 与安全	谁能做什么，工作负载权限和基础安全边界
12	扩缩容与高可用	滚动更新、HPA、PDB、故障域和容量配合
13	集群日常运维	节点维护、升级、证书、etcd 备份和例行检查
14	故障排查	沿完整请求链定位 Pod、网络、存储、节点和应用问题

完成 Kubernetes 基础后，再学习 Helm 将多份资源打包参数化，以及 Argo CD 用 GitOps 管理多环境发布。这样形成“构建镜像 → 描述资源 → 打包配置 → 持续同步 → 运行观测与排障”的完整闭环。

官方参考：Kubernetes Concepts。