Kubernetes 网络模型由多个部分构建而成
集群中的每个 Pod 都会获得一个唯一的集群内 IP 地址。
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 对集群外部的客户端可见。
type: LoadBalancer 来实现一种更简单但配置性较低的集群入口机制。NetworkPolicy 是一种内置的 Kubernetes API，允许你控制 Pod 之间或 Pod 与外部世界之间的流量。
在较旧的容器系统中，不同主机上的容器之间没有自动连接，因此通常需要显式创建容器之间的链接，或者将容器端口映射到主机端口，以便其他主机上的容器可以访问它们。在 Kubernetes 中这不需要这样做；Kubernetes 的模型是：从端口分配、命名、服务发现、负载均衡、应用程序配置和迁移的角度来看，Pod 可以像虚拟机或物理主机一样被对待。
此模型中只有少数部分是由 Kubernetes 本身实现的。对于其他部分，Kubernetes 定义了 API，但相应的功能由外部组件提供，其中一些是可选的
Pod 网络命名空间设置由实现 容器运行时接口 (CRI) 的系统级软件处理。
Pod 网络本身由 Pod 网络实现 管理。在 Linux 上，大多数容器运行时使用 容器网络接口 (CNI) 与 Pod 网络实现进行交互，因此这些实现通常被称为 CNI 插件。
Kubernetes 提供了一个默认的服务代理实现，称为 kube-proxy，但一些 Pod 网络实现会使用它们自己与实现其余部分结合得更紧密的服务代理。
NetworkPolicy 通常也由 Pod 网络实现来完成。（一些较简单的 Pod 网络实现可能不会实现 NetworkPolicy，或者管理员可能选择在没有 NetworkPolicy 支持的情况下配置 Pod 网络。在这些情况下，API 仍然存在，但不会产生任何效果。）
Gateway API 有许多实现，其中一些针对特定的云环境，一些更侧重于“裸机”环境，还有一些则更通用。
连接应用程序与服务 教程通过实践示例让你了解 Service 和 Kubernetes 网络。
集群网络 解释了如何为你的集群设置网络，并概述了所涉及的技术。
要了解特定的网络概念，请参阅