简介本资源是一份系统化、分层级的云原生技术学习路线图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就是启动一个隔离进程但初阶最易忽略的是容器镜像本身就是一个可验证、可签名、可分层复用的软件交付单元。它强制解耦了“构建”与“运行”两个阶段而这个解耦背后是 OCIOpen 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 failed90% 是因为 runtimecontainerd/runc与镜像格式或内核模块不兼容而非 YAML 写错。此时应先ctr images ls查镜像状态再ctr containers ls看 runtime 层是否就绪。一个典型初阶误用是为减小镜像体积直接FROM alpine:latestapk add python3却忽略了 Alpine 的 musl libc 与 glibc 生态如某些 C 扩展的 ABI 不兼容风险。正确做法是Java 应用优先选eclipse-jetty:jre17-slimDebian slimglibc 兼容Go 应用可用golang:1.22-alpine编译后FROM scratchPython 若需 numpy/pandas必须用python:3.11-slim-bookwormDebian 12# ✅ 推荐多阶段构建 明确基础镜像版本 指定时区 FROM golang:1.22-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED0 GOOSlinux go build -a -installsuffix cgo -o main . FROM alpine:3.19 RUN apk --no-cache add ca-certificates tzdata ENV TZAsia/Shanghai COPY --frombuilder /app/main /usr/local/bin/app CMD [/usr/local/bin/app]这段 Dockerfile 的关键不在语法而在三点设计意图① 构建与运行分离避免暴露编译工具链②CGO_ENABLED0强制纯静态链接消除 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.namers-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: calicoipam.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 --versionip 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 命令缺少nfsvers4.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 的VirtualServiceDestinationRule中阶可治理。这样既避免一步到位的复杂度爆炸又确保能力平滑升级。3. 中阶从“可治理”到“可验证”的三大能力跃迁中阶的核心标志不是“用了多少中间件”而是能否回答三个问题我的系统是否符合云原生最佳实践它的行为是否可被第三方客观验证当故障发生时能否在 5 分钟内定位到根因模块这要求你从“操作者”升级为“架构守门人”。3.1 可观测性从“看指标”到“建信号链”的范式转换中阶最大的认知跃迁是理解 Prometheus/Grafana/ELK 不是监控工具集而是构建系统健康信号链Signal Chain的协作协议。每层工具解决不同粒度的问题Metrics指标回答“是否正常”如 HTTP 5xx 率 1%Logs日志回答“发生了什么”如errortimeout after 30sTraces链路回答“在哪发生的”如auth-service → user-service → db的 99% 延迟在 user-service 的 DB 查询但初阶常犯的错误是把所有日志塞进 ELK所有指标推给 Prometheus所有 trace 发给 Jaeger——结果是数据爆炸信号淹没。中阶必须建立“信号分层过滤”机制基础设施层Node/Pod用node_exporterkube-state-metrics监控资源水位阈值设为硬性红线如 CPU 90% 持续 5m平台层Service/Mesh用istio-proxy的envoy_access_logistio_requests_total监控服务间 SLO聚焦destination_serviceresponse_code维度应用层业务逻辑用 OpenTelemetry SDK 埋点仅采集关键业务事件如order_created,payment_confirmed并通过trace_id关联日志与指标注意Grafana 中一个健康的 Dashboard 必须包含“黄金信号Golden Signals”四块LatencyP99 延迟、TrafficQPS、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{le1.0, destination_serviceapi.default.svc.cluster.local}[5m]) / rate(istio_request_duration_seconds_bucket{le0.1, destination_serviceapi.default.svc.cluster.local}[5m]) ) 2 AND ( rate(istio_requests_total{response_code~5.*, destination_serviceapi.default.svc.cluster.local}[5m]) / rate(istio_requests_total{destination_serviceapi.default.svc.cluster.local}[5m]) ) 0.05这段 PromQL 的价值不在语法而在于它把“熔断”这个业务概念翻译成了可量化的、跨组件的、带时间窗口的数学表达——这才是中阶可观测性的本质。3.2 配置与策略从“人工 YAML”到“策略即代码”的治理升级中阶必须告别kubectl edit configmap这类人工操作转向以 OPAOpen 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 的 SHA256AutomatedArgo CD 自动比对并同步无需helm upgradeAuditable每次变更都有 Git commit 记录可追溯、可回滚一个中阶血泪经验Argo CD 的SyncPolicy必须显式配置automated.prunetrue和automated.selfHealtrue否则删除 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_API3 etcdctl --endpointshttps://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-outtable endpoint status检查DBSize和IsLeader再etcdctl check perf确保写入延迟 10ms4.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.ServiceRBAC 权限不足4.3 Helm Release 名称不能含下划线_否则 Tiller/ReleaseServer 拒绝部署易漏点helm install my_app ./chart成功但helm list看不到或helm upgrade my_app报release: not found。为什么漏Helm v2Tiller和 v3 的 Release 名称校验正则为^[a-z0-9]([-a-z0-9]*[a-z0-9])?$下划线_不在允许字符中但错误提示极其隐蔽v2 返回500 Internal Server Errorv3 返回Error: release name is invalid。怎么补Release 名强制小写字母数字连字符如my-app-v1CI 中用echo $RELEASE_NAME | tr _ - | sed s/[^a-z0-9-]//g清洗永远用helm list --all-namespaces --filter prefix而非helm list避免命名空间隔离导致的“看不见”4.4 Pod Security ContextrunAsNonRoot: true不等于“不以 root 运行”而是“禁止以 UID 0 启动”易漏点设置securityContext.runAsNonRoot: true后镜像仍以 root 用户启动且kubectl exec进入后id显示uid0(root)。为什么漏runAsNonRoot只校验容器启动时的USER指令或runAsUser字段若镜像 Dockerfile 未指定USER且未设置runAsUserK8s 会默认以 UID 0 启动但runAsNonRoot校验通过因为它是“允许以非 root 启动”而非“强制非 root”。怎么补镜像必须显式USER 1001非 root UIDPod YAML 必须同时设置securityContext: runAsNonRoot: true runAsUser: 1001 runAsGroup: 1001 fsGroup: 1001用kubectl auth can-i use securitycontextconstraints --list检查集群是否启用 PodSecurityPolicy/PodSecurityAdmission4.5 Ingress ControlleringressClassName不是可选字段而是多 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-nginx5. 高阶从“可编排”到“可进化”的自主智能底座高阶不是“学更多工具”而是构建一套能让系统自我适应、自我修复、自我优化的智能底座。它要求你跳出单点技术站在“云原生操作系统”的高度重新定义基础设施、应用、数据三者的协作契约。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.yamlterraform plan变成kubectl get managedterraform apply变成kubectl apply -f。这样整个基础设施的生命周期创建、更新、销毁就纳入了 K8s 的 RBAC、审计日志、GitOps 流水线——这才是真正的“统一编排”。5.2 应用模型从 OAM 到 KubeVela 的开放应用交付协议OAMOpen Application Model定义了一套与运行时无关的应用描述标准Component应用组件、Trait运维特征、ApplicationScope应用范围。但 OAM 本身不提供运行时KubeVela 是它的参考实现将 OAM 模型编译为 K8s 原生资源。一个高阶典型场景同一份application.yaml在测试环境启用autoscalerTraitHPA在生产环境启用canaryTraitFlagger而无需修改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怎么发布。三者解耦后前端团队可以自由迭代webserviceSRE 团队可以独立升级canaryTrait 的 Flagger 版本而无需彼此协调——这才是大规模协同的基石。5.3 数据面智能从 eBPF 到 Cilium 的内核级可观测性与安全当 Prometheus 的 15s 采样精度无法满足毫秒级故障定位当 Istio 的 Sidecar 注入带来 10% 性能损耗高阶必须深入 Linux 内核用 eBPFextended 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-idpayment-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□2K8s 故障五步定位法Pod 处于CrashLoopBackOff需 5 分钟内定位根因□kubectl describe pod查 Events□kubectl logs --previous看上一次崩溃日志□kubectl exec -it -- ps aux确认进程是否启动□kubectl get events --field-selector involvedObject.namepod-name□crictl logs container-id若 containerd□3Service 网络连通性验证从frontendPod 访问backendServicecurl 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 规则□4Helm 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/instancemy-app验证滚动更新□5Prometheus 告警规则编写编写一条告警当istio_requests_total{destination_serviceapi}的 5xx 错误率 1% 持续 3 分钟□alert: APIHighErrorRate□expr: sum(rate(istio_requests_total{response_code~5.*, destination_serviceapi}[3m])) by (destination_service) / sum(rate(istio_requests_total{destination_serviceapi}[3m])) by (destination_service) 0.01□for: 3m□labels: severity: warning□6OPA 策略强制执行禁止任何 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被拒绝□7GitOps 自动同步验证修改 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显示新同步记录□8etcd 集群健康巡检对三节点 etcd 集群执行每日健康检查□etcdctl --endpoints https://127.0.0.1:2379 endpoint health全部healthy□etcdctl --endpoints https://127.0.0.1:2379 endpoint status --write-outtable查DBSize 2GB□ etcdctl本文还有配套的精品资源点击获取