上周凌晨两点十七分，我手机在枕头底下震到快把人掀飞。是华东区的业务告警，三个集群里的支付服务全挂了。爬起来开电脑才发现，之前图省事发的跨集群配置同步脚本，把三个集群的准入规则全覆盖成了测试环境的白名单。
就这破事，折腾到六点。
很多人聊到Kubernetes多集群管理，上来就列一堆开源工具的优劣，好像选对了工具就能一劳永逸。真不是。我们从3个集群扩到现在27个跨地域的集群，踩的坑能堆满半张办公桌。
别上来就堆集群管理面板
最开始我们集群少，三个集群分别跑用户端、内部系统、测试环境，平时登节点手动改配置都来得及。后来业务涨得快，半年就扩到11个集群，跨了三个云厂商还有两个客户本地的边缘机房，手动操作根本扛不住。
当时图省事，找了个开源的多集群管理面板，把所有集群的管理员kubeconfig全导进去，看着面板上整整齐齐的集群状态、资源使用率，觉得特别爽。结果没过半个月，面板的权限模块出了个公开漏洞，攻击者能直接拿到所有接入集群的管理员权限，我们当时连夜把所有集群的凭证全轮换了，就差给安全团队发锦旗。
所有接入多集群管控端的kubeconfig，必须做权限最小化裁剪，绝对不能直接用集群管理员的凭证。比如给面板的凭证，只保留读取节点、Pod状态的权限，连修改ConfigMap的权限都不给，就算面板被攻破，攻击者也碰不到生产业务的核心配置。
还有之前踩过的配置同步的坑。一开始为了省事儿，写了个简单的脚本，只要在中心仓库改了配置，就自动同步到所有匹配标签的集群里。那次凌晨的故障，就是因为脚本没加配置校验的环节，测试环境的白名单规则，被同步逻辑匹配到了生产集群的标签，直接把生产的准入规则给覆盖了。
权限边界比功能堆叠重要一百倍
上次那个手滑改配置的事之后，我们花了整整一周把整个权限体系拆了。
之前的权限逻辑特别简单：研发拿所有集群的只读权限，运维拿所有集群的写权限，觉得这样效率高。现在想起来都后背发凉。一个刚入职的研发，只要手滑选对了同步规则，就能把整个生产环境的配置给改了。
我们现在把所有集群按信任域划成了三类：客户本地的边缘集群、区域核心的业务集群、异地的灾备集群。每一类集群的凭证，都存在独立的凭证管理模块里，跨模块的访问必须走双人复核。多集群的权限体系必须和集群的信任域绑定，跨域的权限申请必须走双人复核流程。比如边缘集群的凭证，只有负责边缘运维的两个同事能申请调用，业务研发连这个模块的入口都看不到；核心业务集群的写权限，只有核心运维团队能拿，其他团队的人就算提了申请也会被打回来。
之前我们把所有集群的日志都往中心的ELK集群导，结果有次中心ELK的磁盘打满，日志通道堵了三个小时，连带着边缘集群的业务都因为日志写不出去卡了壳。后来干脆把日志留存的职责还给每个集群自己，只有触发告警的异常日志，才会上报到中心的观测平台。算下来，中心的日志存储成本降了60%，还再也没因为日志的事影响过业务。
别迷信所谓的统一控制面
说实话，我之前也觉得统一控制面是多集群管理的终局。一个入口管所有集群，统一做调度、统一做配置、统一做观测，听着就特别美好。
真落地的时候才发现根本不现实。我们有几个客户的集群是跑在境外的，按照合规要求，集群的API流量根本不能传到国内的管控中心，连统一控制面的网络打通都过不了合规审计。那些吹统一控制面能管几百个集群的销售方案，你让他自己去对接下等保三级和跨境数据合规的要求试试，能过审就算他赢。
现在我们的方案特别“土”：每个集群保留完全独立的控制面，管控端只做单向的状态拉取，不做反向的全量配置推送。也就是说，管控端能看到所有集群的节点状态、Pod运行情况、告警信息，但是要往集群里推配置，必须走每个集群本地的GitOps流程，每个集群的配置仓库是独立的，管控端连修改仓库的权限都没有。
真的没必要。
之前我们为了图方便，把所有集群的kubeconfig都存在共享网盘里，结果有次网盘被钓鱼链接攻破，泄露了五个集群的凭证，紧急轮换花了整整两天。现在所有的kubeconfig都是临时生成的短期凭证，有效期只有15分钟，根本不可能被批量导出。
现在算下来，我们的多集群管控系统没有什么高大上的AI调度、跨集群资源弹性的功能，但是稳了。告警响应时间从之前的平均40分钟，降到了8分钟，再也没出现过凌晨被喊起来排配置同步故障的事。
毕竟跑生产的系统，稳比什么都重要。花里胡哨的功能，等真的踩过两次凌晨三点的告警再考虑也不迟。