Application Deployment in K8s — PVCs and Secrets
So far in our journey we have already covered about the basics for K8s, seen it’s actual power along with some powerful use-cases for container orchestration. Further moving along, let’s cover some of the must use concepts of K8s container which will be of great help while deploying a fully managed application over the K8s cluster and by the end we will learn to launch a complete production level application pod for MySQL
We have learned till now:
Introduction to Container Orchestration and K8s
Basics of K8s and K8s scripting
Advance concepts of Kubernetes and Container Orchestration
Taking a further step into our journey of Kubernetes, let’s move to some core concepts which are generally used in actually deploying the application over a kubernetes cluster.
THE PVC (Persistent Volume Claim):
Managing storage is a distinct problem from managing compute instances. In deploying we generally are required to attach a persistent storage to our cluster which is shared between several clusters to maintain the data consistency and data storage inside the cluster. For this purpose Kubernetes has it’s own Persistent Volume subsystem which provides an API for users and administrators that abstracts details of how storage is provided from how it is consumed.
To achieve this task of persistent data storage, the K8s has two new API resources: Persistent Volume and Persistent Volume Claim.
PV (Persistent Volume) — A Persistent Volume (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using Storage Classes. It is a resource in the cluster just like a node is a cluster resource.
PVC (Persistent Volume Claim) — A Persistent Volume Claim (PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., they can be mounted ReadWriteOnce, ReadOnlyMany or ReadWriteMany etc).
There are two ways PVs may be provisioned: statically or dynamically.
Static
A cluster administrator creates a number of PVs. They carry the details of the real storage, which is available for use by cluster users. They exist in the Kubernetes API and are available for consumption.
Dynamic
When none of the static PVs the administrator created match a user’s Persistent Volume Claim, the cluster may try to dynamically provision a volume specially for the PVC. This provisioning is based on Storage Classes: the PVC must request a storage class and the administrator must have created and configured that class for dynamic provisioning to occur.
Implementing Dynamic PVCs for some pods:
To launch a PVC in dynamic format we have to define some of the properties for the PVC which we are requesting form our storage classes, which includes the accessModes for our PVC and storage size.
Here in above example we have created a sample PVC for some MySQL storage which demands 10GB of storage from our storage class.
To check the status of our PVC and it’s properties again we can use command
kubectl get pv or kubectl describe pv
As we can see our PVC is successfully created and now we have a persistent storage of 10GB which we can attach to our application and can have a permanent storage of data in our machine, which won’t be lost when pod is exited or removed forcefully.
Secrets:
A Secret is an object that contains a small amount of sensitive data such as a password, a token, or a key. Such information might otherwise be put in a Pod specification or in an image. Users can create secrets and the system also creates some secrets.
Why Secrets are required?
In real world while launching an application, we are required to pass some vulnerable data while creating clusters, like while creating a pod for MySQL application, we are required to provide root password along with the database password and username. To hide this sensitive data K8s has it’s own service known as Secrets.
For security aspects and data security aspect usage of secrets is highly required in deploying real world applications and we create our own secrets in kubernetes. The secret file holds data in base64 encoded format, hence proving some level of data security to our content.
Creating our own secrets..
Let’s create some secrets in K8s cluster using the HCL script. To create our new secrets we are required to pass the secret data in base64 format which is internally decoded by the K8s while creating the pods, and hence decoded data is passed our the fields where the secretes are invoked.
Here we have created a mysqlsecret which holds 3 values i.e. username, rootpass and userpass. The data is passed in base64 encoding.
We can see that our secret is stored in the K8s under secrets and is not visible to user, and now we can safely pass our crucial application data to the pods with a layer of data security.
Deploying a production ready pod for MySQL application:
As explained earlier to launch a production level pods for MySQL we will require all the concepts which we have learned so far. To launch this application pod we will be using every essence of K8s cluster from Replica set to PVCs and Secrets.
Let’s begin by writing the script for the MySQL pod creation:
Here as we can see we have used the sql Secret and PVC which we have defined earlier and have mounted the PVC to /var/lib/mysql folder. The /var/lib/mysql folder is the basic where MySQL stores all of it’s data and db’s in Linux systems.
Just after creating the pods, the secrets are already decoded and passed to the pods as the MySQL container environment variable along with mounting the persistent volume while creating the container, hence we now have a persistent DB cluster running.
The PVC is successfully mounted with RWO accessMode which we defined for the pod creation.
By getting inside the pod we can confirm for our credentials provided and we can also see the a new db naming test is created in MySQL itself, which we defined during the Pods creation script.
As we can see we have successfully launched a production grade MySQL application over K8s cluster, which has persistent storage along with the power of Fault-Tolerance and a guaranteed uptime. We can attach this SQL application with any server we want without worrying for data loss or server downtime.
Previous — Advance concepts of Kubernetes and Container Orchestration
Next —Deploying Application over K8s cluster
“Simplicity, carried to the extreme, becomes elegance.”
— Jon Franklin
