Maltreated ways to use Kubernetes
Kubernetes is like a captain of a ship and sails its ship smoothly. Ship faces several hazards of shipping by the sea like dangerous weather threats in the form of hurricanes, squalls, typhoons, etc. , geographical hazards like coral reefs, iceberg, sandbars, etc., technological hazards in which anything can go wrong with the ship or its equipment, etc. In calm water, every ship has a good captain but the adroit captain sets his/her course by the stars, not by the lights of every passing ship.
Kubernetes is a great captain for the choice of managing clustering applications. Its main purpose is to provide a platform for container orchestration, scaling, automatic deployment, monitoring, better resource efficiency, and isolation, make large-scale architecture changes, etc.
The ship sinks in the sea during dangerous hazard if its captain is maltreated and directed wrongly by the shipowner. Similarly, Kubernetes will not scale, orchestrate, and manage resources properly if it is programmed or installed to manage containers poorly.
Use Kubernetes only with Master Node
In principle, implementation and behavior Kubernetes is used with a Master node along with the Worker node(s). The master node is responsible for managing the Kubernetes cluster. It is the entry point for all administrative tasks.
The worker node is a kind of node in the form of VM or physical machine depending on the cluster. Each node contains the services necessary to run pods and is managed by the Master node. Previously Worker node was known as a minion.
Master node acts as a coach of a team in a football ground. Coach monitors the playing team and replaces the player if any one of them is injured or doesn’t play well. Coach doesn’t play in the ground, only team members play in the ground in case of any tournaments or the real-time match.
Just imagine a football match or game without a team and only with a coach. Ship only with Captain and without able seaman. Similarly, to use Kubernetes without Workers nodes and only with Master node.
Create and Delete Pod and Container on each Request
In the ship, Pod is also called Port of Discharge. It is the port at which the goods are unloaded vessels. Similarly in Kubernetes, a Pod represents a unit of deployment, a single instance of an application, which might consist of either a single container. It is a basic execution unit of a Kubernetes application that we create or deploy. It represents a process running on your cluster. It encapsulates an application’s container, storage resources, a unique network IP, and operations that govern how the container(s) should run.
Pod creates Container and Container runs as service. When Kubernetes schedules a Pod, it limits resources for the created container. Each container in the Pod can set its requests and limits. In the end, these resources requests are used by the Kubernetes to run and manage workloads. Self-healing, Docker orchestration, and resource management are only possible if the container runs as a service.
Just imagine the role and behavior of Kubernetes, If the same Pod is created, executed, and deleted on every request. This is the misbehave with Kubernetes. Kubernetes will not scale and orchestrate the container-based application.
Conclusion
If Kubernetes is used wrongly or not as per guideline then it will not scale and orchestrate the containers and deployed application. If you use Kubernetes then it means you and not using Kubernetes. You are not using the capability of a well-trained captain on the ship. It is just like a quote “If the highest aim of a captain is to preserve his ship, he would keep it in port forever.”
