服务、负载均衡和网络

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 来拦截或重写数据包，从而编程数据平面以将服务流量路由到其后端。

• Gateway API（或其前身Ingress）允许您让集群外部的客户端访问服务。

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

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

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

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

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

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

• Kubernetes 提供了一个服务代理的默认实现，称为kube-proxy，但一些 Pod 网络实现则使用自己的服务代理，该代理与实现的其他部分更紧密集成。

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

• Gateway API有许多实现，其中一些特定于特定的云环境，一些更侧重于“裸机”环境，还有一些更通用。

下一步

通过使用服务连接应用程序教程，您可以通过动手示例了解服务和 Kubernetes 网络。

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