CKA (CNCF) key terms

The central Kubernetes API endpoint that receives REST requests, validates them, and updates cluster state in etcd. Clients and internal components communicate through it.

A distributed key-value store that holds Kubernetes cluster state and configuration data. The API server reads and writes objects there, making backups and quorum health important.

A control-plane component that assigns newly created Pods to nodes. It filters and scores nodes using resource requests, constraints, affinity rules, taints, and other scheduling policies.

A control-plane process running built-in controllers that reconcile desired state with observed state, such as creating ReplicaSets, handling node lifecycle, and managing service accounts.

An agent running on each node that watches assigned Pods, starts and monitors their containers, reports node and Pod status, and interacts with the container runtime.

A node component that maintains network rules for Service traffic, enabling Pods to reach Service IPs and load-balanced backends. It may use iptables, IPVS, or nftables modes.

A Pod defined by a manifest file on a node and managed directly by the kubelet, not by the API server's scheduler. Control-plane components are often run this way.

A tool for bootstrapping Kubernetes clusters, handling control-plane initialization, joining nodes, certificate setup, and upgrades. It produces a cluster that still needs a CNI plugin.

An RBAC object that grants a Role or ClusterRole to users, groups, or ServiceAccounts within a specific Namespace. It connects permissions to identities.

An RBAC object defining permissions that can apply cluster-wide or be bound within Namespaces. It is commonly referenced by RoleBinding objects and cluster-wide bindings.

An identity for processes running in Pods, used by the API server to authenticate workloads. Tokens or projected credentials let Pods call the Kubernetes API with RBAC permissions.

A logical partition within a cluster that scopes names for many objects and supports access control and resource quotas. Some objects are cluster-scoped instead.

A workload controller that manages ReplicaSets to provide declarative rolling updates, scaling, and rollback for stateless Pods. It ensures a desired number of replicas is available.

A controller that maintains a stable number of identical Pod replicas. Deployments create and manage ReplicaSets to perform rolling updates and revisions.

A workload controller for Pods that need stable identity, ordered deployment, and persistent storage per replica. It uses stable network names and PersistentVolumeClaim templates.

A controller that runs one Pod copy on selected nodes, often for logging, monitoring, or networking agents. It adds Pods as nodes join and removes them as nodes leave.

A workload controller that runs Pods until a specified number of successful completions, then stops. It is suited to batch tasks rather than long-running services.

A controller that creates Jobs on a time-based schedule using cron syntax. It handles recurring batch work and retains history according to configured limits.

The smallest deployable Kubernetes unit, containing one or more containers that share networking and storage. Controllers usually create and manage Pods rather than users directly.

A simple scheduling constraint that makes a Pod run only on nodes whose labels match specified key-value pairs. It is evaluated by the scheduler before other scoring.

A taint marks a node to repel Pods unless they declare a matching toleration. Taints allow dedicated nodes or eviction of unsuitable workloads when combined with scheduling behavior.

An object holding non-sensitive configuration data as key-value pairs or files. Pods consume it through environment variables or mounted volumes, decoupling settings from container images.

An object for storing sensitive data such as passwords, tokens, or certificates. Kubernetes can expose it to Pods as environment variables or mounted files, with optional base64 encoding.

Software implementing the Container Network Interface to provide Pod networking, IP allocation, and often network policy enforcement. A cluster needs one for Pods to communicate across nodes.

A stable virtual IP and DNS name that load-balances traffic to selected Pods. ClusterIP, NodePort, and LoadBalancer types expose workloads internally or externally.

An API object defining HTTP and HTTPS routing from outside the cluster to Services, usually implemented by an Ingress controller. It supports host and path rules plus TLS.

A Kubernetes object that selects Pods and specifies allowed ingress or egress traffic. Enforcement depends on the CNI plugin supporting policy, and default behavior is allow.

The default cluster DNS server that resolves Service names and other records for Pods. It runs as a Deployment and uses ConfigMaps for configuration.

An object containing subsets of network endpoints for a Service, including Pod IPs and ports. kube-proxy and other components use it to route traffic to ready backends.

A cluster-scoped storage resource representing provisioned storage with capacity, access modes, and a reclaim policy. It can be statically created or dynamically provisioned.

A Namespace-scoped request for storage that binds to a matching PersistentVolume or triggers dynamic provisioning. Pods mount the claim to access persistent data.

A cluster-scoped object describing how to provision storage dynamically, including the provisioner, parameters, and reclaim policy. Claims reference it to request volumes.

A plugin implementing the Container Storage Interface so Kubernetes can provision, attach, mount, and snapshot storage from a storage system. It is often deployed via a DaemonSet and controller.

A Pod-scoped temporary volume created when a Pod is assigned to a node. Containers in the Pod can share its files, and its data is deleted when the Pod is removed.

A kubectl command that shows detailed state, configuration, and recent events for an object. It is often the first step when a Pod, node, or Service behaves unexpectedly.

A kubectl command that prints container output from a Pod, optionally for a specific container or previous crashed instance. It helps diagnose application startup and runtime failures.

Timestamped records emitted by Kubernetes components about object changes, scheduling decisions, and errors. They are visible through kubectl describe or kubectl get events and help locate failures.

A Pod status indicating a container repeatedly starts and exits, so kubelet waits before restarting it again. Logs and previous-container output usually reveal the underlying application error.

A check that tells Kubernetes whether a container is ready to receive traffic. Failing Pods are removed from Service endpoints until the probe succeeds again.

A check that tells kubelet whether a running container is still healthy. Repeated failures cause kubelet to restart the container, which can recover stuck processes.