第一部分：到底什么是云原生？别再停留在“用服务器”了
1.1 云原生的定义 (CNCF官方解读)
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
1.2 核心思想：打破传统的“水线思维”
传统应用（Monolith）：像一座巨大的冰山，部署慢、扩容难、故障影响大。
云原生应用：像一群灵活的快艇（微服务），各自独立，通过海流（服务网格）通信，随时可以增减（弹性）。
第二部分：云原生大厦的基石——容器化
2.1 Docker 深度剖析
镜像分层（Layer）：理解UnionFS（联合文件系统），为什么拉取镜像只下载增量层？
容器 vs. 虚拟机：共享宿主机内核 vs. 独立内核。隔离性（Namespace）与资源限制（Cgroups）的实现原理。
2.2 容器镜像的“安全陷阱”
基础镜像选型：Alpine vs. Ubuntu，如何减小攻击面？
镜像扫描：Trivy、Clair 在CI/CD中的应用。
不可变基础设施：容器一旦启动，绝不修改内部配置。修改配置 = 重新构建镜像 + 重新部署。
第三部分：云原生操作系统——Kubernetes (K8s) 核心源码级理解
很多文章只会讲怎么用kubectl，这里我们从设计哲学入手。
3.1 声明式API vs. 命令式API
命令式：
docker run nginx（你告诉它每一步做什么）。声明式：写一个YAML定义期望状态，交给etcd，控制器不断调谐（Reconcile）直至达成期望状态。这是云原生的灵魂。
3.2 核心组件协作流程
kube-apiserver：唯一与etcd交互的组件，所有请求的入口。
controller-manager：各种控制器的集合（如Deployment Controller、ReplicaSet Controller）。
scheduler：watching unscheduled pods，通过预选（Predicates）和优选（Priorities）算法选择最合适的Node。
kubelet：节点上的“守门员”，负责向apiserver注册节点，创建/销毁容器。
3.3 网络模型大乱斗 (CNI)
Flannel：简单，Overlay Network（VXLAN），性能略低。
Calico：强大，纯三层BGP路由，支持Network Policy。
Cilium：新一代，基于eBPF（Extended Berkeley Packet Filter，扩展的伯克利包过滤器），绕过iptables，性能极高，可观测性强。
第四部分：微服务架构的演进与陷阱
4.1 从单体到微服务的“拆分之痛”
拆分的粒度：按照限界上下文（Bounded Context）划分。
数据库拆分：数据库层面必须解耦，不能共享库。
分布式事务难题：放弃ACID（强一致性），拥抱BASE（基本可用、软状态、最终一致性）。使用Saga、TCC（Try-Confirm-Cancel）模式。
4.2 微服务的“双刃剑”——治理
当你有100个微服务时，以下问题爆发：
服务发现：服务A如何找到服务B的IP？—— CoreDNS + K8s Service。
配置管理：不改镜像，如何动态改日志级别？—— ConfigMap + 热加载，或使用配置中心（Apollo、Nacos）。
API网关：统一入口、认证、限流、日志。对比：Kong、APISIX、Nginx Ingress Controller。
第五部分：进阶利器——Service Mesh（服务网格）
这是“不懂云原生”的人最容易忽视的一层。
5.1 为什么要用 Service Mesh？
在没有Service Mesh之前，微服务需要自己处理熔断、限流、重试。要么用库（如Hystrix、Resilience4j），但这些库与代码耦合，且跨语言难以统一。
5.2 Sidecar 模式
本质：将网络通信功能（如重试、超时、监控）从业务容器中剥离，下沉到伴随容器（Sidecar）中。
数据平面：Envoy（高性能代理），劫持业务容器的进出流量。
控制平面：Istio（或其他如Linkerd），下发策略给Envoy。
5.3 Istio 架构详解
Pilot：服务发现和流量管理。
Mixer：策略检查和遥测（较新版本已废弃，功能下沉到Envoy）。
Citadel：安全和证书管理（mTLS自动加密）。
第六部分：云原生可观测性——别等到系统挂了才去查
传统的“盯着服务器CPU”在云原生时代完全无效，因为Pod随时可能重建。
6.1 三大支柱
监控（Metrics）：Prometheus + Grafana。
黄金指标：延迟（Latency）、流量（Traffic）、错误（Errors）、饱和度（Saturation）。
PromQL 实战：如何计算P99延迟？
日志（Logs）：Loki vs. ELK。
痛点：容器漂移导致日志丢失。解决方案：DaemonSet方式收集（如Fluentd、Filebeat）写到中央存储。
追踪（Traces）：Jaeger 或 Zipkin。
分布式追踪原理：一个请求经过几十个服务，如何串联？—— TraceID + Span。解决“一个慢请求到底卡在哪个环节”的问题。
第七部分：云原生DevOps与CI/CD
7.1 GitOps：云原生时代的交付哲学
定义：以Git作为声明式基础设施和应用的单一事实来源。
工作流：开发者提交PR -> 合并到main -> CI系统构建镜像 -> 更新Git仓库中的K8s manifest ->CD工具（如ArgoCD）自动拉取Git仓库变化并同步到K8s集群。
优势：回滚只需
git revert；集群状态始终与Git一致。
7.2 镜像构建的艺术
Docker Build 的痛点：依赖缓存、依赖网络。
Kaniko：在K8s集群内安全构建镜像，不需要Docker守护进程。
Buildpacks：自动检测代码语言，生成安全的运行时镜像（如Google的、Paketo）。
第八部分：云原生存储与有状态应用
谁说K8s只能跑无状态应用？
8.1 PV/PVC/StorageClass 详解
静态供给：管理员先创建好PV，用户PVC绑定。
动态供给：用户直接声明PVC，通过StorageClass调用云厂商接口（如AWS EBS、Azure Disk）自动创建存储卷。
8.2 Operator 模式
问题：如何用声明式API管理有状态应用（如数据库、消息队列）？
解决方案：Operator = 自定义资源（CRD）+ 自定义控制器。
原理：编写代码，将运维专家的知识（如备份、恢复、扩缩容、主从切换）变成代码，由控制器自动执行。
例子：运行一个高可用的etcd集群或MySQL集群？使用 etcd-operator 或 Vitess。
第九部分：云原生安全全景
9.1 镜像安全
SLSA 框架：保证软件供应链的安全。
镜像签名与验证：Cosign（Sigstore项目）。
9.2 运行时安全
Pod Security Standards (PSS)：限制特权容器、root用户、主机网络访问。
Seccomp/AppArmor：限制容器内进程的系统调用。
容器逃逸防护：使用gVisor（Google）或Kata Containers（轻量级虚拟机）作为容器运行时，提供虚拟机级别的隔离。
第十部分：实战案例——如何将遗留应用“云原生改造”？
10.1 改造策略
Rehost（直接搬迁）：物理机 -> 虚拟机（这是上云，不是云原生）。
Replatform（小改）：使用托管的数据库（RDS），应用打包成镜像部署（弹性有了，但架构未变）。
Refactor（重构）：拆分微服务，引入Service Mesh，这是真正的云原生。
10.2 避坑指南
日志不要写本地文件：必须输出到标准输出（stdout/stderr），由kubelet收集。
IP不再固定：不要硬编码IP，用服务名（Service Name）访问。
配置与镜像分离：环境变量、ConfigMap、Secret。
优雅终止：应用要捕获
SIGTERM信号，完成当前请求再退出，避免中断连接。
