/tags/mirrord/ Recent content in mirrord on Hugo -- gohugo.io en Thu, 21 May 2026 11:00:00 +0800 /posts/mirrord-vscode-impersonator-ws403/ Thu, 21 May 2026 11:00:00 +0800 /posts/mirrord-vscode-impersonator-ws403/ 我前一篇 《给 mirrord 开发者按 namespace 签发 kubeconfig》 写完之后，第一次用 VS Code 的 mirrord 扩展真接到那套 demo 集群——结果在 agent 起来之后立刻被一个 403 Forbidden 卡住。这篇是那次排查的复盘：从 IDE 报错一路追到 Kubernetes impersonation 鉴权链路上一个我之前不知道的细节，以及最后那条最小修复怎么落到 demo 里。 相关代码都在 meirongdev/mirrord-demo 的 feat/rbac-mirrord-governance 分支上。修复对应的 commit 是 6e44011。 一、出发点：用 VS Code 扩展跑这套 demo 前一篇 demo 用 bash run-mirrord.sh -- java -jar ... 在命令行里直接跑通。但团队里大部分人是从 VS Code / IntelliJ 直接 launch / debug 进程的，所以我得验证一遍：用 mirrord 的 VS Code 扩展，配合 alice 的 scoped kubeconfig，能不能跑出和命令行一样的效果。 流程很简单： 在 VS Code 里装 mirrord 扩展。 /posts/onboarding-developers-to-mirrord/ Wed, 20 May 2026 10:00:00 +0800 /posts/onboarding-developers-to-mirrord/ 我们的服务部署在 K8s 环境里，要调试一个服务，需要改代码、提 GitLab MR、跑 Jenkins 构建、ArgoCD 部署，整个流程非常慢。而且如果多个人要调试同一个服务的不同 feature，环境占用就会是个问题。为了提升调试效率，我们引入了 mirrord OSS——它能绕过整个 CI/CD 链路，直接在本地进程里接入集群服务。但 mirrord OSS 不带权限模型——直接发 cluster-admin 不现实。这篇我从 DevOps 角度走一遍：怎么给一个开发者签发 kubeconfig、按 namespace 给他绑 RoleBinding、验证授权真的生效。 团队层面「几十个人来来去去怎么管」是另一个更通用的 K8s 用户管理问题，不属于 mirrord 特有，我会另起一篇。 这篇文章对应的可运行 demo 放在 GitHub：meirongdev/mirrord-demo，对应 commit 是 6e44011。如果只是想看脚本细节，可以直接看 repo 里的 rbac/ 目录。 配置形态里有一处不直观的地方：除了按 namespace 绑的 RoleBinding，每个开发者还要额外绑一条只含 1 条规则的 cluster-scoped ClusterRoleBinding。这条来自 K8s impersonation 鉴权的硬约束，单独追到的踩坑过程另起一篇 《VS Code 跑 mirrord 撞上 WebSocket 403》。本文直接采用修复后的形态。 一、这次 demo 想解决什么 我自己在团队里推 mirrord 时，技术上没有大问题；卡住的反而是「给开发者发什么 kubeconfig」。mirrord OSS 不会替我们解决这件事，所以真实团队里通常还会多出几个治理问题： 开发者不应该拿 cluster-admin kubeconfig。 新发的 kubeconfig 默认最好没有任何业务 namespace 权限。 授权应该按 namespace 做，而不是一发就能扫整个集群。 撤销访问时，最好只删一条授权关系，不重新签发所有凭据。 管理员需要一套可重复验证的脚本，证明 allow/deny 都按预期工作。 所以这次 demo 的目标不是介绍 mirrord 的所有能力，而是验证一套更窄的接入模型： /posts/mirrord-local-k8s-debug/ Tue, 28 Apr 2026 12:00:00 +0800 /posts/mirrord-local-k8s-debug/ 调试 Kubernetes 里的服务有多烦？本地改一行代码，要走完 mvn package → docker build → kind load → kubectl rollout restart 这一套，少则一两分钟，多则好几分钟。而且这还只是单服务，如果服务依赖同命名空间里的 MySQL、Redis 或者其他微服务，kubectl port-forward 也救不了你——端口转发不能同时暴露多个服务的网络环境，更没法让你的本地进程「假装」是 Pod 本身。 mirrord 解决的正是这个问题。这篇文章通过一个完整的 Demo 项目，带你从零走完「本地进程通过 mirrord 接入 k8s 集群调试」的完整流程。 问题：开发者与 K8s 之间的摩擦 常见的几种调试方案，各有明显局限： 方案 痛点 kubectl port-forward 只能转发单个端口，进程本身感知不到集群的服务发现和环境变量 Skaffold / Tilt 热重载 仍然需要 build → load → rollout，只是自动化了步骤，没有消除延迟 在 Pod 内直接 exec 调试体验差，IDE 断点无法接入 远程 JVM debug + port-forward 可以断点，但进程还是跑在集群里，不是本地环境 理想状态是：本地用 IDE 正常启动应用，但进程的网络、环境变量、文件系统全都来自集群。 这就是 mirrord 的设计目标。 mirrord 是什么？它怎么工作？ mirrord 是 MetalBear 开源的一个开发者工具（GitHub），核心思路是： /posts/kind-k8s-lab-local-cicd-mirrord/ Wed, 15 Apr 2026 10:00:00 +0800 /posts/kind-k8s-lab-local-cicd-mirrord/ 这是一篇本地开发环境的整理笔记。 我在本地维护一个 Maven 多模块的 Spring Boot 微服务项目 meirongdev/shop，服务数量十几个，日常都跑在 Kind 起的本地 Kubernetes 上。起初只要 kind create cluster + docker build + kind load docker-image + kubectl apply 就够用了，但随着模块变多，这套最朴素的链路开始变慢：每次全量 build、全量 load、只改一个服务也要 redeploy 才能验证。 这篇文章不谈企业级流水线，只记录一下在一台开发机上，我为了解决本地开发中的各种“慢”和“烦”，都选了哪些工具，以及每个工具带来的 tradeoff。 1. 基础底座：如何在本地低成本跑 K8s？ 问题： 本地需要一个 K8s 环境，但资源占用不能太大，且要能方便地模拟多节点和不同的 K8s 版本。 我的做法：Kind (Kubernetes in Docker) 几个本地 Kubernetes 可选项中（Kind、Minikube、k3d、Docker Desktop），我选了 Kind： 低开销： 纯 Docker 容器起 node，资源占用比 Minikube 的 VM 小得多。 高仿真： 节点数、版本可配置，和真实 K8s 的差距相对可控。 镜像直入： kind load docker-image 把本地镜像直接塞进节点，不需要额外推 registry。 Tradeoff：