服务、负载均衡和网络

Kubernetes 网络模型

集群中的每个 Pod 都会获得其唯一的集群范围 IP 地址（每个 IP 地址系列一个地址）。这意味着您无需在 Pod 之间显式创建链接，并且几乎不需要处理将容器端口映射到主机端口。
这创建了一个干净、向后兼容的模型，其中 Pod 可以从端口分配、命名、服务发现、负载均衡、应用程序配置和迁移的角度来看待，就像虚拟机或物理主机一样。

Kubernetes 对任何网络实现都施加了以下基本要求（除非有任何有意为之的网络分段策略）：

• Pod 可以与任何其他 节点 上的所有其他 Pod 通信，而无需 NAT
• 节点上的代理（例如系统守护程序、kubelet）可以与该节点上的所有 Pod 通信

这种模式不仅总体上不那么复杂，而且与 Kubernetes 希望实现将应用程序从虚拟机轻松移植到容器的愿望基本兼容。如果您的作业以前在虚拟机中运行，则您的虚拟机有一个 IP 地址，并且可以与您项目中的其他虚拟机通信。这是相同的基本模型。

Kubernetes IP 地址存在于 Pod 范围内 - Pod 内的容器共享其网络命名空间 - 包括其 IP 地址和 MAC 地址。这意味着 Pod 内的容器都可以通过 localhost 访问彼此的端口。这也意味着 Pod 内的容器必须协调端口使用，但这与虚拟机中的进程没有什么不同。这被称为“每个 Pod 一个 IP”模型。

如何实现这一点是所使用的特定容器运行时的细节。

可以请求 节点 本身上的端口，这些端口转发到您的 Pod（称为主机端口），但这是一种非常特殊的操作。如何实现该转发也是容器运行时的细节。Pod 本身并不知道主机端口的存在与否。

Kubernetes 网络解决了四个问题：

• Pod 内的容器 使用网络进行通信，通过环回接口。
• 集群网络提供不同 Pod 之间的通信。
• 服务 API 允许您 公开在 Pod 中运行的应用程序，以便从集群外部访问。
  • Ingress 提供了专门用于公开 HTTP 应用程序、网站和 API 的额外功能。
  • 网关 API 是一个 附加组件，它提供了一系列用于对服务网络建模的表达能力强、可扩展且面向角色的 API 类型。
• 您还可以使用服务来 发布仅供集群内部使用的服务。

使用服务连接应用程序 教程让您通过一个动手示例了解服务和 Kubernetes 网络。

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