web

第27章｜Kubernetes 入门 1：核心对象与声明式模型

Kubernetes（常写作 K8s）把数据中心抽象成一台「超级计算机」：你只管写期望状态（YAML）， 控制面里的控制器会像恒温空调一样不断观测—纠偏—再观测，直到集群现实与声明一致。 这一章聚焦最常用的一条线：Pod → Deployment → Service → Ingress。

Declarative

声明式 = 写「要什么」

  • apply 的是期望，不是 imperative 脚本
  • 控制器负责收敛（reconcile）
  • GitOps 只是把期望放进 Git
Primitives

最小对象拼图

  • Pod：最小调度单元
  • Deployment：无状态副本与滚动升级
  • Service：稳定虚拟 IP / DNS
  • Ingress：集群入口 HTTP(S) 路由
Mindset

别和 Pod 谈恋爱

  • Pod 会死、会漂、会重建
  • 用 Deployment 管生命周期
  • 用 Service 暴露稳定访问点

1. 控制平面：谁在帮你「盯着集群」？

简化理解：API Server 是唯一入口；etcd 存期望与状态；Scheduler 把 Pod 绑到节点；各节点上的 kubelet 真正拉起容器。 Controller Manager 里跑着一堆控制器（如 Deployment Controller），它们 watch API 中的对象，发现「期望副本数 ≠ 实际」就创建/删除 Pod。

一句话：你改 YAML（或 Git 同步）→ API Server 更新期望 → 控制器循环直到现实匹配期望。这就是声明式模型。
声明式收敛：期望状态 → 控制器 → 实际状态 loop: observe → diff → act → repeat Desired replicas: 3 Deployment spec Controllers Deployment / ReplicaSet create or delete Pods Actual 3 Pods Running reconcile until match Node plane kubelet runs PodSpec container runtime Pods: P1 · P2 · P3 (ephemeral IPs) stable access → need Service
图 1：控制平面与收敛循环。Deployment 声明副本数，控制器创建 Pod；kubelet 在节点上执行；不一致则持续纠偏。

2. Pod：最小调度单元，不是长期资产

一个 Pod 可含一个或多个容器（sidecar 模式），共享网络与存储卷。Pod IP 在集群内可达，但重启后 IP 会变，所以不要写死 Pod IP。 健康检查用 livenessProbe / readinessProbe：前者失败会重启容器，后者失败会把 Pod 从 Service 端点摘除。

3. Deployment：管「多少份」与「怎么升级」

Deployment 不直接等价于 Pod，它管理 ReplicaSet，由 RS 保证副本数。滚动更新（rolling update）通过逐步替换 Pod 实现，可配 maxSurge / maxUnavailable。 回滚 kubectl rollout undo 本质是回到上一版 ReplicaSet 模板。

记忆：无状态 Web/API 默认用 Deployment；有状态服务常见 StatefulSet / DaemonSet（后续可深入）。

4. Service：给一群 Pod 一个稳定名字

ClusterIP（默认）：集群内虚拟 IP，DNS 名为 <svc>.<ns>.svc.cluster.local。 NodePort：在每个节点开端口（调试/小规模）。LoadBalancer：云厂商分配外部 LB。 Service 通过 label selector 关联 Pod，Endpoints 列表随 Pod 变化自动更新。

Deployment + Service：selector 绑定端点 traffic → ClusterIP → kube-proxy / dataplane → Pod endpoints client Service app:80 ClusterIP selector app=web Deployment web replicas=3 Pod app=web 10.1.1.7 Pod app=web 10.1.2.3 Pod app=web load balance across ready endpoints
图 2：客户端访问 Service DNS/ClusterIP，kube-proxy（或 CNI 数据面）把流量转到带正确 label 且 Ready 的 Pod。

5. Ingress：集群对外的 HTTP(S) 入口

Service 解决「集群内稳定访问」；要从公网按域名/路径进来，通常加 Ingress + Ingress Controller（如 nginx、traefik）。 Ingress 描述规则：host、path → backend Service:port。TLS 证书可挂在 Ingress 或网关层。

注意：装 Ingress 资源不等于有入口——必须部署 Ingress Controller，否则规则无人执行。
Ingress：L7 路由到 Service external HTTPS → Ingress Controller → rules → Services → Pods Internet TLS Ingress Controller nginx / traefik / … implements Ingress spec Ingress rules api.example.com /api* → svc-api:8080 www.example.com /* → svc-web:80 backend Service api Service web → Pods (Deployment)
图 3：Ingress 在七层按 host/path 把流量转到不同 Service，再由 Service 负载到 Pod。

6. 最小实践清单

  1. 用 kubectl apply -f 管理 Deployment/Service/Ingress，习惯「声明式」思维。
  2. Pod template 的 labels 与 Service selector 必须一致。
  3. 生产路径：readiness 必配；资源 requests/limits 下一章细讲。
  4. 排查顺序：Pod 事件 → Service endpoints → Ingress backend。
自检：能否画出从 YAML 到 3 个 Running Pod 再到 ClusterIP 再到 Ingress 的完整链路？
← 上一章：Docker 实战 下一章：K8s 入门 2（ConfigMap、Secret、资源） →