Cloud native has changed how infrastructure is designed and operated. Whether you are new to Kubernetes or already starting to take on production responsibilities, these 22 concepts form the core vocabulary you need to understand.
If you’re brand‑new, start with Workloads, then Pod Controllers, then Networking (Services and Ingress). Once you’re deploying real apps, focus on NetworkPolicy and the RBAC objects, because they drive security, reliability, and compliance.
“Fairwinds has saved us time and money by providing expert Kubernetes guidance, so we can focus on building, not maintaining infrastructure.”
Nimret Sandhu, Director of Technical Cloud Operations - Zonar
A node is a virtual or physical machine that runs your containerized workloads. Each node includes the services needed to run Pods and is managed by the Kubernetes control plane.
A cluster is the set of nodes (and the control plane) that Kubernetes manages as a single system. All of your containerized applications run on top of one or more clusters.
A pod is the smallest deployable unit in Kubernetes and usually contains one or more tightly coupled containers. Pods are almost never created directly; controllers handle pod creation, updates, and scaling for you.
A namespace is a virtual cluster within a physical cluster. Namespaces help you separate environments (like dev, staging, prod) or teams, and provide a scope for names and access controls.
A Deployment is the most common way to run stateless applications on Kubernetes. It manages ReplicaSets for you and handles rolling updates, rollbacks, and scaling.
A ReplicaSet maintains a stable set of identical pods, ensuring a specified number are running at any given time. You rarely create it directly; Deployments manage ReplicaSets under the hood.
A DaemonSet ensures that some or all nodes run a copy of a pod—commonly used for system‑level agents like CNI plugins, logging, monitoring, or proxies. As nodes are added or removed, the DaemonSet automatically adds or removes the pods.
A StatefulSet is used for stateful applications that need stable network identities and persistent storage, such as databases or message queues. Pods are created in a specific order, keep consistent names (app‑0, app‑1, …), and retain their associated storage across restarts.
An HPA automatically adjusts the number of pod replicas for a Deployment, ReplicaSet, or StatefulSet based on metrics like CPU or custom metrics such as request latency. It helps align resource usage with demand for both performance and cost.
A PDB defines how many pods of a replicated application can be taken down at once during voluntary disruptions like node maintenance or upgrades. It helps you maintain availability while still allowing infrastructure changes.
A Job runs pods until a task successfully completes, then stops. It is ideal for one‑off or batch workloads such as data processing tasks or maintenance scripts.
A CronJob creates Jobs on a schedule, similar to cron in traditional systems. It is used for recurring tasks like nightly reports, backups, or periodic cleanup.
A ConfigMap stores non‑sensitive configuration data as key‑value pairs, such as application settings or environment variables. Pods can consume ConfigMaps as environment variables, command‑line arguments, or configuration files.
Secret
A Secret is designed to hold sensitive data like passwords, API keys, and tokens. It is similar to a ConfigMap but intended for confidential values and is handled more carefully by Kubernetes and supporting tools.
A Service provides a stable network endpoint for a set of pods, even as the underlying pods are created and destroyed. It handles service discovery and load‑balances traffic across healthy pod instances.
An Ingress defines how external HTTP/HTTPS traffic reaches Services inside the cluster. Paired with an Ingress controller or gateway, it can provide routing, TLS termination, and virtual hosting for multiple applications.
A NetworkPolicy specifies which pods can communicate with each other and with external endpoints. It lets you move toward a zero‑trust model by restricting traffic instead of allowing everything by default.
Kubernetes Role‑Based Access Control (RBAC) is how you define who can do what within the cluster.
A ServiceAccount provides an identity for processes running in pods. Workloads use ServiceAccounts to authenticate to the API server and act within defined permissions.
A Role is a set of permissions (verbs on resources) scoped to a single namespace. It defines what actions are allowed, but only within that namespace.
A ClusterRole is similar to a Role but is not limited to a namespace. It can grant access to cluster‑wide resources or be reused across multiple namespaces.
A RoleBinding attaches a Role to one or more subjects (Users, Groups, or ServiceAccounts) within a specific namespace. It effectively says, “these identities get the permissions from this Role in this namespace.”
A ClusterRoleBinding attaches a ClusterRole to subjects at the cluster scope, granting those permissions across all namespaces (or for cluster‑wide resources).
Once you’re comfortable with these concepts, you’ll be in a strong position to explore more advanced topics like platform engineering, multi‑cluster architectures, and running AI/ML workloads on Kubernetes.
Now that you understand the core Kubernetes objects, the next step is to see how they work together in real clusters. Start by applying these concepts in a small environment: deploy a simple app with a Deployment and Service, add an Ingress, and experiment with ConfigMaps, Secrets, and basic RBAC.
As you grow more comfortable, focus on production‑oriented topics:
Using Namespaces, NetworkPolicies, and RBAC to separate environments (dev/stage/prod) and tighten security
Tuning resource requests/limits and using HPAs to balance performance and cost
Managing add‑ons and upgrades so clusters stay secure and on supported versions
From there, you’ll be well‑positioned to explore more advanced areas such as internal developer platforms, multi‑cluster setups, and running AI/ML workloads on Kubernetes.
Learn more about Kubernetes architecture basics.
Some definitions sourced from kubernetes.io.
Originally published July 24, 2020 and updated December 9, 2025.
