适用于 NetOps 的容器口语翻译器

有时候，来自集装箱领域的专业术语会让你头晕目眩。 相关解决方案（服务网格、编排器、注册表）提供的每个新功能或特性似乎都需要一个新的术语或短语。 这句话对于 DevOps 来说通常很有意义，但对于 NetOps 来说却会引起困惑和迷茫的表情。

有点像当我问最近的起泡器在哪里时你所做的那样。 你称它为喷泉。 在威斯康星州，我们称之为起泡器。 相同之事，不同之用。

事实证明，许多与内部和多云场景中扩展容器有关的“新”功能和特性实际上只是 DevOps 所称的起泡器的喷泉。 随着容器继续有增无减地进入主流，这种口语冲突可能会与 NetOps 产生摩擦。 即使容器集群在生产中保持着类似于隔离的微云的状态，但仍然会存在与企业网络的接触点，而 NetOps 仍会继续控制这些接触点。 而且，NetOps 和 DevOps 必须共同努力才能在多云世界中安全地扩展这些集群。

入口控制器

• 正如已经指出的，“入口控制器”一词为第 7 层负载均衡（内容交换、内容路由等）赋予了新的意义。 入口控制器是第 7 层（HTTP）感知代理，它将请求路由到容器集群内的适当资源。  NetOps 在网络中使用的 HTTP 代理与作为容器集群入口点的 HTTP 代理之间的显著差异在于，入口控制器必须具有容器感知能力。 我所说的“容器感知”是指它根据容器环境中发生的变化（特别是描述入口如何路由传入请求的资源文件的变化）自动配置和管理。

延迟感知负载平衡

• 听起来很酷很新鲜不是吗？ 但是当你拉开和服时，NetOps 会坚定地点头，因为他们发现这只不过是利用“最快响应”负载均衡算法而已。 其目的是通过“将流量从缓慢的实例转移”来提高应用程序的性能。 之所以这样说，是因为一般来说，容器编排器使用的本机负载均衡算法是冷漠的。 循环算法几乎是标准，我们知道，如果您试图优化性能，它就应该是您最后选择的算法。 考虑到满足单个客户端请求而进行的每个微服务-微服务调用都会增加自身的延迟，能够根据最佳性能路由请求非常重要。

多集群 Ingress

• 首先要说的是，这听起来比该行业近二十年来一直使用的术语酷多了。 本质上这就是 GSLB（全局服务器负载平衡）。 是的，我知道你很失望，但在本质上这就是多集群入口所做的事情。 你采用一个入口控制器并在其周围添加一些全局流量管理的优点，瞧！ 您已获得多云配置中用于容器集群的 GSLB。 我投票支持在 NetOps 方面用这个术语取代 GSLB，因为它听起来更令人印象深刻。

这些并不是唯一出现的术语，也不是最后一个。 就 DevOps 所包含的“网络内”的功能和能力而言，它们是最相关的。 其中一些在进入生产环境（如多集群入口）时需要 NetOps 的关注，而其他则不需要——容器环境内的延迟感知负载均衡可能仍然是 DevOps 的职权范围，尽管在讨论提高性能或可用性时最好有所了解。

DevOps 的文化成分经常被忽视或完全忽略。 随着这场运动继续在 NetOps 上留下自己的印记，并且传统网络运营缓慢但坚定地采用其原则来实现敏捷网络，沟通变得至关重要。 这意味着找到共同点。 理解彼此的术语是建立更具协作性的文化的第一步，这对于确保应用部署与交付一样快速、安全和可靠。