速度与规模：使用F5 BIG-IP进行Kubernetes Ingress控制

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

容器领域既混乱又令人困惑。容器编排环境似乎每天都会涌现新的功能或组件。这是必经阶段，因为随着容器的使用从实验性尝试扩展到关乎业务存续的应用，这一领域仍在不断成熟。

速度和规模是推动容器部署的两大主要因素。速度既关乎开发，也关乎交付，因此规模成为关注重点。但这里所说的并非普通的协议扩展能力，而是应用扩展能力。

这一区别很重要。容器被认为最有可能承载微服务，而微服务的一项基本原则是仅通过API进行通信。此类API基于HTTP而非TCP，因此需要更智能的扩展解决方案。

大多数容器编排环境都自带能够进行基础扩展的代理。这意味着在TCP层使用传统负载均衡（POLB）。IP地址和端口是这些代理通用的识别方式。如果根据IP地址和端口组合来区分服务，这些代理可以很好地发挥作用；但如果根据HTTP层特征（例如API版本、URI或主机名）来区分应用（服务），其表现就不尽如人意。这些属于应用层（HTTP）构造，需要更智能的代理，才能按所需速度完成路由和扩展。收到客户端实体的请求时，必须考虑这些构造，而大多数容器基础扩展解决方案无法做到这一点。

为满足这一需求，Ingress*控制的概念应运而生。Ingress控制本质上就是应用或HTTP路由，也称为第7层交换、内容交换，或自本世纪初以来这一功能使用过的其他十余种名称。Ingress控制以应用（HTTP）层的服务差异化为前提，并据此在容器环境中做出路由和扩缩容决策。

但不能只是在容器环境前部署F5 BIG-IP，就称其为Ingress控制。这是因为Ingress控制器还需要与容器编排环境集成，才能达到所需的扩展能力和速度。为此，需要在容器环境内部运行，并能原生与容器编排系统和BIG-IP通信的组件。

这正是BIG-IP Controller for Kubernetes的作用。它是一个在Kubernetes Pod中运行的Docker容器，可将BIG-IP用作Kubernetes Ingress控制器。这意味着它可以读取Kubernetes Ingress资源，并使用适当的对象自动配置BIG-IP，确保根据所需的应用层结构扩展请求处理能力。

在此控制器推出之前，通常会使用BIG-IP将流量“分散”到运行在内部的容器编排环境中的第二层代理。这些代理负责Ingress控制。有几个充分的理由不再采用这种方式，其中之一就是：将可用性服务运行在其所保障可用性的对象内部，会造成循环依赖这一棘手问题。

其他充分理由包括：

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

无论出于何种原因，实际情况是，可以使用BIG-IP作为Kubernetes的Ingress控制器。无需通过两个不同的层级来扩展。取消第二个扩展层级将提高交付和部署速度，简化部署，同时提供一个平台，以便启用各种高级服务，增强安全性、速度和可扩展性。

可以在此处详细了解BIG-IP Controller for Kubernetes，也可以从Docker Hub的此处获取，或直接拉取：

docker pull f5networks/k8s-bigip-ctlr

继续扩展。

* 是的，大写字母“I”很重要，因为它可以与传统网络术语“ingress”区分开来。后者仅指“进入环境的访问”，而“Ingress”则用于指代“HTTP路由”。没错，我们确实常常把事情弄得比实际需要的更复杂，但现实就是如此：开发人员正在实现网络构造，重新定义的不仅仅是应用交付方式。

关于作者

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。

Lori Mac Vittie 的更多博客文章