Skip to main content

Consuming File System artifacts from Kubernetes Pods

When you are deploying an application which contains artifacts written on file system dynamically withing kubernetes (k8s), for example a tomcat server exposed to outside to deploy war files, you need to make sure the file system state is preserved always. Otherwise if the pod goes down, you might loose data.

So one solution is to mount an external disk. Yes indeed you can do that. But how robust is that solution. Say something happened to the external disk. How can you recover the data? Use several disks and rsync to sync the data. Sounds a robust solution. Say you want to increase the reliability. And what happens if rsync process get killed. How much will it cost to make it's reliability closer to 100%?

We have a robust, simple solution. It's using gluster to save data. [1] [2]



We install a pod named gluster for each node. There is an additional disk attached to each node which will be used as the data storage for gluster. This disk is formatted in a special format and attached to the gluster.

This disk can be attached to a specific path and we can mention it as below (eg :- /dev/sdb) in the topology.json. Following is a sample. When your run gkdeploy script to install gluster, you have to place topology.json in the same location.

 
   "clusters": 
       
         "nodes": 
             
               "node": 
                  "hostnames": 
                     "manage": 
                        "node0"
                     ],
                     "storage": 
                        "192.168.10.100"
                     ]
                  },
                  "zone":1
               },
               "devices": 
                  "/dev/sdb"
               ]
            },
             
               "node": 
                  "hostnames": 
                     "manage": 
                        "node1"
                     ],
                     "storage": 
                        "192.168.10.101"
                     ]
                  },
                  "zone":1
               },
               "devices": 
                  "/dev/sdb"
               ]
            },
             
               "node": 
                  "hostnames": 
                     "manage": 
                        "node2"
                     ],
                     "storage": 
                        "192.168.10.102"
                     ]
                  },
                  "zone":1
               },
               "devices": 
                  "/dev/sdb"
               ]
            }
         ]
      }
   ]
}

Once you install gluster in k8s now comes the question on how they interconnect? There is an another component called heketi [3] which is generally used to manage volumes. Here heketi is used to manage gluster cluster. You can use heketi cli [4] to do advanced operations. Heketi is included in the gk-deploy script from glusterfs.

Note that this blog is written to explain a problem and a solution. Here I haven't included any low level operational details or installation details.

Once gluster is installed in your k8s setup, next question is to how to use it? First you need to create a storage class in k8s with the heketi cli url. Here this url should be accessible to master node of k8s deployment. It looks like below.

kind: StorageClass
apiVersion: storage.k8s.io/v1beta1
metadata:
name: glusterfs-storage
provisioner: kubernetes.io/glusterfs
parameters:
resturl: "http://${HEKETI_URL}"

After that there should be a pvc (Persisted Volume Claim) to use this storage class.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: gluster-pvc
annotations:
volume.beta.kubernetes.io/storage-class: glusterfs-storage
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 2Gi

Then you can use pvc in your pod conflagration as a volume mount.

volumeMounts:
-
mountPath: /mnt/files/diff
name: sample-files

volumes:
-
name: synapse-files
persistentVolumeClaim:
claimName: gluster-pvc

Hope this helped someone to create a solution.
Good luck on deployment!!!

[1] https://github.com/gluster/glusterfs
[2] https://github.com/gluster/gluster-kubernetes
[3] https://github.com/heketi/heketi
[4] https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.3/html/container-native_storage_for_openshift_container_platform/chap-documentation-red_hat_gluster_storage_container_native_with_openshift_platform-heketi_cli

Comments

Popular posts from this blog

Generate JWT access tokens from WSO2 Identity Server

In Identity Server 5.2.0 we have created an interface to generate access tokens. Using that we have developed a sample to generate JWT tokens. You can find that sample under msf4j samples[1][2]. If you are build it as it is you will need to use Java 8 to build since msf4j is developed on Java 8. So you will need to run Identity Server on Java 8 as well. After building the project[2] please copy the jar inside target directory to $IS_HOME/repository/components/dropins/ directory. And then please add the following configuration to Identity.xml which is placed under $IS_HOME/repository/conf/identity/ folder inside tag OAuth . <IdentityOAuthTokenGenerator>com.wso2.jwt.token.builder.JWTAccessTokenBuilder</IdentityOAuthTokenGenerator> Then go to the database you used to store oauth tokens (This is the database pointed from the datasource you mentioned in the $IS_HOME/repository/conf/identity/identity.xml) and then alter the size of the column ACCESS_TOKEN of the tab

Oauth custom basic authenticator with WSO2 IS 5.1.0

WSO2 Identity Server supports Oauth2 authorization code grant type with basic authentication OOTB. But basic authentication is done only with WSO2 user store. So there could be use cases that basic authentication has to be done against some other system. In this case you follow below steps to achieve your requirement. First you need to create an class which extends AbstractApplicationAuthenticator and implements LocalApplicationAuthenticator. Because this class is going to act as your application authenticator so it needs to be an implementation of application authenticator interface and to achieve this it needs to be a local authenticator as well. [2] public class CustomBasicAuthenticator extends AbstractApplicationAuthenticator implements LocalApplicationAuthenticator {   Then you need to override the initiateAuthenticationRequest method so you can redirect to the page to enter user and password. In my sample I redirected to the page that is used by our default basic au

Installing gluster in AWS EKS

This article is a continuance of [1] . Purpose of this article is to document the steps, issues and solutions to those issues we have to face when installing gluster in EKS (Elastic Kubernetes Service). For gluster we need a disk to be attached with the K8s node. In EKS easiest way of implementing this is, adding it to the node configuration. So every time a node comes up, it comes up with a disk attached to the defined path. You can use this path in the topology.josn as mentioned in [1] . Next step is to install gluster using the gk-deploy script. The challenge comes here after. To use gluster in pods, you need to define a storage class. The heketi url mentioned in the storage class definition, should be accessible from master node. But the given heketi url is a cluster IP type k8s service. But in EKS deployments masters are managed by AWS and master don't have access to cluster IPs. So how we can solve this? Actually I tried to contact AWS support on this and I didn't got