企业官网建设流程全解析

简介：面向具备Linux和容器基础的技术人员，这份文档系统梳理了使用Rancher部署Kubernetes集群的完整路径：从服务器准备、节点角色划分（Control Plane、Worker、Etcd）到Rancher Server两种安装方式（测试环境Docker快速启动与生产环境高可用部署），再到集群创建、节点注册命令调整、kubectl验证等关键环节。包体为单个docx文档，约19KB，内容紧凑、步骤明确。目前已有540人学习，适合需要快速搭建生产级K8s环境或了解Rancher管理逻辑的运维与开发人员。文档不仅包含详细的部署命令和参数说明，还覆盖常见故障排查（如节点无法加入集群、网络插件异常）以及扩展操作（添加新节点、升级集群、备份恢复），可直接作为实操参考手册，帮助读者少踩坑、高效完成集群交付。

1. 用 Rancher 部署 K8s，先把“图形界面”这个预期放一边

我最早接触 Rancher，是接到一个需要同时交付三套 K8s 集群的活。手动执行 kubeadm 不是不行，但每套集群都要处理证书过期、etcd 备份、组件版本对齐、节点故障转移这些重复劳动，三套就是三倍工作量，而且每一套都可能踩一遍同样的坑。Rancher 的思路是把“部署 K8s”变成“管理 K8s 的一种状态”：你在界面上声明集群期望的版本、节点角色和数量，它负责把 cluster 编排到目标状态，承载这些任务的组件是 agent 和 controller，浏览器里的 UI 只是控制面的一层皮。

这篇笔记覆盖从准备工作、Rancher Server 启动、自定义集群与导入集群两条路径，到集群管理里必调的参数、证书轮换和运维避坑，最后落到版本升级、快照恢复和节点扩缩容。适合两种读者：一种是刚接下 K8s 集群交付任务的运维，另一种是手里已经有多套集群、想用统一入口做管理的平台工程师。如果你只是想看 k8s 部署教程级别的入门内容，这篇也能跟，但重点在生产怎么落地。

2. 动手前先过三关：节点规划、系统参数与私有镜像仓库

在打开 Rancher 的浏览器页面之前，有三件事必须做完：节点怎么分角色、系统参数改没改、节点能不能稳定拉到需要的镜像。这三件事决定集群是一次性拉起，还是你半夜被 etcd 告警叫醒。

2.1 节点角色划分：etcd、controlplane 与 worker 不要混成一道菜

Rancher 创建自定义集群时，每个节点需要勾选角色标签，角色是etcd、controlplane、worker的组合。很多人第一次搭 K8s 集群习惯把所有角色勾在同一台机器上，测试环境能跑，生产环境就是给自己埋雷。etcd 承担整个集群的状态存储，WAL 写入和快照对磁盘 IO 极其敏感；controlplane 上的 apiserver 是每次kubectl请求的入口；worker 才跑业务 pod。三者职责不同，故障域也不同。

我给的参考规划如下：

有一个反直觉的点：Rancher Server 宕机不会让下游 K8s 集群停止调度，业务流量照常走，你只是暂时丢了管理入口。真正让集群瘫痪的是 etcd 和控制面同时出问题。所以 Rancher Server 优先用独立节点，别和下游集群的 etcd 混部，否则一次宿主机故障同时带走管理面和集群状态，谁都救不了。

主机名唯一性也是老生常谈但反复出现的坑。Rancher 把节点注册进集群时，节点的主机名会被写进证书和 kubelet 配置，两台主机名相同的节点会导致 agent 串线、证书校验失败。我一般在每个节点上先做一遍：

# 每个节点都要有唯一主机名，比如 k8s-etcd-01 / k8s-cp-01 / k8s-worker-04 hostnamectl set-hostname k8s-worker-04 # 写进 /etc/hosts，保证所有节点能互相解析 cat >> /etc/hosts <<'EOF' 10.10.0.11 k8s-etcd-01 10.10.0.12 k8s-etcd-02 10.10.0.13 k8s-etcd-03 10.10.0.21 k8s-cp-01 10.10.0.22 k8s-cp-02 10.10.0.31 k8s-worker-01 EOF

hostnamectl set-hostname只改运行时主机名，重启后仍然生效，但你要确认发行版没有额外的 cloud-init 逻辑覆盖它，比如云镜像上经常被回写。/etc/hosts里的内网解析主要给 etcd 节点之间的互访用，也避免某些组件走 DNS 解析出问题时连不上 peer。这一套做完再往后走，后面少很多排查时间。

2.2 内核转发、Swap 与时间同步：最容易被跳过的系统参数

kubelet 和 CNI 组件对内核参数有默认要求，Rancher 生成的节点注册命令不会替你改这些。最常见的两个坑是net.bridge.bridge-nf-call-iptables没开导致 NodePort 和 Service 访问异常，以及节点 Swap 没关导致 kubelet 判定失败。我每次装节点都会先执行下面这段：

# 关闭 swap，kubelet 默认要求 swap 关闭或显式配置 --fail-swap-on=false swapoff -a sed -i '/ swap /s/^/#/' /etc/fstab # 内核转发与桥接流量规则，K8s 网络不通多半是这里没配 cat > /etc/sysctl.d/99-k8s.conf <<'EOF' net.bridge.bridge-nf-call-iptables = 1 net.bridge.bridge-nf-call-ip6tables = 1 net.ipv4.ip_forward = 1 vm.swappiness = 0 vm.overcommit_memory = 1 EOF modprobe br_netfilter sysctl --system

逐参数说明：bridge-nf-call-iptables让经过 Linux 网桥的流量能被 kube-proxy 的 iptables 规则处理，Pod 间通信和 Service 转发依赖它；ip_forward是 Pod 访问集群外部网络的必要条件；vm.swappiness = 0配合关闭 swap，防止内存回收把进程拖到不可用；vm.overcommit_memory = 1是很多部署手册会忽略的，它让内核总是允许内存超卖，避免某些节点因为预估 commit 不足直接 OOM。modprobe br_netfilter是加载桥接过滤模块，重启后内核不会自动加载，所以最好在/etc/modules-load.d/里写一行br_netfilter做持久化。

时间同步单独拿出来说，因为 K8s 和 Rancher 的证书校验强依赖时间，节点时间偏差超过五分钟，你会看到各种x509: certificate has expired or is not yet valid和 TLS 握手失败。这个问题排查起来很费时间，因为现象长得像证书配置错误。

yum install -y chrony && systemctl enable --now chronyd chronyc sources -v

chronyc sources -v输出里能看到同步源和偏移量，^*开头表示当前使用的同步源处于正常状态。注意 Rancher Server 所在节点也要同步，它管理和签发下游证书，时间漂移会让新生成的证书在客户端校验时直接无效。

2.3 容器运行时与私有镜像仓库：先把最关键的镜像备好

Rancher 的节点注册流程本质上是在目标节点上启动一个rancher-agent容器，由这个容器拉起 kubelet、etcd 和其余组件镜像。换句话说，节点必须能拉取 Rancher 相关镜像。网络环境不理想时，这一步最容易卡住。我的经验是提前准备一个私有镜像仓库，把rancher/rancher-agent、rancher/rancher、rancher/mirrored-pause以及目标 K8s 版本对应的组件镜像全部同步进去，然后让节点上的容器运行时统一走私有仓库。

容器运行时选择上，Rancher 2.x 同时支持 Docker 和 containerd。自定义集群默认可以用 Docker 运行时注册，但如果你用的是 containerd，需要提前修改配置。以 containerd 为例，在/etc/containerd/config.toml里加镜像 endpoint：

version = 2 [plugins."io.containerd.grpc.v1.cri".registry] [plugins."io.containerd.grpc.v1.cri".registry.mirrors] [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"] endpoint = ["https://registry.internal.example.com"]

这里的endpoint指向你的私有仓库或代理仓库地址。containerd 解析镜像时会把 docker.io 的请求转发到这个 endpoint，而不是直接访问公网。逻辑上是这五步：节点 agent 请求镜像 → containerd 查 endpoint → 私有仓库响应 → 组件容器启动 → 节点注册完成。只要 endpoint 可达，整个流程就跟外网完全无关。

私有仓库要做好认证。建议在/etc/containerd/config.toml同级目录下配置hosts.toml，或在 Docker 环境用docker login提前登录。这里有个常见翻车点：镜像同步完了，但节点上的容器运行时没有配置认证，agent 容器还是拉取失败。日志里会报unauthorized，和网络不通是两回事，别混在一起排查。

3. 部署 Rancher Server 与创建第一个工作集群

准备工作做完，开始正式部署。这一章先起 Rancher Server，再走一遍“自定义集群”和“导入已有集群”两条路径。前者适合从零搭建，后者适合把手里已有的 kubeadm 集群纳入管理。

3.1 用 docker run 快速拉起单节点 Rancher Server

测试环境我一般用 Docker 直接跑一个单节点 Rancher Server，生产环境可以用 Helm 在 K8s 里部署高可用形态。单节点形态足够跑通完整链路，也方便演示。启动命令如下：

docker run -d --name rancher-server \ --restart=unless-stopped \ -p 443:443 \ -p 80:80 \ -v /data/rancher:/var/lib/rancher \ rancher/rancher:v2.8.5

参数说明：-v /data/rancher:/var/lib/rancher是 Rancher 的数据目录，里面包含它自己维护的集群状态、证书和配置。不挂这个卷，容器重启后一切归零，后面你创建的所有集群记录全部丢失。-p 443:443必须暴露，Rancher 的 Web 管理面走 HTTPS；80 端口用于跳转和 Let's Encrypt 校验，如果不需要申请公网证书可以去掉，但保留更稳妥。镜像 tag 我用v2.8.5举例，实际安装时要以你选择的稳定版本为准，尤其是下游集群要用的 K8s 版本必须落在 Rancher 的兼容矩阵内，后面避坑章节会细说。

启动后等一两分钟，拉取日志里的初始密码：

docker logs rancher-server 2>&1 | grep "Bootstrap Password"

新版本 Rancher 在首次访问https://<server-ip>时会要求设置管理员密码。如果你用了新版本，日志里的 Bootstrap Password 就是初始凭据；如果日志里没有这行，直接访问 UI 页面也会提示你先初始化。这一步完成后，Rancher Server 就是你的管理入口。

3.2 在 UI 里创建自定义集群：节点角色怎么勾选

登录 Rancher UI 后，选择“创建集群”，然后选“自定义”或者“现有节点”。这里要填集群名称，然后在节点池配置里勾选角色。UI 会生成一段docker run注册命令，复制到目标节点上执行。

注册命令长这样：

sudo docker run -d --privileged --restart=unless-stopped \ --net=host \ -v /etc/kubernetes:/etc/kubernetes \ -v /var/run:/var/run \ rancher/rancher-agent:v2.8.5 \ --server https://rancher.example.com \ --token xxxxxxx \ --etcd --controlplane --worker

逐项解释：--privileged是 agent 容器操作节点网络和挂载时需要的权限；--net=host让 agent 直接使用宿主机网络命名空间，避免容器内 NAT 带来的端口映射问题；-v /etc/kubernetes:/etc/kubernetes把 kubelet 和组件配置持久化在宿主机，节点重启后配置不丢；-v /var/run:/var/run让 agent 能看到宿主机运行时 socket。末尾的--etcd --controlplane --worker决定这个节点承担的角色，可以多选，但生产环境每个角色最好独立成节点。

复制命令前先确认一件事：--server这个地址必须是所有要加入集群的节点都能访问到的。如果节点和 Rancher Server 之间有防火墙，443 端口不通，agent 容器会起来，但集群会一直卡在 provisioning 状态。

执行完注册命令后，回 UI 看集群状态。正常情况下节点会从 “provisioning” 走到 “active”，整个过程 10 到 20 分钟，取决于镜像拉取速度和机器配置。创建完成后下载 kubeconfig 文件：

kubectl --kubeconfig=xxxxx.yaml get nodes

能看到所有节点 Ready，集群就交付了。这里顺带提一句 k8s 常用命令：日常我基本只依赖kubectl get nodes、kubectl get pods -A、kubectl describe node、kubectl logs这四个，其他的边用边查。

3.3 把已有 K8s 集群导入 Rancher：一条 kubectl apply 搞定

如果你手里已有用 kubeadm 或 K3s 搭好的集群，完全没必要重建，Rancher 支持直接导入。操作路径是“创建集群 → 导入已有集群”，UI 会生成一个 YAML 文件，下载后到目标集群上执行：

kubectl apply -f import-cluster.yaml

这个文件做的事就是在目标集群的cattle-system命名空间里创建一套 agent 和相关 RBAC 资源。执行后观察 agent 是否正常起来：

kubectl get pods -n cattle-system -w

重点看cattle-cluster-agent的状态。如果是 Running 且没有频繁重启，回到 Rancher UI，集群会在几分钟内变为 active。导入路径不会动现有集群里运行的任何业务负载，只是在集群里多部署一层管理组件，风险很小。唯一要求是目标集群能访问到 Rancher Server，而且server-url配置要和 Rancher 的访问域名一致，否则 agent 回报状态会失败。

4. 集群管理的日常操作：角色标签、项目配额与证书轮换

集群建好只是开始，后面的管理才是日常工作。这一章讲三个高频操作：节点角色查看与多控制面高可用，项目配额管理，以及证书轮换和 kubeconfig 重新生成。

4.1 节点角色标签、多控制面与故障转移的配合方式

Rancher 在节点注册时会把角色写进节点的 labels 和 taints。查看节点角色标签用这条命令：

kubectl get nodes --show-labels | grep node-role

输出里你会看到node-role.kubernetes.io/etcd=true、node-role.kubernetes.io/controlplane=true、node-role.kubernetes.io/worker=true这样的标签。同时，带 etcd 和 controlplane 角色的节点会被自动打上污点，普通业务 pod 默认不会调度上去，这是 Rancher 帮你做好的保护，不要手动删掉这些 taint，否则业务负载可能把控制面节点打满。

为什么至少三台 master 才能保证高可用？这是 K8s 集群搭建里最常被问到的点。控制面组件本身是无状态的，apiserver 可以多副本分摊请求，但 etcd 是强一致的，必须多数派选举，三节点允许挂一个，五节点允许挂两个，偶数节点没有实际收益。Rancher 创建集群时，如果你勾选了三台节点的etcd + controlplane角色，它会自动完成 etcd 集群组建和 Rancher 自家负载均衡的配置。生产环境我一般推荐三台独立 etcd 加两台 controlplane，虽然两台 controlplane 在 etcd 选主时并不参与投票，但 apiserver 和调度器能实现 failover。

# 查看 etcd 集群成员 kubectl -n kube-system get pods | grep etcd

如果用了 RKE1 引擎，etcd 是容器化部署在 controlplane 节点上的；用 RKE2 时 etcd 是静态 pod。不管哪种，看到三个 etcd pod 都是 Running 且没有告警，说明多数派健康。

4.2 用项目配额管好命名空间：CPU、内存、权限一次配齐

Rancher 的“项目”概念是 K8s 里没有的抽象，一个项目是一组命名空间的集合，配额和权限可以设在项目层。实际交付里，我习惯按团队或业务线建项目，比如“支付团队”“数据平台团队”，然后把对应命名空间划进项目。好处是资源配额不用一个命名空间一个命名空间地重复设置。

创建项目时，配额字段里最常用的是：

配额设置完，项目下的所有命名空间共享这组限制，团队内部怎么分由他们自己决定。这个设计比直接给整个集群设置 LimitRange 灵活得多，因为你不用理解每个应用的具体资源画像，只需要和团队对齐预算。

权限这块，Rancher 支持把用户绑定到项目角色：项目成员、项目管理员、只读角色。如果团队要自己管理命名空间和应用，给项目管理员就够，别往上再给集群权限。

4.3 证书轮换与 kubeconfig 重新生成

K8s 集群的证书过期是个固定节奏的焦虑来源。社区里关于 k8s 集群证书过期自动续签的讨论一直很多，kubeadm 的证书默认有效期是一年，很多人第一次遇到是某个周一早上kubectl突然报certificate has expired。Rancher 在这方面有一个优势：由它创建的集群，证书轮换逻辑被内置在 agent 和 Rancher 管理面里，你不需要去每个节点上手动算证书路径和续期命令。

如果你用的是 Rancher 创建的集群，到“集群详情 → 高级选项”里能找到证书轮换入口，勾选需要轮换的组件证书，保存后 Rancher 会自动触发滚动更新。比如 apiserver 证书要轮换，它会先重新签发，再按顺序重启 kube-apiserver 相关静态 pod。这个操作会短暂影响 apiserver 可用性，最好在维护窗口做。

如果遇到已经过期的证书，节点上会持续报x509: certificate has expired，kubelet 无法连上 apiserver。这时先在 Rancher 端重新生成并下载新的 kubeconfig，然后再做证书轮换。已经导入的集群如果 kubeconfig 过期，可以在集群详情页直接下载新 kubeconfig，Rancher 签发的用户证书过期时间通常更长。

还有一个绕不开的组件是cattle-cluster-agent，它是下游集群回报状态给 Rancher Server 的通道。遇到证书相关的连接失败，重启它会重新拉取证书并建立连接：

kubectl -n cattle-system rollout restart deployment cattle-cluster-agent

这条命令是安全的，不会影响业务 pod，只会短暂中断管理面通信。重启后观察 pod 变成 Running，再回 Rancher UI 看集群状态是否同步。

5. 部署与运维避坑：五个反复出现的故障点

这一章全部来自实际操作里的踩坑记录。每条按现象 → 原因 → 解决写，遇到同款问题可以直接照着处理。

5.1 新建集群一直卡在 provisioning，节点状态没有任何变化

现象：集群创建后长时间处于 provisioning，节点列表里没有新节点出现，agent 容器已经起来了，但集群 controller 就是不加它。

原因：最常见的是版本兼容问题。Rancher 某个版本只支持特定范围的 K8s 版本，比如你用的 Rancher 版本不能创建你选择的 1.29.x 集群，或节点注册命令里的 agent 版本与 Server 不匹配。其次是节点访问不了--server地址，agent 报错但 UI 只显示 provisioning。

解决：先去 Rancher 官方 releases 页面查兼容矩阵，确认 Rancher 与 K8s 版本支持范围，再检查docker logs <agent容器>里是不是在反复连接 server 超时。如果 token 失效，回到集群编辑页重新生成注册命令，不要复用旧命令。

5.2 节点始终 NotReady，kubelet 起不来

现象：节点注册成功，但状态一直是 NotReady，kubectl get nodes看到该节点显示 SchedulingDisabled 或 NotReady。登录节点执行journalctl -u kubelet -f能看到大量 failed to run kubelet 的报错。

原因：九成是系统参数没配。我排查过的案例里有几种具体表现：swap 没关干净，/etc/fstab里的 swap 行没注释，重启后 swap 又挂回来；br_netfilter模块没加载，kubelet 检查网络插件前置条件失败；还有 Docker 版本过新，与 Rancher 支持的 containerd 版本不适配。

解决：回第二章的sysctl配置逐项核对。swapoff -a只是临时的，必须把/etc/fstab里 swap 那一行注释掉。然后检查modprobe br_netfilter和sysctl --system是否真的执行成功。改完参数后重启 kubelet，再等两三分钟看节点状态。这个坑在安装类教程里几乎没人强调，但出现频率最高。

5.3 导入已有集群后 cattle-cluster-agent 一直 CrashLoopBackOff

现象：执行完kubectl apply -f import-cluster.yaml后，cattle-cluster-agentpod 反复重启，日志里有failed to connect to server或 TLS 相关报错。

原因：目标集群访问不到 Rancher Server 的server-url。导入 YAML 生成的 agent 配置里写的是 Rancher UI 的访问地址，如果这个地址在集群内部无法解析，比如用的是外网域名而没有内网解析，agent 就永远连不上。

解决：确认目标集群可以访问该域名，最简单的方式是在集群节点上curl -k https://<server-url>/ping，能返回pong说明网络通。如果域名解析有问题，把 Rancher Server 地址也加到目标集群的/etc/hosts里，然后删除原 YAML，重新生成一份再 apply。不要手动改 agent deployment 的 env，Rancher 会认为集群配置被外部篡改，状态反而更乱。

5.4 etcd 节点反复重启，日志出现 fsync took too long

现象：etcd 容器频繁重启，日志里有took too long或fsync took too long，集群状态 intermittent，严重时 apiserver 报 etcd leader election 失败。此时节点 CPU 可能不高，但磁盘 IO 明显异常。

原因：etcd 对磁盘延迟极其敏感，common 做法里推荐的 SSD 不是随便说说。我用过机械盘跑测试集群，etcd 在每天凌晨备份时 IO 飙升，fsync 耗时超过 500ms，etcd 直接判定心跳超时并重新选举，导致整个集群抖动。另一个原因是 etcd 节点上同时还跑了业务 pod，流量高峰期 IO 争抢。

解决：etcd 节点必须独立部署，不要在上面跑业务容器；磁盘换 Nvme SSD 或至少是高性能企业盘；检查iostat -x 1的%util和await，如果等待时间持续超过 20ms，就要考虑迁移节点或升级存储。另外给 etcd 设置资源上限，避免它被宿主机上其他进程挤到饿死。

5.5 Rancher Server 升级后登录 502 或直接白屏

现象：给 Rancher Server 容器升级版本后，访问 UI 出现 502，或者页面能打开但登录后空白。

原因：Rancher Server 容器启动后要跑数据库 migration，有几个大版本升级路径要求先升级到中间版本，直接跨大版本会导致数据迁移失败。另外数据目录权限不对、磁盘空间不足也会造成同样现象。

解决：升级前先备份/data/rancher整个目录，这是后悔药。然后确认升级路径，比如 Rancher 2.6 到 2.7 不能直接跳 2.8，需要按官方支持的链路逐步升级。启动后看容器日志里是否有 migration 报错，如果迁移失败，把目录恢复回去再重来。注意恢复目录后容器会按旧版本数据启动，但新版本的数据结构和旧版本可能不兼容，所以这个操作越早做越好。

6. 把集群养熟：版本升级、快照恢复与节点扩缩容

集群交付后真正要花时间的不是部署，而是之后的例行升级和故障演练。这一章讲三个实用操作，也是我每次交付都要求团队先练一遍的事情。

6.1 用 Rancher 做集群版本升级：别跳版本，先看兼容矩阵

在 Rancher UI 的集群详情页里编辑集群，可以下拉选择 Kubernetes 版本，保存后 Rancher 会按顺序滚动升级 controlplane 和 worker。升级操作最核心的一条原则：不要跨多个小版本。比如 1.27 升 1.28 可以，直接 1.27 升 1.29 很容易遇到 API 兼容性问题。每次升级前，先看 Rancher 与目标 K8s 版本的兼容矩阵，再确认业务里有没有用到已经被弃用的 API。升级过程中观察 controlplane 节点先更新完毕，然后 worker 逐个滚动，中途任何一个节点 NotReady，立即暂停升级并看 kubelet 日志。

6.2 etcd 快照与 Rancher Server 备份恢复

Rancher 对自定义集群提供内置的 etcd 快照能力，配置位置在集群详情的高级选项里，可以设置快照周期和保留数量。我一般设置每天一次快照，保留 5 份。更重要的是 Rancher Server 自身的数据备份，因为它保存着所有集群的配置和证书，丢了它管理面就变成黑匣子。常见做法是把/data/rancher目录定期打包传输到独立存储或对象存储，同时在 Rancher 设置里配置后台上传到 S3 兼容存储。

恢复演练我有过一次惨痛经历：Rancher Server 数据盘损坏，虽然下游集群还在跑，但管理面所有集群配置都看不见了。还好有备份，恢复后几分钟内所有集群状态全部回来。核心是备份文件里包含证书和 token，恢复后不需要重新导入集群。

6.3 节点排空、扩容与僵尸节点清理

扩节点是我觉得 Rancher 比命令行 kubeadm 体验好最多的地方。新节点加入前安装好容器运行时，到 Rancher 节点页面复制新的注册命令执行即可。下线节点先做排空：

kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

排空是为了让 kubelet 将 pod 优雅驱逐到其他节点，--ignore-daemonsets保留 DaemonSet 管理的系统组件，--delete-emptydir-data释放临时目录。排空后到 Rancher 节点列表删除该节点记录，再清理节点上的残留 kubelet 配置。直接删节点不排空是我见过最常见的翻车方式，会导致 pod 在其他节点上重复调度，旧 pod 还没撕掉。

如果节点异常宕机无法排空，等它重新恢复后 Rancher 会自动重新调度 pod 并清掉残留状态，只有彻底放弃的坏节点才需要手动删除记录。

最后说一个我的个人习惯。每次交付 Rancher 平台，我都会在交付文档里固定记录三个东西：Rancher Server 的访问域名及证书到期日、etcd 快照的 S3 配置位置、最后一个恢复演练的时间点。后面排查问题时，这份记录能帮你省下大量重新定位的时间。希望这份指南对你有用。

本文还有配套的精品资源，点击获取