Cloud Foundry中warden的网络设计实现——iptable规则配置

       

        在Cloud Foundry v2版本中，该平台使用warden技术来实现用户应用实例运行的资源控制与隔离。

        简要的介绍下warden，就是dea_ng如果需要运行用户应用实例（本文暂不考虑warden container提供staging打包环境），则发送相应请求给warden server，由warden server来创建warden container，并在warden container内部运行应用实例，而warden container的具体实现中使用cgroups等内核虚拟化技术，保证了container内进程组的资源控制与隔离。warden的架构与实现可以参考我的博文：Cloud Foundry中warden的架构与实现。

warden网络架构图

        warden container的功能可以认为与传统的虚拟机类似，只是传统的虚拟机通过Hypervisor等技术来实现资源的控制与隔离，而warden container通过虚拟化内核来达到该目的。而在网络方面，warden container技术创建出一块虚拟网卡，专门供warden container内部使用，另外为warden container内部的虚拟网卡在warden server所在的宿主机上也配对了一块虚拟网卡，充当container的外部网关。仅仅创建出两块虚拟网卡，原则上可以保证物理上的“连通”，但是却很难做到网络间通信的“联通”，故在物理资源以及虚拟物理资源完备的情况，warden server在宿主机上通过iptables设计并添加了多条规则，保证整个网络的通信可以满足warden container的要求，同时又不影响宿主机的通信。

        以下是warden server所在宿主机的物理环境、iptables所在的网络层、操作系统、用户应用层之间的关系图：

warden container网络通信方式

        在Cloud Foundry中，由于warden container用来运行用户应用实例，而应用用户实例与外界的通信在Cloud Foundry中目前无外乎两种：

1. 用户应用实例作为一个web server，提供HTTP访问服务；
2. 用户应用实例使用service服务时，建立与service instance的连接。

        当然有些Cloud Foundry平台开发者肯定会认为用户应用实例，可以作为一个client端，通过url访问其他应用实例或者访问云外的资源。在这里需要申明的是，首先Cloud Foundry集群默认对应用实例不暴露ip；其次，假设Cloud Foundry内部不存在或者不能连接一个强大的DNS server，用来解析外部资源的url。

        本文即将以上两点作为主要研究的内容，进行warden所在宿主机的网络分析，集中于iptables一块。

warden iptables配置之net.sh文件

       

        在warden的实现过程中，关于iptables的配置主要包括两个部分：

1. 启动warden server时，调用文件warden/warden/root/linux/net.sh，制定warden server所在宿主机的部分iptables规则；
2. 在创建warden container的时候，调用文件warden/warden/root/linux/skeleton/net.sh，制定由于warden container创建后需要添加的iptables规则（包括仅仅创建一个warden container的iptables设置，以及为一个warden container做端口映射时的iptables设置）。

warden server之net.sh

       

setup_filter

       
        关于 warden/warden/root/linux/net.sh，可以看该shell脚本中最为关键的两个方法setup_filter以及setup_nat。以下是setup_filter的源码实现：

function setup_filter() {
  teardown_filter

  # Create or flush forward chain
  iptables -N ${filter_forward_chain} 2> /dev/null || ipta