Containers are great. They provide you with an easy way to package and deploy services, allow for process isolation, immutability, efficient resource utilization, and are lightweight in creation.
But when it comes to actually running containers in production, you can end up with dozens, even hundreds of containers over time. These containers need to be deployed, managed, and connected and updated; if you were to do this manually, you’d need an entire team dedicated to this.
It’s not enough to run containers; you need to be able to:
- Integrate and orchestrate these modular parts
- Scale up and scale down based on the demand
- Make them fault tolerant
- Provide communication across a cluster
Kubernetes: More than just container orchestration
Kubernetes, originally an open source project launched by Google and now part of the Cloud Native Computing Foundation (CNCF), Kubernetes makes managing containers at web scale seamless with low operational overhead.
Kubernetes is fundamentally used to deploy and manage a cluster of containerized applications and can be used to establish your own CaaS platform. It helps manage microservice application architectures and is now a critical tool for building robust modern devops CI/CD pipelines.
To better understand the relation between Kubernetes and containers it’s important to understand containers. Kubernetes bundles a set of containers. An example container set could be an app server, redis cache, sql database. Docker containers are one process per container. Kubernetes puts these containers into a group that it manages on the same machine to reduce network overhead and increase resource usage efficiency.
The six key features of an orchestrator that we mentioned earlier apply to Kubernetes in the following ways:
Scheduling: The Kubernetes scheduler ensures that demands for resources placed upon the infrastructure may be met at all times.
Resource management: In the context of Kubernetes, a resource is a logical construct that the orchestrator can instantiate and manage, such as a service or an application deployment.
Service discovery: Kubernetes enables services sharing the system together to be discoverable by name. This way, the pods containing services may be distributed throughout the physical infrastructure without having to retain network services to locate them.
Health check: Kubernetes utilizes functions called “liveness probes” and “readiness probes” to provide periodic indications to the orchestrator of the status of applications.
Autoscaling: With Kubernetes, the horizontal pod autoscaler automatically generates more replicas when it appears the designated CPU resources for a pod may be underutilized.
Updates/upgrades: An automated, rolling upgrade system enables each Kubernetes deployment to remain current and stable.
A contemporary application, packaged as a set of containers, needs an infrastructure robust enough to deal with the demands of clustering and the stress of dynamic orchestration. Such an infrastructure should provide primitives for scheduling, monitoring, upgrading and relocating containers across hosts. It must treat the underlying compute, storage, and network primitives as a pool of resources. Each containerized workload should be capable of taking advantage of the resources exposed to it, including CPU cores, storage units and networks.
Kubernetes is a cluster manager that abstracts the underlying physical infrastructure, making it easier to run containerized applications at scale. An application, managed through the entirety of its life cycle by Kubernetes, is composed of containers gathered together as a set and coordinated into a single unit. An efficient cluster manager layer lets Kubernetes effectively decouple this application from its supporting infrastructure.
A Kubernetes cluster needs at least one compute node, but will normally have many. Pods are scheduled and orchestrated to run on nodes. Need to scale up the capacity of your cluster? Add more nodes.
A pod is the smallest and simplest unit in the Kubernetes object model. It represents a single instance of an application. Each pod is made up of a container or a series of tightly coupled containers, along with options that govern how the containers are run. Pods can be connected to persistent storage in order to run stateful applications.
Container runtime engine
To run the containers, each compute node has a container runtime engine. Docker is one example, but Kubernetes supports other Open Container Initiative-compliant runtimes as well, such as rkt and CRI-O.
Each compute node contains a kubelet, a tiny application that communicates with the control plane. The kublet makes sure containers are running in a pod. When the control plane needs something to happen in a node, the kubelet executes the action.
Each compute node also contains kube-proxy, a network proxy for facilitating Kubernetes networking services. The kube-proxy handles network communications inside or outside of your cluster — relying either on your operating system’s packet filtering layer, or forwarding the traffic itself.
Since Kubernetes is open source, it allows the freedom to take advantage of on-premises, hybrid, or public cloud infrastructures. And, it lets you effortlessly move workloads to where it matters to you. Kubernetes can be combined with modern pipeline tools like Jenkins to build highly agile and lean CI/CD systems.
While Kubernetes can present some challenges at the outset, it offers clear benefits and stands apart from other orchestration tools in many ways.