Name kubernete generated Google cloud ingress load balancer

0
votes

I have multiple kubernetes clusters that have Google powered load balancers (ingress lbs).

So right now to access my k8s cluster service (s) I just have to ping the public IP given by the $ kubectl get service, cool.

My problem is that sometimes I need to tear down/create clusters, reconfigure services, those services might also need SSL certificates very soon, and my clusters'/services' builds needs to be easily reproducible too (for cloud devs!).

The question is simple: can I instead of having an ingress load balancer IP have an ingress load balancer hostname?

Something like ${LOAD_BALANCER_NAME}.${GOOGLE_PROJECT_NAME}.appspot.com would be uber awesome.

1
google-compute-enginegoogle-cloud-platformkubernetes
Why do you think you need to tear down clusters frequently? Are you creating a separate cluster for each Dev, and tearing them down when not used to save on cost? – Eric Tune
Yes, also to change cluster scopes or machine type I have to tear down the whole cluster and create a new one, with this script : gist.github.com/azr/13e72daa9ec968f52d5d This happens a lot in dev and it's really painfull to have te redeploy dependencies just to change the ip :) – Azr

1 Answers

1
votes

Kubernetes integration with google cloud DNS is a feature request for which there is no immediate timeline (it will happen, I cannot comment on when). You can however create DNS records with the static ip of a loadbalancer.

If I've understood your problem correctly, you're using an L4 loadbalancer (service.Type=LoadBalancer) and you want to be able to delete the service/nodes etc and continue using the same IP (because you have DNS records for it). In other words, you want a loadbalancer not tied to the service lifecycle. This is possible through an L7 loadbalancer [1] & [2], or by recreating the service with an existing IP [3].

Note that [1] divorces the loadbalancer from service lifetime, but if you take down your entire cluster you will lose the loadbalancer. [2] is tied to the Ingress resource, so if you delete your cluster and recreate it, start the loadbalancer controller pod, and recreate the same Ingress resource, it will use the existing loadbalancer. Also note that both [1] and [2] depend on a "beta" resource that will be released with kubernetes 1.1, I'd appreciate your feedback if you deploy them :)

[1] https://github.com/kubernetes/contrib/tree/master/service-loadbalancer

[2] https://github.com/kubernetes/contrib/pull/132

[3] github.com/kubernetes/kubernetes/issues/10323