Kubernetes introduction for begginers
Introduction
Welcome to the world of Kubernetes objects, where efficiency and scalability reign supreme.
In this comprehensive guide, we will delve into the art of optimizing your deployments to unlock the full potential of Kubernetes. From Pods to Services, ConfigMaps to Persistent Volumes, we will demystify each object and equip you with the knowledge and tools needed to master them.
Whether you are a seasoned developer or just starting your journey with Kubernetes, this guide will take you step by step through the process of creating, configuring, and managing these powerful objects.
With best practices, you will be able to streamline your deployments, maximize resource utilization, and ensure seamless scalability.
So, buckle up and get ready to elevate your Kubernetes game as we embark on this exciting journey together. Let's dive in and unlock the true potential of your deployments with Kubernetes objects.
Kubernetes manifests
Kubernetes manifests are created in the YAML format which is translated by the kubectl tool to the format needed to speak to the Kubernetes API.
This means that every Kubernetes component can be defined in the YAML file and applied to the master node which handles the parameters and create the state in the cluster same as in the definition of the file itself.
Adnan Selimovic
The kubectl is the helper CLI tool which simplifies the task of talking to the Kubernetes API. One could directly use kubectl from the terminal to talk to the Kubernetes master node/cluster to apply any definition directly from the YAML file.
Kubectl also has helpers implemented and you can specify commands directly (without using definition files) to create a specific component on the cluster itself.
Kubernetes controllers
As we increase granularity and focus not on the infrastructure part of the cluster but on the end user we see other things pop up. In simpler terms when we zoom in on the Kubernetes cluster we see many components:
- Deployments
- Statefulsets
- Pods
- Services
- Endpoints
- ConfigMaps
- Secrets
- Jobs
- ServiceAccounts
There are many components in which one can easily get lost. But if we layer them correctly, categorize them, and change the perspective from which we are looking - we can manage a lot better in this sea.
Master worker nodes are running, in the forever loop, controllers. Controllers have the responsibility to track the status of the cluster, watch for the applied resources, and converge the cluster state to the applied resources at any time.
What needs to be mentioned is that Kubernetes controllers and controller definitions are separate things.
Kubernetes controllers are software that is running in the loop, on the master node, to apply any definition of the Controller definition to the cluster.
Kubernetes operators
The operator reacts to the custom resource and reconciliate the state in the cluster with the state defined in the custom resource, by implementing logic embedded in the operator itself.
Read more here.
Adnan Selimovic
Kubernetes pods
The most popular controllers which are known by the end-users are:
- Deployment
- StatefulSet
- ReplicaSet
- Job
- DaemonSet
- CronJob
Each one of these controllers is responsible for running the pods.
Pod is the abstraction layer around the container and has these properties:
- Each pod has a unique IP address and is the entry point to the container running on the cluster
- Each pod can run one or many containers
- Each pod gets a new IP address when restarted or recreated by any event on the cluster
To sum up: Pod is running the container payload where the application is packaged and has network capabilities since it has an IP address.
To bring it closer: You tell the pod here is the container image I want to run on the cluster please run it. Kubernetes created the pod, handles networking, and contacts container runtime to start running the container image itself.
Pod by itself is not so useful. Why? If we create a Pod object by talking to the Kubernetes API, when we delete it it will be gone. That is the reason we have Controllers.
For example, the Deployment controller ensures that at any moment there is a specified number of pods running with the help of the ReplicaSet. Each time pod is recreated pod gets a random name.
For the deployment controller, there is a possibility to define the number of replicas (Number of pods) that will be created by this deployment.
Another type of controller is the StatefulSet. StatefulSet ensures that pods maintain the same name when recreated in the same order in the way they were first created.
A high number of other resources (Not all) are gravitating around the pods. ServiceAccounts, Secrets, ConfigMaps, PersistentVolumeClaims, Limits, etc.
To sum up: Pod is the basic running unit where containers are running. Pod has an IP address over which the running container can be contacted, storage, compute and memory resources, and all other components needed for the specific pod. Pods are abstracted by the controller which handles the (re)creation and horizontal scalability of the pods. Many other Kubernetes components are gravitating around the pods and their configuration is directly impacting and showing in action when applied to the specific pod/s.
Kubernetes ConfigMaps and Secrets
ConfigMaps and Secrets are a way to externalize the configuration and secret credentials.
ConfigMaps and secrets are created apart from the pods and they exist by themselves with no connection to the pods or controllers which are running the pods. After they are created and visible in the cluster the end-user needs to alter the definition of the Pod/Controller to connect the ConfigMap or the Secret to be used in the Pod which in fact makes it available to the container in running state.
Kubernetes namespaces
Namespace in Kubernetes is the same as in many other fields of software development. A namespace is a logical group of Kubernetes components that are isolated from the other namespace. For example the pods in the same namespace can't have the same name while in different namespaces they can.
The namespace named default is a default namespace that is created after installing the cluster. The namespace kube-system is the namespace where critical software for the cluster operation is located. For example kube-proxy.
Conclusion
When you master the basics of the Kubernetes you can set yourself to the more complex topic. Adding Kubernetes to your belt in current engineering world you can set yourself apart from the other engineers.
Here is the list of available topics on the qdnqn regarding Kubernetes.
Adnan Selimovic
Member discussion