基本概念

在 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 进程，负责将到某个 Service 的訪问给代理或者均衡（仅支持 TCP）到详细的 Pod 上去。

详细的，对每个 service 的訪问地址（比方：10.0.0.2:80），Kube-Proxy 都会配置 DNAT 规则（从容器出来的訪问，从本地主机的訪问双方面），将到这个地址的訪问映射到本地的一个随机port。

然后 Kube-Proxy 会监听在本地的相应port，将到这个port的訪问给代理到远端真实的 pod 地址上去。

Replication-Controller

Replication-Controller 主要是为了实现对 Pod 的自己主动化运维管理（类似 Linux/Nodejs 等平台上的 sueprvisor 工具）。

它能够保障集群内某个 Pod 的执行实例的个数。

这样，当某 Pod 出现问题停止时候。能够自己主动启动新的相同类型的 Pod 来避免服务受到影响。一般推荐通过 Replication-Controller 来创建和管理 Pod。

Pod 须要设置 RestartPolicy = Always，同一时候也是默认值。

设计理念

事实上 Docker 默认採用 NAT 的方式已经组成了简单的网络了。

但Kubernetes 觉得 Docker 的默认网络採用了 NAT 方式，跨节点通信就须要进行port映射，这会给服务的訪问带来麻烦。

设计理念包含例如以下几点：

• 全部容器不使用 NAT 就能够互相通信（这跟 Docker 的默认实现是不同的）；
• 全部节点跟容器之间不使用 NAT 就能够互相通信；
• 容器自己看到的地址，跟其它人訪问自己使用的地址应该是一样的（事实上还是在说不要有 NAT）。

实现

要满足上面的要求。也不难。最简单的方法，容器网络地址空间跟外部网络的数据空间打通就可以，即容器内网络地址直接暴露到物理网上去。

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

这个地址是直接暴露到物理网络上的。能够直接进行路由。

想让 Pod 訪问外网也非常easy，在通往外部网络的网关上做一把 SNAT 就可以。

扩展

当然。在此基础上还能够进行扩展，比方以下几种方案：

CoreOS 的 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