KLCP key terms

The smallest deployable unit in Kubernetes, representing one or more containers that share a network namespace, IP address, and storage volumes and are scheduled together on a single node.

A physical or virtual machine in a cluster that runs Pods, managed by the control plane and hosting a kubelet plus a container runtime.

The set of cluster components that make global decisions, such as scheduling and responding to events, including the API server, scheduler, controller manager, and datastore.

The front-end component of the control plane that exposes the Kubernetes HTTP API, validating and processing all requests and persisting state to the backing datastore.

A distributed key-value store used as Kubernetes' backing store for all cluster data, holding the desired and observed state of every object.

The control plane component that assigns newly created Pods to Nodes by evaluating resource requests, constraints, affinities, and taints against available capacity.

The node agent that ensures containers described in PodSpecs are running and healthy, communicating with the API server and the local container runtime.

The software on each node that pulls images and actually starts, stops, and manages container processes, invoked by the kubelet through a standard interface.

The command-line client used to run commands against a Kubernetes cluster's API server, creating, inspecting, and modifying resources declaratively or imperatively.

A virtual partition within a cluster that scopes names and resource quotas, letting multiple teams or environments share one cluster with logical isolation.

An immutable, layered filesystem bundle plus metadata that packages an application and its dependencies so a container runtime can instantiate it reproducibly.

A remote repository service that stores and distributes container images by name and tag, from which nodes pull images when starting containers.

An API object holding non-confidential configuration data as key-value pairs that Pods can consume as environment variables or mounted files, decoupling config from images.

An API object for storing sensitive data such as passwords or tokens, which Pods mount or inject while access is restricted via RBAC and optional encryption at rest.

A higher-level controller that manages ReplicaSets to provide declarative rolling updates and rollbacks for stateless Pods, ensuring a desired replica count is running.

A controller that maintains a stable set of identical running Pods, creating or deleting replicas to match a declared count and typically managed by a Deployment.

A workload controller for stateful applications that provides stable Pod identities, ordered deployment and scaling, and persistent storage bound to each replica.

A controller that ensures a copy of a Pod runs on every eligible node, commonly used for log shippers, monitoring agents, or node-level networking components.

A controller that runs Pods until a specified number complete successfully, suited to batch or one-off tasks rather than long-running services.

A controller that creates Jobs on a recurring schedule expressed in cron syntax, useful for periodic batch processing or maintenance tasks.

An abstraction that exposes a stable virtual IP and DNS name for a set of Pods selected by labels, load-balancing traffic across healthy endpoints.

An API object defining HTTP and HTTPS routing rules from outside the cluster to internal Services, typically implemented by an Ingress controller.

A running component that watches Ingress resources and configures an actual proxy or load balancer to route external traffic according to those rules.

A set of role-oriented, extensible Kubernetes API resources for modeling inbound and service-to-service traffic routing, positioned as a successor to Ingress.

A query expression matching objects by their key-value labels, used by controllers and Services to determine which resources they manage or route traffic to.

A periodic health check that tells the kubelet whether a container is still functioning; repeated failures cause the container to be restarted.

A health check indicating whether a container is ready to receive traffic; failing Pods are removed from Service endpoints without being restarted.

Per-container declarations of the CPU and memory a container is guaranteed (requests) and the maximum it may consume (limits), guiding scheduling and enforcement.

A controller that automatically adjusts the number of Pod replicas for a workload based on observed metrics such as CPU utilization or custom signals.

A cluster-level storage resource representing a piece of provisioned storage with a lifecycle independent of any Pod that uses it.

A namespaced request for storage with a size and access mode that binds to a matching PersistentVolume, letting Pods use durable storage without knowing its details.

An API object describing a class of storage and its provisioner, enabling dynamic creation of PersistentVolumes when claims are made.

A directory made available to containers in a Pod, backed by storage that can outlive individual container restarts and be shared among containers in the Pod.

A mechanism where a node marks itself to repel Pods (taint) unless those Pods declare matching tolerations, controlling which workloads may schedule there.

Scheduling rules attached to a Pod that constrain which nodes it may run on based on node labels, either as required or preferred conditions.

An authorization system where Roles and ClusterRoles define permitted actions on resources, and bindings grant those permissions to users, groups, or service accounts.

An identity for processes running in Pods, used to authenticate to the API server and to receive permissions through role bindings.

A deployment strategy that gradually replaces old Pods with new ones while maintaining availability, allowing progress to be paused or rolled back.

An approach where you submit the desired state of resources as manifests and controllers continuously reconcile actual state toward it, rather than issuing step-by-step commands.

An operating model where the desired cluster and application state lives in a Git repository, and an automated agent continuously reconciles the cluster to match it.

A practice where every validated change is automatically built and made deployable to production, with releases gated by automated tests and approval rather than manual assembly.

A package manager for Kubernetes that templates and versions groups of manifests as charts, simplifying installation and upgrades of complex applications.

An API extension that registers a new resource type in the cluster, letting operators and controllers manage custom objects alongside built-in Kubernetes resources.

A controller pattern that encodes operational knowledge for an application in software, watching custom resources and automating tasks like deployment, scaling, backups, and recovery.

A helper container running alongside the main application container in the same Pod, sharing its network and storage to add capabilities such as proxying, logging, or metrics.

An infrastructure layer that manages service-to-service communication using proxies, providing traffic routing, retries, mutual TLS, and observability without changing application code.

A set of principles for building portable cloud-native applications, emphasizing configuration in the environment, stateless processes, disposability, and clear dependency declarations.