website/content/zh-cn/docs/concepts/services-networking/_index.md

title	weight	description
服务、负载均衡和联网	60	Kubernetes 网络背后的概念和资源。

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 的信息。

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

• Gateway API （或其前身 Ingress 使得集群外部的客户端能够访问 Service。

  • 当使用受支持的 {{< glossary_tooltip term_id="cloud-provider">}} 时，通过 Service API 的 type: LoadBalancer 可以使用一种更简单但可配置性较低的集群 Ingress 机制。

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

在早期的容器系统中，不同主机上的容器之间没有自动连通， 因此通常需要显式创建容器之间的链路，或将容器端口映射到主机端口，以便其他主机上的容器能够访问。 在 Kubernetes 中并不需要如此操作；在 Kubernetes 的网络模型中， 从端口分配、命名、服务发现、负载均衡、应用配置和迁移的角度来看，Pod 可以被视作虚拟机或物理主机。

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

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

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

• Kubernetes 提供了一个默认的服务代理实现，称为 {{< glossary_tooltip term_id="kube-proxy">}}， 但某些 Pod 网络实现使用其自己的服务代理，以便与实现的其余组件集成得更紧密。

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

• Gateway API 的实现有很多， 其中一些特定于某些云环境，还有一些更专注于“裸金属”环境，而其他一些则更加通用。

{{% heading "whatsnext" %}}

使用 Service 连接到应用教程通过一个实际的示例让你了解 Service 和 Kubernetes 如何联网。

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