创建和管理强大的 Kubernetes 环境需要网络和application团队之间的顺畅协作。 但他们的优先事项和工作风格通常有很大差异,从而导致冲突并可能造成严重后果——应用程序开发缓慢、部署延迟,甚至网络停机。
只有两个团队朝着共同的目标努力并取得成功,才能确保当今的现代应用能够按时交付并具有适当的安全性和可扩展性。 那么,如何利用每个团队的技能和专业知识,同时帮助他们协同工作?
在我们的白皮书《进入集群》中,我们详细介绍了实现对 Kubernetes 服务的外部访问的解决方案,该解决方案使网络和application团队能够结合他们的优势而不会发生冲突。
该解决方案专门适用于在本地托管的 Kubernetes 集群,其中节点在裸机或传统 Linux 虚拟机 (VM) 上运行,标准第 2 层交换机和第 3 层路由器为数据中心的通信提供网络。 它不能扩展到云托管的 Kubernetes 集群,因为云提供商不允许我们控制其数据中心的核心网络或其管理的 Kubernetes 环境中的网络。
在讨论解决方案的具体细节之前,让我们先回顾一下为什么在 Kubernetes 集群中公开应用的其他标准方式不适用于本地部署:
A
记录。 不幸的是,本地集群没有等效的解决方案。这给我们留下了 Kubernetes Ingress 对象,它是专门为从集群外部用户流向集群内部 pod 的流量(南北流量)而设计的。 Ingress 为集群创建一个外部 HTTP/HTTPS 入口点 - 一个单一的 IP 地址或 DNS 名称,外部用户可以通过该 IP 地址或 DNS 名称访问多个服务。 这正是所需要的! Ingress 对象由 Ingress 控制器实现 - 在我们的解决方案中是基于NGINX Plus 的企业级F5 NGINX Ingress 控制器。
您可能会感到惊讶,该解决方案的另一个关键组件是边界网关协议(BGP),一种第 3 层路由协议。 但一个好的解决方案不一定很复杂!
《Get Me to the Cluster》中概述的解决方案实际上有四个组件:
该图说明了解决方案架构,指出了解决方案组件用于通信的协议,而不是在请求处理过程中交换数据的顺序。
通过共同实施具有明确定义组件的解决方案,网络和application团队可以轻松提供最佳性能和可靠性。
我们的解决方案使用现代网络工具、协议和现有架构。 由于它的设计成本低廉,并且易于实施、管理和支持,它增加了便利性并在您的团队之间架起了桥梁。
要查看代码的实际运行并逐步了解如何部署我们的解决方案,请免费下载Get Me to the Cluster 。
“这篇博文可能引用了不再可用和/或不再支持的产品。 有关 F5 NGINX 产品和解决方案的最新信息,请探索我们的NGINX 产品系列。 NGINX 现在是 F5 的一部分。 所有之前的 NGINX.com 链接都将重定向至 F5.com 上的类似 NGINX 内容。”