A Short Note on K8s Components
Hola! Fellow DevOps personnel here is a gist about the main components of the most popular tool, Kubernetes. Let me start with a brief intro to the tool.
Kubernetes is an open-source container orchestration tool and the most preferred orchestration platform for medium to large-scale applications. Applications in the sense, I refer to those built in a cloud-native fashion.
“No masterpiece can be built without involving some sort of modularization and so applies for an end-to-end functioning software. You need to chunk down your software idea into features, multiple engineers and designers need to work together on multiple programming languages, frameworks, and hell, a lot of tools! This scenario seems too ambiguous and if not handled appropriately, could add a lot of complexities day by day which is not such a vague circumstance in a microservices-based architecture though. Kubernetes solves a major part of this problem by orchestrating all the containers involved in a rhythmic fashion. Different developers use different programming languages for different features and so obviously the dependencies and frameworks are all contained and isolated as Docker containers(Docker is a widely used containerization platform among the rest in the market). After containerization, each feature remains as a closed box in itself and has to be put together to obtain an end-to-end software masterpiece.”
K8s, as it solves a big part of IT architectural problems, has many different components working cordially for achieving their purpose, vivifying the workflows and thereby invigorating the Engineers on the row!
Components are as follows:
- Nodes
- Pods
- Services
- External Service
- Internal Service
- Ingress
- ConfigMaps
- Secrets
- Volumes
- Deployments
- StatefulSets
Nodes:
A node can be any server like a compute engine, EC2 instance, on-prem data center server, etc with an apt container runtime, kubeproxy and kubelet installed.
Pods:
“A pod is the smallest unit of K8s.” A pod is responsible for offering the appropriate application runtime environment for the workloads. Basically, a pod is an abstraction of containers. Many pods can run per node.
Services:
Every pod needs a static IP to it. By default, pods get IP addresses but are non-static and so regular. They use to fickle all the time. In order to introduce reliability and consistency to the running pods, services come into play.
External Services:
These are nothing but endpoints outbound and are totally insecure and without any defined DNS name.
Internal Services:
These are the inbound endpoints with similar entities like the one quoted above.
Ingress:
Real-time application usage is always pleased with predominantly defined FQDNs. Ingresses serve the purpose.
ConfigMaps:
Serves as a key-value data store for configuration files, environment variables, etc, and anything that fickles.
Secrets:
Same as the ConfigMaps but the purpose is intended only for usernames and passwords.
Volumes:
Volumes act as physical storage devices for the default hard drives and ensure data persistency.
Deployments:
Deployments are the blueprint for pods and every configuration in detail. They merely set the rule for entire cluster creation.
StatefulSets:
StatefulSets as the name indicates are for those stateful databases in the cluster.
Hope you had an informative read!
