文章指出扁平的 Kubernetes 网络安全模型在大规模应用时会因调试困难、合规压力和变更僵局而失效。为解决此问题，建议引入安全层级和策略试运行模式，以提升网络的可预测性、可审计性和弹性，从而支持云原生平台的发展。
译自：Why flat Kubernetes networks fail at scale
作者：Reza Ramezanpour
重新思考云原生平台的网络安全层级
Kubernetes 网络功能强大。其灵活性使团队能够连接跨命名空间、集群和环境的数百个微服务。但随着平台的发展，同样的灵活性可能会将一个整洁的设置变成一个混乱、脆弱的系统。
对于许多组织来说，网络是首先出现摩擦的地方。工程师们努力调试连接问题。安全团队努力执行全局控制。平台架构师感受到证明合规性的压力。而这些问题大多数都源于一个共同的根本原因：无法扩展的扁平网络安全模型。
扁平网络的局限性
Kubernetes 网络策略 为团队提供了一种控制工作负载之间流量的方法。默认情况下，所有策略都存在于同一级别，没有内置的可管理优先级。
“随着策略的增加，越来越难以预测做出更改时会发生什么。”
这在小型、单团队集群中运行良好。但在大型、多团队环境中，它很快就会变得有风险。
在扁平模型中，安全性是通过例外而不是强制来管理的。保护关键服务通常意味着列出每个允许的连接，并希望没有其他内容意外覆盖它。随着策略的增加，越来越难以预测做出更改时会发生什么。
如果没有明确的优先级规则或验证工具，故障排除就变成了一项侦探工作。团队不断追问：哪个策略首先运行？哪个规则实际生效了？最近的更改是否破坏了安全控制？
变更僵局与合规压力
这些问题直接影响日常运营。
当团队无法自信地回答“如果我应用此策略会发生什么？”时，变更就会感到有风险。策略会被延迟、避免或保守地应用。随着时间的推移，这会导致策略漂移、技术债务和更大的攻击面。
审计员增加了另一层压力。他们希望证明全局安全规则不会被应用程序级别的配置覆盖。扁平网络使得这很难展示，导致审计麻烦，有时还需要在集群外部进行额外的工作。
结果呢？变更僵局。网络成为瓶颈，而不是创新的基础，减缓了交付并给每个人增加了压力。
通过安全层级引入结构
解决方案原则上很简单：引入层级。
安全层级为网络策略提供了明确的顺序和职责分离。策略不再在同一级别上相互竞争，而是根据优先级和目的进行分组和评估。
常见模式包括：
- 平台层 – 集群服务所需的连接性
- 安全层 – 强制性控制，例如出站限制或拒绝规则
- 应用层 – 开发人员管理的服务通信规则
- 数据或基础设施层 – 保护数据库等高价值工作负载
安全层级的实际实现，展示了不同团队如何管理特定的层级和策略以保持零信任姿态。
层级使策略意图清晰，并减少意外覆盖。全局规则得到一致执行，同时团队在定义的边界内保持自主权。这种方法也符合 零信任原则，即即使在集群内部，访问也是明确授予并持续评估的。
在不破坏现有功能的情况下测试更改
仅有层级是不够的。团队还需要安全的方法来测试新策略。
在传统网络中，验证通常在流量中断后，也就是强制执行后才进行。在云原生环境中，这种方法不再可接受。
一种日益增长的最佳实践是策略模拟或试运行模式。策略在不强制执行的情况下部署。系统观察流量并报告哪些本应被允许或拒绝。
这使团队能够：
- 针对实时工作负载安全地验证新规则
- 根据真实数据优化策略
- 在平台、安全和应用程序团队之间更早地协作
通过将验证提前到生命周期早期，组织可以减少中断并加速安全变更。
云原生安全的更广泛趋势
摆脱扁平网络反映了云原生社区更广泛的转变。
随着 平台变得更大更复杂，团队正在寻找：
- 明确的职责分离
- 跨环境的可预测行为
- 支持意图驱动配置而非手动协调的工具
层级和试运行测试正在成为标准模式。它们不局限于单一工具，并且在多个环境中都很有用。随着组织采用 AI 工作负载、混合部署和全球规模的集群，它们变得尤为重要。
Kubernetes 网络的未来走向
当集群规模较小且团队紧密耦合时，扁平网络模型运行良好。现在情况已不再如此。
“目标不是减缓创新。目标是使网络行为可预测、可审计和具有弹性。”
为了大规模安全地运行 Kubernetes，平台团队正在通过层级和安全变更机制重新引入结构。目标不是减缓创新。目标是使网络行为可预测、可审计和具有弹性。
随着云原生生态系统的不断发展，这些模式将把网络从风险源转变为现代平台的可靠基础。
