/tags/kind/ Recent content in kind on Hugo -- gohugo.io en Wed, 20 May 2026 10:00:00 +0800 /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/full-stack-flag-upgrade-order/ Thu, 30 Apr 2026 10:00:00 +0800 /posts/full-stack-flag-upgrade-order/ 本文是 《Spring Boot 3.5 + Java 25 + React：在 K8s 里跑通一套跨链路 OpenFeature flag》 的续篇，聚焦三个场景中的第三个——全链路共享 flag 在升级过程中的顺序选择。 对应的 demo 代码仓库：sb3-k8s-hot-reload（私有）。 从一篇文章引发的真实问题讲起 上一篇写完后，有人在评论区提了一个非常实际的问题： “你说的全链路 flag（full-stack shared flag）确实好理解——后端在 gateway 评估，前端通过 /experience/shared-flags 拿到同样的值。但实际加一个新 flag 的时候，先改哪一边？” 这个问题戳中了全链路 flag 最微妙的地方。 假设你的团队要上线一个"会员折扣算法 v2"功能： 后端：pricing-service 要用新算法计算价格 前端：UI 要在会员用户上展示"v2 折扣体验" 目标：u-vip-* 用户看到新体验，其他用户保持原样 先升级前端还是先升级后端？ 这不是一个语义问题，这是一个部署时序问题。部署时序错了，用户就会看到不一致的行为。 三种升级路径的风险拆解 路径一：前后端同时发布（“理想情况”） 前后端同时发布在理想状态下看起来很干净，但有几个现实坑点： CI/CD 不同步：后端在 order-service/，前端在 ui/，通常走不同的 PR、不同的 review、不同的 merge。让两个独立流水线在精确的同一分钟上线几乎不可靠。 回滚不对称：如果上线后 10 分钟发现后端有 bug，你 kubectl rollout undo 回滚了后端，前端已经在跑新逻辑——此时前端看到的行为和后端完全脱节。 A/B 验证困难：你想先让 10% 用户尝鲜，但 flag 还没在 flagd 里配好（或者配了但 defaultVariant 不是目标值），新前端就已经在跑了。 所以"同时发布"更多是一种理想态，不是你可以依赖的策略。 /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/spring-boot-openfeature-flagd-cross-stack/ Sun, 26 Apr 2026 15:00:00 +0800 /posts/spring-boot-openfeature-flagd-cross-stack/ 本文对应的 demo 项目：sb3-k8s-hot-reload（私有）。代码组织在 gateway/ order-service/ pricing-service/ ui/ k8s/ scripts/ 下，一条 ./scripts/e2e-demo.sh 从 kind 集群创建到端到端验证全跑完。 起点：一个朴素的约束 接到的题目是这样的： 在 Spring Boot 3.5 + Java 25 + Kubernetes（kind 本地）里，不用 Spring Cloud Config Server，不用 Netflix 套件（Eureka / Zuul / Ribbon / Hystrix）的前提下，验证一下"运行时配置变更不重启服务"这件事到底有哪些解、各自取舍是什么。后续要能支持 feature flag。 约束被排除的两块是有理由的：Config Server 在 K8s 原生场景里往往不再是首选（ConfigMap/Secret 已经在那里），Netflix 套件在 Spring Cloud 2023 起官方也已停止维护。但 Spring Cloud 不等于 Spring Cloud Config——spring-cloud-context、spring-cloud-kubernetes 这些仍然在维护，并且在 K8s 场景里依然是常见选择。 把约束精确化之后，问题就清晰了：在允许 spring-cloud-context 的前提下，K8s 上把"配置热加载"和"feature flag"分别做对，应该选什么。 热加载方案的选型矩阵 我把 2026 年还能找到、也比较贴近这个题目的可选项先压成一张表： /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： /posts/kubernetes-vpa-inplace-resize/ Thu, 09 Apr 2026 10:00:00 +0800 /posts/kubernetes-vpa-inplace-resize/ 背景 如果你在 Kubernetes 里用过 Vertical Pod Autoscaler（VPA），大概率遇到过一个很现实的问题：推荐值有了，但真正生效时，Pod 先被驱逐，再由控制器拉起新实例。 对无状态服务来说，这种做法还能接受。但对数据库、消息队列、长任务、状态服务，甚至一些对尾延迟敏感的 API 服务来说，重建 Pod 本身就是一次明显的扰动。 如果你还没有把 requests / limits、QoS 和 throttling 这些基础概念串起来，可以先看我之前的这篇：Kubernetes CPU 资源管理与 QoS 机制。 Kubernetes 1.35（2025 年 12 月发布）把这个能力补齐了： In-Place Pod Resize 已经 GA VPA 的 InPlaceOrRecreate 更新模式进入 beta 也就是说，VPA 现在可以优先尝试在原地修改运行中 Pod 的 CPU 和内存资源，而不是直接把 Pod 赶走。 先区分三件事 很多讨论会把 HPA、VPA 和 in-place resize 混在一起，其实它们解决的是三层不同的问题。 能力 调整对象 会不会重建 Pod 典型用途 HPA 副本数 不一定 跟随流量扩缩容 VPA 单个 Pod 的 requests / limits 旧模式通常会 让资源更贴合真实负载 In-Place Resize 运行中 Pod 的资源定义 目标是不重建 降低垂直调容带来的扰动 一句话总结： /posts/java25-k8s-jvm-config/ Wed, 11 Mar 2026 12:00:00 +0800 /posts/java25-k8s-jvm-config/ Akamas 发布的 The State of Java on Kubernetes 2026 提出了一个让人不安的论断：很多跑在 Kubernetes 上的 Java 应用，默认配置可能正在悄无声息地浪费资源、降低性能，甚至让服务在压力下更容易失稳。 联系到最近我碰到的生产环境上的 oom 和 CPU 限制问题。于是我用 Java 25 + Spring Boot 3.5.1 + kind 本地集群搭了一套实验环境，用真实数据来验证这些说法。 结论先说：按这次实验结果看，这些担心大多都有依据，而且修复成本并不高。 实验设计 用一个 Spring Boot 应用暴露两个压测端点： GET /stress/memory?mb=N：分配 N MB 短生命周期对象，触发 GC GET /stress/cpu?seconds=N：持续计算质数 N 秒，消耗 CPU k6 混合打压（60% 内存请求 + 40% CPU 请求，10 VUs，60 秒），通过 Spring Actuator 采集 JVM 指标。 基准容器规格：1c / 1Gi，4 个场景： 场景 JVM 参数 资源 验证目标 01-default 无 1c / 1Gi 默认配置基准 02-heap-fixed MaxRAMPercentage=75 1c / 1Gi 修复堆大小 03-cpu-throttle MaxRAMPercentage=75 250m / 1Gi CPU 节流影响 04-pod-small MaxRAMPercentage=75 0.