CoreOS：在etcd2 cloud-config中注入真正的私有IP

我在Rackspace上有三个networking：

1. 公共networking
2. 服务networking10.181.XXX.XXX （他们有时把它称为私有networking，但它不是私有的，它是数据中心私有的，因此它们的租户可以共享它）
3. 一个真正的私人networking192.168.3.0/24通过networking用户界面创build

我的计划是推出一个安全的etcd集群，其etcd对等端和客户端仅限于真正的专用networking，因此无法用于外部世界。

所以，我推出了一个CoreOS服务器，它有三个接口：

1. eth0有公网的IP地址 – 很好
2. eth1有服务networking的IP地址 – 很好
3. eth2具有专用networking的IP地址 – 太棒了！

所有看起来不错，但etcd绑定到服务networking，而不是我手动创build的私人。 这是一个cloud-config ：

• 使用USB设备和CoreOS ISO安装CoreOS
• 系统失控开始服务
• neo4j docker coreos – 将所有内容logging到控制台
• 如何为CoreOS使用2个磁盘？
• 在Grid K2下显示奇怪的bios，uuid的nvidia驱动程序

 #cloud-config coreos: etcd2: discovery: https://discovery.etcd.io/XXX advertise-client-urls: http://$private_ipv4:2379,http://$private_ipv4:4001 initial-advertise-peer-urls: http://$private_ipv4:2380 listen-client-urls: http://$private_ipv4:2379,http://$private_ipv4:4001 listen-peer-urls: http://$private_ipv4:2380 

这意味着$private_ipv4variables被扩展到eth1 IP地址，这里是/etc/environment的内容：

 COREOS_PUBLIC_IPV4=166.78.XXX.XXX COREOS_PRIVATE_IPV4=10.181.XXX.XXX 

好吧，看起来像Rackspace注入自己的networking，这是可以解释的。 但是这是否意味着etcd只locking到前两个networking，并且没有办法将其configuration为使用真正的私有networking？

我已经尝试了一堆这样的黑客：

 listen-peer-urls: http://`/usr/bin/ifconfig eth2 | /usr/bin/grep --word-regexp inet | /usr/bin/awk '{print $2}'`:2380 

和其他人，但没有得到正确执行，也没有取代cloud-config 。

我的问题是：

1. 我在CoreOS集群设置领域做了些奇怪的事情，以至于我无法轻松自然地实现目标？ 如果是这样的话，你将如何build立一个安全的集群，在一个真正的专用networking中运行etcd ？
2. 有没有办法将dynamic值“注入”到cloud-init文件中，以便在运行时插入？ 问题是，IP地址是不知道的，所以它需要得到和注入我想。