# 服务、负载均衡和网络

## Kubernetes 网络模型

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

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

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

{% hint style="info" %} <mark style="color:blue;">**说明：**</mark>

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

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

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

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

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

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

* 一个 Pod 中的容器之间通过本地回路（loopback）通信。
* 集群网络在不同 Pod 之间提供通信。
* Service API 允许向外暴露 Pod 中运行的应用，以支持来自集群外部的访问。
  * Ingress 提供专门用于暴露 HTTP 应用、网站和 API 的额外功能。
* 也可以使用 Service 来发布仅供集群内部使用的服务

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

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