KCNA key terms

The smallest deployable unit in Kubernetes, representing one or more containers that share a network namespace, storage volumes, and a lifecycle; containers in a pod are always scheduled together on the same node.

A physical or virtual machine in a Kubernetes cluster that runs containerized workloads; each node hosts the kubelet and a container runtime and is managed by the control plane.

The set of components that manage a Kubernetes cluster's overall state, including the API server, etcd, scheduler, and controller manager, which accept requests, store data, and make scheduling decisions.

The front-end component of the Kubernetes control plane that exposes the REST API; all clients and internal components read and write cluster state through it, and it validates every request.

A distributed, consistent key-value store that holds all Kubernetes cluster state and configuration; it is the source of truth that the API server reads from and writes to.

An agent running on each Kubernetes node that watches for pod assignments and ensures the described containers are running and healthy by talking to the container runtime.

The control-plane component that watches for newly created pods with no assigned node and selects a suitable node based on resource requirements, constraints, affinity rules, and policies.

A Kubernetes workload resource that manages ReplicaSets to run stateless pods, supporting declarative updates, scaling, and controlled rollouts with revision history for easy rollback.

A Kubernetes controller that keeps a specified number of identical pod replicas running at all times, replacing pods that fail or are deleted; Deployments typically manage them on your behalf.

A stable network abstraction in Kubernetes that gives a group of pods a single DNS name and virtual IP, load-balancing traffic to them even as individual pods are replaced.

A logical partition inside a Kubernetes cluster that groups and isolates resources and names, commonly used to separate environments, teams, or projects and to scope quotas and access.

A Kubernetes object used to store non-sensitive configuration data as key-value pairs, which can be injected into pods as environment variables or mounted files without rebuilding images.

A Kubernetes object for holding small amounts of sensitive data such as passwords, tokens, or certificates, kept separate from images and mounted or exposed to containers at runtime.

A query made of key-value pairs that identifies a set of Kubernetes objects; controllers and Services use selectors to find the pods they should manage or send traffic to.

A request by a pod for storage of a given size and access mode; Kubernetes binds it to a matching PersistentVolume so data survives pod restarts and rescheduling.

A lightweight, isolated runtime environment that packages an application with its libraries and dependencies, sharing the host operating system kernel while appearing as its own machine.

A read-only, layered template containing an application's filesystem, dependencies, and startup command; containers are launched as running instances of such images.

Software such as containerd or CRI-O that pulls images, creates and starts containers, and manages their lifecycle on a node, usually through the Kubernetes Container Runtime Interface.

The Open Container Initiative, a standards body that publishes specifications for container image formats and runtimes, enabling images built by one tool to run on any compliant runtime.

A set of machines, called nodes, managed together by a Kubernetes control plane so workloads can be scheduled, replicated, and healed as a single logical system.

The control-loop principle where controllers continuously compare the declared desired state of resources with the observed actual state and act to close the gap between them.

A Kubernetes controller that automatically adjusts the number of pod replicas in a workload based on observed metrics such as CPU utilization or custom metrics.

A Kubernetes API object that defines HTTP and HTTPS routing rules from outside the cluster to internal Services, usually implemented by an ingress controller acting as a reverse proxy.

A deployment strategy that replaces pods gradually with a new version, keeping a portion of old replicas available so the application stays up throughout the change.

A Kubernetes workload controller for applications that need stable, unique network identities and persistent storage per replica, such as databases, with ordered deployment and scaling.

Continuous integration automatically builds and tests code changes; continuous delivery or deployment then packages and releases them, shortening feedback loops and making releases small and repeatable.

A package manager for Kubernetes that bundles related manifests into charts with templates and configurable values, simplifying installation, upgrades, and release management.

An operating model where the desired state of infrastructure and applications is stored in Git, and automated agents continuously sync clusters to match that committed state.

A delivery technique that sends a small slice of traffic to a new version while most users stay on the old one, then gradually widens exposure if metrics stay healthy.

A release strategy that runs two identical environments, switching all traffic from the current blue version to the new green version and allowing instant rollback by switching back.

A dedicated infrastructure layer that handles service-to-service communication, providing traffic routing, mutual TLS, retries, and telemetry through sidecar or node-level proxies.

An architectural style that structures an application as small, independently deployable services, each owning a business capability and communicating through well-defined APIs or messages.

A set of twelve practices for building portable, maintainable cloud-native applications, covering configuration, dependencies, stateless processes, logging, and disposability.

The Cloud Native Computing Foundation, a vendor-neutral organization that hosts open-source projects such as Kubernetes and Prometheus and runs certification programs including the KCNA.

A model where the platform manages provisioning and scaling entirely, running code in response to events and charging only for resources consumed during execution.

An approach where users describe the end state they want, typically in YAML or JSON manifests, and the system works out and continuously maintains the steps to achieve it.

A design where a helper container runs alongside the main application container in the same pod, adding capabilities such as logging, proxying, or configuration sync without changing the app.

The ability to understand a system's internal state from its outputs, typically achieved by combining metrics, logs, and traces to diagnose issues and understand behavior.

A practice where servers and containers are never patched in place; instead new versions replace old ones, reducing configuration drift and making deployments reproducible.