Re: How to make 172.30.0.1 (kubernetes service) health checked?

2018-09-10 Thread Clayton Coleman
Masters should actually remove themselves, but maybe that regressed. I’ll try to take a look but removing themselves when they receive a sigterm is a good idea. On Sep 10, 2018, at 6:58 PM, Joel Pearson wrote: Hi Clayton, Sorry for the extensive delay, but I’ve been thinking about this more

Re: How to make 172.30.0.1 (kubernetes service) health checked?

2018-09-10 Thread Joel Pearson
Hi Clayton, Sorry for the extensive delay, but I’ve been thinking about this more and I’m wondering if it’s safe to remove a master from the endpoint just before restarting it (say in Ansible), so that failures aren’t seen inside the cluster? Or would something in Kubernetes just go and add the

Re: How to make 172.30.0.1 (kubernetes service) health checked?

2018-06-27 Thread Clayton Coleman
In OpenShift 3.9, when a master goes down the endpoints object should be updated within 15s (the TTL on the record for the master). You can check the value of "oc get endpoints -n default kubernetes" - if you still see the master IP in that list after 15s then something else is wrong. On Wed,

How to make 172.30.0.1 (kubernetes service) health checked?

2018-06-27 Thread Joel Pearson
Hi, I'm running OpenShift 3.9 on AWS with masters in HA mode using Classic ELB's doing TCP load balancing. If I restart masters, from outside the cluster the ELB does the right thing and takes a master out of service. However, if something tries to talk to the kubernetes API inside the cluster,