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 <[email protected]> | larsks @ {freenode,twitter,github} Cloud Engineering / OpenStack | http://blog.oddbit.com/
pgpJNhfmzhr7O.pgp
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
