Main Kubernetes Components
Kubernetes has many components, but these are the main ones you need to know:
✅ POD
▪ Pods are the smallest, most basic deployable objects in Kubernetes. A Pod represents a single instance of a running process in our cluster.
▪ An abstraction over container
▪ Usually 1 application/container per Pod
▪ Pods are ephemeral - are destroyed frequently
New IP address assigned on re-creation
✅ SERVICE
It is a logical, abstract layer, which helps us to connect the sets of pods to the specified abstract service name and the IP address; let take a few points to understand the service in detail;
▪ Kubernetes service provides us with the route between the pods and also the discovery.
▪ Helps us to connect a set of pods.
▪ Kubernetes service helps us to connect our application frontend to its backend.
▪ Services use selectors and labels, which helps us match the pods with the other application.
▪ It consists of various types of an attribute; some of them are mentioned below;
● Port definition
● Label which helps us to connect to the pods
● Port number and assigned cluster IP address.
● Mapping of incoming ports to the out coming ports.
Also, in Kubernetes, we have different types of service, which can be discussed in detail in the coming section of the tutorial for better clarity for beginners to understand and implement it in a better way.
If Pod crashes, the Service and its IP address will be the same
Internal SERVICE vs External Service
▪ When creating a service you can specify its type:
● Internal Service: By default, for example a database, which should not be accessible from outside
● External Service: Application accessible through browser
✅ INGRESS
Kubernetes Ingress is an API object that provides routing rules to manage external users' access to the services in a Kubernetes cluster, typically via HTTPS/HTTP. With Ingress, we can easily set up rules for routing traffic without creating a bunch of Load Balancers or exposing each service on the node. This makes it the best option to use in production environments.
▪ Ingress is the entry point to our K8s cluster
▪ Request goes to Ingress first, which does the forwarding to the Service
An Ingress provides the following:
▪ Externally reachable URLs for applications deployed in Kubernetes clusters
▪ Name-based virtual host and URI-based routing support
▪ Load balancing rules and traffic, as well as SSL termination
✅ CONFIGMAP and SECRET
For external configuration, Kubernetes has these 2 components:
1️⃣ CONFIGMAP
▪ ConfigMaps are intended for non-sensitive data—configuration data—like config files and environment variables and are a great way to create customized running services from generic container images.
2️⃣ SECRET
▪ Secrets are a Kubernetes object intended for storing a small amount of sensitive data. It is worth noting that Secrets are stored base64-encoded within Kubernetes, so they are not wildly secure. Make sure to have appropriate role-based access controls (RBAC) to protect access to Secrets. Even so, extremely sensitive Secrets data should probably be stored using something like HashiCorp Vault. For the root password of a MariaDB database, however, base64 encoding is just fine.
▪ Similar to ConfigMap, but to store sensitive data such as passwords or tokens
Create a Secret manually
To create the Secret containing the MYSQL_ROOT_PASSWORD, choose a password and convert it to base64:
Make a note of the encoded string. You need it to create the YAML file for the Secret:
Save that file as mysql-secret.yaml and create the Secret in Kubernetes with the kubectl apply command:
Storing the data in a Secret component doesn't automatically make it secure. There are built-in mechanisms (like encryption, defining authorization policies) for basic security, which are not enabled by default! Recommended to use third-party secret management tools, because the provided capabilities by K8s are not enough for most companies
✅ VOLUME
When a container crashes, K8s restarts the container but with a clean state. Meaning your data is lost!
▪ Volume component basically attaches a physical storage on a hard drive to our Pod
▪ Storage could be either on a local server or outside the K8s cluster
Think of storage as an external hard drive plugged in to your K8s cluster
K8s doesn't manage any data persistence, meaning you are responsible for backing up, replicating the data etc.
✅ DEPLOYMENT and STATEFULSET
Deployment and StatefulSet are an abstraction of Pods
DEPLOYMENT
Deployment is the easiest and most used resource for deploying an application. It manages the deployment of ReplicaSet. You can define deployments to update, create new replicasets, or to remove existing deployments. The main role of a deployment is to provide declarative updates to both pod and replicaset.
Deployments help you to achieve the following:
▪ To roll out ReplicaSet - It will create your pods in the background. You can check the status of the rollout to check if it is succeeded or not.
▪ Declare the new state of the pods - You can update the PodTemplateSpec of the deployment manifest. A new replicaset is created, and the deployment moves the pods from the old replicaset to the new one, at the controlled rate. Each new replicaset will now have the updated revision of the deployment.
▪ Rollback to earlier deployment revision - If due to some circumstance, the current state doesn’t turn out to be stable, then the deployment can be rolled back to earlier deployment revision.
▪ We work with Deployments and by defining the number of replicas, K8s creates Pods
STATEFULSET
Stateful applications are applications that store data and keep tracking it. All databases, such as MySQL, Oracle, and PostgreSQL, are examples of stateful applications.
▪ It is a Kubernetes resource, to manage stateful applications. It manages the deployment and scaling of a set of pods, and provides a guarantee of ordering and uniqueness of the pods.
▪ Unlike deployments, statefulset maintains an identity for each of the pods. Each pod has a persistent identifier, that it maintains across any scheduling.
For example, if you create a statefulset with a name “flag”, it will create a pod with name flag-0, and for multiple replicas of a statefulset, the pod names would increment like flag-0,flag-1,flag-2, etc.
▪ Every node is given its own Persistent Volume. If you delete or scale down the pods, volumes associated with them, will not be deleted, therefore data persists.
▪ In addition to replicating features, StatefulSet makes sure database reads and writes are synchronized to avoid data inconsistencies
Having load balanced replicas our setup is much more robust
Last updated
