最近在把微服务治理组件往 k8s 上迁移Sentinel Dashboard 1.8.9 这块前后折腾了几天。标题看起来简单——写个 Deployment 拉起来一个 Java 服务就行但真正落地的过程里镜像选哪个、登录鉴权怎么配、Nacos 地址怎么传进去、重启之后规则还在不在每个问题都能卡你一会儿。如果你也正打算在 k8s 里部署 Sentinel Dashboard或者准备把原来单机跑的控制台迁进集群这篇应该能帮你少踩不少坑。先说一下这次部署的背景我们服务端的限流降级一直用的 Sentinel但控制台一直是运维手工在虚拟机里起一个 Java 进程。版本升级要靠人肉替换 jar参数配置散落在启动脚本里出了故障也没法快速扩容。把 Sentinel Dashboard 1.8.9 放进 k8s本质上就是把治理页面的生命周期统一交给集群管理同时通过环境变量把 Nacos 地址、登录账号这类配置全部外置化实现一次构建到处部署。这篇文章会从版本特性、部署方案选型、完整 YAML 实操、问题排查四个维度展开看完你基本可以直接照着抄一套上线。1. 部署前先摸清 Sentinel Dashboard 1.8.9 的家底1.1 控制台到底是什么和客户端是什么关系Sentinel 的体系可以理解成两层一层是埋点在业务应用里的客户端 SDK负责采集指标、执行限流降级逻辑另一层就是 Dashboard 控制台负责展示实时指标、配置规则并推送给客户端。很多人刚接触的时候会混淆一个概念Dashboard 本身并不做限流它只做可视化和规则管理。真正的限流动作发生在业务应用的 Sentinel SDK 里。控制台通过 HTTP 接口拿到客户端上报的监控数据同时把你在页面上配置的流量规则通过 transport 模块下发给客户端。这个关系在 k8s 部署时特别重要。因为控制台部署在集群里以后客户端要用一个能访问到它的地址去心跳上报和拉取规则。如果你把控制台放在 namespace A业务应用放在 namespace B中间的网络策略、Service 地址能不能通直接决定了控制台对你到底有没有用。部署前先把这条链路想清楚后面会省很多事。1.2 1.8.9 带来的几个关键变化Sentinel 版本迭代里1.8.x 是一个比较重要的分水岭。从 1.8.0 开始Dashboard 默认开启了登录鉴权不再像 1.7.x 那样裸奔而 1.8.9 在 1.8.6 之后又补了不少东西几个比较关键的点登录鉴权默认开启默认账号密码是 sentinel/sentinel但可以通过启动参数覆盖。内置了对 Nacos 作为动态数据源的支持规则可以推到 Nacos 持久化而不是只存在内存里。集群流控能力完善了一些如果有网关或者集群限流场景用 1.8.9 会更稳。控制台页面支持多命名空间隔离可以按项目或者环境区分不同的应用分组。这里要提醒一句命名空间这个功能是 Sentinel 自己页面上的一个逻辑概念跟 k8s 的 namespace 完全是两码事。你可以在页面上建“prod”、“test”这样的分组来区分环境但它不会自动读取 k8s namespace。部署的时候别被这两个同名概念绕晕。1.3 部署前要准备的东西清单按我这次实操的经验先列一个最小的准备清单一个可用的 k8s 集群版本在 1.20 以上基本都能跑Ingress 的话看集群里有没有部署 Ingress Controller。一个 Sentinel Dashboard 1.8.9 的镜像这个下面单独讲建议有自己的私有镜像仓库。Nacos 集群地址如果用 Nacos 做规则持久化以及对应的 namespace。应用客户端用的 Sentinel 版本尽量和 Dashboard 保持同一大版本避免协议兼容问题。了解自己内部规划控制台放在哪个 namespace、用什么域名访问、是否要做 HTTPS。这一步看起来没什么技术含量但恰恰是最容易返工的地方。我第一次部署的时候镜像拉下来启动没问题结果发现 Nacos 地址没传进去控制台日志里一直刷连接失败页面倒是能进可规则推送全废了。提前把环境变量和地址规划好比在那之后排查要快得多。2. 部署方案怎么定状态、副本、镜像与访问方式2.1 单副本还是多副本这个决策先做别等上线再改很多人一上 k8s 就想当然地开三个副本认为这样高可用。但 Sentinel Dashboard 在设计上有一个很关键的前提它默认把规则保存在本地内存里。也就是说如果你在 A 副本的页面上加了一条限流规则这条规则只存在于 A 的内存里B 副本完全不知道。客户端心跳上报时连接到了 BB 这边既没有这条规则也看不到对应的指标统计。所以在不改造、不接入外部数据源的情况下Sentinel Dashboard 必须单副本运行。这不是 k8s 的限制而是 Sentinel 控制台自身的状态模型决定的。那什么时候可以多副本当你把规则存储切换到 Nacos 或者其他外部配置中心以后理论上多副本读取的是同一份数据源页面展示可以一致。但即便这样客户端上报的监控数据仍然是各副本独立缓存你看到的统计视图依然可能是“分片”的多个副本之间没有聚合。基于这些我给的建议是测试环境或者中小规模直接用单副本别折腾。如果真要做高可用优先考虑把控制台接入 Nacos再评估是否需要多个副本应对页面访问压力。正常使用下一个 Dashboard 管理几百个应用问题不大单副本资源给够就行。2.2 镜像从哪里来社区镜像与自构建镜像这块是很多人会偷懒的地方。直接docker pull bladex/sentinel-dashboard:1.8.9确实省事社区里也有不少人这样用。但从生产安全角度我建议你自己构建镜像原因很简单社区镜像的 Dockerfile 和基础镜像你不可控里面加了什么变量、用的什么 JDK 版本都不透明。如果以后要定制控制台页面、加登录二次认证、接公司自己的配置中心你早晚得走源码构建这条路。自构建镜像可以把 TZAsia/Shanghai 这些环境变量直接固化在镜像里不用每次部署都写。自构建流程其实不复杂。先把源码拉下来git clone https://github.com/alibaba/Sentinel.git cd Sentinel/sentinel-dashboard mvn clean package -DskipTests构建产物在target/sentinel-dashboard.jar。然后写一个非常简单的 DockerfileFROM openjdk:8-jre-alpine RUN apk add --no-cache tzdata ENV TZAsia/Shanghai RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime echo $TZ /etc/timezone COPY sentinel-dashboard.jar /app/sentinel-dashboard.jar WORKDIR /app EXPOSE 8080 ENTRYPOINT [java, -jar, /app/sentinel-dashboard.jar]构建命令docker build -t sentinel-dashboard:1.8.9 .然后推到你自己的镜像仓库。这样得到的镜像没有任何多余的层行为完全可控。如果你不想自己构建、只是本地快速验证社区镜像也能凑合用但生产环境我真不建议直接裸用。2.3 外部访问NodePort、Ingress 还是 LoadBalancer控制台是一个 Web 页面部署完之后总得让人访问。三种方式的取舍其实很简单NodePort快速验证、临时环境用。在 Service 上直接暴露一个 30000-32767 之间的端口浏览器通过节点IP:端口访问。缺点是端口号不优雅而且如果节点有防火墙需要额外放行。LoadBalancer云环境阿里云、腾讯云等首选创建一个负载均衡器自动分配公网 IP端口可以直接用 80/443。Ingress公司内部一般都有 Ingress Controller通过域名访问最规范也方便配 HTTPS。这也是我推荐的方式。不管选哪种核心问题只有一个从浏览器到控制台 Pod 的链路要通。我在实际部署中见过不少人把 Deployment 和服务都建好了结果 Service 类型写成 ClusterIP然后浏览器访问不了以为控制台坏了其实只是没有外部入口。3. 实操用 YAML 在 k8s 里把 Sentinel Dashboard 跑起来3.1 Deployment 完整配置与逐行拆解下面这份 YAML 是我这次部署最终使用的版本做了一些精简但关键配置都在。你可以直接复制修改。apiVersion: apps/v1 kind: Deployment metadata: name: sentinel-dashboard namespace: sentinel labels: app: sentinel-dashboard spec: replicas: 1 selector: matchLabels: app: sentinel-dashboard template: metadata: labels: app: sentinel-dashboard spec: containers: - name: sentinel-dashboard image: sentinel-dashboard:1.8.9 imagePullPolicy: IfNotPresent ports: - containerPort: 8080 name: http protocol: TCP env: - name: TZ value: Asia/Shanghai - name: JAVA_OPTS value: -Ddashboard.auth.usernameadmin -Ddashboard.auth.passwordadmin123 -Dnacos.addrnacos-headless.nacos.svc.cluster.local:8848 -Xms256m -Xmx512m resources: requests: cpu: 500m memory: 512Mi limits: cpu: 1 memory: 1Gi startupProbe: tcpSocket: port: 8080 initialDelaySeconds: 30 periodSeconds: 10 failureThreshold: 20 readinessProbe: tcpSocket: port: 8080 initialDelaySeconds: 5 periodSeconds: 10 livenessProbe: tcpSocket: port: 8080 initialDelaySeconds: 30 periodSeconds: 15逐段说几个容易出问题的点。命名空间我这里用了一个专门的sentinelnamespace方便和其他系统隔离。如果你公司有统一的中间件命名空间直接放那个里面也行但注意 Service DNS 要跟着 namespace 走后面客户端配置的时候要用到。镜像imagePullPolicy: IfNotPresent。如果你是自己构建的镜像并且已经推到仓库用这个策略没问题。如果是本地 minikube 测试最好改成Never或者确保节点上有这个镜像不然会一直在拉取镜像失败的状态里打转。资源限制requests 和 limits 是我实测过比较稳的数值。Sentinel Dashboard 启动后 JVM 堆、内部缓存、页面资源加起来512Mi 内存是起步1Gi 是安全线。如果 limits 给太低会出现 Pod 被 OOMKilled 反复重启的情况。CPU 给 500m 到 1 核都可以页面操作不频繁的话 500m 足够。探针配置我全部用了 tcpSocket 没有用 httpGet因为登录页接口会返回 302 跳转探针判定逻辑容易出乌龙。tcpSocket 能 TCP 连上就代表 JVM 起来了对 Java 应用来说已经够用。startupProbe 给 20 次失败次数是为了覆盖 Java 进程启动慢的场景Nacos 连接超时不会阻塞启动但 JVM 本身初始化需要时间。JAVA_OPTS 环境变量这个要特别说明。我用的是自己构建的镜像启动命令是固定的java -jar所以可以通过JAVA_OPTS环境变量去传递 JVM 参数吗其实这里有个细节JAVA_OPTS不是 JVM 自动读取的环境变量需要启动脚本去解析它。如果镜像是用原始java -jar启动是不读JAVA_OPTS的。所以我自己构建的镜像里实际处理方式有两种。一种是改 Dockerfile 的 ENTRYPOINTENTRYPOINT [sh, -c, java $JAVA_OPTS -jar /app/sentinel-dashboard.jar]另一种更推荐直接在 Deployment 里覆盖 command 和 args这样不依赖镜像的启动脚本command: [sh, -c] args: - java -Ddashboard.auth.usernameadmin -Ddashboard.auth.passwordadmin123 -Dnacos.addrnacos-headless.nacos.svc.cluster.local:8848 -Xms256m -Xmx512m -jar /app/sentinel-dashboard.jar这比环境变量更直观谁来看 YAML 都知道启动参数是什么。你在测试的时候如果发现-D参数没生效大概率就是启动方式的问题优先检查这里。3.2 Service 和 Ingress 配置Deployment 只是把 Pod 拉起来了要让浏览器能访问还需要 Service。下面这份是 NodePort 版本apiVersion: v1 kind: Service metadata: name: sentinel-dashboard namespace: sentinel spec: type: NodePort selector: app: sentinel-dashboard ports: - name: http port: 8080 targetPort: http nodePort: 30880port是 Service 的虚拟端口targetPort指向容器的http也就是 8080。nodePort如果没指定集群会随机分配一个 30000-32767 的端口我习惯显式指定 30880方便记住和防火墙规则配置。如果走 IngressService 类型就可以改成 ClusterIP更安全apiVersion: v1 kind: Service metadata: name: sentinel-dashboard namespace: sentinel spec: selector: app: sentinel-dashboard ports: - name: http port: 8080 targetPort: httpIngress 配置如下apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: sentinel-dashboard-ingress namespace: sentinel spec: rules: - host: sentinel.example.com http: paths: - path: / pathType: Prefix backend: service: name: sentinel-dashboard port: number: 8080这里要注意两点一是pathType用Prefix并且 path 写/这样才能匹配所有路径二是 Ingress 的版本旧集群可能是extensions/v1beta1新集群用networking.k8s.io/v1写法有差异先确认集群版本再写 YAML。3.3 把 Nacos 和鉴权一起接进去这一节是整篇的精华所在。Sentinel Dashboard 1.8.9 默认的规则存储是内存重启即丢所以生产环境必须接 Nacos。常见的接入方式有两种一种是源码里的 Nacos profile另一种是通过-Dnacos.addr参数指定地址。如果你是自己构建的镜像最省事的方式就是在启动参数里加上-Dnacos.addrnacos-headless.nacos.svc.cluster.local:8848注意这里的地址要填 Nacos 在集群内的完整 DNS 地址格式是服务名.命名空间.svc.cluster.local:端口。如果你的 Nacos 部署在nacosnamespace服务叫nacos-headless那就是nacos-headless.nacos.svc.cluster.local:8848。填错地址最典型的现象是控制台页面能打开但日志里一直刷 Nacos 连接异常规则推送功能全部不可用。鉴权配置同样通过 JVM 参数-Ddashboard.auth.usernameadmin -Ddashboard.auth.passwordadmin123需要特别提醒不要只用默认密码 sentinel/sentinel。控制台一旦暴露到公网或者内网可访问默认密码等于裸奔。而且这个密码是明文存在启动参数里的如果公司有安全规范建议通过 Secret 挂载或者配置中心下发不要直接写死在 YAML 里。客户端侧的配置也要同步改。业务应用连控制台需要配置-Dcsp.sentinel.dashboard.serversentinel-dashboard.sentinel.svc.cluster.local:8080 -Dproject.nameyour-app-nameproject.name就是控制台页面上显示的应用名。这里有个常见错误是客户端在集群外控制台在集群内然后直接把 Service DNS 填进去结果客户端根本解析不了。跨网络环境的时候要用 Ingress 对外域名或者 NodePort 地址。3.4 部署、验证、连通性测试YAML 准备好以后按顺序执行kubectl create namespace sentinel kubectl apply -f deployment.yaml kubectl apply -f service.yaml kubectl apply -f ingress.yaml等一下再看状态kubectl get pod -n sentinel -o wide正常情况会出现一个 Running 状态的 Pod。然后看日志确认启动有没有报错kubectl logs -f -n sentinel deployment/sentinel-dashboard看到类似Started SentinelDashboardApplication的日志就说明 JVM 起来了。这时候再用浏览器访问 Ingress 域名或者 NodePort 地址。验证步骤可以按下面这个表格逐项检查检查项方式预期结果Pod 状态kubectl get podRunning 且 READY 为 1/1服务端口kubectl get svc8080 映射正常页面访问浏览器访问域名/端口出现登录页登录鉴权输入账号密码进入控制台主页Nacos 连接查看日志无持续报错客户端心跳业务应用日志出现 sentinel 心跳上报记录第一次执行的时候不要急着跳过中间步骤尤其是 Nacos 连通性。我见过有人把全部 YAML apply 上去以后页面也能登录就以为部署成功了直到配规则才发现推不出去回头查日志全是 Nacos 连接超时白白浪费了半天。4. 上线后最容易踩的坑问题与排查实录4.1 页面能访问但客户端连不上这个现象非常典型控制台页面正常打开、能登录但业务应用的控制台列表里就是不显示应用。先从链路排查。客户端上报用的是sentinel-transport-simple-http模块默认端口是 8719。客户端在启动时会尝试连接csp.sentinel.dashboard.server配置的地址连接成功后通过这个地址和控制台做心跳。常见原因有两个。一个是project.name没配导致控制台无法识别归属于哪个应用。另一个是地址类型不对客户端用的还是 localhost而控制台在 k8s 集群里怎么可能通。解决办法就是在客户端启动命令里显式指定-Dcsp.sentinel.dashboard.serversentinel-dashboard.sentinel.svc.cluster.local:8080 -Dproject.nameorder-service改完重启业务应用才会生效。注意transport 模块的端口 8719 如果被占用Sentinel 会自动往后顺延找空闲端口没关系只要 8080 能通就行。4.2 规则一重启就丢问题不在控制台有回群里一个朋友找我说控制台重启以后之前配的限流规则全部没了。第一反应是以为 k8s 没挂 PVC数据丢了。其实这就是 Sentinel Dashboard 默认内存存储的预期行为跟 k8s 无关。Sentinel Dashboard 1.8.9 默认情况下就是内存存储控制台进程一重启规则和部分监控数据就清零。解决这个问题只有一条路接外部数据源也就是 Nacos、Apollo 这类配置中心。接入以后规则下发链路会变成控制台写规则到 Nacos同时通知客户端监听 Nacos 中的对应配置客户端本地再应用规则。这样控制台重启也罢、Nacos 重启也罢只要配置在 Nacos 里规则就不会丢。部署层面有没有要确认的有。接上 Nacos 以后客户端也必须引入对应的数据源依赖。只改控制台不改进程规则依然没法持久化。这个坑很容易漏因为控制台日志显示推送成功但客户端没有监听 Nacos规则自然也没生效。4.3 控制台时间和打印日志差 8 小时部署完一打开页面发现监控图表的时间比当前时间慢了 8 小时。这是因为基础镜像默认时区是 UTC而我们是东八区。这个坑在自构建镜像时最容易遇到解决的办法很直接在镜像和容器两个层面同步设置镜像里我已经加了 TZAsia/Shanghai 的 ENVDeployment 环境变量里同样加上TZAsia/Shanghai。这样 JVM 和操作系统层面时区就统一了。如果之前已经部署完才发现不需要重新构建镜像直接在 Deployment 里补一个 TZ 环境变量滚动更新一次即可。4.4 多副本导致的规则互相覆盖这个坑我前面提过但值得单独拿出来说一遍。有人为了“高可用”把 replicas 改成 2然后用 ClusterIP Service 暴露。客户端连接控制台时请求会在两个副本之间负载均衡。问题就来了你在副本 A 上加了一条规则客户端下次心跳连接到副本 BB 上没有这条规则就把 A 上的规则覆盖了回去。表现出来就是规则刚配好几分钟就消失或者不同客户端看到的规则不一致。这种问题非常隐蔽因为它不是报错而是逻辑状态的不一致。排查半天可能都定位不到原因。所以再次强调在没做规则外部存储的情况下replicas 永远设置成 1。如果你确实需要多副本先把 Nacos 规则推送链路整体跑通再讨论扩展。4.5 Nacos 报错但控制台还能启动要不要管控制台启动时如果-Dnacos.addr配的不对或者 Nacos 本身没就绪控制台不会直接挂掉因为 Nacos 配置是可选的。但日志里会不断出现类似这样的异常com.alibaba.nacos.api.exception.NacosException: Client not connected很多人看到日志刷了一屏 panic其实不用慌。等 Nacos 恢复或者地址修正以后控制台会自动重新连接不需要重启。但要注意另一个方向的问题日志一直刷异常会吃掉大量网络和线程资源集群内网络环境不好时会拖慢控制台的整体响应页面卡顿、登录转圈都和这个有关。所以我的建议是要么把 Nacos 地址配到准确无误要么先用-Dnacos.addr留空或者去掉等 Nacos 环境就绪后再通过滚动更新补上。不要在日志一直刷错的状态下跑太久不然控制台后面会越来越慢。最后说点实在的把 Sentinel Dashboard 搬到 k8s本身就是一个“写 YAML 的事情”但难度都在那些不起眼的细节里镜像谁负责、鉴权怎么不写死、Nacos 地址是集群内 DNS 还是外部 IP、副本策略选什么。我这次部署下来最大的体会是单副本不是妥协在 Sentinel 的模型下规则存储没外部化之前单副本反而是最正确的选择。还有一个小技巧分享给用过的人如果团队有多套环境dev、test、prod不要把控制台部署成一套然后靠页面里的命名空间硬隔离建议每套环境单独部署一套 Dashboard各连各的 Nacos。看起来多花了资源实际上隔离效果和可排查性要好得多也不会出现规则串环境的问题。这些配置和踩坑经验都是这几天一点点试出来的。照着这个流程走一遍一小时内把 Sentinel Dashboard 1.8.9 在 k8s 里跑起来顺带把 Nacos 持久化和登录鉴权接上是没有问题的。