简介：

Kubernetes网络解决下面四类不同的问题：

　1. 高耦合容器和容器间通信,通过 Pod 和 localhost 访问解决。
　2. Pod和Pod间通信,建立通信子网，比如隧道、路由，Flannel、Open vSwitch、cailco。
　3.Pod和Service间通信，以及外部系统和Service的通信，引入Service解决。
　4.外部和内部通信，通过ingress解决。

Kubernets 常用的网络方案

• Flannel

  参考链接：https://github.com/coreos/flannel#flannel

• Google Compute Engine (GCE)

  参考链接：http://kubernetes.io/docs/admin/networking/#google-compute-engine-gce

• L2 networks and linux bridging

  参考链接：http://kubernetes.io/docs/admin/networking/#l2-networks-and-linux-bridging

• OpenVSwitch

  参考链接：http://kubernetes.io/docs/admin/ovs-networking

• Project Calico

  参考链接：https://github.com/projectcalico/calico-containers/blob/master/docs/cni/kubernetes/README.md

• 其他方式

  参考链接：https://github.com/kubernetes/kubernetes/blob/master/docs/design/networking.md

Kubernets 默认使用了CoreOS项目里的Flannel，常用的几种工作模式：

• udp - 默认[使用udp协议传输]
• vxlan - 目前CacheMoment正在使用的模式，创建一个虚拟的
  VXLAN 接口。
• host-gw - 通过远程机器 IP ，创建到子网的 IP 路由。这要求运行 flannel 的不同主机在
  二层直接互通。
• aws-在 Amazon AWS 实例表中注册新增机器子网。该实例表最多支持 50 项记录，这意味着，如果你
  使用 flannel + aws-vpc 方案，集群最多只能包含 50 台机器，集群也只能运行在 AWS 云平台。
• gce-GCE Backend for Flannel

性能测试

性能测试参考：kubernetes网络性能

网络规划

1. 网络的现状

以下摘自互联网文章，具体在这里：
从容器诞生开始，存储和网络这两个话题就一直为大家挂在嘴边。我们今天这个环境下讲网络这个问题，其实是因为容器对网络的需求，和传统物理、虚拟环境对网络环境需求非常不一样。虚拟网络做了很多工作，比如说虚拟路由器虚拟交换机，现在发现容器环境不是那么好就能够适配。很重要原因： 虚拟时代几百个虚拟机可能就不少了，大不了就几千个；但容器时代谈微服务，一个应用一个庞大的生态系统，那么多服务，每个服务都有那么多容器实力，他们在一起构成这么多生态系统之后，他们的力度要比传统虚拟机小得多，他们的离散度也比传统的虚拟机要明显高很多，所以会对网络有着更高的要求。
容器技术发展到今天，容器网络一直发展比较滞后，不知道大家有没有这样的感觉？以前很早的时候就对存储Docker就发布了Volume Plugin这样一个接口。但是网络层面一直没有一个标准，直到近期才出现了一个叫CNM的规范。所以说它的网络一直发展比较滞后。这种情况给大量创业公司或者开源组织提供了一个空间，他们开发了各种各样的网络实现，并且没有出现一家独大的状态，而是有了很多复杂的解决方案，让客户无从挑选。
有些客户感觉SDN很好，把SDN概念引进到容器领域，结果把个问题变得更复杂，所以我们看到大量客户对容器网络选型非常挠头。不仅是客户，方案解决提供商每天也在思考能提供什么样的容器网络方案满足客户的需求。所以，我们今天把网络重点和大家梳理一下。
容器网络发展经历了三个阶段。第一个阶段是“石器时代”，最早的容器网络模型，就是主机内部的网络，想要把服务暴露出去需要做端口映射，非常原始古老。例如一个主机内有很多Apache容器，每一个Apache要往外抛80的端口，那我怎么办？我需要针对第一个容器和主机80端口做映射，第二个和主机81端口做映射，依此类推，到最后发现非常混乱，没办法管理。这个东西石器时代的网络模型，基本上没办法被企业采用。
后来进化到下一个阶段，我们称之为豪杰辈出的解决方案，非常优秀的比如Rancher基于IPSec的网络实现，比如Flannel基于三层路由的网络实现，包括我们国内也有一些开源项目都在做。
时至今日，容器网络出现了双雄会的格局。一个以Docker领导的和开发的CNM架构，另一个以Google、Kubernetes、CoreOS主导开发的CNI架构。

2. 现在的工作

我们会发现容器网络技术不外乎出自两个技术流派，第一个隧道技术，比如说Flannel的VXLAN模式。这个技术的特点是对底层的网络没有过高的要求，通常来说唯一的要求就是就是三层可达——你的主机只要是在一个三层可达网络里，就能给你构建出一个基于隧道的容器网络，对网络要求比较低。但问题在于什么呢？一旦构建了Overlay的网络，目前企业已经构建的网络监控的价值，以及企业网络部门的管理职能就会降低很多，因为传统的网络设备根本看不到你在隧道里面跑了什么样的数据，也就无从监控和管理。同时我们知道所有的Overlay网络基本核心的实现点都在主机内部，而网络管的又不是主机，他们管的是下层网络，结果现在必须管一部分主机里的虚拟设备，而传统主机的管理应该是系统部，那么就会出现交叉管理，网络部和系统部出现权责不分的情况，导致很多客户不愿意使用隧道技术。
第二种技术是路由技术，路由技术好处在于很干净，没有NAT，效率比较高，和目前的网络能够融合在一起，每一个容器都可以像虚拟机一样分配一个业务的IP。大家可以用最自然最容易接受的方式使用容器，好像你就分配了一个新的虚拟机一样。但路由网络也有两个问题，一旦使用了路由网络对现有网络设备冲击非常大，现在做网络同志应该知道，路由器的路由表应该有空间限制——两三万条。如果一下子几万新的容器IP冲击到路由表里，导致下层的物理设备没办法承受；同时每一个容器都分配一个业务IP，你的业务IP很快消耗光了。一般大型的企业里IP分配是很有原则的，可能分配给容器平台项目的IP也就是几千个，或者一个段，没有办法让你在每一个容器里都分配一个IP。这就是路由和隧道技术，我们没有看到一个完美的技术，每一个都有优势也都有劣势。
根据目前的情况看，路由技术无论性能还是维护成本都是首选。我们在现阶段采用Flannel 的host-gw模式，下面是host-gw的一个案例；

环境准备

• OS: CoreOS alpha
• kubernetes master: 在一台虚拟机上部署kubernetes master相关组件。作为集群的管理和协调者(172.24.3.150)。
• kubernetes nodes: 在两台物理机上部署kubernetes worker节点的相关组件(两台物理机分别为172.24.2.207, 172.24.2.208)。
• flannel 版本： 0.5.5
• 物理机配置：
  CPU :24 core Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
  内存:64G memory
  网卡:Intel Corporation I350 Gigabit Network Connection 千兆网卡（4口）

网络拓扑

网络配置

使用下面这个链接的cloud-config完成master和worker的配置：https://github.com/typhoonzero/kubernetes_binaries/tree/master/cloud-config 部署方式参考这个链接

性能测试

场景：

node01(172.24.2.207): pod01 (coides-server)
node02(172.24.2.208):pod02(coides-client)
方法：通过pod02->pod01加压
测试结果：

3. 未来的目标

官方网络现在采用flannel网络插件，模式采用udp，但是性能差的一塌糊涂；vxlan模式overly网络性能比udp好很多，但是延迟比较大，当网络拓扑非常大了维护可是非常考验团队的能力；host-gw采用主机路由模式比上面的两个网络好的多，是现在最理想的网络模式，可是它也有自己的不足，这要求运行 flannel 的不同主机在二层直接互通。

近期目标

目前建议选择 flannel + host-gw 方案，没有特别依赖，性能也够用。一旦 flannel 支持 IPvlan （有自动化设置工具了），且 Linux 内核版本比较新，就可以采用 IPvlan 方案。
具体参考：一个适合 Kubernetes 的最佳网络互联方案
IPVlan参考:https://github.com/docker/docker/blob/master/experimental/vlan-networks.md
IPvlan 是 Linux 内核中的一个驱动，有了它，无需使用桥接接口，就可以创建拥有唯一 IP 地址的虚拟网络接口。
使用 IPvlan 为容器分配一个 IP 地址，需要下列步骤：

• 创建一个不包含任何网络接口的容器；
• 在默认的网络命名空间中创建一个 ipvlan 接口；
• 把新建的 ipvlan 接口转移到容器的网络命名空间。

IPvlan 是一个相对较新的解决方案，现在还没有能完成上述过程的自动化工具。如果集群的机器和容器比较多，部署 IPvlan 的难度不小，不容易设置。

不过， IPvlan 不需要使用桥接接口，网络包从网卡直接转发到虚拟网络接口，我们预期它的性能应该好于 flannel 。

远期目标

对于k8s网络规划理想的状况是，可以分成一下几种情况

1. 通用模式：那些对网络性能要求不高的用户可以采用当前官方的提供网络模式，可以快捷方便的搭建；
   2.高性能模式：对于网络性能要求很高的用户，可以采用linux内核自带的虚拟网卡驱动，ipvlan和macvlan；
   3.多租户网络模式：当容器规模很大和环境复杂的时候租户隔离就显得比较重要了，我们这里只讨论网络隔离，公有云中心网络是一个多租户网络。因为中心网络需要提供给云计算用户服务，这些服务的计算资源是按照云用户提供租借计算资源和应用软件服务的。在多租户网络中，需要保持各个租户之间的相互独立和隔离，需要为每个租户实施不同的网络服务和应用提供策略。同时，租户网络又是动态地变化网络，需要根据用户的请求，快速实现部署和配置，实现公有云的商业服务模式。
   数据中心网络是一个融和网络，存储网络、数据网络、特殊应用网络完全融和在一起，所以要根据每种网络的需求不同，部署不同的网络策略。
   可以参考一下：使用开源Calico构建Docker多租户网络

背景知识

vxlan

参考链接：https://en.wikipedia.org/wiki/Virtual_Extensible_LAN

udp

参考链接：https://en.wikipedia.org/wiki/UDP

OpenVSwitch

参考链接：https://en.wikipedia.org/wiki/Open_vSwitch

OSI7层模型

参考链接：https://en.wikipedia.org/wiki/OSI_model