容器、Kubernetes、服务网格、平台工程、可观测性与交付体系 (2025-2026)
| 上层 | 依赖的下层 | 关系说明 |
|---|---|---|
| 容器运行时 | 基础设施 | 容器隔离最终还是建立在 Linux Namespace、Cgroups、OverlayFS 和主机网络之上 |
| Kubernetes | 容器运行时 | K8s 自己不运行容器，它通过 CRI 调用 containerd / CRI-O 来创建和管理容器 |
| 平台能力 | Kubernetes | Ingress、Service Mesh、GitOps、可观测性本质都是构建在 K8s API 和控制器模式之上 |
| 业务交付 | 平台能力 | 真正的业务研发依赖一套稳定的平台抽象，否则每个团队都在重复造发布、监控、权限的轮子 |
| Serverless | Kubernetes + Runtime | Knative/FaaS 看似隐藏底层，实际仍需要容器、镜像仓库、弹性调度与事件系统支撑 |
| 服务网格 | Sidecar / CNI / xDS | Istio/Linkerd 的治理能力来自代理注入、流量劫持、控制面下发配置，而不是应用代码魔法 |
| 平台工程 | K8s API + 自动化 | Internal Developer Platform 的核心不是页面，而是标准化资源模型、模板、权限与流水线 |
| FinOps | 观测 + 标签体系 | 没有资源标签、成本归集和用量数据，再谈成本优化基本只能靠拍脑袋 |
容器不是轻量虚拟机，而是“进程级隔离”。同一台主机上的多个容器共享同一个内核。
Namespace: 隔离 PID、Network、Mount、IPC、UTS、User。
Cgroups: 限制 CPU、内存、IO 等资源，防止某个容器把宿主机打爆。
OCI Image 定义镜像格式，OCI Runtime 定义运行时接口。Docker 生态最终被标准化拆分为镜像、构建、运行三个层次。
常见运行时: containerd、CRI-O、runc、gVisor、Kata Containers。
多阶段构建、最小化基础镜像、不可变标签策略、减少层数、尽量无 root 运行。
API Server: 集群唯一入口，所有声明式资源最终都落到 API Server。
etcd: 存储整个集群状态，是 K8s 的“数据库”和单点命脉。
Scheduler: 负责把 Pod 调度到合适节点，考虑资源、亲和性、污点、拓扑等约束。
Controller Manager: 持续把“实际状态”向“期望状态”收敛，是 K8s 声明式模型的灵魂。
Deployment、StatefulSet、DaemonSet、Job 本质都是不同的 controller。Operator 只是把这个模式扩展到数据库、中间件和业务平台。
Kubernetes 的门槛不在命令，而在抽象层次高。你需要同时理解网络、存储、调度、权限和故障模型。
K8s 假设每个 Pod 都有独立 IP，Pod 之间无需 NAT 直接互通。这要求底层 CNI 插件实现统一网络平面。
CNI 主流: Calico、Cilium、Flannel。近年趋势明显偏向 Cilium + eBPF；Weave Net 更适合作为历史项目了解。
Service 解决服务发现与负载均衡，Ingress / Gateway API 负责把集群内部服务暴露给外部流量。
新趋势: Ingress API 已冻结；Gateway API 是 Kubernetes 社区重点演进的下一代流量管理接口，配置模型更清晰，扩展性更强。
PV/PVC/StorageClass 提供持久化抽象。无状态应用最适合 K8s，但真正考验平台能力的是数据库、消息队列、对象存储网关这类有状态负载。
指标: 关注系统健康和容量趋势，例如 CPU、延迟、QPS、错误率。
日志: 记录离散事件，适合排查某次异常到底发生了什么。
链路: 追踪跨服务请求路径，解决“一个请求经过十几个服务后到底卡在哪里”。
Prometheus + Alertmanager + Grafana 仍是基础盘；日志常见 Loki / ELK；Tracing 常见 Tempo / Jaeger；采集与语义层逐步统一到 OpenTelemetry。
“装了监控就是可观测”是错觉。没有 SLI/SLO、告警分级、服务画像和排障手册，平台依然会在夜里把人叫醒。
环境状态以 Git 仓库中的声明式配置为准，控制器持续对比并收敛现场状态。部署从“推送到集群”转为“提交到 Git”。
代码提交 → CI 构建镜像 → 镜像扫描与签名 → 更新 Helm/Kustomize 配置 → Argo CD/Flux 同步 → 集群滚动发布。
发布流程可审计、可回滚、可对比，特别适合多环境、多集群和多人协作场景。
GitOps 不是银弹。对于高度动态配置、数据库变更、临时运维操作，仍需要额外治理和变更策略。
| 类别 | 主流项目 | 定位 | 适用场景 | 成熟度 |
|---|---|---|---|---|
| 容器运行时 | containerd / CRI-O | 容器生命周期管理 | Kubernetes 节点运行时 | 生产常见选择 |
| 编排系统 | Kubernetes | 统一调度与声明式管理 | 微服务、批处理、平台基础层 | 主导型基础设施 |
| 包管理 | Helm / Kustomize | 配置模板与资源组合 | 应用发布、环境差异管理 | 成熟 |
| GitOps | Argo CD / Flux | 声明式持续交付 | 多环境自动同步、审计 | 成熟 |
| 观测 | Prometheus / Grafana / Loki / Tempo | 指标、日志、链路 | 运行态监控与排障 | 成熟 |
| 服务网格 | Istio / Linkerd / Cilium Service Mesh | 流量治理与零信任通信 | 复杂微服务通信 | 中高 |
| 平台工程 | Backstage / Crossplane / Port | 开发者平台、资源抽象 | 中大型组织平台化 | 快速上升 |
| 安全供应链 | Trivy / Cosign / Kyverno / Falco | 镜像扫描、签名、策略、防护 | DevSecOps、运行时安全 | 成熟 |
| 方案 | 复杂度 | 灵活性 | 运维成本 | 适合谁 |
|---|---|---|---|---|
| Docker Compose | 低 | 低 | 低 | 本地开发、小型单机部署 |
| Kubernetes 自建 | 高 | 最高 | 高 | 对平台控制力要求高的团队 |
| 托管 Kubernetes (EKS/GKE/ACK/AKS) | 中高 | 高 | 中 | 大多数企业团队的现实选择 |
| PaaS / Serverless | 低 | 中 | 低 | 追求交付速度、平台团队薄弱的组织 |
| 组合 | 优点 | 短板 | 建议 |
|---|---|---|---|
| Prometheus + Grafana | 开源主流组合、生态成熟 | 日志和链路需额外拼装 | 多数团队都值得优先考虑 |
| Loki + Tempo + Grafana | 统一体验好，成本相对可控 | 大规模日志检索能力不如成熟 ELK | 平台一体化优先时很好用 |
| ELK / OpenSearch | 日志检索和分析能力强 | 资源开销大，维护成本高 | 日志中心化需求强时采用 |
| 商业 APM | 开箱即用、产品体验成熟 | 成本高、厂商绑定 | 预算充足且要求快速落地时可选 |
镜像构建后至少要做漏洞扫描、依赖清单生成 (SBOM)、签名验证，再决定是否允许进入仓库和集群。
Pod Security、Seccomp、AppArmor、只读根文件系统、非 root 用户、网络策略，是基础而不是高级选项。
CI/CD 本身已经是重要攻击面。代码仓库、依赖仓库、构建节点、制品仓库、发布控制器都需要纳入安全边界。
| 类别 | 推荐工具 | 说明 |
|---|---|---|
| 容器构建 | Docker / BuildKit / Podman | 镜像构建、缓存优化、多平台输出 |
| 本地集群 | kind / k3d / minikube / Rancher Desktop | 学习 K8s、验证 Helm Chart、做 CI 集群测试 |
| 集群管理 | kubectl / k9s / Lens / Aptakube | 集群日常管理与可视化 |
| 配置管理 | Helm / Kustomize / Jsonnet | 管理环境差异与模板复用 |
| GitOps | Argo CD / Flux | 声明式持续交付与环境收敛 |
| 观测 | Prometheus / Grafana / Loki / Tempo / OpenTelemetry | 指标、日志、链路统一观测 |
| 安全 | Trivy / Cosign / Kyverno / Falco | 镜像扫描、签名验证、策略控制、运行时安全 |
| 网络 | Cilium / Calico / Istio / Linkerd | CNI 与服务治理能力 |
| 基础设施即代码 | Terraform / OpenTofu / Pulumi | 管理云资源、集群和网络 |
| 平台门户 | Backstage / Port | 内部开发者平台入口与服务目录 |
平台工程继续上升: 企业开始从“人人学 K8s”转向“平台团队抽象 K8s，业务团队消费平台”。
eBPF 深入基础设施: 网络、可观测性、安全都会继续向 eBPF 靠拢，Sidecarless 路线会更热。
GPU / AI 工作负载进入云原生主战场: K8s 将继续成为统一调度 CPU、GPU、推理与批处理任务的平台。
Gateway API 持续演进: Ingress API 已冻结，Gateway API 的路由抽象更清晰，生态正在加速跟进。
Wasm / 沙箱运行时: 还没全面爆发，但在边缘、插件化和安全隔离方向值得持续看。
FinOps 与绿色计算: 成本优化会从“削峰填谷”升级到组织级资源治理和资源利用率文化。
复杂度失控: 云原生不是功能越多越先进，越成熟的团队越懂得克制。
人才错配: 给业务团队过多基础设施自由度，常常会导致治理崩盘；给平台团队过少产品思维，又会把平台做成“管控系统”。
安全后置: 把镜像扫描、权限治理、密钥管理放到最后补，代价通常成倍增加。