/tags/devops/ Recent content in devops 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 的所有能力，而是验证一套更窄的接入模型： /reading/github/kubernetes-best-practices/ Sat, 16 May 2026 10:00:00 +0800 /reading/github/kubernetes-best-practices/ 原文链接 diegolnasc/kubernetes-best-practices 前言 这份 GitHub 仓库是一份覆盖面相当广的 K8s 实践手册，从集群基础配置、安全、网络到 GitOps 都有涉及，对于想系统梳理 K8s 知识体系的工程师来说很有参考价值。 但该仓库最后更新停留在较早期的内容，遗漏了 K8s 近几个版本中已经稳定（或接近稳定）的重要特性，最典型的就是 Gateway API。本文以仓库内容为骨架，加入我自己的实践理解，同时补充这些新特性，力求给出一份更完整的参考。 一、集群基础：规划要在最前面 网络 CIDR 规划 集群建好之后最难改的就是网络。在创建集群之前必须认真计算三块地址段： 节点子网：根据最大节点数预留，留足余量 Pod CIDR：每个节点 maxPods 数量决定每个节点需要多大的子网块。例如每节点最多 110 个 Pod，则每节点需要 /25（128 个地址），256 个节点就需要 /17 Service CIDR：独立规划，避免与内网路由冲突 对于托管 K8s（GKE/EKS/AKS），云厂商通常会额外保留部分地址，规划时要读清楚文档，留出 1.5~2 倍余量。 私有集群 节点和 API Server 不应暴露在公网。控制面通过私有端点访问，节点出流量经过 NAT 网关。这一点在公有云环境下几乎是标配，但在自建集群（K3s/kubeadm）里容易被忽视。 Infrastructure as Code 所有集群配置（节点池、网络、IAM）都应该用 Terraform / Pulumi 管理，而不是在控制台手点。没有 IaC 的集群，两周后就没人知道某个配置是怎么来的。 二、安全 Pod Security Standards 替代 PSP Pod Security Policy 在 K8s 1.21 被废弃，1.25 彻底移除。现在的替代方案是 Pod Security Admission（PSA），通过 Namespace 标签控制： /posts/tmux-remote-server-best-practices/ Sun, 12 Apr 2026 14:00:00 +0800 /posts/tmux-remote-server-best-practices/ 问题背景 在远程服务器上部署模型或运行长任务时，最让人焦虑的就是 SSH 断连导致命令被杀： 部署 vLLM 服务器，模型加载需要几分钟，突然网络抖动，进程直接中断 跑 benchmark 测试，笔记本合上盖子，测试直接失败 在咖啡厅或高铁上运维，网络不稳定，随时可能中断关键操作 这个问题的根源是：SSH 断连会发送 SIGHUP 信号，终端下的所有子进程都会被终止。 一个常见做法：用 tmux 在服务器上创建持久化会话。 即使你断开了 SSH，tmux 会话里的命令仍然在后台继续运行。 什么是 tmux？ tmux（Terminal Multiplexer）是一个终端复用器，允许你在单个终端窗口中创建多个会话、窗口和窗格。它的核心价值在于： 会话持久化：会话运行在服务器端，不依赖你的 SSH 连接 网络韧性：WiFi 断线、VPN 断开、笔记本睡眠，都不会影响服务器上的进程 多窗口/多窗格：可以在一个终端里同时运行命令、查看日志、监控资源 这与 Screen 类似，但 tmux 在今天的资料和使用案例里更常见一些。 一些外部实践参考 tmux 在 ML/DevOps 场景里已经很常见。下面是一些我阅读过、也觉得有参考价值的材料： Weights & Biases（W&B）官方教程 W&B 在其 ML 从业者 tmux 教程（2022）里提到了一些做法： 为每个实验创建命名会话（tmux new -s <experiment_name>） 使用 Ctrl+B, d 安全分离，尽量避免直接关闭终端 配置扩展的回滚缓冲区（history-limit 50000）保留训练日志 在状态栏显示 GPU/服务器指标 tmux-trainsh：GPU 工作流自动化工具 tmux-trainsh（2026）是一个专门为 GPU 和远程服务器设计的工作流运行器。它的核心理念是 “terminal-first”： 用 Python 编排远程任务，在 tmux 会话中执行 支持在 Vast. /posts/debian-proxmox-power-optimization/ Sun, 29 Mar 2026 12:00:00 +0800 /posts/debian-proxmox-power-optimization/ 我的 Homelab 跑在一台迷你主机上：AMD Ryzen 5 5600H（6 核 12 线程，笔记本 U），上面装的是 Proxmox VE，里面只开了一台 K3s 虚拟机。最近摸机箱的时候明显感觉烫手，一查 CPU 温度常驻 72°C，决定好好优化一下。 现状诊断 先 SSH 上去摸底。我的 Proxmox 宿主机在 Ansible inventory 里已经配好了，直接用 ad-hoc 命令采集信息： ansible proxmox -m shell -a 'lscpu | grep "Model name"; sensors; free -h; qm list' 诊断结果比我预想得更激进一些： 项目 现状 问题 CPU Governor powersave 已经是省电模式，没问题 Turbo Boost 开启 CPU 频率飙到 3GHz+，主要热源 内存 13GB 物理 / VM 分配 15GB 严重超售，swap 占了 3.9GB KSM (ksmd) 默认 20ms 扫描间隔，占 5% CPU 因为内存超售疯狂做内存去重 ASPM default PCIe 链路没有启用最省电模式 lm-sensors 未安装 之前甚至没法看温度 三个主要热源很清晰：Turbo Boost 没关、VM 内存超售导致 swap 和 KSM 双重 CPU 开销、powertop 没做自动调优。