基于容器的PaaS平台，若希望容器网络外部可达，有什么实现方案？
客户需求
1.在很多场景中用户对于容器网络的使用，还是希望业务与管理隔离，即通过一张独立的网卡来运行业务流量。
2.在混合组网的场景中，用户一部分业务运行在裸机中，另一部分业务运行在容器内
1同行回答
你好，针对于rancher实现的扁平网络，内部CNI网络主要需要解决两个问题：
1.如何访问Metadata和DNS server的地址169.254.169.250；
2.采用独立的网卡来转发业务流量后，二层广播域跨主机了，若每台主机上还通过同一个IP 169.254.169.250访问DNS和Metadata服务，如何解决地址冲突的问题；
1.container-1内部有到达169.254.169.250的一条主机路由，即要访问169.254.169.250需要先访问10.43.0.2；
2.通过veth-cni与veth-doc的链接，CNI bridge下的container-1可以将ARP请求发送到docker0的10.43.0.2地址上。由于10.43.0.2的ARP response报文是被veth-cni放行的，于是container-1能够收到来自10.43.0.2的ARP response报文。
3.然后container-1开始发送到169.254.169.250的IP请求，报文首先被送到docker0的veth-doc上，docker0查询路由表，将报文转到DNS/metadata对应的容器。然后IP报文原路返回，被docker0路由到veth-cni上往br0发送，由于来自169.254.169.250的IP报文都是被放行的，因此container-1最终能够收到IP。
4.由于属于该network的所有的宿主机的docker0上都需要绑定IP地址10.43.0.2；因此，该IP地址必须被预留，即，在catalog中填写CNI的netconf配置时，不能将其放入IP地址池。
5.同时，为了保障该地址对应的ARP请求报文不被发送出主机，从而收到其他主机上对应接口的ARP响应报文，需要对所有请求10.43.0.2地址的ARP REQUEST报文做限制，不允许其通过br0发送到宿主机网卡。