服务、负载均衡和联网

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

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

    • 节点上的代理（比如：系统守护进程、kubelet）可以和节点上的所有 Pod 通信

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

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

    如何实现以上需求是所使用的特定容器运行时的细节。

    也可以在 Node 本身请求端口，并用这类端口转发到你的 Pod（称之为主机端口）， 但这是一个很特殊的操作。转发方式如何实现也是容器运行时的细节。 自己并不知道这些主机端口的存在。

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

    • 一个 Pod 中的容器之间。
    • 集群网络在不同 Pod 之间提供通信。
    • Service 资源允许你 ， 以支持来自于集群外部的访问。
      • Ingress 提供专门用于暴露 HTTP 应用程序、网站和 API 的额外功能。
    • 你也可以使用 Service 来。

    使用一种能感知协议配置的机制来理解 URI、主机名称、路径和更多 Web 概念，使得 HTTP（或 HTTPS）网络服务可用。 Ingress 概念允许你通过 Kubernetes API 定义的规则将流量映射到不同的后端。

    EndpointSlice API 是 Kubernetes 用于扩缩 Service 以处理大量后端的机制，还允许集群高效更新其健康后端的列表。

    你的工作负载可以使用 DNS 发现集群内的 Service，本页说明具体工作原理。

    Kubernetes 允许你配置单协议栈 IPv4 网络、单协议栈 IPv6 网络或同时激活这两种网络的双协议栈网络。本页说明具体配置方法。

    **拓扑感知提示（Topology Aware Hints）**提供了一种机制来帮助将网络流量保持在其请求方所在的区域内。 在集群中的 Pod 之间优先选用相同区域的流量有助于提高可靠性、增强性能（网络延迟和吞吐量）或降低成本。