Updated 1 Nov 2026 · 7 min read
On this page
This guide explains the Kubernetes objects you meet first, using the definitions in the official kubernetes.io documentation. By the end you will be able to say what each object is for, pick the right workload object for a job, choose between the four Service types, and explain how a Pod gets configuration and persistent storage.
What a Kubernetes object is
The documentation defines Kubernetes objects as persistent entities that Kubernetes uses to represent the state of your cluster. An object is a "record of intent": once you create it, Kubernetes constantly works to make sure it exists. You are describing the desired state, not issuing a one-off command.
Almost every object has two nested fields that matter. The spec is what you set: the desired state. The status is the current state, supplied and updated by Kubernetes. The control plane continually works to make the actual state match the spec. The docs list the fields you need to set in a manifest as apiVersion, kind, metadata and spec, where spec applies to objects that have one. This is the Deployment example from the docs:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 2 # tells deployment to run 2 pods matching the template
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80You would create it with kubectl apply -f and the file name.
Pods, ReplicaSets and Deployments
A Pod is the smallest deployable unit of computing you can create and manage in Kubernetes. It is a group of one or more containers with shared storage and network resources and a specification for how to run them, always co-located and co-scheduled. The docs say you will rarely create individual Pods directly, even singleton Pods, because Pods are designed as relatively ephemeral, disposable entities. Instead you create them through workload resources.
A ReplicaSet exists to maintain a stable set of replica Pods running at any given time. It has a selector to identify its Pods, a replica count and a Pod template for creating new ones. The docs recommend that you usually define a Deployment and let it manage ReplicaSets for you.
A Deployment provides declarative updates for Pods and ReplicaSets. When you change the Pod template, the Deployment creates a new ReplicaSet and gradually scales it up while scaling the old one down. By default a rolling update keeps at least 75% of the desired Pods up (25% max unavailable) and at most 125% (25% max surge). You can also roll back to an earlier revision. With the example above, a Deployment of 2 replicas owns one ReplicaSet, which owns 2 Pods.
StatefulSets, DaemonSets, Jobs and CronJobs
Deployments suit applications that do not keep state and whose Pods are interchangeable. The other workload objects cover the cases a Deployment does not.
| Object | What it guarantees | Use it for |
|---|---|---|
| StatefulSet | Each Pod keeps a sticky identity: an ordinal (0 up to N-1 by default), a stable network identity and stable storage, whichever node it is rescheduled on. Hostnames follow the pattern $(statefulset name)-$(ordinal). |
Applications needing stable network identifiers, stable persistent storage, or ordered deployment, scaling and rolling updates |
| DaemonSet | All (or some) nodes run a copy of a Pod. New nodes get the Pod, removed nodes have theirs garbage collected. | A storage, log collection or monitoring daemon on every node |
| Job | Creates one or more Pods and keeps retrying until a specified number of them successfully terminate. | One-off tasks that run to completion |
| CronJob | Creates Jobs on a repeating schedule written in Cron format in .spec.schedule. |
Regular scheduled actions such as backups and report generation |
Two details are worth knowing. A StatefulSet needs a headless Service for the network identity of its Pods, and you are responsible for creating it. A Job's Pod template only allows a restart policy of Never or OnFailure.
Services and their types
Pods are created and destroyed to match the desired state, so you should not rely on any individual Pod. A Service is a method for exposing a network application running as one or more Pods behind a single outward-facing endpoint. The set of Pods behind it is usually chosen by a selector you define. The type field sets how it is exposed:
| Type | Behaviour |
|---|---|
| ClusterIP | A cluster-internal IP, reachable only from within the cluster. This is the default when you set no type. |
| NodePort | Exposes the Service on each node's IP at a static port, allocated by default from 30000 to 32767. Kubernetes also sets up a cluster IP, as for ClusterIP. |
| LoadBalancer | Exposes the Service externally using an external load balancer. Kubernetes does not provide the load balancer itself: you supply one or integrate with a cloud provider. |
| ExternalName | Maps the Service to an external hostname by making the cluster DNS return a CNAME record. No proxying is set up. |
For HTTP traffic from outside the cluster there is Ingress, an API object that manages external access to Services, typically HTTP, and may provide load balancing, SSL termination and name-based virtual hosting. An Ingress does nothing on its own: you must have an Ingress controller running. Note the current status on kubernetes.io: the Ingress API is frozen, the project has no plans to remove it, and the Kubernetes project now recommends the Gateway API instead.
ConfigMaps, Secrets and Namespaces
A ConfigMap stores non-confidential data as key-value pairs, which Pods can consume as environment variables, command-line arguments or configuration files in a volume. That keeps environment-specific settings out of your container images. The data in one ConfigMap cannot exceed 1 MiB, and a ConfigMap provides no secrecy or encryption.
A Secret holds a small amount of sensitive data such as a password, token or key, so it does not have to live in a Pod specification or image. Individual Secrets are limited to 1 MiB. Be precise about what a Secret protects: by default Secrets are stored unencrypted in the API server's data store (etcd), anyone with API access can retrieve or modify one, and anyone allowed to create a Pod in a namespace can read any Secret in that namespace.
A Namespace isolates groups of resources within one cluster. Names must be unique within a namespace but not across namespaces, and namespaces cannot be nested. Scoping applies only to namespaced objects such as Deployments and Services, not to cluster-wide objects such as StorageClasses, Nodes and PersistentVolumes. A new cluster starts with four: default, kube-node-lease, kube-public and kube-system.
PersistentVolumes and PersistentVolumeClaims
Kubernetes separates how storage is provided from how it is consumed. A PersistentVolume (PV) is a piece of storage in the cluster, provisioned by an administrator or dynamically through a StorageClass, with a lifecycle independent of any Pod that uses it. A PersistentVolumeClaim (PVC) is a user's request for storage of a given size and access mode. Pods use claims as volumes. A PVC to PV binding is one-to-one, and a claim stays unbound if no matching volume exists.
| Access mode | Meaning |
|---|---|
| ReadWriteOnce (RWO) | Read-write by a single node (several Pods on that node can still use it) |
| ReadOnlyMany (ROX) | Read-only by many nodes |
| ReadWriteMany (RWX) | Read-write by many nodes |
| ReadWriteOncePod (RWOP) | Read-write by a single Pod |
The reclaim policy decides what happens once a claim is released. Retain keeps the volume for manual reclamation, Delete removes the PV and its backing storage, and Recycle is deprecated in favour of dynamic provisioning. Dynamically provisioned volumes inherit their StorageClass's policy, which defaults to Delete.
How this fits your exam
Linux Foundation CKA. The Linux Foundation's CKA page says the exam is based on Kubernetes v1.35. Its curriculum lists, under Workloads & Scheduling (15%), "Understand application deployments and how to perform rolling update and rollbacks" and "Use ConfigMaps and Secrets to configure applications". Services & Networking (20%) includes "Use ClusterIP, NodePort, LoadBalancer service types and endpoints", "Use the Gateway API to manage Ingress traffic" and "Know how to use Ingress controllers and Ingress resources". Storage (10%) includes "Manage persistent volumes and persistent volume claims" and "Configure volume types, access modes and reclaim policies". The CKA exam guide covers the remaining domains.
Linux Foundation KCNA. The KCNA curriculum is broader and does not list individual objects. Kubernetes Fundamentals (44%) covers Kubernetes Core Concepts, Administration, Scheduling and Containerization, and Container Orchestration (28%) covers Networking, Security, Troubleshooting and Storage. See the KCNA study guide for the full outline.
Frequently asked questions
Should I learn Ingress or the Gateway API?
Both, if you are sitting the CKA, because its curriculum lists both Ingress controllers and resources and the Gateway API. For new work, kubernetes.io recommends Gateway over Ingress. The Ingress API is frozen but generally available, and the project has no plans to remove it.
Is a Secret encrypted?
Not by default. The docs state that Secrets are stored unencrypted in etcd unless you take extra steps, and that anyone with API access, or permission to create Pods in the namespace, can read them. A Secret's value is that it keeps sensitive data out of Pod specs and images and can be handled separately from them.
When do I choose a StatefulSet over a Deployment?
When each Pod needs its own stable identity: a fixed ordinal and hostname, stable storage, or ordered start-up and updates. If an application needs none of those, the docs say to use a workload object that provides stateless replicas, which is what a Deployment does.
Sources
- Objects In Kubernetes
- Deployments
- Service
- Persistent Volumes
- Certified Kubernetes Administrator (CKA)
- Kubernetes and Cloud Native Associate (KCNA)
Check what you remember with the free CKA practice questions, and use the CKA study guide to plan the hands-on work.