Comparing Virtual Machines to Containers
|Each VM runs an operating System
||All containers share the OS
||Operating system level virtualization
|Startup time in minutes
||Startup time in seconds
|Allocates required memory
||Requires less memory space
Their lightweight size is usually measured in megabytes and takes just seconds to start, versus gigabytes and minutes for virtual machines. Containers provide a highly efficient and granular technique for combining software components into the service stacks needed in a modern enterprise, as well as keeping those software pieces updated and maintained.
Docker has demonstrated that containerization can streamline the process of moving applications through development, testing, and production. However, once the app matures, there is a growing demand to run multiple containers across multiple computers.
Containers are environment agnostic meaning they can run without changes
Microservices architecture enables a single monolithic application to be structured into its component services
A container requires minimal resources to run thus increasing operating efficiency while reducing costs.
The intricate architecture dealing with scheduling, networking, and storage needs supporting containers demanded another set of tools. Without proper instruments, building and maintaining a series of microservices can be even more challenging than maintaining a single monolithic application. Some workloads require thousands of container instances running across multiple hosts. They require constant scheduling, monitoring, orchestrating, and scaling.
By design – containers are ephemeral – so the developers can quickly and easily perform testing and afterward recycle them back into the resource pool. In fact, one recent study had found that 74% of containers have a lifespan of less than an hour.
To address that challenge, various frameworks for organizing containers running in distributed computing environments have surfaced such as Kubernetes, Mesosphere DC/OS, Docker Swarm, and others. The Kubernetes platform has emerged as the most favored and operator-friendly solution. Since it was converted to an open-source in 2014, it has received exceptional support from the community, members, enterprises, and the rest of the industry, which resulted in the creation of an incredible ecosystem.
The Rise of Kubernetes
Kubernetes is based on Google’s internal cluster management system that scales its ecosystem of apps, Gmail, YouTube, Maps, and so on. While the technology was pioneered at Google, it is now maintained by the Cloud Native Computing Foundation (CNCF).
Google partnered with the Linux Foundation to form the CNCF and donated Kubernetes 1.0. The open-source community has nurtured and contributed to it to the extent of making it the undisputed go-to container management platform. Today, Kubernetes is a must-have and the only platform offered as a managed service by all of the top public cloud vendors (Google, Microsoft, Amazon, IBM, DigitalOcean, VMware, and so on). If and whenever needed, you can
routinely move containerized applications among public cloud vendors and private environments. Kubernetes breaks cloud barriers and may be a viable solution to the vendor-lock-in perplexity. Although Kubernetes is self-healing, the need for continuous monitoring of your cluster and application health is crucial. Some of the most prominent add-on tools are Prometheus and Grafana, which provide real-time monitoring.
To understand better, let’s look at the Kubernetes’ components. At its core, etcd is Kubernetes’ system of record, a highly consistent database. The API Server is a frontend policy agent and the only component that talks to etcd. It handles gateway policies such as permissions, authentication, schema validation, and resource initialization.
Scheduler does the bin packing or which container is going to run on which machine (selects the nodes for new pods). Controller Manager does the background processes. Kubelet is the agent that is responsible for sets of pods that are allocated to its node. Each Controller continuously compares its configuration (ideal state) with the actual state of pods and clusters in the real world. They react to each other very quickly, making the system exceptionally responsive and self-healing. If a controller cannot fully achieve the desired state, it will keep trying until it finds a fix. Pods are the smallest deployable units in which at least one container is managed – a container image runs in a pod. A set of pods typically binds a container, its storage resources, IP address, and other components into an instance of an application that will run on Kubernetes. Groups of pods are co-located on a single machine called a node. Docker is usually the container runtime used in a pod. Nodes are grouped into clusters, which, in turn, are managed by a master node. As a Kubernetes administrator, you specify clusters by using a YAML file declaration.
As more services move to the cloud and containerization, organizations will be able to focus more on deploying their applications and less on managing virtual or bare-metal machines. Kubernetes is sprawling, sophisticated, and thus challenging to set up and configure. Most pods hold just one container though tightly-coupled processes will sometimes share a pod.
Businesses are struggling to understand the need and the role of containers in their DevOps strategy as well as to build teams that can develop and support these technologies. Not only that, but much of the heavy lifting is left to the end-user. The most optimal approach, therefore, is not to take the code and try to implement it solely, but to seek out a complete container solution that includes Kubernetes as a managed component.