从 Kubernetes 谈容器网络

在 Kubernetes 中，资源从管理粒度上分为三级：容器、Pod、Service。

容器

---

即 Docker 或者 Rocket 容器（1.0 中仅支持这两种容器）。
容器是最低粒度的资源，但是不能被直接操作。

Pod

---

Kubernetes 中的基本操作单元（非单个容器）。
Pod 是一组共享了下面资源的（运行在同一节点上的）容器：
进程命名空间
网络命名空间
IPC 命名空间（可以 SystemV IPC 或 POSIX 消息队列通信）
UTS 命名空间（同一主机名称）
可以将一个 Pod 当作是一个抽象的“虚拟机”，里面运行若干个不同的进程（每个进程实际上就是一个容器）。
比如某个后端应用是若干处理组件组成，可以作为一个后端 Pod。
一个 Pod，往往带有若干 label，比如 type=prod, app=nginx 之类，并且被 kubelet 汇报到 Endpoints 中记录。
实现上，是先创建一个 gcr.io/google_containers/pause 容器，然后创建同一个 Pod 中的其它容器，共享 pause 容器的命名空间。
Kubernetes 要干的事情是要把这些 Pod 给互相连接起来，是不是联想到了什么了？跟虚拟机网络的基本需求是相同的。

Service

---

Service 是一类运行相同/相似应用（通过 label 来过滤）的 Pod，组成一个完整的服务。比如一组前端 Pod，形成一个前端 Service。

Service 主要是为了： 解耦直接对 Pod 的访问（Pod 是动态的，随时可能停止或变化） 提供隐式的负载均衡（可以配置均衡策略到后端真实的 Pod）

访问其实是以 Service 为单位的，可以通过 DNS 或者（写入环境变量的） Cluster 地址来解耦掉实际的 Pod 地址。实现上是通过 Kube-Proxy 进程。

kube-proxy

实际上，每个节点上都会运行一个 Kube-Proxy 进程，负责将到某个 Service 的访问给代理或者均衡（仅支持 TCP）到具体的 Pod 上去。

具体的，对每一个 service 的访问地址（比如：10.0.0.2:80），Kube-Proxy 都会配置 DNAT 规则（从容器出来的访问，从本地主机的访问两方面），将到这个地址的访问映射到本地的一个随机端口。然后 Kube-Proxy 会监听在本地的对应端口，将到这个端口的访问给代理到远端真实的 pod 地址上去。

Replication-Controller

Replication-Controller 主要是为了实现对 Pod 的自动化运维管理（类似 Linux/Nodejs 等平台上的 sueprvisor 工具）。它可以保障集群内某个 Pod 的运行实例的个数。

这样，当某 Pod 出现故障停止时候，可以自动启动新的同样类型的 Pod 来避免服务受到影响。一般推荐通过 Replication-Controller 来创建和管理 Pod。Pod 需要设置 RestartPolicy = Always，同时也是默认值。

设计理念

其实 Docker 默认采用 NAT 的方式已经组成了简单的网络了。但Kubernetes 认为 Docker 的默认网络采用了 NAT 方式，跨节点通信就需要进行端口映射，这会给服务的访问带来麻烦。

设计理念包括如下几点：
所有容器不使用 NAT 就可以互相通信（这跟 Docker 的默认实现是不同的）；
所有节点跟容器之间不使用 NAT 就可以互相通信；
容器自己看到的地址，跟其他人访问自己使用的地址应该是一样的（其实还是在说不要有 NAT）。
实现
要满足上面的要求，也不难，最简单的方法，容器网络地址空间跟外部网络的数据空间打通即可，即容器内网络地址直接暴露到物理网上去。

Kubernetes 的基于 GCE 的实现就是这种机制，给每个物理节点直接分配一个内部子网（默认是 /24 的），这样每个 Pod 就能分到一个地址了（意味着每个节点最多 256 个 Pod）。这个地址是直接暴露到物理网络上的，可以直接进行路由。

想让 Pod 访问外网也很简单，在通往外部网络的网关上做一把 SNAT 即可。

---

扩展

当然，在此基础上还可以进行扩展，比如下面几种方案：

CoreOS 的 Flannel

Flannel内部流量出到物理网之前，非本地的流量过一下整个内部网的网关，然后用 UDP/VXLAN 封装下，直接 tunnel 到对端后进行解包。

Weave

Weave 的网络设计也是对承载网这部分进行改进，对这部分流量进行封装，发送到对端的 peer 上，但不清楚封装协议类型。

socketplane

SocketPlane 的思路也是大同小异，在主机之间建 Tunnel，本地网桥默认使用 OpenvSwitch。

不同的主机发现采用 mDNS。

这家被 Docker 给收购了，很奇怪，背后应该有一些故事。

OpenStack Neutron

其实，现在的面向虚拟机的网络方案（比如 OpenStack Neutron）早就已经实现了上面的几点，而且使用网络虚拟化的手段，能做到比上面具有更加丰富和灵活的特性。例如，不同物理机上的容器可以拥有任意相同或者不同的子网，并且可以实现多租户的概念。

如果使用 Nova-Docker 来管容器的话，默认采用的就是 Neutron 网络。

结论和展望

---

网络的设计离不开对需求的深入分析。

从目前的几个项目来看，大家都是在模仿虚拟机的网络来实现容器的网络，甚至还有不少地方没有达到虚拟机网络的成熟度。

未来至少应该从下面两个方面去考虑设计容器网络：

本地的优化：虚拟机的本地网络经过多年优化已经逼近了线速，但容器网络在这方面还有不少坑，特别对物理设备虚拟化技术的支持等。挖掘性能，降低对主机资源的消耗，仍有一些工作要做；
网络特性的优化：容器网络根本上跟虚拟机网络存在很大的差异，这体现在容器的生命周期和使用行为上有很大的不同，传统的网络特性并不能很好地满足这些需求。

---

http://blog.csdn.net/yeasy/article/details/46443933