服务网格优化运营中心权限配置，耗时降70%

　　去年八月，我在运营中心权限配置台里蹲着，手边泡的茶都凉透了——第七次点开那个灰掉的“同步策略”按钮，弹窗又卡在 loading 三秒后直接 502。陈工站我身后看屏幕，突然说：“你试过把 service-mesh-ops 这个 namespace 的 rbac 权限删了重挂吗？”

　　我原以为是 etcd 集群压力大，结果抓包发现连 API server 的 request header 都没发出去；再查 audit log，根本没这条调用记录。反正就卡在 istio-operator 到 k8s-apiserver 中间那层 webhook 里，像被钉住的钉子。

　　后来才发现是运维组上周给所有控制平面加了个新的 admission controller 插件，叫 authz-strict-mode（他们起名向来这么直白），默认开启，且不认老版 ClusterRoleBinding 的 subjects 字段里带 serviceaccounts 的旧写法。它自己也不报错，就默默 reject——日志里只有一行 “rejected by authz-strict-mode: missing required label ‘mesh-role’”，而我们所有服务账户压根没打这个 label。

　　我把这行 log 复制粘贴到钉钉群里，刚敲完“这个 label 是谁加的”，李姐直接语音进来：“哦那个啊，测试环境跑通了我们就上了，没文档——你们配权时不是一直用模板吗？”

　　模板？我翻出上个月导出的 YAML 模板，第七行注释写着“v2.4.0+ 必须加 mesh-role=ops-center”，但我当时看的是第八次更新前的版本。打印机正好在隔壁工位嗡嗡响，我听见纸张卡住了，但没过去管。

　　改法其实简单：批量给所有 serviceaccount 加 label，再 reload rbac。执行脚本跑完，同步耗时从原来的二十来分钟，缩成六分钟——算下来刚好降了七十。监控图上那根蓝线哗一下塌下去，快得像没发生过事。

文章配图，仅供参考

　　现在点“同步策略”按钮，loading 走两秒，直接 green check。陈工拍我肩说“可以啊”，我没回，盯着屏幕右下角的时间戳——2023年8月17日16:22:07，比上次成功快了十四分三十三秒。但我不知道这十七秒省在哪，就像不知道昨天工位上多出来的那盆绿萝是谁放的。

　　服务网格优化运营中心权限配置，耗时降70%，这事站得住的地方就是优胜劣汰——淘汰掉那种觉得“测试过了就行”的习惯，也淘汰掉我自己写脚本时漏掉 label 校验的那半行 if。至于那套老模板……它还在 GitLab 里躺着，last commit 是王磊，日期是五月十二号。

　　有谁碰到过 operator 缓存 CRD schema 不刷新，又没任何 error log，连 kubectl rollout restart 都没用的情况吗？

（编辑：航空爱好网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!