Kubernetes 101: containers, components, and the basics


Kubernetes is an open-source container orchestration platform that was originally developed by Google and released as a seed technology for the Cloud Native Computing Foundation in 2015. It means ‘helmsman’ or ‘pilot’ in Greek and is written in programming language, Go.

It’s currently one of the most popular open source projects on GitHub, and has a massive supporting ecosystem, including a huge array of supporting technologies, both open and closed source. In addition to the pure open source Kubernetes, there are multiple enterprise versions, both from the major cloud providers as well as third parties. Pure open-source Kubernetes can run in any environment, including an on-premises data center.

Containers and Kubernetes

If you’re going to use containers, you will most likely want to use Kubernetes for managing a group of containers. Without Kubernetes, the manual effort required to manage containers would be prohibitive in any use case beyond a small pilot project. Containers in concert with Kubernetes are designed to more efficiently support a microservices architecture — and at an organizational level, even small companies will have hundreds of containers.

Here’s a non-exhaustive list of what Kubernetes does:

  • Manages service discovery and load balancing
  • Orchestrates storage, allowing users to connect to different storage systems
  • Automates rollouts and rollbacks, as well as allows for advanced deployment techniques
  • Handles self-healing, so that containers that fail are automatically replaced
  • Handles secrets, configurations and access management.

However, Kubernetes isn’t a complete Platform-as-a-Service. There’s also a robust ecosystem around it to help integrate everything from CI/CD tools to operational tools. Many Kubernetes tools don’t add functionality per se, but instead help automate the process of configuring Kubernetes to prevent errors and speed development cycles.  

Kubernetes components

It comes with its own set of vocabulary, so here’s what you need to know:

Pods. Kubernetes wraps one or more containers together into units called pods, which is the basic unit of deployment in Kubernetes. Containers in the same pod share resources and networks, and they are scaled up and down as a unit.

Deployments. In most cases, there will be multiple replicas of each pod. A deployment is a layer of abstraction on top of pods, that refers to the number of pods that should be running. Working with deployments allows you to declare how many pod replicas should be running at any time, and Kubernetes will ensure that number is maintained, automatically spinning up new replicas if a pod dies.

Node. A Kubernetes node is a single server in a Kubernetes cluster. This is where the container runtime runs. It also contains the Kubelet, a container that runs as an agent to communicate with the Kubernetes control plane and to ensure that pods are healthy. Each node also has a Kube-proxy, a proxy service that handles networking.

Cluster. Nodes pool their resources together to form a cluster, which is the level at which Kubernetes thinks about resources. Clusters shift resources around when nodes are killed or added in a way that’s completely automated.

Persistent volumes. Local or cloud drives can be attached to the cluster as persistent volumes — persistent storage is not pooled and managed by the cluster. Persistent volumes are associated with the cluster, but not to any specific node.

Extending Kubernetes

One of the biggest attractions of Kubernetes is its near-infinite extensibility through APIs. Even out-of-the-box Kubernetes is very flexible, controlled largely through configurations.

This highly flexible, extensible aspect of Kubernetes is both its biggest advantage and drawback. Kubernetes is very complex, and has so many potential knobs to fiddle with that accurately configuring a workload can take a long time and is error-prone. Without additional automation tools, it’s easy for teams to make mistakes at the configuration stage, leading to either security, resource usage or operational risks. The complexity also means that Kubernetes often has a steep learning curve.

This is exacerbated by the fact that Kubernetes itself is not a complete solution. Its extendable nature makes it possible to connect additional technologies to get whatever functionality is lacking, turning Kubernetes into the center of an ecosystem designed to support container-native applications.

Getting visibility

The distributed, highly interconnected nature of any microservices architecture is already very complex — and Kubernetes makes it even more so. Understanding how services relate to each other in Kubernetes is challenging, which makes both troubleshooting incidents even more challenging. effx helps organizations get visibility into services and the relationship between services, cutting through the infrastructure-level information in Kubernetes so that teams can troubleshoot incidents faster. Try effx for free!

Amir Kazemi

Amir Kazemi