Kubernetes for Dummies — Part 2: Understanding Kubernetes
Introduction
In Part 1, we saw what is the purpose of kubernetes and some use cases on how Kubernetes can be useful. Now the next step will be understanding Kubernetes related stuff
Everything in Kubernetes are called objects. They are all created by Kubernetes API. Lets take a look at the most common objects in Kubernetes to understand and get to know
Objects
Pod
This is the smallest unit in Kubernetes. A pod is a group of one or more containers with shared resources like network and storage. In more Linux terms, A pod is a group of shared namespaces and cgroups with other isolation configurations, just like for any other container
Single container pods are with one container inside the pod.
For ex: An Nginx Pod can contain a container with the Nginx docker image
Multi- container pods are sometimes run due to the need for such a service. For ex:
- an init container to populate the config for the app container to run
- A sidecar container to run along with the app container, kind of a helper container
What to understand here is that, do not use a single pod to host a single monolithic application. For example, It does not make sense to run a pod with a frontend, an application layer end and a database together. Thats just not good or completely stupid.
Services
Pod as it is running cannot be accessed by simply running in the cluster. Service enables to create a network connectivity to make the pod communicate from within the cluster or external.
How does the service make communication available?
Each service when created, will be assigned a unique IP address. This is called ClusterIP. This address is tied to the service till the lifespan of the service. Each service will be backed with a pod or a set of pods. All communications to the service will be redirected to the pods like a loadbalancer redirects traffic to each instance.
Each pod has a unique IP address and ports that are exposed with it. These are called endpoints. This endpoints are continuously monitored. In an event if one of the pod fails the health check, the endpoint is removed.
By default when a service is created, the service type is ClusterIP. This means the service will be available only within the cluster. To expose the service, the type can be changed to NodePort. This will enable to expose the service externally outside the cluster using the IP address of the server and the port number of the NodePort.
The next type is Loadbalancer. This is useful in a cloud environment setup where the service can be exposed to internet with the help of Loadbalancers from Cloud providers. For on-premise solution Loadbalancer service can be mimicked with help of tools like MetalLB
Namespace
Most of the time, there is requirement where we need to deploy same application in the cluster or deploy applications from different teams. Since Kubernetes is a cluster, there is an option that we can create virtual clusters, to separate different environments, teams, or applications. This is called Namespace.
Replicaset
Running a pod is a good idea, but what if the pod fails? Replicaset comes here, where it ensures to make the number of pods available running on the cluster. If one pod crashes due to any application issues, Replicaset with spin up a new pod and remove the crashed pod.
Replicaset is defined with a set of labels, including a selector that specifies how to identify the pods.
Deployment
Deployment under the hood is just a Replicaset, which ensures number of Pods to be available all the time. In addition to it, Deployment also allows the rollout and rollback of the deployment, which is a nice must have for an application deployment.
When a new version needs to be released, a rollout event is triggered, which will create a new Replicaset with the replicas. If the pods in the new Replicaset is successfully deployed without problems, then the old Replicaset will be removed along with the old pods. The rollout strategy can be defined along with the percentage to rollout.
StatefulSet
Deployments are very good for stateless applications where we can get the storage on demand and there is no issue when those storage is destroyed. What about stateful applications, like cluster based applications? Statefulsets are good for this purpose, where the state of the application is really important and need to be persisted across nodes.
Role / Clusterrole
When deploying stuff on Kubernetes, security or access should also be not taken lightly. To secure the access, we can create a Role. If the access to be provided is restricted only to a namespace, it is a Role. If the access to be provided is a cluster wide, then it is a Cluster Role
Roles are set of permissions on what to do.
Service account
When users want to connect to Kubernetes cluster, they need to make use of a Kubeconfig file. This config file contains information about the certificates to connect to the cluster. What if we need to create “technical user” for applications or services to have access each other? Thats when we use Service accounts.
Role binding / Clusterrole binding
We understood what is role and service account or user. How to attach or bind the role to the service account? Thats where the bindings come into play. If the binding is namespaced, then it is called Role binding and if the binding is cluster wide, then its a Clusterrole binding
The Role bindings are simple, a role and a resource, service account or user to bind the role to.
Persistent Volumes / Persistent Volume Claims
The next important object is storage related. When we need to mount volumes to the containers in pods, we use PV (Persistent Volume) or PVC (Persistent Volume Claims). For storage, we define a PV first, this is to create a storage class or define the type of volume to create. This can be a hostpath or a disk from a cloud provider
When a PV is defined, then PVC can be claimed when there is a need from the the PV created before. In cloud solutions, we can create PVCs without creating PVs by adding storage class in the PVC.
ConfigMaps / Secrets
This is one of the interesting object I have liked. When we need to provide configuration or secrets as files into a pod, we have the option of using PVs. But they are recommended to use without data, so that every time a pod spins up, there is a fresh volume. ConfigMap is way of passing configurations into the pod, where the configurations are created as a key value pair and the configuration is mounted as a file in a location on the pod. Secrets also works the same way, except they are base64 encoded values
Some may argue that base64 encoded values are not really secure. For simple or small use-cases this is perfectly fine. For really secure secrets, its advisable to use other secret storing mechanisms like Hashicorp Vault, Azure Key vault, Amazon KMS.
These are the basic objects that we need to understand, before diving deep into Kubernetes and stuff. Some of the next objects to look for are:
- Daemonsets: Ensures that a single pod of an application is deployed on all nodes in the cluster
- Jobs: To run any particular jobs or tasks
- Cronjobs: To run cronjobs
- NetworkPolicy: To create network policy for restricted use. This depends on the CNI plugin (or the networking tool) used in the Cluster.
- Certificates: For creating certificates for securing communication
and much more…
Conclusion
This document will provide information about how to dip your feet in to the world of Kubernetes. Although this is not everything, but this can pave way to start Kubernetes. There is a lot of other objects to learn, which I am sure you can find it when you start playing with Kubernetes
