Kubernetes 的主要职责之一是在应用程序之间共享节点。由于这些应用程序需要相互通信并与外部世界通信，因此网络是一个基本的需求。

Kubernetes 托管的分布式应用程序架构

来自 Kubernetes 集群外部的请求通常通过负责将它们代理到适当服务的路由器或 API 网关进行。Kubernetes 网络的责任是提供底层通信层，使请求能够到达它们预期的目的地。

分布式应用程序分布在许多节点上。当每个应用程序有多个副本时，Kubernetes 处理服务发现和服务与 Pod 之间的通信。在 Pod 内部，容器可以轻松且透明地通信。在集群内部，Pod 可以连接到其他 Pod，这是通过虚拟网络接口、桥接以及通过叠加网络的路由规则的组合实现的。

尽管有透明的处理，但 Kubernetes 网络比看起来更复杂。在多个云上部署、维护多个环境以及确保可靠且可扩展的网络策略都是重大的挑战。并不是所有这些复杂性都被 Kubernetes 原生地解决了。在本文中，我们将探讨如何应对这些挑战。

Kubernetes 网络的基础

在 Kubernetes 中，Pod 负责处理容器到容器的通信。Pod 利用具有自己的网络资源（接口和路由表）的网络命名空间。在 Pod 内部，容器共享这些资源，允许它们通过 localhost 进行通信。

Pod 到 Pod 的通信必须满足以下 Kubernetes 的要求：

Pod 需要无网络地址转换 (NAT) 的通信。
节点需要能够无 NAT 的与 Pod 通信。
Pod 可以看到分配给自己的 IP 地址必须与其他 Pod 看到的 IP 匹配。

Container Network Interface (CNI) 包括编写网络插件以配置网络接口的规范。这使您可以创建满足 Pod 到 Pod 通信要求的覆盖网络。

服务是 Kubernetes 的一个抽象，允许 Pod 暴露和接收请求。它通过 Pod 标签提供服务发现机制和基本的负载均衡能力。在 Pod 内部运行的应用程序可以轻松地使用服务连接到集群中运行的其他应用程序。来自集群外部的请求可以通过 Ingress 控制器路由。这些控制器将使用 Ingress 资源配置路由规则，通常利用服务来促进路由到正确的应用程序。

重大挑战

尽管这些网络功能为 Kubernetes 管理的工作负载提供了基础的构建块，但云原生系统的动态和复杂性带来了几个挑战。

服务到服务通信的可靠性

在分布式系统中，业务功能被划分为多个自主服务，在节点、Pod 和容器的集群上运行。微服务架构引入了服务需要通过网络进行通信的需求。

云的不稳定性和弹性特性要求对 Kubernetes 集群进行持续监控，并在出现故障时进行重新路由。由于 Pod 是短暂的并且资源持续地被重新路由，所以服务到服务的通信并不是既定的。

高效的负载均衡算法需要将流量分配给可用的副本并隔离过载的副本。同样，服务失败意味着客户端请求需要被重试并优雅地超时。复杂的场景可能需要断路器和负载减轻技术来处理需求的激增和失败。

复杂的多云部署

复杂的大规模系统通常被划分为多个环境，不同的部分部署到不同的云平台。这些异构环境需要相互通信。

甚至在同一个云租户内------或在本地------相同的工作负载可以在不同的环境中运行（开发、暂存和生产）。尽管这些环境是分开的，但它们有时需要相互通信。例如，暂存环境可能需要模拟生产工作负载，并在上线前对应用程序进行严格测试。通过成功的测试，代码和数据可能需要从中迁移。

在这种情况下，无缝迁移可能是一个挑战。此外，可能存在同时支持 VM 和 Kubernetes 托管服务的团队的情况。或者，团队设计支持多云------或至少是多区域------部署以确保可靠性的系统，指定复杂的网络配置和详细的入口和出口规则。

服务发现

在云原生环境中运行 Kubernetes 时，通过在多个节点上生成多个副本来轻松扩展服务是很容易的。这些应用程序副本是短暂的------按 Kubernetes 的需要实例化和销毁。应用程序中的微服务非常不容易跟踪所有这些 IP 地址和端口的更改。尽管如此，这些微服务需要一个有效的方法来查找服务副本。

网络规则的可扩展性

安全性最佳实践和行业法规，如支付卡行业数据安全标准 (PCI DSS)，都强制执行严格的网络规则。这些规则规定了服务之间的严格通信约束。

Kubernetes 有 Network Policies 的概念。这些允许您在 IP 地址或端口级别控制流量。您可以使用标签和选择器指定允许 Pod 与其他服务通信的规则。

随着您的微服务系统在数量上增长，达到数百或数千个服务，网络策略管理变得复杂、繁琐且容易出错。

Kong Ingress 控制器如何帮助

来自 Kong 的 Kubernetes Ingress 控制器 (KIC) 是 Kubernetes 的一个 Ingress 实现。这个由 Kong Gateway 提供支持的 Ingress 控制器，充当一个云原生、平台无关、可扩展的 API 网关。它是为混合和多云环境而构建的，并且针对微服务和分布式架构进行了优化。

KIC 允许创建路由规则、健康检查和负载均衡的配置，并且支持多种提供高级功能的插件。这一广泛的功能可以帮助解决我们已经讨论的挑战。

可靠的服务到服务通信

Kubernetes 服务提供了简单的负载均衡功能（轮询调度）。KIC 的一个核心功能是在同一应用程序的副本之间进行负载均衡。它可以使用诸如加权连接或最少连接的算法，或者甚至是复杂的、自定义的实现。这些算法利用 KIC 的服务注册表提供高效的路由。

使用 KIC，您可以轻松地在服务停止时配置重试、合理的超时、将请求重新路由到健康的服务实例或错误处理。您还可以实现诸如断路器和负载减轻等失败模式，以平滑和节流流量。

简化多云环境部署

多环境和异构基础设施部署需要复杂的网络策略和路由配置。内置在 KIC 中的 Kong Gateway 解决了其中许多挑战。

Kong Gateway 允许服务独立于部署位置进行注册。使用已注册的服务，您将能够添加路由，KIC 将准备好代理请求到您的服务。此外，当复杂的系统有时使用不同的协议（REST 与 gRPC）进行通信时，您可以轻松地配置 KIC 以支持多个协议。

插件系统允许您扩展 KIC 的功能以满足更复杂的场景。Kong Plugin Hub 包含了一系列有用且经过实战测试的插件，而 KIC 也使您能够开发和使用最适合您需求的任何插件。

增强的服务发现

如前所述，KIC 通过其服务注册表跟踪可用实例。随着服务与 KIC 的集成，它们可以自我注册并报告其可用性。此注册也可以通过第三方注册服务完成。通过利用服务注册表，KIC 可以在任何时候将客户端请求代理到适当的后端。

可扩展的网络规则

尽管通过 Network Policies 强制执行网络规则可能会很复杂，但 KIC 可以轻松地与诸如 CNCF 的 Kuma 或与 Kong Istio Gateway 的 Istio 这样的服务网格实现集成，扩展 Network Policies 的功能并保证额外的安全性。

使用身份验证和授权策略，您将能够以安全、一致且自动化的方式增强网络安全。此外，您可以将网络策略和服务网格策略一起使用，以提供更好的安全姿态。

服务网格集成的另一个好处是它允许进行像金丝雀部署和蓝绿部署这样的部署模式。它还通过可靠的指标和追踪增强了可观察性。

结论

Kubernetes 可以处理常见的网络任务，使开发人员和操作员更容易启动服务。然而，在大型和复杂的云原生系统中，网络问题很少是简单的。组织希望将单体划分为微服务，但他们需要解决如有效的负载均衡或容错等独特的问题。同样，实现不同环境之间的无缝服务迁移和转换并不容易。Kubernetes 的网络功能需要扩展以支持更广泛的场景。

KIC 可以有效地应对其中许多挑战。它提供了广泛的功能，包括高级的路由和负载均衡规则、复杂的入口和出口规则，以及容错措施。您可以使用 KIC 的服务注册表大大改进服务发现，该注册表可以跟踪每个服务的所有可用实例。与 KIC 和服务网格的简单集成可以帮助建立强大的网络安全策略，并利用不同的部署模式。

作者：Michael Bogan

更多内容请关注公号【云原生数据库】

Kubernetes 的四个网络挑战