DZone>Web Dev Zone>解决Kubernetes网络的四大挑战
解决Kubernetes网络方面的四个挑战
在多个云中部署，维护多个环境，确保可靠和可扩展的网络策略；我们将看看如何解决这些挑战。
作者
CORE -
1月18日，22日 - Web Dev Zone -分析
喜欢 (1)
评论
保存
鸣叫
160次浏览
加入DZone社区，获得完整的会员体验。
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一致。
容器网络接口（CNI）包括一个用于编写网络插件以配置网络接口的规范。这允许你创建覆盖网络，以满足Pod到Pod的通信要求。
服务是一个Kubernetes抽象，允许Pod公开和接收请求。它通过Pod标签和基本的负载平衡能力提供了一个服务发现机制。在Pod内运行的应用程序可以很容易地使用服务来连接到集群中运行的其他应用程序。来自集群外的请求可以通过Ingress控制器进行路由。这些控制器将使用Ingress资源来配置路由规则，通常利用服务来促进路由到正确的应用程序。
非微不足道的挑战
虽然这些网络功能为Kubernetes管理的工作负载提供了基本的构建模块，但云原生系统的动态和复杂性质带来了一些挑战。
服务对服务的通信可靠性
在分布式系统中，业务功能被划分为多个自主服务，在节点、Pod和容器的集群上运行。微服务架构引入了服务在网络上通信的需求。
云的波动性和弹性性质要求对Kubernetes集群进行持续监控，并在出现故障时进行重新路由。有了短暂的Pod和持续的资源重路由，可靠的服务与服务之间的通信是不可能的。
高效的负载平衡算法需要将流量分配给可用的副本，并隔离过载的副本。同样地，服务失败意味着客户端请求需要重新尝试并优雅地超时。复杂的场景可能需要断路器和减载技术来处理需求的激增和故障。
精心设计的多云部署
复杂的大规模系统通常被划分为多个环境，不同的部分被部署到不同的云平台。这些异质的环境需要相互沟通。
即使在同一个云租约中，或者在原地，同一个工作负载也可以在不同的环境中运行（开发、暂存和生产）。虽然是分开的，但这些环境有时需要相互通信。例如，暂存环境可能需要模拟生产工作负载，并在上线前对应用程序进行严格的测试。随着测试的成功，代码和数据都可能需要从这里迁移。
在这种情况下，无缝迁移可能是一个挑战。另外，可能有这样的情况，一个团队同时支持虚拟机和Kubernetes托管的服务。或者，也许一个团队设计的系统支持多云或至少是多区域部署的可靠性，指定复杂的网络配置和详细的入站和出站规则。
服务发现
在云原生环境中运行Kubernetes时，很容易通过在多个节点上催生多个副本来扩展服务。这些应用副本是短暂的--在Kubernetes认为有必要的时候，会被销毁。对于应用程序中的微服务来说，跟踪所有这些IP地址和端口的变化是非同小可的。尽管如此，这些微服务需要一种有效的方式来寻找服务副本。
网络规则的可扩展性
安全最佳实践和行业法规，如支付卡行业数据安全标准（PCI DSS），强制执行严格的网络规则。这些规则规定了服务之间严格的通信限制。
Kubernetes有网络策略的概念。这些允许你在IP地址或端口级别控制流量。你可以使用标签和选择器指定使Pod与其他服务通信的规则。
随着你的微服务系统数量的增加，达到数百或数千个服务，网络策略管理成为一个复杂、乏味和容易出错的过程。
Kong Ingress Controller如何提供帮助
Kong的Kubernetes Ingress Controller（KIC）是Kubernetes的Ingress实现。这个Ingress控制器由Kong Gateway驱动，作为一个云原生的、与平台无关的、可扩展的API网关。它是为混合和多云环境建立的，并为微服务和分布式架构进行了优化。
KIC允许创建路由规则、健康检查和负载平衡的配置，它还支持各种提供高级功能的插件。这种广泛的能力可以帮助解决我们所讨论的挑战。
可靠的服务与服务之间的通信
Kubernetes服务提供简单的负载平衡能力（Round Robin）。KIC的核心功能之一是在同一应用的副本之间进行负载平衡。它可以使用加权连接或最小连接等算法，甚至是复杂的、自定义的实现。这些算法利用KIC的服务注册表来提供有效的路由。
有了KIC，你可以很容易地配置服务停机时的重试，合理的超时，将请求重新路由到健康的服务实例，或错误处理。你还可以实施故障模式，如断路和减载，以平滑和节制流量。
更简单的多云环境部署
多环境和异质基础设施的部署需要复杂的网络策略和路由配置。内置在KIC中的Kong Gateway可以解决许多这样的挑战。
Kong Gateway允许服务注册，与服务的部署地点无关。有了注册的服务，你就可以添加路由，而KIC将准备好代理请求给你的服务。此外，虽然复杂的系统有时会用不同的协议进行通信（REST与gRPC），但你可以轻松地配置KIC以支持多种协议。
插件系统允许你为更复杂的场景扩展KIC的功能。Kong Plugin Hub包含一个强大的有用的、经过实战检验的插件集合，KIC也可以让你开发和使用任何最适合你的插件。
增强的服务发现
如前所述，KIC通过其服务注册表跟踪可用实例。随着服务与KIC的整合，它们可以自我注册并报告其可用性。这种注册也可以通过第三方的注册服务来完成。通过利用服务注册表，KIC可以在任何时候将客户的请求代理给适当的后端。
可扩展的网络规则
虽然通过网络策略执行网络规则可能很复杂，但KIC可以很容易地与服务网状结构实现集成，如CNCF的Kuma或Istio与Kong Istio Gateway，扩展网络策略的功能，并保证额外的安全性。
通过认证和授权策略，你将能够以安全、一致和自动化的方式加强网络安全。此外，你可以同时使用网络策略和服务网状结构策略，以提供更好的安全态势。
服务网状结构集成的一个额外好处是，它允许采用金丝雀部署和蓝/绿部署等部署模式。它还通过可靠的指标和跟踪来增强可观察性。
总结
Kubernetes可以处理常见的网络任务，使开发者和运营商更容易登上服务。然而，对于大型和复杂的云原生系统，网络问题很少是简单的。企业希望将单体分割成微服务，但他们需要解决独特的问题，如有效的负载平衡或容错。同样，实现不同环境之间的无缝服务迁移和过渡也不容易。Kubernetes网络功能需要扩展，以支持更广泛的场景。
KIC可以有效地解决这些挑战中的许多问题。它提供了广泛的功能，包括高级路由和负载平衡规则、复杂的入口和出口规则以及容错措施。你可以通过KIC的服务注册表大大改善服务发现，它可以跟踪每个服务的所有可用实例。与KIC和服务网格的轻松整合可以帮助建立强大的网络安全策略，并利用不同的部署模式。
主题。
kubernetes、 网络、 devops、 webdev
DZone贡献者所表达的观点属于他们自己。
DZone上的热门话题
评论
