微服务与云原生架构 系统性知识体系总结

一、基础认知：云原生与微服务的核心协同关系

1. 核心定义

• 云原生：是一套构建和运行可弹性扩展应用的技术、架构与工程实践体系，核心目标是在公有云、私有云、混合云等动态环境中，实现应用的高可用、高弹性、可观测、可运维、低成本，核心设计理念为声明式API、不可变基础设施、自愈能力、面向分布式设计。
• 微服务：是云原生架构的核心应用架构模式，将单体应用拆分为一组松耦合、可独立部署、可独立迭代的小型服务，每个服务聚焦单一业务能力，通过标准化API通信。
• 核心协同：Docker、K8s等云原生技术栈，是微服务架构落地的基础设施底座，彻底解决了微服务大规模部署、生命周期管理、流量治理、弹性伸缩等核心痛点，二者相辅相成，共同构成现代分布式应用的标准架构。

2. 知识体系整体架构

云原生技术底座
├─ 容器 runtime 层：Docker（应用打包、环境一致性）
├─ 容器编排层：K8s 集群架构（控制平面+数据平面）
├─ 核心资源模型：Pod/Deployment/Service/Ingress（应用编排与流量治理核心）
└─ 核心能力体系
   ├─ Pod 全生命周期管理
   ├─ 健康检查与自愈能力
   ├─ 滚动更新与零停机发布
   └─ HPA 水平自动扩缩容

二、云原生核心底座：Docker 容器技术

Docker 是云原生体系的基石，实现了应用的一次构建、到处运行，彻底解决了微服务部署的环境异构、依赖冲突问题。

1. 核心原理

Docker 基于 Linux 内核核心技术实现容器的隔离与资源管控：

• Namespace：实现容器间的资源隔离，包括 PID、网络、挂载、用户、IPC、UTS 六大 namespace，每个容器拥有独立的运行环境，互不干扰。
• Cgroups：实现容器的资源配额与限制，可精准控制容器的 CPU、内存、磁盘IO、网络带宽等资源使用，避免容器间资源抢占。
• UnionFS（联合文件系统）：实现镜像的分层存储与共享，镜像由多个只读层叠加而成，容器启动时仅新增一个可写层，大幅降低镜像存储与分发的开销。

2. 核心组件与核心概念

3. 云原生核心价值

• 解决微服务的环境一致性问题：开发、测试、生产环境使用同一镜像，彻底避免「在我电脑上能跑」的问题。
• 实现应用的快速交付与部署：镜像秒级启动，大幅缩短微服务的发布周期。
• 提升服务器资源利用率：容器比虚拟机轻量化，单机可部署数十倍于虚拟机的容器实例。
• 为 K8s 编排提供标准的应用载体：K8s 的所有编排能力，最终都落地到容器的生命周期管理。

三、云原生编排核心：Kubernetes（K8s）整体架构

K8s 是云原生体系的容器编排平台核心，负责大规模容器集群的调度、部署、运维、自愈、弹性伸缩，是微服务架构的分布式操作系统。
K8s 集群采用声明式API的核心设计，用户只需定义应用的「期望状态」，K8s 控制器自动驱动集群的「实际状态」向「期望状态」收敛，全程自动化执行。

K8s 集群分为两大核心平面：控制平面（Control Plane） 和 数据平面（Node 节点），各组件职责清晰，协同工作。

1. 控制平面：集群的大脑，负责全局决策与管控

控制平面组件通常部署在集群的 Master 节点，不运行业务容器，核心组件如下：

2. 数据平面：集群的工作节点，负责业务容器的运行

数据平面由集群的 Node 节点（工作节点）组成，负责运行用户的业务 Pod，核心组件如下：

四、K8s 核心资源模型

K8s 所有操作都基于资源对象实现，资源对象是 RESTful API 中的实体，用户通过 YAML/JSON 声明资源的期望状态，K8s 控制器完成状态收敛。以下是用户指定的四大核心资源，是云原生应用编排的核心。

1. Pod：K8s 最小的调度与部署单元

核心定义

Pod 是 K8s 中不可再分的原子调度单元，不是单个容器，而是一组共享网络、存储、生命周期的容器集合。同一个 Pod 内的容器共享同一个 namespace，拥有完全一致的生命周期，同生共死。

核心特性

• 共享网络栈：同一个 Pod 内的所有容器共享同一个 IP 地址和端口空间，可通过 localhost 互相访问，无需端口映射；Pod 与 Pod 之间通过 Pod IP 直接通信。
• 共享存储：通过 Volume 挂载到 Pod，Pod 内的所有容器都可以访问该 Volume，实现容器间的数据共享与持久化。
• 原子调度：K8s 调度的最小单位是 Pod，而非容器，整个 Pod 内的所有容器必须调度到同一个节点上，不支持跨节点拆分。
• 生命周期绑定：Pod 是临时的、有生命周期的实体，销毁后无法重建，新的 Pod 会生成新的 Pod IP。

核心分类与配置

• 分类：普通Pod（由控制器管理，如Deployment）、静态Pod（由节点kubelet直接管理，不受apiserver控制）、有状态Pod（由StatefulSet管理）。
• 核心配置字段：spec.containers（容器配置）、spec.volumes（存储卷）、spec.restartPolicy（重启策略）、spec.nodeSelector（节点选择）、spec.initContainers（初始化容器）等。

2. Deployment：无状态应用的核心编排控制器

核心定义

Deployment 是 K8s 中最常用的工作负载控制器，专门用于管理无状态应用的全生命周期，提供 Pod 的副本管理、自愈、滚动更新、版本回滚、扩缩容等核心能力，是微服务无状态实例的标准管理载体。

核心原理

Deployment 不直接管理 Pod，而是通过管理 ReplicaSet（RS，副本集） 实现版本控制：

• 每个 Deployment 对应多个 RS，每个 RS 对应一个应用版本，管理该版本的 Pod 副本。
• 应用更新时，Deployment 会创建新的 RS，逐步增加新 RS 的 Pod 副本数，同时减少旧 RS 的 Pod 副本数，实现滚动更新。
• 旧 RS 会被保留，用于应用的版本回滚，默认保留10个历史版本。

核心能力与配置

• 核心能力：
  1. 自愈能力：Pod 异常退出时，自动重建 Pod，保证副本数与期望一致。
  2. 扩缩容能力：手动调整 replicas 字段，快速调整 Pod 副本数。
  3. 滚动更新与回滚：零停机发布，新版本异常时可快速回滚到历史版本。
  4. 暂停与恢复：支持更新过程中暂停/恢复，实现灰度发布。
• 核心配置字段：replicas（期望副本数）、selector（Pod 标签选择器）、template（Pod 模板，定义 Pod 的规格）、strategy（更新策略）、minReadySeconds（Pod 就绪后的稳定等待时间）。

3. Service：Pod 访问的固定抽象与四层负载均衡

核心定义

Service 是 K8s 中 Pod 访问的抽象层，解决了 Pod 生命周期短暂、IP 动态变化的核心痛点，为一组具有相同标签的 Pod 提供固定的访问入口、服务发现、四层负载均衡能力，实现访问流量与后端 Pod 的解耦。

核心原理

• Service 通过 label selector 匹配一组后端 Pod，为其分配固定的虚拟 IP（ClusterIP），该 IP 在 Service 生命周期内固定不变。
• Service 与后端 Pod 的关联通过 EndpointSlice 实现，EndpointSlice 实时维护匹配标签的健康 Pod 的 IP 与端口列表。
• kube-proxy 监听 Service 与 EndpointSlice 的变化，在节点上维护网络转发规则，将访问 Service IP 的流量，负载均衡转发到后端健康的 Pod 上。

核心类型与适用场景

4. Ingress：集群七层流量入口与路由治理

核心定义

Ingress 是 K8s 中集群 HTTP/HTTPS 流量的统一入口，提供七层负载均衡能力，弥补了 Service 仅支持四层负载的不足，实现基于域名、路径的流量路由、SSL/TLS 终结、灰度发布、限流、重写等高级流量治理能力。

核心原理

• Ingress 资源本身只是路由规则的声明定义，本身不具备流量转发能力，必须配合 Ingress Controller 才能生效。
• Ingress Controller 是 Ingress 规则的执行载体，持续监听 apiserver 中的 Ingress 资源变化，根据规则实时更新负载均衡配置，实现流量的转发与治理。
• 主流 Ingress Controller 实现：Nginx Ingress Controller（官方默认）、Traefik、APISIX、Kong 等。

核心能力与配置

• 核心能力：
  1. 域名虚拟主机：基于不同域名，将流量转发到不同的后端 Service。
  2. 路径路由：基于同一个域名的不同 URL 路径，将流量转发到不同的后端 Service。
  3. SSL/TLS 终结：统一管理 HTTPS 证书，实现 HTTPS 加密访问，无需每个微服务单独配置证书。
  4. 高级流量治理：支持请求重写、重定向、限流、熔断、灰度发布、蓝绿发布等高级能力。
• 核心配置字段：rules（路由规则，定义 host、path、后端 Service）、tls（HTTPS 证书配置）、ingressClassName（指定对应的 Ingress Controller）。

五、Pod 全生命周期管理

Pod 生命周期是 K8s 对 Pod 从创建到终止的全流程状态管理，是 K8s 实现应用自愈、流量调度、优雅启停的核心基础。

1. Pod 核心生命周期阶段（Phase）

Pod 的 status.phase 字段标识了 Pod 当前所处的宏观阶段，共5种核心状态：

2. Pod 完整创建全流程（串联集群全组件）

1. 配置提交：用户通过 kubectl 提交 Pod/Deployment 配置到 kube-apiserver，apiserver 完成配置验证后，将数据写入 etcd。
2. 调度决策：kube-scheduler 通过 apiserver watch 到未调度的 Pod，执行调度算法，为 Pod 选择最优的运行节点，将绑定信息写入 apiserver/etcd。
3. 节点准备：目标节点的 kubelet watch 到绑定到本节点的 Pod，开始执行 Pod 启动准备：
   • 创建 Pod 的共享 namespace、存储卷等共享资源。
   • 按顺序执行初始化容器（Init Container）：所有 Init 容器必须按顺序执行完成且全部成功，才会启动业务容器；Init 容器失败会根据重启策略重试。
4. 容器启动：Init 容器执行完成后，kubelet 调用容器运行时拉取业务容器镜像，创建并启动业务容器。
5. 生命周期钩子：执行业务容器的 PostStart 钩子（容器启动后立即执行，用于应用初始化、预热等操作）。
6. 健康检查激活：业务容器启动后，激活配置的启动探针、存活探针、就绪探针。
7. 流量接入：启动探针执行成功，就绪探针连续检查通过后，Pod 被标记为 Ready 状态，被加入对应 Service 的 EndpointSlice 中，开始接收业务流量，进入 Running 稳定运行阶段。

3. Pod 完整终止全流程（优雅终止核心逻辑）

Pod 终止的核心设计是优雅关闭，确保应用在退出前完成流量收尾、资源释放、数据持久化，避免业务异常，默认终止宽限期为30s。

1. 删除请求提交：用户提交 Pod 删除请求到 apiserver，apiserver 更新 Pod 元数据，设置终止宽限期，标记 Pod 为 Terminating 状态。
2. 流量摘流：Endpoint 控制器 watch 到 Pod 进入终止状态，将 Pod 从所有关联的 Service 的 EndpointSlice 中移除，停止接收新的业务流量。
3. 终止前钩子执行：kubelet 触发业务容器的 PreStop 钩子（容器终止前执行，用于优雅关闭应用、释放资源、注销注册中心等，必须在终止宽限期内完成）。
4. 优雅关闭通知：PreStop 钩子执行完成，或宽限期过半后，kubelet 向容器内的主进程发送 SIGTERM 信号，通知应用优雅关闭，停止处理请求、保存数据。
5. 强制终止：如果终止宽限期到期后，应用进程仍未退出，kubelet 会发送 SIGKILL 信号，强制终止容器内的所有进程。
6. 资源清理：所有容器终止后，kubelet 清理 Pod 的相关资源（存储卷、网络等），并通知 apiserver 删除 Pod 元数据，从 etcd 中彻底移除。

4. Pod 生命周期核心扩展点

• Init Container（初始化容器）：在业务容器启动前执行，用于前置依赖检查、配置拉取、数据初始化、权限设置等场景，无状态，执行完成即退出，不影响业务容器的运行。
• 生命周期钩子（Lifecycle Hook）：
  • PostStart：容器启动后触发，用于应用预热、初始化配置、注册服务等。
  • PreStop：容器终止前触发，用于应用优雅下线、注销服务、释放资源、数据落盘等。
• 重启策略（restartPolicy）：定义容器异常退出时的重启行为，包括 Always（默认，始终重启）、OnFailure（仅异常退出时重启）、Never（永不重启）。

六、健康检查（Probe）：K8s 自愈能力的核心

健康检查是 K8s 精准感知应用运行状态、实现自动化故障自愈、流量精准调度的核心机制，彻底避免了「容器进程在运行，但业务已无法提供服务」的假活问题。

1. 三大核心探针：职责与适用场景

K8s 提供三种独立的健康检查探针，各司其职，协同实现应用的全生命周期状态管控：

2. 探针的四大实现方式

探针支持四种标准化的检查方式，可根据应用场景灵活选择：

1. ExecAction：在容器内执行指定的 shell 命令，命令退出码为 0 则判定为检查成功，非 0 则失败。适用于无 HTTP 服务的应用、自定义检查逻辑的场景。
2. HTTPGetAction：向容器的指定端口和路径发送 HTTP GET 请求，返回 2xx/3xx 状态码则判定为成功。适用于提供 HTTP 服务的 Web 应用、微服务，是最常用的方式。
3. TCPSocketAction：尝试与容器的指定端口建立 TCP 连接，连接成功则判定为成功。适用于 TCP 服务、数据库、中间件等非 HTTP 服务的场景。
4. GRPCAction：向容器的指定端口发送 gRPC 健康检查协议请求，检查成功则判定为成功。K8s 1.24+ 正式支持，适用于 gRPC 微服务场景。

3. 探针核心配置参数

4. 核心最佳实践

• 慢启动应用必须配置启动探针，用 failureThreshold * periodSeconds 覆盖应用的最大启动时间，避免误杀。
• 存活探针仅检测应用自身的存活状态，不要检测外部依赖（如数据库、缓存），避免外部依赖故障导致应用被无限重启，引发级联故障。
• 就绪探针要检测业务的真实可用性，而非仅检测端口是否通，需覆盖核心业务接口、依赖服务可用性。
• 生产环境避免使用过短的超时时间和过高的检查频率，避免给应用带来额外的性能压力。

七、滚动更新（Rolling Update）：零停机发布核心能力

滚动更新是 Deployment 控制器的核心能力，实现微服务应用的零停机、无感知发布，是云原生应用发布的标准模式，彻底解决了传统发布模式的停机时间长、回滚困难、风险集中的问题。

1. 核心原理

滚动更新的核心是渐进式替换：通过多 ReplicaSet 版本管理，逐步用新版本的 Pod 替换旧版本的 Pod，整个更新过程中，始终有足够的可用 Pod 提供服务，确保业务零中断。

• 更新时，Deployment 会创建一个新的 ReplicaSet（对应新版本应用）。
• 控制器逐步增加新 RS 的 Pod 副本数，同时同步减少旧 RS 的 Pod 副本数。
• 直到新 RS 的副本数达到期望的 replicas，旧 RS 的副本数降为 0，更新完成。
• 旧 RS 会被保留，用于后续的版本回滚，无需重新构建镜像。

2. 核心配置参数

滚动更新的行为通过 Deployment 的 spec.strategy 字段配置，默认策略类型为 RollingUpdate，核心参数如下：

示例：期望副本数为 4，maxSurge=25%，maxUnavailable=25%，则更新过程中，最多可同时运行 5 个 Pod（4125%），最少需保证 3 个可用 Pod（475%）。

3. 完整滚动更新执行流程

以 4 副本、默认 25% 配置为例，完整流程如下：

1. 用户更新 Deployment 的 Pod 模板（如镜像版本），提交到 apiserver。
2. Deployment 控制器检测到 Pod 模板变更，创建新的 ReplicaSet，更新版本号。
3. 控制器计算可扩容的副本数，先启动 1 个新版本 Pod，此时集群内有 4 个旧版本 Pod + 1 个新版本 Pod，总副本数 5，符合 maxSurge 限制。
4. 新版本 Pod 启动完成，就绪探针检查通过，且 minReadySeconds 到期后，被标记为可用。
5. 此时可用 Pod 数为 5，超过期望副本数，控制器终止 1 个旧版本 Pod，旧 RS 的副本数降为 3，符合 maxUnavailable 限制。
6. 重复「新增新版本 Pod→就绪可用→删除旧版本 Pod」的循环，直到新 RS 的副本数达到 4，旧 RS 的副本数降为 0。
7. 更新完成，旧 RS 被保留在集群中，用于后续回滚。

4. 配套核心能力

1. 版本回滚：当新版本应用出现异常时，可通过 kubectl rollout undo 命令快速回滚到历史版本，原理是将旧 RS 的副本数恢复到期望数，新 RS 的副本数降为 0，全程同样是滚动执行，零停机。
2. 暂停与恢复更新：通过 kubectl rollout pause 暂停更新，仅更新部分 Pod，验证新版本无异常后，通过 kubectl rollout resume 恢复更新，实现灰度发布/金丝雀发布。
3. 重建更新策略：可选策略类型 Recreate，先删除所有旧版本 Pod，再创建新版本 Pod，会有停机时间，仅适用于不支持多版本同时运行的有状态应用。

八、自动扩缩容 HPA（Horizontal Pod Autoscaler）：云原生弹性核心

HPA（水平 Pod 自动扩缩容）是 K8s 实现云原生弹性能力的核心组件，可根据监控指标自动调整工作负载的 Pod 副本数，实现流量高峰自动扩容、低峰自动缩容，在保障服务可用性的同时，最大化提升资源利用率，降低资源成本。

1. 核心定义与版本演进

• 核心定义：HPA 是 K8s 的自动扩缩容资源对象，持续监控目标工作负载（Deployment/StatefulSet）的 Pod 监控指标，自动调整副本数，实现弹性伸缩。
• 版本演进：
  • HPA v1（autoscaling/v1）：初代版本，仅支持 CPU 使用率指标，功能有限。
  • HPA v2（autoscaling/v2）：K8s 1.23+ 正式 GA，当前主流版本，支持 CPU、内存、Pod 自定义指标、对象指标、外部指标，支持自定义扩缩容行为，功能全面。

2. 核心原理与依赖

核心计算逻辑

HPA 的核心是基于指标计算期望副本数，核心公式：

期望副本数 = ceil( 当前副本数 * ( 当前指标实际值 / 指标目标值 ) )

计算完成后，HPA 会将期望副本数限制在配置的 minReplicas（最小副本数）和 maxReplicas（最大副本数）之间，避免无限制扩缩容。

核心依赖组件

HPA 依赖 Metrics API 体系获取监控指标数据，不同指标对应不同的实现：

• 核心指标（CPU/内存）：依赖 Metrics Server，K8s 集群的核心指标采集组件，是 HPA 的基础依赖。
• 自定义指标：依赖 Prometheus + Prometheus Adapter，实现 Custom Metrics API，支持业务自定义指标（如 QPS、请求延迟、消息队列堆积数）。
• 外部指标：依赖 External Metrics API，对接云厂商的监控系统，支持集群外的指标（如负载均衡 QPS、CDN 带宽）。

3. 核心配置与指标类型

HPA v2 的核心配置字段如下：

四大核心指标类型

1. Resource 指标：K8s 内置的资源指标，CPU、内存使用率/用量，最常用的基础指标。
2. Pods 指标：Pod 级别的自定义指标，如每个 Pod 的 QPS、平均请求延迟、连接数等，与业务强相关。
3. Object 指标：K8s 集群内对象的指标，如 Ingress 的 QPS、Service 的流量带宽等。
4. External 指标：集群外的外部指标，如云厂商负载均衡的公网 QPS、Kafka 消息队列的堆积数、Redis 的命中率等。

4. 完整工作流程

1. 部署 Metrics Server/Prometheus Adapter，完成 Metrics API 的对接，提供指标查询能力。
2. 用户创建 HPA 资源，指定目标工作负载、指标阈值、副本数上下限、扩缩容行为。
3. HPA 控制器默认每隔 15s，从 Metrics API 拉取目标 Pod 的监控指标数据。
4. 控制器根据指标数据，通过核心公式计算期望副本数，确保在 min/max 副本数范围内。
5. 对比期望副本数与当前副本数，结合 behavior 配置的扩缩容策略，判断是否需要执行扩缩容。
6. 如需调整，HPA 控制器更新目标工作负载的 replicas 字段。
7. 工作负载控制器（Deployment）根据更新后的 replicas，创建/删除 Pod，完成扩缩容动作。

5. 核心最佳实践

• 必须配置合理的 minReplicas 和 maxReplicas，避免流量洪峰时扩容不足，或低峰时缩容到0引发服务不可用。
• 配置扩缩容稳定窗口，默认缩容稳定窗口为5分钟，避免流量短暂波动导致的频繁扩缩容（抖动）。
• CPU 使用率阈值建议设置在 60%-70%，预留足够的缓冲空间，应对流量突发增长。
• 优先使用与业务可用性强相关的自定义指标（如 P99 请求延迟、QPS），而非单一的 CPU/内存指标，实现更精准的弹性扩缩容。
• 必须为 Pod 配置合理的 CPU/内存 requests 和 limits，HPA 的资源使用率指标是基于 requests 计算的，无 requests 会导致指标计算异常。

九、体系闭环总结

Docker、K8s 及上述核心能力，共同构成了微服务与云原生架构的完整技术闭环：

1. Docker 解决了微服务应用的打包、环境一致性问题，为微服务提供了标准化的交付载体。
2. K8s 集群架构 提供了分布式容器集群的统一管控底座，实现了大规模微服务实例的调度与资源管理。
3. 四大核心资源 实现了微服务的全生命周期编排：Pod 作为微服务实例的载体，Deployment 管理微服务的部署与副本，Service 实现微服务的服务发现与内部通信，Ingress 实现微服务的公网流量接入与路由治理。
4. Pod 生命周期与健康检查 实现了微服务的自动化自愈能力，确保故障实例自动恢复，流量精准调度到健康实例。
5. 滚动更新 实现了微服务的零停机迭代发布，保障业务迭代无感知、风险可控。
6. HPA 自动扩缩容 实现了微服务的弹性伸缩，应对流量波动，平衡服务可用性与资源成本。