Kubernetes网络

Kubernetes 网络模型

Kubernetes 网络模型由多个关键部分构建而成：

• 在 Kubernetes 集群中，每个 Pod 都会被分配一个独一无二的、在集群范围内有效的 IP 地址。
  • Pod 拥有自己独立的私有网络命名空间，该命名空间由 Pod 内的所有容器共享。这意味着，在同一 Pod 中运行的不同容器进程能够通过 localhost 进行便捷的相互通信。
• Pod 网络（也称为集群网络）处理 Pod 之间的通信。主要负责处理 Pod 之间的通信任务。在没有进行有意的网络分段情况下，它能够确保：
  • 所有 Pod，无论它们处于同一节点还是不同节点，都能够直接相互通信，无需借助代理或地址转换（NAT）¹。
    不过，在 Windows 系统环境下，该规则并不适用于主机网络 Pod²。
  • 节点上的代理，比如系统守护程序或者 kubelet，能够与该节点上的所有 Pod 进行通信。
• 服务 API 的存在意义重大，它能为一个或多个后端 Pod 所实现的服务提供稳定持久的 IP 地址或主机名。尽管构成服务的各个 Pod 可能会随着时间推移而发生变化，但服务 API 能保障服务的稳定性。
  • Kubernetes 会自动对 EndpointSlice³ 对象进行管理，以提供有关当前支持 Service 的 Pod 的详细信息。
  • 服务代理实现会实时监控 Service 和 EndpointSlice 对象的集合，并通过运用操作系统或云提供商 API 对数据包进行拦截或重写，从而对数据平面进行编程，实现将服务流量精准路由到后端的功能。
• Gateway API（或其前身 Ingress）则为集群外部的客户端访问 Service 提供了可能。
  • 当使用受支持的云供应商时，通过服务 API 的 type: LoadBalancer 能够获得一种更为简便但可配置性稍弱的集群入口机制。
• NetworkPolicy 是 Kubernetes 内置的一种 API，它允许用户对 Pod 之间以及 Pod 与外部网络之间的流量进行精细化控制。

在以往的旧容器系统中，不同主机上的容器之间无法自动实现连接，通常需要在容器之间显式创建链接，或者将容器端口映射到主机端口，以便其他主机上的容器能够访问。但在 Kubernetes 中，这种复杂操作并非必要。Kubernetes 的网络模型将 Pod 从端口分配、命名、服务发现、负载均衡、应用程序配置以及迁移等多个角度，都视作 VM 或物理主机来处理。

需要注意的是，Kubernetes 网络模型仅有少数部分是由 Kubernetes 自身实现的。对于其他部分，Kubernetes 只是定义了 API，而相应的功能则由外部组件提供，其中部分组件是可选的：

• Pod 网络命名空间设置由实现 Container Runtime Interface 的系统级软件负责处理的。
• Pod 网络本身由 Pod 网络实现进行管理。在 Linux 系统中，大多数容器运行时会借助容器网络接口（CNI）⁴与 Pod 网络实现进行交互，所以这些实现通常被称为 CNI 插件。
• Kubernetes 提供了一个默认的服务代理实现，即 kube-proxy，不过，部分 pod 网络实现会使用自身的服务代理，这种代理与实现的其余部分集成得更为紧密。
• NetworkPolicy 通常也由 pod network实现。当然，一些较为简单的 Pod 网络实现可能不会实现 NetworkPolicy，或者管理员可能会选择在没有 NetworkPolicy 支持的情况下对 Pod 网络进行配置。在这些情况下，API 虽然依然存在，但不会产生实际作用。
• Gateway API 有许多实现，有些是特定于特定云环境的，有些更侧重于 “裸机” 环境，还有一些则通用性更强。

相关概念

Service 服务

将集群中运行的应用程序巧妙地暴露在单个面向外部的终端节点之后，即便工作负载被拆分到多个后端，也能确保服务的正常对外提供。

Ingress 入口

运用协议感知配置机制，让 HTTP（或 HTTPS）网络服务得以对外可用。它能够理解 URI、主机名、路径等 Web 概念，并依据通过 Kubernetes API 定义的规则，将流量精准映射到不同的后端。

Ingress Controllers 入口控制器

要使 Ingress 在集群中正常工作，必须有一个正在运行的 Ingress 控制器。用户需要至少选择一个 Ingress Controller，并确保其在集群中正确设置。

Gateway API 网关 API

Gateway API 是一系列 API 类型的集合，能够提供动态基础设施预置和高级流量路由功能。

EndpointSlices

EndpointSlice API 是 Kubernetes 用于让 Service 扩展以处理大量后端的关键机制，它能让集群高效地更新其健康的后端列表。

Network Policies 网络策略

若想在 IP 地址或端口级别（OSI 第 3 层或第 4 层）对流量进行精确控制，NetworkPolicy 允许用户为集群内部以及 Pod 与外部世界之间的流量制定规则。不过，集群必须使用支持 NetworkPolicy 实施的网络插件。

DNS for Services and Pods 服务和 Pod 的 DNS

工作负载可以使用 DNS 发现集群中的 Service

IPv4/IPv6 dual-stack IPv4/IPv6 双栈

Kubernetes 允许配置单堆栈 IPv4 网络、单堆栈 IPv6 网络或双堆栈网络，实现两个网络系列同时处于活动状态。

Topology Aware Routing 拓扑感知路由

拓扑感知路由提供了一种有效机制，有助于将网络流量限制在其来源区域内。在集群中的 Pod 之间优先选择同一区域流量，这对于提升可靠性、性能（网络延迟和吞吐量）以及控制成本都有积极作用。

Service Internal Traffic Policy 服务内部流量策略

当集群中的两个 Pod 需要通信，并且这两个 Pod 实际上都运行在同一个节点上时，使用服务内部流量策略可以将网络流量限制在该节点内部。避免通过集群网络进行往返，有助于提高可靠性、性能（网络延迟和吞吐量）或降低成本。

链接

• Kubernetes 网络
• Gateway
• Ingress

---

1. 网络地址转换（Network Address Translation，NAT）是一种在计算机网络中用于实现私有网络与公共网络之间通信的技术手段。它的主要功能是将私有网络内部的多个设备使用的私有IP地址转换为一个或少数几个公共IP地址，使得这些内部设备能够共享一个公共IP地址来访问外部网络，同时也能让外部网络的设备正确地与内部网络中的设备进行通信，从而有效解决了IP地址短缺问题，增强了网络的安全性和灵活性，并且可以在一定程度上提高网络的可管理性。 ↩︎

2. 在 K8S 中，主机网络 Pod 是一种特殊类型的 Pod，它使用所在节点的网络命名空间，而不是像普通 Pod 那样拥有自己独立的私有网络命名空间。这意味着主机网络 Pod 会直接共享节点的网络接口、IP 地址和端口等网络资源，它可以避免额外的网络地址转换，对于某些需要高性能网络和低延迟的应用，如网络密集型应用或监控系统，使用主机网络模式可以获得更好的性能表现。然而，由于使用了节点的网络资源，可能会受到节点网络的限制和影响，并且可能与节点上的其他服务产生网络资源的竞争，同时，其网络行为可能会更依赖于节点的网络配置和状态。 ↩︎

3. K8S中的EndpointSlice是一种用于管理服务后端端点信息的资源。它为Kubernetes的服务提供了一种更高效、更具扩展性的方式来存储和更新后端Pod的信息，尤其在处理大量后端端点时表现出色。与传统的Endpoint资源相比，EndpointSlice将端点信息分割成多个切片，避免了单个资源过大导致的性能问题。每个EndpointSlice包含一组端点的信息，如IP地址、端口和就绪状态等，并且可以动态更新以反映后端Pod的变化，帮助服务代理实现将流量准确地路由到健康的后端Pod，确保服务的正常运行和负载均衡功能的有效执行，为大规模服务的管理和流量分发提供了有力支持。 ↩︎

4. 容器网络接口（Container Network Interface，CNI）是一种用于容器网络的规范和插件系统，旨在为容器提供简单、高效、可扩展的网络连接解决方案。它定义了一组标准的接口和操作，如添加、删除容器网络接口等，使得容器运行时（如Docker、rkt等）可以与各种不同的网络插件进行交互，从而实现容器的网络配置和管理。CNI插件负责具体的网络功能实现，包括为容器分配IP地址、设置网络路由、实现网络隔离与安全等，通过支持多种类型的网络插件，如Flannel、Calico等，CNI能让用户根据不同的需求和场景，灵活地构建各种复杂的容器网络拓扑，为容器化应用提供稳定可靠的网络基础。 ↩︎