速度和规模： F5 BIG-IP 作为 Kubernetes 的入口控制

集装箱领域同样存在混乱。 每天似乎都会为容器编排环境的世界带来一些新的功能或组件。 这是必要的，因为随着容器的使用从实验扩展到存在，它仍在不断成熟。

速度和规模是容器部署的两个主要驱动因素。 前者既注重开发，也注重交付，因此注重规模。 但我们谈论的不仅仅是原始协议规模，还有应用规模。

这种区别很重要。 容器被认为最有可能包含微服务，而微服务的基本规则之一就是仅通过 API 进行通信。 基于 HTTP（而非 TCP）的 API，因此需要更智能的扩展解决方案。

大多数容器编排环境都是“开箱即用的”，具有可进行原始扩展的代理。 这意味着 TCP 层的普通旧负载均衡 (POLB) 。 IP 地址和端口是这些代理的通用语言。 虽然它们在基于 IP 地址/端口组合区分服务的环境中表现良好，但对于通过 HTTP 层特征（如 API 版本、URI 或主机名）区分的应用（服务），它们的表现并不好。 这些是应用层（HTTP）构造，需要更智能的代理来以所需的速度进行路由和扩展。 在收到来自客户端实体的请求时必须考虑这些构造，这是大多数原始容器解决方案无法提供的。  

为了满足这种需求，出现了 Ingress* 控制的概念。 入口控制基本上是应用程序或 HTTP 路由或第 7 层交换或内容交换或自世纪之交以来已有的十几个其他名称。 入口控制假设应用（HTTP）层的服务区分，并相应地在容器环境内进行路由和扩展决策时对其采取行动。

但是您不能仅仅将 F5 BIG-IP 放在容器环境前面并称之为入口控制。 这是因为 Ingress 控制器还需要与容器编排环境集成才能实现所需的规模和速度。 为了实现这一点，您需要在容器环境中存在某种东西，它可以原生地支持容器编排和 BIG-IP。

这就是Kubernetes 的 BIG-IP 控制器的作用。 它是一个在Kubernetes Pod 中运行的 Docker 容器，使您能够使用 BIG-IP 作为 Kubernetes Ingress 控制器。 这意味着它可以读取 Kubernetes Ingress 资源并使用适当的对象自动配置 BIG-IP，以确保根据您想要的应用层构造进行请求的扩展。

现在，在该控制器可用之前，人们倾向于使用 BIG-IP 在容器编排环境内运行的第二层代理上“喷洒”流量。 这些代理提供了入口控制。 有几个很好的理由可以停止这样做，包括在提供可用性的对象内部运行可用性服务所带来的递归麻烦。

其他充分理由包括：

• 启用 DDoS 缓解措施
• 利用Web应用防火墙保护 API 和应用程序
• 支持 IPv6 客户端使用 IPv4 容器化应用 
• 将 TLS 卸载到 BIG-IP 并使用自签名证书重新加密
• 使用应用加速选项来提高性能

无论原因是什么，事实是您可以使用 BIG-IP 作为 Kubernetes 的 Ingress 控制器。 您不需要两个不同的层级来扩展。 消除第二层规模将提高速度（交付和部署）并简化部署，同时提供一个平台，您可以在此平台上启用各种高级服务，以实现安全性、速度和规模。  

您可以在此处阅读有关 Kubernetes 的 BIG-IP 控制器的更多信息，或从 Docker中心获取它，或者直接拉取它：

docker pull f5networks/k8s-bigip-ctlr

扩大规模。

* 是的，大写的“I”很重要，因为它与传统的网络术语“ingress”区分开来，后者仅指“进入环境”，而“Ingress”则用于指“HTTP 路由”。 是的，我们确实倾向于把事情弄得比本来的更困难，但这个世界就是这样，开发人员正在实现网络构造，并重新定义应用程序的交付方式。