Open Stack

On Tue, Oct 07, 2014 at 06:14:22PM +1100, Angus Lees wrote:
> What you haven't stated here is whether the catalog endpoints should be 
> reachable outside the kubernetes minions or not.

I thought I had been clear about that, but reading over the email it
looks like the part where I made that clear was actually already iny
my head.

This solution was meant primarily to facilitate pod-to-pod
communication, particularly in cases where a service ends up moving
from one minion to another.

I agree that
https://github.com/GoogleCloudPlatform/kubernetes/issues/1161 needs to
land for a kubernetes-only solution to external access.  Without that,
public urls will need to come through some sort of load balancer
solution or something.  I haven't really thought about that in any
detail at this point.

> Perhaps we could even use this mysterious(*) keystone publicURL/internalURL 
> division to publish different external and kubernetes-only versions, since we 
> can presumably always do more efficient communication pod<->pod.

That is pretty much exactly what I am doing.

> 1.  Fixed hostname
> 
> Add something like this to the start.sh wrapper script:
>  echo $SERVICE_HOST proxy >> /etc/hosts
> and then use http://proxy:$port/... etc as the endpoint in keystone catalog.

This was one of my first thoughts, but according to the
#google_containers folks, SERVICE_HOST is going away real soon now:

  https://github.com/GoogleCloudPlatform/kubernetes/pull/1402

There will be a per-service ip available, so we could still do
something similar.

> Create a regular OpenStack loadbalancer and configure this (possibly publicly 
> available) IP in keystone catalog.
> 
> I _think_ this could even be a loadbalancer controlled by the neutron we just 
> set up, assuming the the loadbalancer HA works without help and the nova<-
> >neutron "bootstrap" layer was setup using regular k8s service env vars and 
> not the loadbalancer IPs.

There's no guarantee that we're running Kubernetes on top of
openstack, and I don't think we could use Neutron deployed inside
kubernetes because we'd want the LB in place for basic services like
keystone and the database server.

> In case it needs to be said, I think we should watch discussions like 
> https://github.com/GoogleCloudPlatform/kubernetes/issues/1161 and try to 
> follow the "standard" kubernetes approaches as they emerge.

Yup, I think that is definitely the way to go.

-- 
Lars Kellogg-Stedman <lars at redhat.com> | larsks @ {freenode,twitter,github}
Cloud Engineering / OpenStack          | http://blog.oddbit.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141007/b07c16ce/attachment.pgp>