[GlusterFS dynamic Provisioner] New endpoint and service name format for GlusterFS volumes!

What is this all about? I would like to keep a short blog article about glusterfs endpoint and service creation happening under the hood when you dynamically provision glusterfs volumes in kubernetes/Openshift cluster.


1) Provisioner Take Request
2) Call Heketi Volume Create API
3) Heketi Talk to Gluster and create a Volume
4) Upon successful completion of Volume creation, Provisioner name endpoint/service of form:
glusterfs-dynamic-PVCNAME
5) Then provisioner try to create Endpoint/Service
6) Upon successful endpoint/service creation, PVC move to BOUND state

Let us pay attention to Step “4”, here, the endpoint and service name is created with a prefix “glusterfs-dynamic” to PVC name.
However if you create a PVC with latest Kubernetes Version ( 1.13) , you would see that the endpoint and services are in below format:

If I list endpoints and service in my system:

[root@Node ~]# kubectl get ep NAME ENDPOINTS AGE

glusterfs-dynamic-8e155928-f77f-11e8-b229-005056a5c1c4 10.70.46.80:1,10.70.47.189:1,10.70.47.68:1 3h glusterfs-dynamic-a71fa382-f77d-11e8-b229-005056a5c1c4 10.70.46.80:1,10.70.47.189:1,10.70.47.68:1 4h heketi-db-storage-endpoints 10.70.46.80:1,10.70.47.189:1,10.70.47.68:1 5d heketi-storage 10.130.0.6:8080 5d [root@Node ~]#

[root@Node ~]# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

glusterfs-dynamic-8e155928-f77f-11e8-b229-005056a5c1c4 ClusterIP 172.31.221.49 <none> 1/TCP 3h glusterfs-dynamic-a71fa382-f77d-11e8-b229-005056a5c1c4 ClusterIP 172.31.147.132 <none> 1/TCP 4h heketi-db-storage-endpoints ClusterIP 172.31.202.20 <none> 1/TCP 5d heketi-storage ClusterIP 172.31.183.17 <none> 8080/TCP 5d


Here I would like to map the endpoint/service for claim1, How would I do that?

In short:

*) Fetch PVC UID
*) Look for this UID in endpoint/service output

[root@Node ~]# kubectl describe pvc claim1 Name: claim1 Namespace: app-storage StorageClass: glusterfs-storage Status: Bound Volume: pvc-a71fa382-f77d-11e8-b229-005056a5c1c4 Labels: <none> Annotations: pv.kubernetes.io/bind-completed=yes pv.kubernetes.io/bound-by-controller=yes volume.beta.kubernetes.io/storage-class=glusterfs-storage volume.beta.kubernetes.io/storage-provisioner=kubernetes.io/glusterfs Finalizers: [kubernetes.io/pvc-protection] Capacity: 2Gi Access Modes: RWO Events: <none>

“claim1” PVC got UID “a71fa382-f77d-11e8-b229-005056a5c1c4” and endpoint/service “glusterfs-dynamic-a71fa382-f77d-11e8-b229-005056a5c1c4″ belong to this claim!!

Let us wrap it up. Why this change?

This change was introduced mainly because of:

1) There is an issue if you delete and recreate a PVC with the same name without any delay. Due to a race scenario, the second PVC creation would end up without endpoint and service..

2) If user want to create a PVC with a name in range of 45-63 characters, it was not possible to create endpoint and service due to the prefix ( glusterfs-dynamic) added to it. The API server will reject the lengthy endpoint and service name.

Disadvantages:

It was very easy to fetch an endpoint/service in a namespace with PVC name with naming format glusterfs-dynamic-pvcname, but now it need some more steps.

As always, please let me know your thoughts!!