There are several kubernetes components which we as a kubernetes administrator must be familiar with, each of the component is described below.
Node:
It’s a physical or virtual machine.
Pod:
It’s a smallest unit/component present in kubernetes.
It’s an abstraction over a container so that we can have different kind of container runtimes like docker, rocket etc.
Usually we run one application within a Pod but if there is a requirement of side car containers then we can have it in the same Pod where actual application container is residing.
Each Pod has it’s own IP address using which it can communicate with other Pods.
Pods by nature are ephemaral meaning they can die easily so we actually can’t rely on Pod’s IP addresses to communicate.
Due to this we use services to communicate among Pods.
Service:
Service has its own permanent IP address.
Service acts as a load-balancer among the different replicas of the same Pod be it on same or different Nodes, So Service spans across all the Nodes.
Lifecycle of Service and Pod are not connected so even if Pod dies, still service and its IP address will be there.
Now when we deploy our application we want our users to access our application and that can be achieved using External Service.
These types internal and external service can be specified while creating a service object.
Config-Map:
Suppose we have two components ‘my-app‘ & ‘my-db‘ now when we want to connect to ‘my-db‘ from ‘my-app’ we usually configure the url and its credentials in our properties file.
Drawback of having these details in properties file is first security and additionally if in future the ‘my-db‘ service url changes then we need to change it in the properties file and then again rebuild the image and deploy newly created image.
To avoid this we can make use of Config-Map in kubernetes which is kind of external-configuration to our application. This config-map will then be plugged in to our deployment object so now suppose we have changed the DB-URL so that change will be done in Config-Map and since our application will be reading that property from Config-Map there won’t be any issues as we haven’t hardcoded the URL in our application itself.
Secret:
Its same like config-map, only difference is that while storing the data it won’t store in plain text rather stores it using base64 encoded.
Useful for storing sensitive data like db-credentials and all.
We can read these data (Secret & ConfigMap data) into our application pod using environmental variables.
Volume:
Suppose we have a db pod running and we stored some data on that Pod, now due to some issues that Pod dies so in that case all our stored data on that Pod will be lost.
To solve the above issue we can make use of Kubernetes Volumes to store our data.
It will attach a physical storage to our Pod it could be a local storage meaning the storage from the same Node on which the Pod is running or it could be a remote storage i.e outside of kubernetes cluster (Cloud Storage, On Premise Storage).
Deployment:
When we talk about high availability of our application then it means we have almost zero downtime, so to achieve this we deploy multiple replicas of our application/pods so that it will be highly available event in case some of the Pod dies other Pods can serve the requests.
To acheive this replication of Pods we make use of Deployment object in kubernetes.
Deployment holds the blue-print of the Pod where we configure Pod details along with its replicas.
The replicas which we specifies are then guaranteed by kubernetes that at any point of time those many Pods will be available.
StatefulSet:
With deployments we can provide the no. of replicas we want for that Pod but what if that Pod is a DB Pod, so we can’t replicate the DB pod with deployments as DB Pod will be having some state.
To achieve this we can make use of StatefulSet to provide replicas of DBs.
However deploying stateful applications like DB using statefulset is not easy, so it is always recommended to host staeful applications like DBs outside of kubernetes cluster.
DeamonSet:
Suppose we want to collect logs from our main app pods, to achieve this we need to have our app-log collector Pod running in each node to collect the logs generated from main app-pods.
Now when we add/delete a new node we need to adjust the replicas for that app-log pod.
With Deployments, we can’t be assured that Pods are distributed equally among Nodes i.e we need to have this app-log Pod in each Node to collect the logs from main app-pod but deployment object doesn’t guarantees that.
To solve this issue we can make use of DeamonSets. It calculates the no.of replicas needed based on existing Nodes.
It Deploys one replica per Node, so when a new Node is added it will automatically add the required Pod to that Node and also when a Node is deleted it will garbage collect the Pod.So with DeamonSets we don’t need to specify the replica counts for a Pod, It will automatically scales up & down.