k8s007之网络

kubernetes网络

一、有哪些网络问题？

集群网络系统是 Kubernetes 的核心部分。 下面列出的是网络系统的的四个主要问题：

1. Pod中的容器间通信：通过 Pods 和 localhost 通信解决。
2. Pod 与 Pod 之间的通信：通过Overlay Network来解决。
3. Pod 与 服务 之间的通信：通过各节点的Iptables/Ipvs解决。
4. 外部 与 Pod 之间的通信：通过Service/Ingress方式解决。

Kubernetes 的宗旨就是在应用之间共享机器。 通常来说，共享机器需要两个应用之间不能使用相同的端口，但是在多个应用开发者之间去大规模地协调端口是件很困难的事情（网络策略问题），尤其是还要让用户暴露在他们控制范围之外的集群级别的问题上。

动态分配端口也会给系统带来很多复杂度 - 每个应用都需要设置一个端口的参数， 而 API 服务器还需要知道如何将动态端口数值插入到配置模块中，服务也需要知道如何找到对方等等。 与其去解决这些问题，Kubernetes 选择了其他不同的方法。

二、Kubernetes 网络模型

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

Kubernetes 对所有网络设施的实施，都需要满足以下的基本要求（除非有设置一些特定的网络分段策略）：

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

备注：仅针对那些支持 Pods 在主机网络中运行的平台（比如：Linux），那些运行在节点的主机网络里的 Pod 可以不通过 NAT 和所有节点上的 Pod 通信

三层网络模型

可以简单的把 kubernetes 网络划分为三层：

• Pod与 Pod 之间通信通过 Pod 网络（底层）
• Pod 与 服务之间通信通过 Service 网络（中间层）
• Pod 与 外部 之间通信通过 节点网络（外层）

这个模型不仅不复杂，而且还和 Kubernetes 的实现廉价的从虚拟机向容器迁移的初衷相兼容， 如果你的工作开始是在虚拟机中运行的，你的虚拟机有一个 IP ， 这样就可以和其他的虚拟机进行通信，这是基本相同的模型。

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

有很多种方式可以实现这种网络模型，这里仅仅介绍一种，Flannel网络。Flannel 是一个非常简单的能够满足 Kubernetes 所需要的覆盖网络。

三、Flannel网络

Flannel 是 CentOS 团队针对kubernetes 设计的一个网络规划服务（k8s太火了，因此CentOS团队专门针对k8s开发设计了Flannel网络），简单来说：它的功能是让集群中的不同节点主机创建的 Docker 容器都具有全集群唯一的虚拟 IP 地址，并在这些 IP 地址之间建立了一个覆盖网络（通常称为Overlay Network），通过这个覆盖网络，就可以将数据包原封不动的传递到指定的目标容器内，从而达成通信。

注明：ETCD 会存储并管理 Flannel 可分配的 IP 地址段资源；Flannel 会监控 ETCD 中每个 Pod 的实际地址，并在内存中建立维护 Pod 节点路由表。

详细说明

• 同一个 Pod 内部通信：同一个 Pod 共享同一个网络空间，共享同一个 Linux 协议栈（例如localhost），所以天然互通。

• Pod1 到 Pod2 之间的通信分为两种情况：

  • Pod1 和 Pod2 在同一台机器，由 Docker0 网桥直接转发请求至 Pod2，不需要经过 Flannel
  • Pod1 和 Pod2 不在同一台机器，Pod 地址是与 Docker0 在同一个网段的，但是 Docker0网段与宿主机是两个完全不同的 IP 网段（如上图），并且不同 Node 之间的通信只能通过宿主机的物理网卡进行。将 Pod 的 IP 和所在的 Node 的 IP 通过 Flannel 关联起来，这个关联可以让不同 Node 的 Pod 之间可以互相访问。

• Pod 到 Service 之间的网络：目前基于性能考虑，由 iptable/ipvs（默认iptable，但ipvs性能更高）维护和转发。

• Pod 到 外网的通信：Pod 向外网发送请求，会查找路由表，转发数据包到宿主机的网卡，宿主机网卡通过路由选择iptables/ipvs 执行 Masquerade，把源 IP 更改为宿主网卡的IP，然后就可以向外部网络发送请求。

• 外网 到 Pod 的通信：通过Servcice（四层网络）、Ingress（七层网络）等技术实现。

四、k8s组件间通信原理

• API Server 负责 etcd 存储的所有操作，且只有 API Server 才直接操作 etcd 集群。
• API Server 对内（集群中的其他组件）和对外（用户）提供统一的 REST API，其他组件均通过 API Server 进行通信。
• Controller Manager、Scheduler、Kube-proxy 和 Kubelet 等均通过 API Server watch API 监测资源变化情况，并对资源作相应的操作。
• 所有需要更新资源状态的操作均通过 API Server 的 REST API 进行。
• API Server 也会直接调用 Kubelet API（如 logs, exec, attach 等），默认不校验 Kubelet 证书，但可以通过 --kubelet-certificate-authority 开启（而 GKE 通过 SSH 隧道保护它们之间的通信）。

可以看出API Server 是通信的核心，因此，k8s的安全设计就是围绕API Server设计的。

比如典型的创建 Pod 的流程为：

1. 用户通过 REST API 创建一个 Pod。

2. API Server 将其写入 etcd。

3. Scheduler 检测到未绑定 Node 的 Pod，开始调度并更新 Pod 的 Node 绑定。

4. Kubelet 检测到有新的 Pod 调度过来，通过 Container Runtime 运行该 Pod。

5. Kubelet 通过 Container Runtime 取到 Pod 状态，并更新到 API Server 中。