服务、负载均衡和联网

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

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

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

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

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

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

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

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

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

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

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

    将在集群中运行的应用程序暴露在单个外向端点后面，即使工作负载分散到多个后端也是如此。

    为了让 Ingress 在你的集群中工作， 必须有一个 Ingress 控制器正在运行。你需要选择至少一个 Ingress 控制器并确保其已被部署到你的集群中。 本页列出了你可以部署的常见 Ingress 控制器。

    EndpointSlice

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

    网络策略

    如果你希望在 IP 地址或端口层面（OSI 第 3 层或第 4 层）控制网络流量， NetworkPolicy 可以让你为集群内以及 Pod 与外界之间的网络流量指定规则。 你的集群必须使用支持 NetworkPolicy 实施的网络插件。

    Service 与 Pod 的 DNS

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

    IPv4/IPv6 双协议栈

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

    拓扑感知提示
    Windows 网络
    Service ClusterIP 分配
    服务内部流量策略

    如果集群中的两个 Pod 想要通信，并且两个 Pod 实际上都在同一节点运行， 服务内部流量策略 可以将网络流量限制在该节点内。 通过集群网络避免流量往返有助于提高可靠性、增强性能（网络延迟和吞吐量）或降低成本。

    使用拓扑键实现拓扑感知的流量路由