简介：本资源是一份系统化、分层级的云原生技术学习路线图PDF，面向开发者、运维工程师及希望转型云原生领域的IT从业者，帮助其建立从入门到高阶的完整知识体系与演进路径。文件共1个，为1.29MB的高清PDF文档，内容涵盖初阶（容器、Kubernetes基础、微服务框架）、中阶（Service Mesh、Serverless、CI/CD、可观测性）、高阶（边缘计算、联邦集群、Database Mesh、eBPF生态、云原生安全与标准化）三大能力层级，并包含各技术栈的核心组件（如etcd、Nacos、Istio、Prometheus、KubeEdge、Dapr等）、工具链（Helm、Kustomize、Terraform、OAM）及编程语言适配要点（GraalVM、Quarkus、Go/Rust实践）。已有1072人学习下载，路线图由阿里云技术专家王银利、孙林林联合参与编写，结构清晰、模块可拆解，支持按需精读任一技术分支，是制定个人成长计划、团队技术规划或课程教学设计的权威参考。
1. 云原生不是一堆工具的堆砌，而是一张分层演进的能力地图
很多人第一次打开《云原生技术学习路线图.pdf》，第一反应是：密密麻麻全是名字——etcd、Istio、Prometheus、KubeSphere、Knative、Dapr……像闯进了一个开源工具博览会。但梳理下来会发现，这份路线图根本不是“工具清单”，而是一张按能力成熟度分层、按技术纵深递进、按角色协同演进的三维成长地图。它把云原生拆成初阶（可运行）、中阶（可治理）、高阶（可编排）三个能力断层，每层都覆盖「基础设施抽象→应用交付→可观测性→弹性与自治」四条主线，且明确标注了哪些是必选项（如 Kubernetes API、YAML 声明式语法、CNI/CSI/CRI 接口规范），哪些是场景增强项（如 OAM、KubeVela、Dapr）。适合两类人：一是刚从传统运维或单体开发转岗、需要系统锚定学习坐标的工程师；二是已用过 K8s 但总在排查问题时卡在“为什么 Pod 起不来”“为什么 Service 不通”“为什么指标对不上”的实战者——这张图真正价值，在于帮你把零散经验缝合成可复用的认知框架。它不教你怎么敲kubectl apply -f，而是告诉你：当kubectl get pod显示ContainerCreating时，该顺着哪条链路往下查（CRI → CNI → CSI → 镜像拉取策略），这才是能扛住生产环境压力的底层能力。
2. 初阶：从“能跑起来”到“知道为什么能跑”的四道门槛
云原生初阶不是“学会 Docker 和 K8s 命令”，而是建立四个不可跳过的认知基座：容器运行时本质、声明式 API 意义、网络与存储的抽象契约、以及微服务落地的最小可行闭环。跳过任一环，后续所有调试都会变成玄学。
2.1 容器不是进程封装，而是标准化的运行时契约
很多人以为docker run就是启动一个隔离进程，但初阶最易忽略的是：容器镜像本身就是一个可验证、可签名、可分层复用的软件交付单元。它强制解耦了“构建”与“运行”两个阶段，而这个解耦背后是 OCI（Open Container Initiative）标准的三重约束：
- 镜像格式：必须符合
image-spec（如 manifest.json + layer.tar.gz 的组织方式） - 运行时规范：
runtime-spec定义了config.json中process,root,linux等字段语义（例如no-new-privileges: true是默认安全基线） - 分发协议：
distribution-spec规定了 registry 如何通过/v2/<name>/manifests/<reference>提供内容寻址
提示：当你遇到
failed to register layer: devmapper或failed to create endpoint: network driver failed，90% 是因为 runtime（containerd/runc）与镜像格式或内核模块不兼容，而非 YAML 写错。此时应先ctr images ls查镜像状态，再ctr containers ls看 runtime 层是否就绪。
一个典型初阶误用是：为减小镜像体积直接FROM alpine:latest+apk add python3，却忽略了 Alpine 的 musl libc 与 glibc 生态（如某些 C 扩展）的 ABI 不兼容风险。正确做法是：
- Java 应用优先选
eclipse-jetty:jre17-slim（Debian slim，glibc 兼容） - Go 应用可用
golang:1.22-alpine编译后FROM scratch - Python 若需 numpy/pandas，必须用
python:3.11-slim-bookworm（Debian 12）
# ✅ 推荐：多阶段构建 + 明确基础镜像版本 + 指定时区 FROM golang:1.22-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o main . FROM alpine:3.19 RUN apk --no-cache add ca-certificates tzdata ENV TZ=Asia/Shanghai COPY --from=builder /app/main /usr/local/bin/app CMD ["/usr/local/bin/app"]这段 Dockerfile 的关键不在语法，而在三点设计意图：① 构建与运行分离，避免暴露编译工具链；②CGO_ENABLED=0强制纯静态链接，消除 musl/glibc 依赖；③tzdata和TZ确保日志时间戳可信——这些才是初阶必须刻进肌肉记忆的“为什么”。
2.2 Kubernetes 不是容器编排器，而是声明式 API 的分布式状态机
初学者常把kubectl apply -f deploy.yaml当作“启动服务”，但真正要理解的是：Kubernetes 控制平面本质是一个基于 etcd 的分布式状态协调系统。你提交的 YAML 不是命令，而是“期望状态（desired state）”，而 kube-controller-manager、kube-scheduler、cloud-controller-manager 这些组件，就是不断将“实际状态（actual state）”向期望状态驱动的控制器集合。
这意味着：
kubectl delete pod不是“杀死进程”，而是将该 Pod 的metadata.deletionTimestamp写入 etcd，触发podgc控制器执行优雅终止流程kubectl scale deploy实际是 PATCHDeployment.spec.replicas字段，由deployment-controller触发 ReplicaSet 的滚动更新- Service 的 ClusterIP 并非真实 IP，而是 kube-proxy 在每个节点上维护的 iptables/ipvs 规则表，其生命周期完全独立于 Pod
所以初阶最该掌握的不是kubectl get all，而是：
kubectl get <resource> -o wide看分配节点与 IPkubectl describe <resource>看 Events（事件流是诊断黄金线索）kubectl get <resource> -o yaml看完整 spec/status，尤其注意status.conditions和status.phase
例如，当 Deployment 显示Available: 0/3，先kubectl describe deploy <name>，若 Events 中出现FailedCreatePod，再kubectl get events --field-selector involvedObject.name=<rs-name>定位 ReplicaSet，最后kubectl describe rs <rs-name>查status.replicas与status.availableReplicas差异——这套链路比死记kubectl rollout status有用十倍。
2.3 网络与存储：别碰“黑匣子”，先吃透 CNI/CSI 的接口契约
初阶最容易翻车的场景：Pod 能起，但跨节点不通；PVC 申请成功，但挂载失败。根源在于没理解 Kubernetes 的接口抽象哲学：它不实现网络和存储，只定义标准接口（CNI、CSI），让具体实现（Calico、Ceph CSI）插拔式接入。
CNI 的核心契约只有两个文件：
/etc/cni/net.d/*.conflist：定义网络配置（如plugin: "calico"+ipam.type: "host-local"）/opt/cni/bin/*：提供ADD/DEL/CHECK三个可执行命令，接收 JSON 格式 stdin（含CNI_COMMAND,CNI_CONTAINERID,CNI_NETNS）
所以当kubectl exec -it <pod> -- ping <other-pod-ip>失败时，不要急着查 Calico 日志，先确认：
- 该节点
/etc/cni/net.d/下有有效配置（非空、JSON 合法） /opt/cni/bin/calico可执行且版本匹配（calico --version）ip link show是否有cali*网卡，ip route是否有对应 Pod CIDR 路由
CSI 同理：kubectl get csinodes看节点注册状态，kubectl describe csidriver <driver-name>看attachRequired和podInfoOnMount字段含义——前者决定是否需 ControllerPublishVolume，后者决定是否在 Mount 时注入 Pod 信息。很多 NFS PVC 挂载失败，就是因为 CSI Driver 未开启podInfoOnMount，导致 mount 命令缺少nfsvers=4.1等关键参数。
2.4 微服务落地：从 Spring Cloud 到 Service Mesh 的能力迁移路径
初阶常陷入“该用 Dubbo 还是 Istio”的选择焦虑，但路线图给出的清晰信号是：Spring Cloud 是微服务的“教学版”，Service Mesh 是生产级的“操作系统版”。二者不是替代关系，而是能力继承关系——Spring Cloud 解决的是“怎么写微服务”，Istio 解决的是“怎么管微服务”。
因此初阶必须打通两条线：
- 代码侧：理解
@LoadBalanced RestTemplate背后是 Ribbon 的 ServerListFilter + IRule，而@SentinelResource的降级逻辑实际运行在 JVM 内存中，无法跨语言 - 基础设施侧：理解 Istio 的
VirtualService是 Envoy xDS 协议下发的路由规则，DestinationRule是集群内负载均衡与熔断策略，它们与应用代码完全解耦
一个典型过渡实践是：先用 Spring Cloud Alibaba Nacos 做服务注册+配置中心（初阶可控），再逐步将流量管理（灰度、限流）迁移到 Istio 的VirtualService+DestinationRule（中阶可治理）。这样既避免一步到位的复杂度爆炸，又确保能力平滑升级。
3. 中阶：从“可治理”到“可验证”的三大能力跃迁
中阶的核心标志不是“用了多少中间件”，而是能否回答三个问题：我的系统是否符合云原生最佳实践？它的行为是否可被第三方客观验证？当故障发生时，能否在 5 分钟内定位到根因模块？这要求你从“操作者”升级为“架构守门人”。
3.1 可观测性：从“看指标”到“建信号链”的范式转换
中阶最大的认知跃迁，是理解 Prometheus/Grafana/ELK 不是监控工具集，而是构建系统健康信号链（Signal Chain）的协作协议。每层工具解决不同粒度的问题：
- Metrics（指标）：回答“是否正常？”（如 HTTP 5xx 率 > 1%）
- Logs（日志）：回答“发生了什么？”（如
error="timeout after 30s"） - Traces（链路）：回答“在哪发生的？”（如
auth-service → user-service → db的 99% 延迟在 user-service 的 DB 查询）
但初阶常犯的错误是：把所有日志塞进 ELK，所有指标推给 Prometheus，所有 trace 发给 Jaeger——结果是数据爆炸，信号淹没。中阶必须建立“信号分层过滤”机制：
- 基础设施层（Node/Pod）：用
node_exporter+kube-state-metrics监控资源水位，阈值设为硬性红线（如 CPU > 90% 持续 5m） - 平台层（Service/Mesh）：用
istio-proxy的envoy_access_log+istio_requests_total监控服务间 SLO，聚焦destination_service+response_code维度 - 应用层（业务逻辑）：用 OpenTelemetry SDK 埋点，仅采集关键业务事件（如
order_created,payment_confirmed），并通过trace_id关联日志与指标
注意：Grafana 中一个健康的 Dashboard 必须包含“黄金信号（Golden Signals）”四块：Latency（P99 延迟）、Traffic（QPS）、Errors（错误率）、Saturation（饱和度，如线程池使用率）。缺一块，就不是可观测，只是“可看见”。
一个中阶必备技能是：用promql写出可告警的复合表达式。例如，检测“API 熔断生效”不能只看istio_requests_total{response_code=~"5.*"}，而要关联istio_request_duration_seconds_bucket与istio_requests_total计算 P99 延迟突增 + 错误率同步上升：
# ✅ 熔断检测：过去5分钟P99延迟增长200% 且 5xx错误率>5% ( rate(istio_request_duration_seconds_bucket{le="1.0", destination_service="api.default.svc.cluster.local"}[5m]) / rate(istio_request_duration_seconds_bucket{le="0.1", destination_service="api.default.svc.cluster.local"}[5m]) ) > 2 AND ( rate(istio_requests_total{response_code=~"5.*", destination_service="api.default.svc.cluster.local"}[5m]) / rate(istio_requests_total{destination_service="api.default.svc.cluster.local"}[5m]) ) > 0.05这段 PromQL 的价值不在语法，而在于它把“熔断”这个业务概念，翻译成了可量化的、跨组件的、带时间窗口的数学表达——这才是中阶可观测性的本质。
3.2 配置与策略：从“人工 YAML”到“策略即代码”的治理升级
中阶必须告别kubectl edit configmap这类人工操作，转向以 OPA（Open Policy Agent）和 Kyverno 为核心的策略即代码（Policy as Code）体系。因为配置漂移（Configuration Drift）是生产事故头号元凶——没人记得上周谁改了nginx-ingress的proxy-buffer-size。
OPA 的 Rego 语言核心是“声明式策略断言”。例如，禁止任何 Pod 使用hostNetwork: true：
# policy.rego package kubernetes.admission import data.kubernetes.namespaces deny[msg] { input.request.kind.kind == "Pod" input.request.object.spec.hostNetwork == true msg := sprintf("hostNetwork is not allowed in namespace %v", [input.request.namespace]) }而 Kyverno 更贴近 K8s 原生体验，用 YAML 写策略：
# kyverno-policy.yaml apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: require-labels spec: rules: - name: check-for-environment-label match: resources: kinds: - Pod validate: message: "label 'environment' is required" pattern: metadata: labels: environment: "?*"中阶的关键动作是：把所有“必须做”的事（如 Pod 必须有 resource limits、Ingress 必须启用 TLS、Secret 不能明文写在 YAML）全部编码为策略，并接入 CI 流程——kubectl apply -f policy.yaml只是部署策略，真正的防线在kyverno apply --policy policy.yaml --resource my-app.yaml的预检环节。
3.3 应用交付：从“Helm Chart”到“GitOps 工作流”的可靠性重构
中阶交付的分水岭，是能否用 Argo CD 或 Flux 实现“Git 仓库即唯一事实源（Source of Truth）”。Helm Chart 只是模板，而 GitOps 是一套完整的变更控制协议：
- Declarative：集群状态 = Git 仓库中 YAML 的 SHA256
- Automated：Argo CD 自动比对并同步，无需
helm upgrade - Auditable：每次变更都有 Git commit 记录，可追溯、可回滚
一个中阶血泪经验：Argo CD 的SyncPolicy必须显式配置automated.prune=true和automated.selfHeal=true，否则删除 Git 中的资源，集群不会自动清理（prune），导致僵尸对象堆积。
更关键的是环境分层策略。中阶推荐的 Git 仓库结构是：
gitops-repo/ ├── clusters/ │ ├── prod/ # 生产集群：严格审批，自动同步关闭 │ └── staging/ # 预发集群：自动同步开启，但需 PR + 2 人 approve ├── applications/ │ ├── nginx-ingress/ # HelmRelease + values-prod.yaml/values-staging.yaml │ └── prometheus/ # Kustomize base + overlays └── infrastructure/ # Cluster-wide CRD, PSP, NetworkPolicy这样，argocd app sync staging-nginx-ingress的本质，是kustomize build clusters/staging/applications/nginx-ingress后的 diff 与 apply——所有环境差异收敛到values-*.yaml或kustomization.yaml，而非分支。
4. 易错点：那些文档不写、教程不说、但线上翻车率超 70% 的细节
云原生学习中最容易漏掉的，从来不是高大上的架构理论，而是几个看似微小、实则决定成败的“魔鬼细节”。这些点往往藏在 GitHub Issue、SIG Meeting 纪要或某次深夜排障的 Slack 记录里，新手踩坑一次，至少浪费 3 小时。
4.1 etcd 数据库：备份不是cp /var/lib/etcd，快照恢复必须校验一致性
易漏点：认为etcdctl snapshot save生成的文件可直接用于恢复，或用cp复制整个/var/lib/etcd目录当备份。
为什么漏：etcd 文档强调“snapshot save”，但没说快照文件必须配合etcdctl snapshot restore使用，且 restore 后必须etcdctl check perf验证性能。cp复制的目录在节点重启后大概率因 WAL 日志不一致而拒绝启动。
怎么补：
- 备份必须用
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key snapshot save /backup/etcd-snapshot.db - 恢复前先
etcdctl snapshot status /backup/etcd-snapshot.db确认hash和revision - 恢复后
etcdctl --write-out=table endpoint status检查DBSize和IsLeader，再etcdctl check perf确保写入延迟 < 10ms
4.2 Service 的 ClusterIP：不是“虚拟 IP”，而是 kube-proxy 的 iptables 规则索引
易漏点：kubectl get service显示CLUSTER-IP: 10.96.0.1，就以为这是个真实 IP，尝试ping 10.96.0.1或telnet 10.96.0.1 80。
为什么漏：ClusterIP 是 iptables NAT 表中的一个“占位符”，它本身不响应 ICMP 或 TCP SYN，只有当 Pod 发起连接时，kube-proxy 才根据iptables -t nat -L KUBE-SERVICES规则做 DNAT。
怎么补：
- 测试 Service 连通性，必须从集群内 Pod 执行
curl http://<service-name>.<namespace>.svc.cluster.local - 查看规则：
iptables -t nat -S KUBE-SERVICES | grep <service-name>，确认有-j KUBE-SVC-XXXXXX链 - 若无响应，检查
kube-proxy日志是否有Failed to list *v1.Service（RBAC 权限不足）
4.3 Helm Release 名称：不能含下划线_，否则 Tiller/ReleaseServer 拒绝部署
易漏点：helm install my_app ./chart成功，但helm list看不到，或helm upgrade my_app报release: not found。
为什么漏：Helm v2（Tiller）和 v3 的 Release 名称校验正则为^[a-z0-9]([-a-z0-9]*[a-z0-9])?$，下划线_不在允许字符中，但错误提示极其隐蔽（v2 返回500 Internal Server Error，v3 返回Error: release name is invalid）。
怎么补：
- Release 名强制小写字母+数字+连字符，如
my-app-v1 - CI 中用
echo $RELEASE_NAME | tr '_' '-' | sed 's/[^a-z0-9-]//g'清洗 - 永远用
helm list --all-namespaces --filter <prefix>而非helm list，避免命名空间隔离导致的“看不见”
4.4 Pod Security Context：runAsNonRoot: true不等于“不以 root 运行”，而是“禁止以 UID 0 启动”
易漏点：设置securityContext.runAsNonRoot: true后，镜像仍以 root 用户启动，且kubectl exec进入后id显示uid=0(root)。
为什么漏：runAsNonRoot只校验容器启动时的USER指令或runAsUser字段，若镜像 Dockerfile 未指定USER，且未设置runAsUser，K8s 会默认以 UID 0 启动，但runAsNonRoot校验通过（因为它是“允许以非 root 启动”，而非“强制非 root”）。
怎么补：
- 镜像必须显式
USER 1001（非 root UID） - Pod YAML 必须同时设置：
securityContext: runAsNonRoot: true runAsUser: 1001 runAsGroup: 1001 fsGroup: 1001 - 用
kubectl auth can-i use securitycontextconstraints --list检查集群是否启用 PodSecurityPolicy/PodSecurityAdmission
4.5 Ingress Controller：ingressClassName不是可选字段，而是多 Controller 共存的路由开关
易漏点：集群装了 Nginx Ingress 和 Traefik，但所有 Ingress 都被 Nginx 处理，Traefik 的IngressClass形同虚设。
为什么漏：K8s 1.18+ 默认启用IngressClass，但旧版 Ingress 资源不带ingressClassName字段时，会匹配ingressclass.spec.controller为k8s.io/ingress-nginx的默认 IngressClass（如果存在）。
怎么补：
- 删除所有
ingressclass的annotations.kubernetes.io/ingress.class（已废弃） - 为每个 Ingress 显式指定：
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress spec: ingressClassName: nginx # 必须与 ingressclass.metadata.name 一致 rules: ... - 用
kubectl get ingressclass -o wide确认CONTROLLER列值，避免拼写错误（如nginxvsk8s.io/ingress-nginx）
5. 高阶：从“可编排”到“可进化”的自主智能底座
高阶不是“学更多工具”，而是构建一套能让系统自我适应、自我修复、自我优化的智能底座。它要求你跳出单点技术，站在“云原生操作系统”的高度，重新定义基础设施、应用、数据三者的协作契约。
5.1 基础设施即代码（IaC）：从 Terraform 到 Crossplane 的统一资源编排
Terraform 擅长云厂商资源（AWS EC2、Azure VM），但无法管理 K8s 内部资源（Namespace、CRD）。Crossplane 的突破在于：它把 K8s API Server 变成“通用资源编排引擎”，通过Provider将 AWS/Azure/GCP 的 REST API 封装为 K8s CRD，从而用kubectl apply -f统一创建云资源与集群资源。
例如，创建一个 RDS 实例并绑定到 K8s Namespace：
# rds-instance.yaml apiVersion: database.example.org/v1alpha1 kind: RDSInstance metadata: name: prod-rds namespace: prod spec: forProvider: dbInstanceClass: db.t3.medium engine: postgres masterUsername: admin masterPasswordSecretRef: name: rds-secret key: password --- # rds-claim.yaml apiVersion: database.example.org/v1alpha1 kind: RDSInstanceClaim metadata: name: prod-rds-claim namespace: prod spec: resourceRef: name: prod-rds高阶的关键洞察是：Crossplane 不是替代 Terraform，而是将其能力“K8s 化”。你的main.tf可以变成providerconfig.yaml，terraform plan变成kubectl get managed，terraform apply变成kubectl apply -f。这样，整个基础设施的生命周期（创建、更新、销毁）就纳入了 K8s 的 RBAC、审计日志、GitOps 流水线——这才是真正的“统一编排”。
5.2 应用模型：从 OAM 到 KubeVela 的开放应用交付协议
OAM（Open Application Model）定义了一套与运行时无关的应用描述标准：Component（应用组件）、Trait（运维特征）、ApplicationScope（应用范围）。但 OAM 本身不提供运行时，KubeVela 是它的参考实现，将 OAM 模型编译为 K8s 原生资源。
一个高阶典型场景：同一份application.yaml，在测试环境启用autoscalerTrait（HPA），在生产环境启用canaryTrait（Flagger），而无需修改Component定义：
# application.yaml apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: my-app spec: components: - name: frontend type: webservice properties: image: nginx:1.20 port: 80 policies: - name: topology-prod type: topology properties: cluster: prod-cluster workflow: steps: - name: deploy type: deploy properties: policies: ["topology-prod"] --- # traits/canary.yaml (生产) apiVersion: core.oam.dev/v1beta1 kind: TraitDefinition metadata: name: canary spec: appliesToWorkloads: - webservice workloadRefPath: spec.workloadReference podDisruptionBudget: true高阶的价值在于：开发者只关心 Component（我做什么），运维只关心 Trait（怎么管），平台只关心 Workflow（怎么发布）。三者解耦后，前端团队可以自由迭代webservice，SRE 团队可以独立升级canaryTrait 的 Flagger 版本，而无需彼此协调——这才是大规模协同的基石。
5.3 数据面智能：从 eBPF 到 Cilium 的内核级可观测性与安全
当 Prometheus 的 15s 采样精度无法满足毫秒级故障定位，当 Istio 的 Sidecar 注入带来 10% 性能损耗，高阶必须深入 Linux 内核，用 eBPF（extended Berkeley Packet Filter）构建零侵入的数据面智能。
Cilium 是 eBPF 在云原生的标杆实现，它把网络、安全、可观测性全部下沉到内核态：
- 网络：用 eBPF 替代 iptables，实现 L3/L4/L7 流量转发，延迟降低 50%+
- 安全：用
cilium network policy定义 L7 HTTP/gRPC 策略，无需 Sidecar - 可观测性：
cilium monitor实时捕获所有 eBPF 事件，包括 socket、TCP、HTTP 请求头
一个高阶实战：用 Cilium 的 Hubble UI 替代传统链路追踪。Hubble 不需要应用埋点，它直接从内核抓取socket connect、tcp send、http request事件，并自动构建成服务拓扑图。当user-service调用payment-service超时，Hubble 能精确显示：
user-service发出的 HTTP 请求头（含trace-id）payment-service内核态accept()耗时 2.3s（说明是应用瓶颈，非网络）payment-service向 DB 发起的mysql query事件（确认是否 DB 慢查询）
这种“内核级全链路”能力，是任何用户态代理（Envoy/Istio）都无法企及的——因为它不经过用户态，没有上下文切换开销。
6. 复习清单：一份可打印、可勾选、可嵌入日常工作的云原生能力自查表
学完这份路线图，你不需要记住所有工具名，但必须能独立完成以下 12 项任务。我把它们做成一张可打印的 A4 复习清单（PDF 版已随路线图附赠），每项任务对应一个真实生产场景，完成后请在方框 □ 打钩。这不是考试，而是帮你把知识锚定在肌肉记忆里的“防遗忘协议”。
| 序号 | 能力项 | 场景描述 | 关键检查点 | 我已完成 |
|---|---|---|---|---|
| 1 | 容器镜像瘦身与安全加固 | 为一个 Spring Boot 应用构建生产镜像，大小 < 150MB，无 CVE-2023-XXXX 高危漏洞 | □ 使用distroless或ubi-minimal基础镜像□ docker scan报告无 HIGH/CRITICAL 漏洞□ docker history显示层数 ≤ 5 | □ |
| 2 | K8s 故障五步定位法 | Pod 处于CrashLoopBackOff，需 5 分钟内定位根因 | □kubectl describe pod查 Events□ kubectl logs --previous看上一次崩溃日志□ kubectl exec -it -- ps aux确认进程是否启动□ kubectl get events --field-selector involvedObject.name=<pod-name>□ crictl logs <container-id>（若 containerd） | □ |
| 3 | Service 网络连通性验证 | 从frontendPod 访问backendService，curl http://backend:8080/health返回 200 | □kubectl get endpoints backend确认有 Pod IP□ kubectl exec frontend -- nslookup backend.default.svc.cluster.local□ kubectl exec frontend -- curl -v http://backend:8080/health□ iptables -t nat -S KUBE-SVC-XXXXXX查 DNAT 规则 | □ |
| 4 | Helm Release 可靠升级 | 将my-app从 v1.2.0 升级到 v1.3.0，零停机，失败可秒级回滚 | □helm upgrade --atomic --timeout 300s my-app ./chart --version 1.3.0□ helm history my-app显示DEPLOYED状态□ helm rollback my-app 1可回退到 v1.2.0□ kubectl get pods -l app.kubernetes.io/instance=my-app验证滚动更新 | □ |
| 5 | Prometheus 告警规则编写 | 编写一条告警：当istio_requests_total{destination_service="api"}的 5xx 错误率 > 1% 持续 3 分钟 | □alert: APIHighErrorRate□ expr: sum(rate(istio_requests_total{response_code=~"5.*", destination_service="api"}[3m])) by (destination_service) / sum(rate(istio_requests_total{destination_service="api"}[3m])) by (destination_service) > 0.01□ for: 3m□ labels: severity: warning | □ |
| 6 | OPA 策略强制执行 | 禁止任何 Pod 设置spec.containers[].securityContext.privileged: true | □opa run -s启动服务□ curl -X POST http://localhost:8181/v1/data/k8s/allow --data-binary @input.json返回false□ kubectl apply -f policy.yaml后，kubectl create -f privileged-pod.yaml被拒绝 | □ |
| 7 | GitOps 自动同步验证 | 修改 Git 仓库中ingress.yaml的host字段，Argo CD 自动同步到集群 | □argocd app get my-app显示Sync Status: OutOfSync→Sync Status: Synced□ kubectl get ingress my-ingress -o jsonpath='{.spec.rules[0].host}'与 Git 一致□ argocd app history my-app显示新同步记录 | □ |
| 8 | etcd 集群健康巡检 | 对三节点 etcd 集群执行每日健康检查 | □etcdctl --endpoints https://127.0.0.1:2379 endpoint health全部healthy□ etcdctl --endpoints https://127.0.0.1:2379 endpoint status --write-out=table查DBSize< 2GB□ `etcdctl |
本文还有配套的精品资源，点击获取
