服务、负载均衡和网络

Kubernetes 网络模型

Kubernetes 网络模型由几个部分组成

• 集群中的每个 Pod 都有其自己唯一的集群范围 IP 地址。

  • Pod 拥有自己的私有网络命名空间，该命名空间由 Pod 内的所有容器共享。同一 Pod 中不同容器中运行的进程可以通过 localhost 相互通信。

• Pod 网络（也称为集群网络）处理 Pod 之间的通信。它确保（除非有意的网络分段）：

  • 所有 Pod 都可以与所有其他 Pod 通信，无论它们是在同一 节点 上还是在不同的节点上。Pod 可以直接相互通信，无需使用代理或地址转换（NAT）。

    在 Windows 上，此规则不适用于主机网络 Pod。

  • 节点上的代理（如系统守护进程或 kubelet）可以与该节点上的所有 Pod 通信。

• Service API 允许您为由一个或多个后端 Pod 实现的服务提供稳定的（长期存在的）IP 地址或主机名，而构成服务的各个 Pod 可能会随着时间的推移而变化。

  • Kubernetes 自动管理 EndpointSlice 对象，以提供有关当前支持 Service 的 Pod 的信息。

  • 服务代理实现会监视 Service 和 EndpointSlice 对象集，并使用操作系统或云提供商 API 来拦截或重写数据包，从而对数据平面进行编程，将服务流量路由到其后端。

• 网关 API（或其前身 Ingress）允许您使集群外部的客户端可以访问服务。

  • 当使用受支持的 云提供商 时，通过 Service API 的 type: LoadBalancer 可以使用一种更简单但可配置性较低的集群入口机制。

• NetworkPolicy 是一个内置的 Kubernetes API，允许您控制 Pod 之间或 Pod 与外部世界之间的流量。

在较旧的容器系统中，不同主机上的容器之间没有自动连接，因此通常需要显式地创建容器之间的链接，或者将容器端口映射到主机端口，以使其他主机上的容器可以访问它们。这在 Kubernetes 中是不需要的；Kubernetes 的模型是，从端口分配、命名、服务发现、负载平衡、应用程序配置和迁移的角度来看，可以将 Pod 视为类似于 VM 或物理主机。

此模型只有少数部分由 Kubernetes 本身实现。对于其他部分，Kubernetes 定义了 API，但相应的功能由外部组件提供，其中一些是可选的

• Pod 网络命名空间设置由实现 容器运行时接口 的系统级软件处理。

• Pod 网络本身由 Pod 网络实现 管理。在 Linux 上，大多数容器运行时使用 容器网络接口 (CNI) 与 Pod 网络实现进行交互，因此这些实现通常称为 CNI 插件。

• Kubernetes 提供了一种名为 kube-proxy 的默认服务代理实现，但某些 Pod 网络实现反而使用它们自己的服务代理，该代理与实现的其余部分更紧密地集成。

• NetworkPolicy 通常也由 Pod 网络实现来实现。（一些较简单的 Pod 网络实现不实现 NetworkPolicy，或者管理员可以选择在没有 NetworkPolicy 支持的情况下配置 Pod 网络。在这些情况下，API 仍然存在，但它不会产生任何影响。）

• 有许多 网关 API 的实现，其中一些是特定于特定云环境的，一些更侧重于“裸机”环境，而另一些则更通用。

下一步是什么

使用服务连接应用程序教程让您通过一个实际的示例了解服务和 Kubernetes 网络。

集群网络 解释了如何为集群设置网络，并提供了所涉及技术的概述。