企业应坚持使用标准的应用程序网络模型，该模型适用于基于管理程序和裸机的工作负载以及 Kubernetes。
译自 The Black Hole That Is the Kubernetes Network，作者 Mitch Connors。
在过去的一个世纪左右，物理学中一直存在两种理论之间的紧张关系。两种理论都被证明对于预测宇宙的行为以及推进技术工程都很有价值，但它们似乎对现实的本质做出了完全不兼容的主张。
我当然指的是广义相对论和量子理论。通常，这两种理论解决的是关于宇宙的非常不同的问题——一个在最大尺度上，另一个在最小尺度上——但两种理论都汇聚在对黑洞的研究中，黑洞是信息无法逃逸的空间点。
如今，在许多企业组织中，两种企业网络启发式方法之间也存在紧张关系，这两种方法多年来都为软件公司产生了出色的成果。这种紧张关系围绕着 Kubernetes 展开。正如一家大型区域银行的云安全和网络基础设施经理所说，“Kubernetes 最终成为这个网络黑洞。”
这个类比很恰当。与黑洞一样，Kubernetes 抽象掉了传统上用于理解和控制网络的大部分信息。与量子理论一样，Kubernetes 提供了一种思考网络的新方式，但这种新的思考方式通常与现有的网络工具以及不运行在 Kubernetes 上的应用程序不兼容。但是，是什么让 Kubernetes 对现有网络如此具有挑战性？
传统上，网络工程一直与边界有关——围绕地址集绘制的分层线。每个边界都描述了一组流量规则，这些规则会跨越边界，并包括防火墙或路由器等强制机制。
图 1：传统网络使用虚拟局域网 (VLAN) 和子网边界来确保安全性。
从技术上讲，Kubernetes 在边界网络模型的边界内运行。但是一个集群通常包含数百或数千个应用程序，只占据一个边界。传统边界在集群内或多或少不被容忍。这给寻求管理 Kubernetes 和非 Kubernetes 流量的网络工程师带来了各种挑战。
图 2：Kubernetes 集群在集群内不使用 VLAN 或子网边界。
IPAM — IPv4 网络具有有限的地址空间可供使用。创建 Kubernetes 集群的一些常见指南要求为每个集群预置一个 /14（“斜杠十四”）子网，或整个私有地址范围的近 2%。毫不奇怪，网络工程师与 Kubernetes 的第一次互动是开发人员要求他们提供他们曾经发出的最大地址块，他们对此做法表示担忧。
可以通过跨集群发出重叠地址并对出站流量使用源网络地址转换来解决 IPAM 问题。但这种解决方案是有代价的，因为防火墙和网络监控工具无法再正确地归因于流量。
防火墙 — 第 3 层网络使用 IP 地址、端口和协议来识别流量流的源和目标，并应用策略来允许或拒绝该流量。Kubernetes 持续回收 IP 地址，这意味着来自给定地址的流量可能在一分钟内代表一个应用程序，而在下一分钟内代表另一个应用程序。可以针对整个集群子网编写策略，但这几乎不是大型企业需要的粒度级别。
IDS/IPS — 入侵检测和预防系统不仅监控源和目标，还监控网络流的内容，以识别和隔离入侵者。虽然 Kubernetes 本身不会干扰此过程，但使用服务网格进行加密的常见做法会使这些操作无效。
在 Kubernetes 中，服务网格可以帮助重建边界模型的概念，但每个进程都有自己的边界和强制。那么，对于在 Kubernetes 内外都有依赖关系的应用程序呢？我们如何获取黑洞外部的信息？与 Kubernetes 一样，黑洞仅占可观测宇宙中 1% 的质量，因此我们需要一个适用于这两个世界的解决方案。我们需要一个应用程序网络的标准模型。
寻求对其应用程序堆栈进行现代化的成熟企业应坚持使用应用程序网络的标准模型，该模型对基于管理程序和裸机的负载以及 Kubernetes 同样有效。通过为网络定义和策略创建一种单一语言，这些企业将看到其安全态势比试图在其网络中划分容器和虚拟机（VM）的公司有大幅改善，并且还应体验到现代化的敏捷性提升。
要了解有关 Kubernetes 和云原生生态系统的更多信息，请于 3 月 19 日至 22 日在巴黎加入我们的 KubeCon + CloudNativeCon Europe 活动。