From: Adrian Otto <adrian.o...@rackspace.com<mailto:adrian.o...@rackspace.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Tuesday, July 14, 2015 at 11:11 AM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [magnum] The way magnum-conductor communicates with k8s master
On Jul 13, 2015, at 8:40 PM, Steven Dake (stdake) <std...@cisco.com<mailto:std...@cisco.com>> wrote: From: "OTSUKA, Motohiro" <yuany...@oeilvert.org<mailto:yuany...@oeilvert.org>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Monday, July 13, 2015 at 8:11 PM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [magnum] The way magnum-conductor communicates with k8s master Hi, Wanghua Currently magnum-conductor can communicates with k8s master which has a floating ip in all-in-one deployment. But if magnum-conductor is not deployed on the neutron network node which has the br-ex, how can magnum-conductor communicate with k8s master. The magnum-conductor node then has no access to the k8s master. Currently this is a limitation of our architecture. The floating IP is a public routed network, so it should be able to communicate in a properly setup cloud. Another question: Magnum-conductor only communicate with k8s master, why k8s minion has a floating ip too? What is the floating ip of k8s minion used for? I think, there is no reason. Historically, Our heat template come from larsks/heat-kubernetes [1] template. larsks/heat-kubernetes provides floating ip to minion nodes, this is just a reason. The minion floating ips are needed to access the micro-service front ends from the internet. To be clear, the actual requirement is that the minion nodes must be able to make TCP connections to the master node. Depending on the routing setup on your nodes, and the arrangement of your network, that could be possible without a floating ip on the minion nodes. With that in mind, having a publicly routable address (floating ip) on your minion node is one way to produce such connectivity. Iām sure we would be open to a proposal that eliminates our requirement for the floating ip on the minion nodes that would work properly in various network environments. The minions need to be publically routed, but the master does not. The reason minions need to be publically routed is because front end applications (such as chrome) access the microservices running in the k8s cluster via their publically routed ip address. Regards -steve Adrian Regards -steve [1]: https://github.com/larsks/heat-kubernetes Thanks -Yuanying __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org<mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
