--- title: "Key Kubernetes Concepts" source: "https://www.tigera.io/blog/key-kubernetes-concepts/" --- [Technical Blog](https://www.tigera.io/category/technical-blog/) # Key Kubernetes Concepts By [Jeff Hale](https://www.tigera.io/blog/author/jeffhale/) on May 10, 2019 • 14 min read Cloud computing, containerization, and container orchestration are the most important trends in DevOps. Whether you’re a data scientist, software developer, or product manager, it’s good to know Docker and Kubernetes basics. Both technologies help you collaborate with others, deploy your projects, and increase your value to employers. In this article, we’ll cover essential Kubernetes concepts. There are a lot of Kubernetes terms, which can make it intimidating. I’ll help you make a mental model to speed your understanding of the technology. ## Kuberwhat? Kubernetes is an open-source platform for managing containerized apps in production. Kubernetes is referred to as K8s for short. I’ll mostly use the term *K8s* going forward, because who doesn’t love efficiency? ![Kubernetes logo](https://cdn-images-1.medium.com/max/1200/1*nJACeVQHoVi7QYcc6Eqk3w.png) K8s is hot. As you can see in the chart below, Google searches for it have grown rapidly in the past five years. ![Chart showing rapid growth in Google searches for K8s over the past five years](https://cdn-images-1.medium.com/max/800/1*K2qc67GtA52dZrbpQbORmw.png) Worldwide search interest for *Kubernetes* Why is K8s so in demand? Kubernetes makes it easier for you to automatically scale your app, reduce downtime, and increase security. No more writing scripts to check, restart, and change the number of Docker containers. Instead, you tell K8s your desired number of containers and it does the work for you. K8s can even automatically scale your containers based on resources used. Kubernetes is all about abstracting away complexity. It provides clear points to interface with your app’s development environment. K8s doesn’t make a lot of sense for a basic static website that gets a handful of visitors per day. Its use case is for larger apps that might have to scale up and down quickly. For large apps, you can use K8s to get the most out of your compute and storage resources. When paired with cloud providers, K8s can save you money. No matter where you run K8s, it should help you save time and reduce DevOps headaches. Docker has a competing product named [Docker Swarm](http://docs.docker.com/engine/swarm/) that orchestrates containers. However, it doesn’t have the features and market share that K8s does. While you might think that Docker wouldn’t play nicely with K8s when it has its own offering, the two play extremely well together. I strongly suggest you use K8s to orchestrate your containers. ![Two children holding hands, symbolizing Docker and Kubernetes playing well together despite competition](https://cdn-images-1.medium.com/max/1200/1*skAU3Q_nyw1RR9Xh6X8Zpg.jpeg) Keeping the many K8s abstractions straight can be tricky. I’ll explain how the key parts fit together so you can wrap your head around this powerful platform. Let’s explore key K8s concepts and how they relate to each other. First, we’ll look at six layers of abstraction and the parts that make them up. Then we’ll look at seven other key K8s API objects.   ## The Six Layers of K8s Let’s assume you have an app that is running continuously and doesn’t need to store state. ![Stateless app deployment stack: Deployment, ReplicaSet, Pods, Node Cluster, Node Processes, and Docker Container](https://cdn-images-1.medium.com/max/800/1*YggVOtB-mep_HP1C4rhpGg.png) Kubernetes abstractions for a Deployment. © Jeff Hale 2019 Here are the six layers of K8s concepts, starting with the highest-level abstraction. - Deployment - ReplicaSet - Pod - Node Cluster - Node Processes - Docker Container Deployment creates and manage ReplicaSets, which create and manage Pods, which run on Nodes, which have a container runtime, which run the app code you put in your Docker image. Sounds like a the Irish folk song “[The Rattlin’ Bog](http://en.wikipedia.org/wiki/The_Rattlin%27_Bog)”. Here’s a diagram with the Worker Node processes broken out. Let’s dig in a bit. ![Diagram showing Worker Node processes: kubelet, kube-proxy, container runtime, and Docker container. Deployment, ReplicaSet,](https://cdn-images-1.medium.com/max/800/1*Y4TTxjBCff9GVRfTZy8GGw.png) Detailed Kubernetes abstraction Deployment levels. © Jeff Hale 2019 The levels shaded blue are higher-level K8s abstractions. The green levels represent Nodes and Node subprocess that you should be aware of, but may not touch. Note that your K8s instances will often have multiple Pods that can run on a single Node. The Docker container contains your application code. ***Grammar interlude*** According to K8s own [style guide](http://kubernetes.io/docs/contribute/style/style-guide/), capitalization of API objects such as *Pods*should follow the “same uppercase and lowercase letters that are used in the actual object name.” However, this guideline is often not followed in the docs — API objects are capitalized or lowercased seemingly randomly. I’m going to follow the style guide’s stated policy in my K8s articles and error on the side of capitalization. ***Grammar interlude over. *** Let’s look at the six levels individually, starting with the highest level of abstraction. ## Deployment If you want to make a stateless app that will run continuously, such as an HTTP server, you want a Deployment. Deployments allow you to update a running app without downtime. Deployments also specify a strategy to restart Pods when they die. You can create a Deployment from the command line or a configuration file. I’ll show you both methods in future articles, so follow [me](http://medium.com/@jeffhale) to make sure you don’t miss them. ? ## ReplicaSet The Deployment creates a ReplicaSet that will ensure your app has the desired number of Pods. ReplicaSets will create and scale Pods based on the triggers you specify in your Deployment. *Replication Controllers* perform the same function as ReplicaSets, but Replication Controllers are old school. ReplicaSets are the smart way to manage replicated Pods in 2019. ## Pod The [*Pod*](http://kubernetes.io/docs/concepts/workloads/pods/pod-overview/#pods-and-controllers) is the basic building block of Kubernetes. A Pod contains a group of one or more containers. Generally, each Pod has one container. ![A pea pod with multiple peas, illustrating a Kubernetes Pod containing one or more containers](https://cdn-images-1.medium.com/max/800/1*ziwaLWYlP_X4gHhf6uuYww.png) Pod Pods handle Volumes, Secrets, and configuration for containers. Pods are ephemeral. They are intended to be restarted automatically when they die. Pods are replicated when the app is scaled horizontally by the ReplicationSet. Each Pod will run the same container code. Pods live on Worker Nodes. ## Cluster Level ### Cluster A K8s Cluster consists of a C*luster Master*and *Worker Nodes.* ![Star Cluster](https://cdn-images-1.medium.com/max/800/1*vT2FsK1vXVu42yipNoagSQ.jpeg) Star Cluster. Credit: [NASA, ESA and the Hubble Heritage (STScI/AURA)-ESA/Hubble Collaboration](http://www.spacetelescope.org/images/heic0715a/) Below is a representation of a Cluster. This diagram emphasizes how multiple Pods can run on a Worker Node and multiple Worker Nodes are governed by a Master. ![Diagram of a Cluster showing multiple Pods within Worker Nodes, governed by a Cluster Master](https://cdn-images-1.medium.com/max/800/1*gT5K52iFTJf6SDhwWBaClQ.png) Kubernetes Nodes, Pods, & Containers © Jeff Hale 2019 ### Worker Node A [*Worker Node*](http://kubernetes.io/docs/concepts/architecture/nodes/)is also referred to as a *Node* for short*.*A Node is an abstraction for a machine — either a physical machine or a virtual machine. Think of a Node as a computer server. One or more Pods run on a single Worker Node. A Pod is never split between two Nodes — a Pod’s contents are always located and scheduled together on the same Node. Who’s telling the Worker Nodes what to do? The Master. ### Cluster Master The[*Cluster Master*](http://cloud.google.com/kubernetes-engine/docs/concepts/cluster-architecture#master)has a seriously ridiculous number of aliases. It’s also referred to as the *Master Node, Kubernetes Master, Cluster Control Plane, Control Plane,*andjust M*aster.*Whatever you call it, it directs the Worker Nodes. Masters make scheduling decisions, respond to events, implement changes, and monitor the Cluster. Both the Worker Nodes and the Master have subprocess components. ## Node Processes ### Master Components The Master components are the *API* *server (*aka*kube-apiserver)*, *etcd*, S*cheduler*(aka *kube-scheduler), kube-controller-manager, and cloud-controller manager*. **I added the controller-managers for completeness Apr. 10, 2019** ![Diagram of Cluster Master components: API Server, etcd, Scheduler, kube-controller-manager, and cloud-controller-manager](https://cdn-images-1.medium.com/max/800/1*2B3eMo0iCx3GCPoHWHd1EQ.png) Cluster Master subprocesses Let’s briefly look at each one. ***API Server*** — Exposes the K8s API. It’s the frontend for Kubernetes control. (aka. kube-apiserver) Think *hub*. ***etcd***— Distributed key-value store for Cluster state data. Think *Cluster info*. ***Scheduler***— Selects the Nodes for new Pods. Good guide [here](http://medium.com/@dominik.tornow/the-kubernetes-scheduler-cd429abac02f). (aka kube-scheduler) Think *matcher*. ***kube-controller-manager***—Process that runs controllers to handle Cluster background tasks. Think *Cluster controller*. ***cloud-controller-manager****—*Runs controllers that interact with cloud providers. Think *cloud interface*. ### Worker Node Components The Worker Node’s [components](http://kubernetes.io/docs/concepts/overview/components/#node-components) are the *kubelet*, *kube-proxy*, and *Container Runtime*. ![Diagram showing the Worker Node components: kubelet, kube-proxy, and Container Runtime](https://cdn-images-1.medium.com/max/800/1*rrm3H9IVzNOrlLmJsvE4dg.png) Worker Node subprocesses ***kubelet*** — Responsible for everything on the Worker Node. It communicates with the Master’s API server. Think *brain* for Worker Node. [***kube-proxy***](http://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/) — Routes connections to the correct Pods. Also performs load balancing across Pods for a Service. Think *traffic cop*. ***Container Runtime***— Downloads images and runs containers. For example, Docker is a Container Runtime. Think *Docker*. Let’s drill down one final level and look at what those Container Runtimes are running. ## Docker Container Level Your app needs to be in a container of some sort if you want to run it with K8s. Docker is by far the most common container platform. We’ll assume you’re using it. ![Docker logo: A blue whale carrying shipping containers, representing the containerization needed for Kubernetes](https://cdn-images-1.medium.com/max/800/1*glD7bNJG3SlO0_xNmSGPcQ.png) You’ll specify which Docker image your Pods should use when you create your Deployment. The Container Runtime will download the image and create the containers. K8s doesn’t create containers directly. It creates Pods that hold containers inside them. The containers in a Pod share any configured resources, such as Volume storage. There are five high-level K8s API resources that manage and run Pods: *Deployments, StatefulSets, DaemonSets, Jobs,*and*CronJobs*. These objects are responsible for managing and running the Pods that create and run your containers. Let’s look at these controllers that create and manage continuous processes ## ReplicaSets, StatefulSets, and DaemonSets As you’ve seen, aReplicaSetcreates and manages Pods. If a Pod shuts down because a Node fails, a ReplicaSet can automatically replace the Pod on another Node. You should generally create a ReplicaSet through a Deployment rather than creating it directly, because it’s easier to update your app with a Deployment. ![Diagram showing a Deployment managing a ReplicaSet, which in turn manages Pods](https://cdn-images-1.medium.com/max/800/1*4J08LAIHRduvtlaj_KzJGA.png) A Volume can be attached to a ReplicaSet, but it’s required for a StatefulSet. © Jeff Hale 2019 Sometimes your app will need to keep information about its state. You can think of state as the current status of your user’s interaction with your app. So in a video game it’s all the unique aspects of the user’s character at a point in time. For example, the state in the original [Super Mario Bros.](http://en.wikipedia.org/wiki/Super_Mario#Super_Mario_Bros.) game would include every relevant aspect of the user’s game: what level, what location in that level, big or small, fireballs or no fireballs, how many coins, how many points, and how many lives. ![Mario & Luigi figures. World 1-1, ground level. Both big, no fireballs. Coins: 0. Points: 0. Lives: 3](https://cdn-images-1.medium.com/max/800/1*Ofsyr1MsOaxCerN6fa0A-w.jpeg) What do you do when your app has state you need to keep track of? Use a StatefulSet. ### StatefulSet Like a ReplicaSet, a[*StatefulSet*](http://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)manages deployment and scaling of a group of Pods based on a container spec. Unlike a Deployment, a StatefulSet’s Pods are not interchangeable. Each Pod has a unique, persistent identifier that the controller maintains over any rescheduling. StatefulSets for good for persistent, stateful backends like databases. The state information for the Pod is held in a Volume associated with the StatefulSet. We’ll discuss Volumes in a bit. ### DaemonSet [*DaemonSets*](http://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) are for continuous process. They run one Pod per Node. Each new Node added to the cluster automatically gets a Pod started by the DaemonSet. DaemonSets are useful for ongoing background tasks such as monitoring and log collection. StatefulSets and DaemonSets are not controlled by a Deployment. Although they are at the same level of abstraction as a ReplicaSet, there is not a higher level of abstraction for them in the current API. Now let’s look at Jobs and CronJobs. ## Jobs and CronJobs ### Job A [*Job*](http://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/)is a supervisor for Pods that run a batch process. A Job creates Pods and ensures they do a task by tracking the number of successful Pod completions. Unlike a ReplicaSet, once the process inside the container finishes successfully, the container is not restarted. Use a Job when you want to run a process once. ### CronJob If you want to run a Job at regular, specified times (e.g. hourly, daily, or monthly), create a [*CronJob*](http://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/)*.*A CronJob is similar to a Job, but is scheduled to repeat at regular intervals or set times. ![Pocket watch with visible gears, representing scheduled, repeated tasks of a CronJob](https://cdn-images-1.medium.com/max/800/1*jsgssp7WXxxYULDxk_jVbw.jpeg) Time You’ll often need to create a Service to provide consistent access to your ephemeral Pods. ## Service A K8s [*Service*](http://kubernetes.io/docs/concepts/services-networking/service/) creates a single access point for a group of Pods. A Service provides a consistent IP address and port to access underlying Pods. Both external users and internal Pods use Services to communicate with other Pods. Services come in a variety of flavors. Networking with K8s a topic worthy of its own guide. Fortunately, there’s a good one by [Sandeep Dinesh](http://medium.com/@SandeepDinesh) [here](http://medium.com/google-cloud/kubernetes-nodeport-vs-loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0). Now let’s look at storing data with Volumes and PersistentVolumes. ## Volumes, PersistentVolumes, and PersistentVolume Claims ### Volumes A [*Volume*](http://kubernetes.io/docs/concepts/storage/volumes/) is a directory that can hold data. A Volume is a component of a Pod, and is not independent of it. A Volume is created in the Pod specification. A Volume cannot be deleted on its own. A Volume is made accessible to all the containers in a Pod. Each container that you want to access the Volume must mount it individually. A K8s Volume outlives any individual containers, but when the enclosing Pod dies, the Volume dies, too. However, the files of some Volume types continue to exist in local or cloud storage, even after the Volume is gone. ![Shelves of files and boxes represent data persistence in K8s Volumes](https://cdn-images-1.medium.com/max/800/1*7NY9Itkqy57i_Hd8uP-FuA.jpeg) Volumes A K8s Volume has more functionality than a Docker volume. A Volume can provide access to local disk storage, memory storage, or cloud storage. A Pod can use a combination of them simultaneously. K8s Volume types include empty directories, Worker Node’s filesystems, and cloud provider-specific storage. For example, awsEleasticBlockStore and gcePersistentDisk are provider-specific options for long-term storage. See more in the docs [here](http://kubernetes.io/docs/concepts/storage/volumes/). ### PersistentVolumes and PersistentVolumeClaims To help abstract away infrastructure specifics, K8s developed [*PersistentVolumes*](http://kubernetes.io/docs/concepts/storage/persistent-volumes/)and *PersistentVolumeClaims*. Unfortunately the names are a bit misleading, because vanilla Volumes can have persistent storage, as well. PersisententVolumes (PV) and PersisentVolumeClaims (PVC) add complexity compared to using Volumes alone. However, PVs are useful for managing storage resources for large projects. With PVs, a K8s user still ends up using a Volume, but two steps are required first. - A PersistentVolume is provisioned by a Cluster Administrator (or it’s provisioned dynamically). - An individual Cluster user who needs storage for a Pod creates a *PersistentVolumeClaim*manifest. It specifies how much and what type of storage they need. K8s then finds and reserves the storage needed. The user then creates a Pod with a Volume that uses the PVC. PersistentVolumes have lifecycles independent of any Pod. In fact, the Pod doesn’t even know about the PV, just the PVC. PVCs consume PV resources, analogously to how Pods consume Node resources. Wild! ![A roaring lion, mouth open wide, illustrating the consumption of resources. Wild](https://cdn-images-1.medium.com/max/800/1*58estJjCSLocLzWKP3sm0w.jpeg) ## Wrap I hope you found this introduction to K8s concepts helpful. If you did, please share it on your favorite social media so others can find it, too. ? Let’s recap the K8s concepts we’ve seen. Here are the six levels of abstraction for a Deployment: - **Deployment**: manages ReplicaSets. Use for persistent, stateless apps (e.g. HTTP servers). - **ReplicaSet***:* creates and manages Pods. - **Pod***:*basic unit of K8s. - **Node Cluster**: Worker Nodes + Cluster Master. – **Worker** **Nodes**: machines for Pods. – **Cluster Master***:*directs worker nodes. - **Node Processes** Master subcomponents: – **API server**: hub. – **etcd**: cluster info. – **scheduler**: matcher. – **kube-controller-manager*:***cluster controller. – **cloud-controller-manager:**cloud interfa. Worker Node subcomponents: – **kubelet**: Worker Node brain. – **kube-proxy**: traffic cop. – **container-runtime**: Docker. - **Docker Container:**where the app code lives. Here are the 7 additional high-level K8s API objects to know: - **StatefulSet**: Like a ReplicaSet for stateful processes. Think *state*. - **DaemonSet:**One automatic Pod per Node. Think *monitor*. - **Job**: Run a container to completion. Think *batch*. - **CronJob:**Repeated Job.Think *time*. - **Service**: Access point for Pods. Think *access point*. - **Volume**: Holds data. Think*disk.* - **PersistentVolume, PersistentVolumeClaim:** System for allocating storage. Think *storage claim*. Wrapping your head around K8s requires understanding many abstract concepts. Don’t expect that you’ll remember them all the first time. Check out some of the resources below to build your mental model. ## Resources Here are resources to reinforce what you’ve learned. - [Here’s a nice comic](http://cloud.google.com/kubernetes-engine/kubernetes-comic/) from Google that introduces key concepts. - [Another good overview](http://medium.com/google-cloud/kubernetes-101-pods-nodes-containers-and-clusters-c1509e409e16) of key K8s concepts by [Daniel Sanche](http://medium.com/@sanche). - Check out Nigel Poulton’s [The Kubernetes Book](http://www.amazon.com/Kubernetes-Book-Version-November-2018-ebook-dp-B072TS9ZQZ/dp/B072TS9ZQZ/ref=mt_kindle?_encoding=UTF8&me=&qid=1509660871) — now at v3. The Kindle Book was last updated Nov. 2018. Also, follow [me](http://medium.com/@jeffhale) to make sure you don’t miss my future articles on K8s. In the next article I’ll show you how to set up and run your first K8s Deployment. We’ll also cover key K8s commands. I write about DevOps, cloud computing, Python, and data science. Check out my articles [here](http://medium.com/@jeffhale) if you’re into that stuff. This article originated from http://towardsdatascience.com/key-kubernetes-concepts-62939f4bc08e [Jeff Hale](http://towardsdatascience.com/@jeffhale?source=user_popover) is a Tigera guest blogger. Jeff helps organizations unlock the potential in their data. He is an experienced entrepreneur who has managed technology, operations, and finances for several companies. ————————————————- [**Free Online Training**](https://www.tigera.io/events/) Access Live and On-Demand Kubernetes Tutorials [**Calico Enterprise – Free Trial**](https://www.calicocloud.io/home) Solve Common Kubernetes Roadblocks and Advance Your Enterprise Adoption [Open Source](https://www.tigera.io/tags/open-source/) ## Related posts [![What’s new in Calico: Spring 2026 Release](https://www.tigera.io/app/uploads/2026/06/Whats-New-in-Calico-NEW-TEMPLATE-2026.png)](https://www.tigera.io/blog/whats-new-in-calico-spring-2026-release/) [Company Blog](https://www.tigera.io/category/company-blog/) #### [What’s new in Calico: Spring 2026 Release](https://www.tigera.io/blog/whats-new-in-calico-spring-2026-release/) By [Veronika Smolik](https://www.tigera.io/blog/author/veronika-smolik/) on Jun 2, 2026 Kubernetes has come a long way since its debut in 2014. It’s gone from running a couple of containerized microservices to orchestrating fleets of production workloads spanning everything from AI agents to full scale VMs... [Read more](https://www.tigera.io/blog/whats-new-in-calico-spring-2026-release/) [![Kubernetes Operational Maturity: Secure and Resilient Cluster Federation with Cluster Mesh](https://www.tigera.io/app/uploads/2026/05/Kubernetes-Operational-Maturity-Secure-and-Resilient-Cluster-Federation-with-Cluster-Mesh.png)](https://www.tigera.io/blog/kubernetes-operational-maturity-secure-and-resilient-cluster-federation-with-cluster-mesh/) #### [Kubernetes Operational Maturity: Secure and Resilient Cluster Federation with Cluster Mesh](https://www.tigera.io/blog/kubernetes-operational-maturity-secure-and-resilient-cluster-federation-with-cluster-mesh/) By [Veronika Smolik](https://www.tigera.io/blog/author/veronika-smolik/) on May 25, 2026 Practically no one runs a single Kubernetes cluster in production these days. Maybe that’s how it started but data sovereignty requirements, acquisitions, AI initiatives and the need for edge servers, among other considerations, have pulled... [Read more](https://www.tigera.io/blog/kubernetes-operational-maturity-secure-and-resilient-cluster-federation-with-cluster-mesh/) [![What’s New in Calico v3.32](https://www.tigera.io/app/uploads/2026/05/Green-Please-use-a-different-background-color-alternately-1.png)](https://www.tigera.io/blog/whats-new-in-calico-v3-32/) #### [What’s New in Calico v3.32](https://www.tigera.io/blog/whats-new-in-calico-v3-32/) By [Reza Ramezanpour](https://www.tigera.io/blog/author/rezar/) on May 13, 2026 We’re excited to announce the release of Calico Open Source v3.32! 🎉 This release corresponds with Kubernetes v1.36 (Codename Haru) and it goes beyond just sharing a cat as the mascot of the release, it... [Read more](https://www.tigera.io/blog/whats-new-in-calico-v3-32/)