Kubernetes 文档 / 概念 / 服务、负载均衡和联网

此文档从 Kubernetes 官网摘录
中文地址
英文地址

Kubernetes 网络模型

集群中每一个 Pod 都会获得自己的、独一无二的 IP 地址，这就意味着你不需要显式地在 Pod 之间创建链接，你几乎不需要处理容器端口到主机端口之间的映射。这将形成一个干净的、向后兼容的模型；在这个模型里，从端口分配、命名、服务发现、负载均衡、应用配置和迁移的角度来看，Pod 可以被视作虚拟机或者物理主机。

Kubernetes 强制要求所有网络设施都满足以下基本要求（从而排除了有意隔离网络的策略）：

Pod 能够与所有其他节点上的 Pod 通信，且不需要网络地址转译（NAT）
节点上的代理（比如：系统守护进程、kubelet）可以和节点上的所有 Pod 通信

说明：对于支持在主机网络中运行 Pod 的平台（比如：Linux），当 Pod 挂接到节点的宿主网络上时，它们仍可以不通过 NAT 和所有节点上的 Pod 通信。

这个模型不仅不复杂，而且还和 Kubernetes 的实现从虚拟机向容器平滑迁移的初衷相符，如果你的任务开始是在虚拟机中运行的，你的虚拟机有一个 IP，可以和项目中其他虚拟机通信。这里的模型是基本相同的。

Kubernetes 的 IP 地址存在于 Pod 范围内 —— 容器共享它们的网络命名空间 —— 包括它们的 IP 地址和 MAC 地址。这就意味着 Pod 内的容器都可以通过 localhost 到达对方端口。这也意味着 Pod 内的容器需要相互协调端口的使用，但是这和虚拟机中的进程似乎没有什么不同，这也被称为“一个 Pod 一个 IP”模型。

Kubernetes 网络解决四方面的问题：

一个 Pod 中的容器之间通过本地回路（loopback）通信。
集群网络在不同 Pod 之间提供通信。
Service API 允许你向外暴露 Pod 中运行的应用，以支持来自于集群外部的访问。
- Ingress 提供专门用于暴露 HTTP 应用程序、网站和 API 的额外功能。
- Gateway API 是一个插件，为服务网络建模提供富有表现力、可扩展和面向角色的 API 系列类别。
你也可以使用 Service 来发布仅供集群内部使用的服务。

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

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

—————————————————————————————————————

服务（Service）
将在集群中运行的应用通过同一个面向外界的端点公开出去，即使工作负载分散于多个后端也完全可行。
Ingress
使用一种能感知协议配置的机制来解析 URI、主机名称、路径等 Web 概念，让你的 HTTP（或 HTTPS）网络服务可被访问。 Ingress 概念允许你通过 Kubernetes API 定义的规则将流量映射到不同后端。
Ingress 控制器
为了让 Ingress 在你的集群中工作，必须有一个 Ingress 控制器正在运行。你需要选择至少一个 Ingress 控制器并确保其已被部署到你的集群中。本页列出了你可以部署的常见 Ingress 控制器。
Gateway API
网关（Gateway）API 是一组 API 类别，可提供动态基础设施配置和高级流量路由。
EndpointSlice
EndpointSlice API 是 Kubernetes 用于扩缩 Service 以处理大量后端的机制，还允许集群高效更新其健康后端的列表。
网络策略
如果你希望在 IP 地址或端口层面（OSI 第 3 层或第 4 层）控制网络流量， NetworkPolicy 可以让你为集群内以及 Pod 与外界之间的网络流量指定规则。你的集群必须使用支持 NetworkPolicy 实施的网络插件。
Service 与 Pod 的 DNS
你的工作负载可以使用 DNS 发现集群内的 Service，本页说明具体工作原理。
IPv4/IPv6 双协议栈
Kubernetes 允许你配置单协议栈 IPv4 网络、单协议栈 IPv6 网络或同时激活这两种网络的双协议栈网络。本页说明具体配置方法。
拓扑感知路由
拓扑感知路由提供了一种机制帮助保持网络流量处于流量发起的区域内。在集群中 Pod 之间优先使用相同区域的流量有助于提高可靠性、性能（网络延迟和吞吐量）或降低成本。
服务内部流量策略
如果集群中的两个 Pod 想要通信，并且两个 Pod 实际上都在同一节点运行，服务内部流量策略可以将网络流量限制在该节点内。通过集群网络避免流量往返有助于提高可靠性、增强性能（网络延迟和吞吐量）或降低成本。