使用 F5 BIG-IP 在容器中扩展应用程序时消除层级

或者那是沮丧的‘眼泪’？¯\_(ツ)_/¯ 也许两者兼而有之。

网络和应用架构之间存在关系。 通常我们喜欢谈论应用架构的变化和转变如何影响网络——包括解决方案和架构方面。 但反之亦然；网络的架构和行为会对应用及其架构产生相当大的影响。

也就是说，我们现在看到整体式应用分解为许多微服务，而不是像 SOA 时代那样，原因之一就是网络。 或者更准确地说，是因为网络速度。 在 SOA 时代，由于网络特性（以及物理定律）的限制，不可能从三到四个以上的服务中撰写单一响应。 好吧，这并非不可能，但由于每次呼叫都会产生延迟，因此这是不可取的。

今天，我们拥有更快、更宽带的网络和更高数量级的计算能力，这使得这种分解变得可行。 容器的性质使得事情变得更加简单，它们经常与微服务配对，就像咖啡和甜甜圈一样。 因为需要通信的两个服务之间的“网络”通常是虚拟构造（数据包实际上从未离开主机服务器，因此不会遭受“传输”产生的延迟），所以可以调用来响应单个请求的服务数量远远高于我们在 SOA 时代可以合理实现的数量。

但这并不意味着我们应该忽略响应请求需要遍历多少连接和跳数，或者架构对应用性能的影响。 因为即使计算速度更快、管道更粗，运营开销仍然是我们必须处理的问题。 仍然会阻碍性能的事情。 处理运营开销（和提高性能）的最简单方法之一是通过消除架构中的（不必要的）层来降低复杂性。

降低容器环境的复杂性

大多数容器部署将使用集群内的某种类型的负载均衡器来管理容器环境内的微服务/应用程序的规模。 这是因为它们通常负责执行 API 的 L7 路由（即入口控制），并且本机负载均衡结构基于 iptables，而 iptables 当然不讲 HTTP（L7 路由的语言）。 因此，集群容器内部有一堆 L7 负载均衡器。

现在，大多数部署也需要在集群外部进行负载均衡，以便将外部流量传输到集群内部正确的负载均衡器。 为此，他们使用普通的负载均衡将请求分配到内部正确的负载均衡器。

我们将外部的负载均衡器称为BIG-IP ，将集群内部的负载均衡器称为内部 lb 。 因为这是我的博客，就是这样。

问题是内部 lb实例的数量会发生波动（有时会剧烈波动）。 每次发生变化时，BIG-IP 都需要知晓。 传统上，这是一个手动操作，需要 BIG-IP 所有者亲自出去手动修改池。 这对于开发人员和 DevOps 来说是令人沮丧的，对于 NetOps 来说则是乏味的。 换句话说，没人愿意这么做。

这就是F5 容器连接器等解决方案存在的原因。 F5 容器连接器是一种容器原生服务，可与容器编排器集成并观察环境。 当发生影响内部 lb 的变化时，它会触发更新 BIG-IP 的过程。 这意味着随着需求的起伏，BIG-IP 会自动保持最新状态，并能够适当地将请求分配给活跃、健康的内部负载平衡器。 无需手动修改。

这种两层扩展架构的优势在于提供了一个方便的入站位置（BIG-IP），可以在该位置终止 SSL/TLS，从而提供可衡量的性能改进。 好的。

但为什么要停在那里呢？ BIG-IP 能够提供L7 路由。 如果您正在使用 F5 容器连接器的服务，则可以通过完全消除内部 lb来进一步提高性能（并降低运营开销）。 真的。 BIG-IP 可以充当 Kubernetes 和 Red Hat OpenShift 的入口控制器。

通过将入口责任转移到 BIG-IP，您可以消除整个规模层（内部 lb），从而立即提高性能。 由于外部 lb是F5 BIG-IP ，您可以进一步在接触点而不是在容器集群内部（或根本不部署）部署以安全为中心的应用服务，例如具有机器人防御功能的Advanced WAF（API 安全 - 新一代 WAF） 。 

部落冲突

随着容器更频繁地投入生产（而且它们将会如此），将需要加强 DevOps 和 NetOps 之间的协作，以便实现这些改进并确保应用程序的规模、速度和安全性。 毕竟，这不仅仅是按按钮和自助服务管道那么简单。 架构是一个关键组件，需要在 DevOps 和 NetOps 的输入下进行设计，以免我们忽视改进应用性能等方面的机会。

因为应用性能是一项团队运动。 它受到代码（AppDev）、代码部署平台（DevOps）、网络架构以及用于保护和扩展应用程序的应用服务（NetOps）的影响。 尽可能通过消除层级来实现架构优化，这对于运营和业务都有良好的意义。 但这需要全队所有球员的参与。

所以订一些披萨和啤酒，把 DevOps 和 NetOps 放在一起开始讨论。 了解您是否也可以通过消除容器环境中不必要的层来提高应用程序的性能。