Change:
I create a glusterfs endpoint, but after I restart kube-apiserver, the endpoint is missing. Does Kubernetes persistence endpoints?
Do you mean and Endpoints object in the API or something else? , Bin Wang wrote:
Here is what I do: Then use I can see this line: But after I restart kube-apiserver, this endpoint is lost.
Do you have a Service named ? Otherwise it should persist, just the same as any other API object , Bin Wang wrote:
No. This endpoints is just used for persistent volumes, which is used by other pods. I followed . Is it necessary to define a service?
Can one of you guys try to repro?
What does that mean exactly? What kind of cluster are you running? Does anything persist and endure between restarts of the API server? When you restart the API server (why?), are you also restarting etcd or other services?
The cluster just have one master. The pods, secrets, controllers and services are recovered after the restart, but the endpoints are not. About why I restart the API server, well, it may fail (or something else). You cannot expect the api-server runs and never restart. After I restart it, I expect all the things are recovered. In my case, I just restart api-server through /etc/init.d/kube-apiserver (kill the process manually should do the same thing). Etcd is always running and the data in it is not lost.
Any update on this? I cannot use kubernetes in production if this problem is not solved. Or do you have a work around, like define a service with the glusterfs endpoints?
I'm running into this too on GKE so I'm not sure if it's the api-server restarting, but just now after a loadtest and intermittently a couple of other times, after my app tries to come back up it failes to mount from gluster due to the gluster endpoints having mysteriously disappeared.
Do you mean the whole object disappeared or that it exists but is empty?
In the original YAML "IP" should be "ip"
does not show the resource On Mar 27, 2017 8:16 PM, "Tim Hockin" <:
I am trying to repro, but no luck so far.
Just checked.. IP is does come up, and it works well enough as the pods are able to mount the gluster volumes, but every once in a while I find that they're gone. On Mar 27, 2017 8:18 PM, "Tim Hockin" <:
I haven't been able to either, it happens every once in a while. I think maybe they're deleted before I notice and I only notice because a pod is fails and on restart it fails to mount it's volume On Mar 27, 2017 8:21 PM, "Tim Hockin" <:
Just checked a cluster I created an hour ago, and yup all the pods that had been created are running smoothly but the gluster endpoints resource is gone , Jonathan <: — You are receiving this because you commented. Reply to this email directly, view it on GitHub , or mute the thread
Interesting. It appears this is intentional. If you create a service with clusterIP: None and an empty selector, this will not be activated. It is trying to prevent submarine problems, such as creating an Endpoints then later creating a Service and conflicting. , Jonathan Kosgei <:
So the fix is to create a corresponding service for the endpoints?
Yes. Endpoints are usually a derived value, and in hindsight they should probably have been a sub-resource of Service. On Mar 28, 2017 7:20 AM, "Jonathan Kosgei" <:
In case you're wondering (like I was) how to attach a service to the EP the was updated to include an example service for it.
I'm having this issue again in a very different setup, basically I'm using the Nginx Ingress controller and it uses endpoints and these endpoints keep disappearing intermittently breaking all ingress to the cluster. Opened an issue at the nginx-ingress repo Saving the endpoints with a and recreating them when resolution failure occurs fixes it immediately.
this will make kubelet notready if i create a Service named glusterfs-cluster, after reboot endpoint is not lost. but the kubelet will be notready , something wrong? hope response tks.
The correct explanation should be When the cluster starts Endpoint-Controller Will check all Endpoint list Then put Endpoint name in workqueue, worker get value from workqueue, Found Endpoint no corresponding Service,Just delete Endpoint.
yes, the manually created EP resource will not be reconciled by the controller. This is the cause. Usually we do not create EP, this kind of secondary resource directly. It is created for the corresponding service resource.

Discussion:
"../examples/glusterfs": { "glusterfs-pod":       &api.Pod{}, "glusterfs-endpoints": &api.Endpoints{}, <ins> "glusterfs-service":   &api.Service{}, </ins> }, "../docs/user-guide/liveness": { "exec-liveness": &api.Pod{},

glusterfs-cluster   10.240.106.152:1,10.240.79.157:1 ``` <ins> We need also create a service for this endpoints, so that the endpoints will be persistented. We will add this service without a selector to tell Kubernetes we want to add its endpoints manually. You can see [glusterfs-service.json](glusterfs-service.json) for details. Use this command to create the service: ```sh $ kubectl create -f examples/glusterfs/glusterfs-service.json ``` </ins> ### Create a POD The following *volume* spec in [glusterfs-pod.json](glusterfs-pod.json) illustrates a sample configuration.

<ins> { "kind": "Service", "apiVersion": "v1", "metadata": { "name": "glusterfs-cluster" }, "spec": { "ports": [ {"port": 1} ] } } </ins>