用AI来评估Kubernetes扁平网络模型到底是怎么在大规模环境下把队伍给困住的？文章给出的说法是，只要平台变大了，这模型就会因为调试太难、合规压力太重还有改不了东西，直接就不灵光了。Reza Ramezanpour在那篇Why flat Kubernetes networks fail at scale的文章里就讲了，要想解决这烂摊子，就得把安全层级给加进去，并且搞个策略试运行模式。这么搞的好处就是让网络行为变得能预测、能审计，也更有弹性，好给云原生平台撑腰。 Kubernetes网络确实挺强大的，那种灵活性能让开发团队在一个命名空间里把几百个微服务连起来。但麻烦来了，系统一旦发展起来，这种灵活性反而容易把原本整齐的设定给搞成一团乱麻。对很多公司来说，网络这块儿就是最早出岔子的地方。工程师天天忙着查连接问题，安全团队也在拼命设全局控制。平台架构师呢，就得死磕证明自己合规这件事。这些乱七八糟的麻烦，其实都指向一个共同原因：那种没法扩展的扁平网络安全模型根本不管用。 Kubernetes网络策略本来是给团队控制流量的工具，但默认情况下它全是在同一个平面上运行，也没有什么好的优先级管理办法。“策略一多，根本就不知道改了之后会发生啥。”这种做法在小公司或者单团队搞的集群里还凑合，但放到大公司多团队的环境里，马上就有大风险。扁平模型下，安全性全靠例外情况来管。想保护关键服务？通常就得把每个允许的连接都列出来，还得祈祷没有别的东西把它给覆盖了。策略越来越多以后，要想预测改动的结果就越来越难了。要是没有明确的优先级规则或者验证工具，排查故障简直就像在玩侦探游戏。大家都在那儿问：哪个策略先跑？哪个规则真管事？最近的改动是不是把安全给弄崩了？ 这些问题直接把日常工作给搅和了。大家都不敢肯定自己问的问题能回答上来的时候，改东西就变得特别吓人。策略就会被压下来、被规避或者保守地部署着。时间一长就会导致策略漂移、技术债堆积还有攻击面变大。审计员那边又是另外一道坎儿。他们非得看见全局的安全规则没法被应用层的配置给盖住才行。扁平网络这东西要想展示出来太难了，最后只能让审计变得很烦琐，有时候甚至得在集群外面再额外干一堆活儿。结果怎么样？改不动东西了呗。网络变成了瓶颈而不是创新的基础，大家的压力都跟着变大了。 那到底该怎么办呢？答案其实挺简单：引入层级结构。安全层级就是给网络策略定了个顺序和分工。策略不再是在同一平面上乱打一架，而是根据优先级和目的分组去评估的。常见的分层法有这么几种：平台层主要管集群服务需要的连通性；安全层负责强制执行控制；应用层让开发人员去管理服务通信；数据或基础设施层专门用来保护像数据库这种高价值的东西。 有了层级以后效果很明显。不同的团队就知道该怎么管自己那一层的策略了。意图也变得很清晰了，出了意外覆盖的概率也就小了很多。全局规则能得到统一执行的同时，各个团队在自己的边界里还是能自主决定的。这跟零信任原则也挺搭的——哪怕是在集群内部访问资源也是明确授予的还要持续评估的。 光有层级还不够用啊。大家还得有个安全的办法来测试新策略。以前在传统网络里通常是先断了流量才去验证规则，但现在这招在云原生环境里行不通了。大家越来越流行用策略模拟或者试运行模式来干这事儿。策略先别强制执行，只是在那里部署着。系统观察着实时的流量看看哪些本该被允许或者拒绝的事情发生了没有。这就能让大家： 用实际的工作负载安全地去验证新规则 拿着真实的数据去优化策略 在平台、安全和开发团队之间早点开始协作 通过把验证工作提前到生命周期的早期阶段去做组织就能减少中断加快安全更新的速度。 这次脱离扁平网络的做法其实也反映了云原生圈子里的一个大趋势：平台越大越复杂大家就越想要明确的分工、跨环境的可预测行为还有那种能支持意图驱动配置的工具了。分层和试运行测试这种模式现在正变得越来越标准。它们不光能用在一个工具上还能在多个环境里通用呢。 当集群的规模变得很大而且团队又松散的时候扁平网络模型就不行了。现在的情况肯定不是当初那样了。“咱们的目标不是要把创新给拖慢了。”咱们的目标是要让网络的行为变得可预测、能审计还有弹性强。为了能大规模安全地用Kubernetes平台的人都在通过层级结构和安全变更机制重新把秩序给加回来呢。