服务、负载均衡与网络

Kubernetes 网络模型

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

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

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

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

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

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

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

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

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

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

• Gateway API（或其前身 Ingress）允许你使 Service 可供集群外部的客户端访问。

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

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

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

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

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

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

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

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

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

接下来

使用 Service 连接应用 教程通过实践示例让你了解 Service 和 Kubernetes 网络。

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