Container
A container is an isolated process that runs from a container image, sharing the host operating system kernel rather than booting its own. It packages an application together with its dependencies so it runs identically across environments. Isolation is provided by Linux kernel features such as namespaces (for visibility) and cgroups (for resource limits).
Container Image
A container image is a read-only, layered filesystem bundle plus metadata that describes how to run a container. Each instruction in a Dockerfile produces a layer, and layers are content-addressed so identical layers are shared and cached. An image is identified by a name, tag, and an immutable digest (a SHA-256 of its manifest).
Image Layer
A layer is an immutable filesystem diff produced by a single build step. Layers stack via a union filesystem (such as overlayfs) so the running container sees a merged view, with a thin writable layer on top. Because layers are content-addressed and cached, ordering Dockerfile instructions from least to most frequently changing maximises reuse.
Dockerfile
A Dockerfile is a text file of instructions (FROM, RUN, COPY, ENV, CMD, ENTRYPOINT, and others) that the builder executes to assemble a container image. Each instruction generally creates a new layer, so their order affects cache reuse and final image size. Multi-stage builds let you compile in one stage and copy only the artefacts into a small final stage.
Multi-stage Build
A multi-stage build uses multiple FROM statements in one Dockerfile, copying selected artefacts from earlier build stages into a lean final stage. This keeps build-time tooling (compilers, SDKs) out of the runtime image, shrinking size and attack surface. You reference a prior stage with COPY --from=
OCI (Open Container Initiative)
The OCI is the standards body that defines vendor-neutral specifications for container images, runtimes, and distribution. Its image-spec, runtime-spec, and distribution-spec mean an image built by one tool runs on any compliant runtime and is pushed to any compliant registry. Docker, containerd, Podman, and CRI-O all implement OCI specs.
Container Registry
A registry is a server that stores and distributes container images via the OCI distribution API, addressing artefacts by repository, tag, and digest. Public examples include Docker Hub and GitHub Container Registry; private options include Harbor and cloud-managed registries. Clients push and pull images and may pin to immutable digests for reproducibility.
containerd
containerd is an OCI-compliant container runtime that manages the complete container lifecycle: image transfer and storage, container execution, supervision, and low-level storage and network attachments. It runs as a daemon and is used by both Docker Engine and Kubernetes (via the CRI plugin). It delegates the actual container spawn to a lower-level runtime such as runc.
runc
runc is a lightweight CLI tool that creates and runs containers according to the OCI runtime specification. It is the reference low-level runtime that actually sets up namespaces, cgroups, and the root filesystem before executing the container process. Higher-level runtimes like containerd and CRI-O call runc (or an alternative such as crun) to spawn each container.
Docker Compose
Docker Compose is a tool for defining and running multi-container applications from a single declarative YAML file (compose.yaml). It describes services, networks, and volumes and brings them up together with one command. It targets local development and single-host deployments rather than production clustering.
Volume
A volume is Docker-managed persistent storage that exists independently of a container's writable layer, so data survives container removal. Volumes are the preferred mechanism for persistence over bind mounts because they are managed by Docker, portable, and work on all platforms. They can be shared between containers and backed by drivers for networked or cloud storage.
Bind Mount
A bind mount maps a specific host filesystem path directly into a container. Unlike volumes, the data lives at a host path you control, which is convenient for local development (mounting source code) but couples the container to the host layout. Bind mounts bypass Docker's volume management and can expose host files to the container.
Kubernetes
Kubernetes (K8s) is an open-source platform for automating deployment, scaling, and operations of containerised applications across a cluster of machines. It exposes a declarative API: you submit the desired state of objects and controllers continuously reconcile actual state toward it. It originated at Google and is now governed by the CNCF.
Pod
A Pod is the smallest deployable unit in Kubernetes: one or more containers that share a network namespace (one IP and port space) and can share storage volumes. Containers in a Pod are always co-scheduled on the same node and started together. Pods are usually created and managed by higher-level controllers rather than directly.
Node
A node is a worker machine (virtual or physical) in a Kubernetes cluster on which Pods run. Each node runs a kubelet, a container runtime, and a kube-proxy. The control plane schedules Pods onto nodes based on resource requests and constraints.
Control Plane
The control plane is the set of components that manage the cluster's global state and make scheduling decisions. It comprises the API server, etcd, the scheduler, and the controller managers. It exposes the Kubernetes API and continuously drives the cluster toward the declared desired state.
kube-apiserver
The kube-apiserver is the front end of the Kubernetes control plane and the only component that talks directly to etcd. All reads and writes of cluster state go through its REST API, which handles authentication, authorization, admission control, and validation. Every other component (kubelet, controllers, kubectl) communicates through it.
etcd
etcd is a consistent, distributed key-value store that serves as Kubernetes' backing store for all cluster data. It uses the Raft consensus algorithm to remain consistent across replicas. Losing etcd means losing cluster state, so it must be backed up and run with quorum (an odd number of members).
kube-scheduler
The kube-scheduler watches for newly created Pods that have no assigned node and selects a node for each one. It filters nodes that cannot run the Pod (insufficient resources, failed affinity rules) and then scores the remaining candidates. The decision accounts for resource requests, affinity/anti-affinity, taints and tolerations, and constraints.
kube-controller-manager
The kube-controller-manager runs the core control loops (controllers) that reconcile actual state toward desired state, such as the node, replicaset, and deployment controllers. Each controller watches the API server for changes and takes corrective action. Bundling them in one binary reduces operational complexity.
kubelet
The kubelet is the node agent that ensures the containers described in the Pod specs assigned to its node are running and healthy. It talks to the container runtime via the Container Runtime Interface (CRI), reports node and Pod status to the API server, and runs liveness and readiness probes. It does not manage containers it did not create through Kubernetes.
kube-proxy
kube-proxy is a network agent on each node that implements the Service abstraction by maintaining network rules that route traffic to the right backend Pods. It typically programs iptables or IPVS rules (or hands off to a CNI's eBPF dataplane). It enables stable virtual IPs for Services despite Pods coming and going.
Deployment
A Deployment is a Kubernetes controller that manages a stateless application by maintaining a desired number of identical Pod replicas via a ReplicaSet. It supports declarative rolling updates and rollbacks by creating a new ReplicaSet and shifting Pods gradually. It is the standard way to run stateless workloads.
ReplicaSet
A ReplicaSet ensures that a specified number of identical Pod replicas are running at any time, creating or deleting Pods to match. It is the lower-level controller a Deployment manages; you rarely create one directly. Each Deployment revision corresponds to a distinct ReplicaSet, which is how rollbacks work.
StatefulSet
A StatefulSet manages stateful applications, giving each Pod a stable, unique network identity and stable persistent storage that survives rescheduling. Pods are created, scaled, and deleted in a deterministic order, and each gets its own PersistentVolumeClaim from a volumeClaimTemplate. It suits databases and clustered systems that need stable identity.
DaemonSet
A DaemonSet ensures that a copy of a Pod runs on all (or a selected subset of) nodes, adding the Pod automatically as nodes join the cluster. It is used for node-level agents such as log collectors, monitoring agents, and CNI plugins. Removing the DaemonSet garbage-collects the Pods it created.
Job
A Job creates one or more Pods and ensures that a specified number of them run to successful completion, retrying on failure up to a backoff limit. It is for batch or run-to-completion tasks rather than long-running services. Once the required completions succeed, the Job is finished.
CronJob
A CronJob creates Jobs on a repeating schedule defined with cron syntax, for periodic tasks such as backups or report generation. It manages history limits for successful and failed Jobs and a concurrency policy controlling overlapping runs. Each scheduled tick spawns a new Job object.
Service
A Service is an abstraction that defines a stable network endpoint (a virtual IP and DNS name) for a logical set of Pods selected by labels. It load-balances traffic across the healthy backend Pods, decoupling clients from individual Pod IPs that change over time. Types include ClusterIP, NodePort, LoadBalancer, and ExternalName.
ClusterIP
ClusterIP is the default Service type, exposing the Service on an internal virtual IP reachable only from within the cluster. It provides stable in-cluster DNS and load balancing across the Service's Pods. It is the building block that NodePort and LoadBalancer Services extend for external access.
Ingress
An Ingress is an API object that manages external HTTP and HTTPS access to Services, providing host- and path-based routing, TLS termination, and virtual hosting. It requires an Ingress controller (such as ingress-nginx) to actually fulfil its rules. It consolidates routing that would otherwise need many LoadBalancer Services.
Namespace (Kubernetes)
A Kubernetes Namespace is a virtual cluster that partitions resources within a single physical cluster, scoping names and enabling per-team isolation and quotas. Object names must be unique within a namespace but can repeat across namespaces. ResourceQuotas, RBAC, and NetworkPolicies are commonly applied per namespace.
Linux Namespace
A Linux namespace is a kernel feature that gives a process an isolated view of a global system resource, such as process IDs (pid), network stack (net), mounts (mnt), and hostname (uts). Containers combine several namespaces so each sees its own private slice of the system. They are the primary isolation primitive underlying containers.
cgroups
Control groups (cgroups) are a Linux kernel feature that limits, accounts for, and isolates the resource usage (CPU, memory, I/O) of a group of processes. Containers use cgroups to enforce CPU and memory limits so one container cannot starve others. Kubernetes resource requests and limits ultimately map onto cgroup settings.
ConfigMap
A ConfigMap is a Kubernetes object that stores non-confidential configuration as key-value pairs, decoupling configuration from image content. It can be consumed as environment variables, command-line arguments, or files mounted into a Pod. It is not encrypted and must not hold secrets.
Secret
A Secret is a Kubernetes object for storing small amounts of sensitive data such as passwords, tokens, and keys. By default Secrets are stored base64-encoded (not encrypted) in etcd unless encryption at rest is enabled. They can be mounted as files or exposed as environment variables, and access should be restricted with RBAC.
PersistentVolume
A PersistentVolume (PV) is a piece of cluster storage provisioned by an administrator or dynamically by a StorageClass, with a lifecycle independent of any Pod. It abstracts the underlying storage (cloud disk, NFS, CSI driver) behind a uniform API. Pods consume PVs by binding to them through PersistentVolumeClaims.
PersistentVolumeClaim
A PersistentVolumeClaim (PVC) is a user's request for storage of a given size and access mode, which Kubernetes binds to a matching PersistentVolume. It lets workloads request storage without knowing the underlying provider details. With a StorageClass it can trigger dynamic provisioning of a new PV.
StorageClass
A StorageClass describes a class of storage (its provisioner, parameters, and reclaim policy) and enables dynamic provisioning of PersistentVolumes on demand. When a PVC references a StorageClass, the cluster creates a suitably backed volume automatically. Clusters typically define a default StorageClass for claims that omit one.
Label and Selector
A label is a key-value pair attached to a Kubernetes object for identifying and grouping it; a selector queries objects by their labels. Services, Deployments, and NetworkPolicies use selectors to target the right Pods loosely, without hardcoding identities. Labels are the central mechanism for connecting objects in Kubernetes.
Liveness Probe
A liveness probe is a periodic check the kubelet runs to determine whether a container is still healthy; failing it causes the container to be restarted. It detects deadlocks or hung states where the process is running but not making progress. Probes can be HTTP, TCP, or exec-based with configurable timing.
Readiness Probe
A readiness probe determines whether a container is ready to receive traffic; while it fails, the Pod is removed from Service endpoints but not restarted. It prevents routing requests to a Pod that is still starting, warming caches, or temporarily overloaded. It is distinct from the liveness probe, which governs restarts.
Resource Requests and Limits
A request is the amount of CPU or memory the scheduler reserves for a container, while a limit is the maximum it may use. Requests drive scheduling and define a Pod's Quality of Service class; exceeding a memory limit causes an OOM kill, and exceeding a CPU limit causes throttling. Setting both prevents noisy-neighbour problems.
Horizontal Pod Autoscaler
The Horizontal Pod Autoscaler (HPA) automatically adjusts the number of Pod replicas in a workload based on observed metrics such as CPU utilisation or custom metrics. It queries the metrics API and scales the replica count up or down within configured bounds. It complements, and is distinct from, vertical scaling and cluster autoscaling.
Helm
Helm is a package manager for Kubernetes that bundles related manifests into versioned, parameterisable units called charts. Templating with values files lets one chart be reused across environments, and releases can be upgraded or rolled back. It simplifies installing and managing complex applications.
CNI (Container Network Interface)
The CNI is a specification and set of plugins that configure network interfaces for Linux containers, used by Kubernetes to provide Pod networking. A CNI plugin (Calico, Cilium, Flannel, and others) assigns Pod IPs and implements the cluster's flat network model so every Pod can reach every other Pod. Kubernetes itself does not implement Pod networking; it delegates to CNI.
NetworkPolicy
A NetworkPolicy specifies how groups of Pods are allowed to communicate, acting as a firewall at the Pod level using label selectors for ingress and egress rules. By default Pods accept traffic from anywhere; once a Pod is selected by a policy, only the allowed traffic is permitted. It requires a CNI plugin that supports NetworkPolicy enforcement.
RBAC (Role-Based Access Control)
RBAC in Kubernetes governs who can perform which actions on which resources via Roles/ClusterRoles (permission sets) bound to subjects with RoleBindings/ClusterRoleBindings. It follows least privilege and is namespaced (Role) or cluster-wide (ClusterRole). It is the primary authorization mechanism for the Kubernetes API.
Taint and Toleration
A taint is applied to a node to repel Pods that do not tolerate it, and a toleration on a Pod allows (but does not require) it to schedule onto a tainted node. Together they let you reserve nodes for specific workloads, such as GPU nodes or control-plane nodes. They work alongside, not instead of, affinity rules.
Operator
An Operator is a pattern that extends Kubernetes with a custom controller plus Custom Resource Definitions to automate the operation of a specific application (for example provisioning, backup, and failover of a database). It encodes human operational knowledge into software that reconciles a custom resource. Operators are how stateful and complex applications are managed declaratively.