Introduction to K8s: The Basics

If you work with cloud anything, you will have at least heard the name Kubernetes or its abbreviation K8s. It is a system for automating deployment, scaling, and management of containerized applications that quickly rose to dominance after Google open-sourced it.  The original code grew out of similar tools used to run Google’s own systems.  Since its release, it has attracted a large following and has been taken under the wing of the Cloud Native Computing Foundation, which manages development and supports the community.

One of the key draws to adopting Kubernetes comes from the SRE mindset at Google to automate away “toil” or unnecessary manual tasks.  Kubernetes provides the ability to run containerized applications in production environments in a responsive manner.  Kubernetes can be configured to scale a system up or down in response to changes in load. It can smoothly roll out new applications and, if needed, roll back to a previous version.  It can gracefully handle the loss of application instances by automatically bringing new instances online. It automates service discovery and provides load balancing.

Kubernetes Concepts 

One challenge about Kubernetes is that there is a fair bit of terminology to learn to make sense of what the pieces are and what function those pieces provide.

Kubernetes Cluster 

A cluster encompasses the compute, network, and storage resources that Kubernetes, and the applications it will manage, have access to. Cluster networks are flat to support East-West communication between pods and support both IPV4/IPV6 addresses. Storage can be local, provided via a cloud service, or provided via a networked storage system (e.g. Gluster, Ceph, NFS,…)  The actual cluster size will depend on the available compute resources.  It is possible to spin up a Kubernetes cluster with one to a few nodes on a typical laptop.  For production systems, can be run on bare metal servers, on virtual machines, or even nested within containers.

Kubernetes Pods 

Pods are a container management concept that is truly unique to Kubernetes. A pod is a logical group of containers that are run together. The applications that are grouped in a pod provide the application, storage and a shared namespace. While Pods could run a single application container, the model supports the use of microservice architectures where the multi-container pod represents an instance of a complete application.


A production system will most likely be running multiple Pods, called ReplicaSets, and a Kubernetes Deployment provides a declarative process to update ReplicaSets. Initially, this could mean deploying a ReplicaSet that launches the application pods for the first time.  This is handy enough, but when your system is already running, updating your Deployment specification will cause the Deployment Controller to compare the desired state with the current state and then gracefully update the system to the new state.  This could, incidentally, mean removing an existing Deployment.  The Controller also monitors the system and assures that the desired state is enforced.  If a Pod goes offline, the Controller will spin up another to make sure the correct number of pods remain in service.


The labels are key: value pairs used to tag objects and create resource groupings. Individual objects, such as Pods, each have a unique ID. Labels allow the creation of meaningful tags that then simplify group interactions, such as using a label selector to identify a set of objects.


A Kubernetes Service is an abstraction that defines a logical set of Pods. It also provides an access policy. While Pods have their own IP addresses, a Service provides a single DNS name for a set of Pods and Kubernetes can load-balance across them. This setup allows a Service function to be targeted rather than specific application pods, which are ephemeral resources. For example, this allows a frontend application targeting, say a back end database, to call the service and be appropriately connected rather than needing a way to select a specific database Pod.


The Kubelet is the agent running on each node that handles registering the node, sharing the health status of the node, and watching the Kubernetes API for for scheduled creations and deletions of pods. It runs as a binary and works with a combination of configuration files and the etcd servers to handle clusters on each node.

The Kubelet is an agent that runs on each Kubernetes-managed node and is itself responsible for managing Pods on the node where it resides. It registers its node with the Kubernetes apiserver using either the hostname, a flag (used to override the hostname), or cloud-provider specific logic. The Kubelet further provides updates on node health and is responsible for managing Pod creation and deletion.  The Kubernetes API provides a YAML or JSON PodSpec to ensure that the desired Pods are running correctly and healthy.

As you can see, there is a fair bit of terminology to get familiar with before getting started working with Kubernetes. You can find greater details, and more terminology, at the Kubernetes homepage.  For more Kubernetes info, check out Kubernetes Best Practices & Cloud Cost Optimization.

At Opsani, we automate away the complexity of operating Kubernetes systems with machine learning algorithms that provide continuous optimization for Kubernetes. What is challenging or impossible for a human, the Opsani AI handily finds and applies optimal configurations to the environment.  Further, Opsani continually refines its understanding of the optimum across time and through load variations.

Contact Opsani to know more about how they can help you optimize your infrastructure and cut your costs with the power of AI and ML. You can also sign up for a free trial and experience how Opsani can take your business to greater heights.