容器网络规范

类型:

1.原始容器网络, 桥接 –> Nat 和 端口映射

  • 桥接模式
  • HOST 模式
  • Container 模式

2.容器网络规范

CNM 和 CNI 不是网络实现, 而是网络规范和网络体系. 这两个模型完全插件化的, 用户可以以插件的形式去插入具体的网络实现.

1) Container Networking Model (CNM)

主导 : docker 公司, –> 不够灵活, 是 docker 原生网络实现.

实现 : 现已被 Cisco Contiv, Kuryr , Open Virtual Networking(OVN), Project Calico, VMware 和 weave 这些公司和项目支持.

结构解析:

CNM_drivers

Libnetwork 是 CNM 的原生实现, 他为 docker daemon 和 网络驱动程序之间提供了接口. 网路控制器负责将驱动和一个网络进行对接, 每个驱动程序负责管理它所拥有的网络以及为该网络提供的各种服务, 如 IPAM 等. 由多个驱动支撑的多个网络可以同时并存.

网络驱动可以按提供方式划为原生驱动(libnetwork内置的或docker 支持的)或者远程驱动(第三方插件). 原生驱动包括 none,bridge,overlay,MACvlan.

驱动也可以按照适用范围划分为本地(单主机)和全局(多主机)

CNM_interfaceing

Network Sandbox : 容器内部的网络栈, 包含 interface,路由表,及DNS等配置, 可以看做基于容器网络配置的一个隔离环境(其概念类似 'network namespace') 

Endpoint : 网络接口, 一端在网络容器内, 另一端在网络内. 一个 Endpoint 可以加入一个网络, 一个容器可以有多个 Endpoint.

Network : 一个 Endpoint 的集合, 该集合内的所有 Endpoint 可以互联互通, (其概念类似于 Linux Bridge, VLAN)

CNM 支持标签(lables), lable 是以 key-value对 定义的元数据, 用户可以通过定义lable这样的元数据来自定义 libnetwork 和驱动的行为.

2) Container Networking Interface (CNI)

主导 : google k8s 主导 –> 更具通用性, 十分灵活拍.

实现 : 采纳该规范的包括 Mesos, Cloud Foundry, Kubernets, Kurma, rkt. 另外 Contiv Networking , project Calico 和 Weave 这些项目为 CNI 提供插件支持.

结构解析 :

CNI_Drivers

CNI 的规范比较小巧, 规定了一个容器runtgime 和网络插件之间简单的契约. 这个契约通过 JSON 的语法定义了CNI插件所需要提供的输入和输出. 

一个容器可以被加入到不同插件锁駆动的多个网络之中. 一个网络有自己对应的插件和唯一的名称. CNI 插件需要提供两个指令: 一个用来将网络接口加入到指定网络, 一个用来将其移除. 这两个接口分别在容器被创建和销毁的时候调用.

在使用CNI 接口是容器runtime 首先需要分配一个网络命名空间以及一个容器ID, 然后联通一些CNI配置参数传给网络驱动. 接着网络驱动会将该容器链接到网络并将分配IP地址以及JSON的格式的返回给容器runtime. 

目前 CNI 的功能涵盖了IPAM,L2和L3 , 端口映射(L4) 则用容器runtime 自己负责. CNI 也没有规定端口映射的实现. 这样比较简单的设计对于 Mesos 来讲有些问题. 端口映射是其中之一. 另外一个问题是: 当CNI的配置被改变时, 容器的行为在规范中没有定义. 为此 Mesos 在CNI agent 重启的时候, 会使用该容器与CNI关联的配置.