Kubernetes Advanced

A way to teach the Kubernetes API a new object type without recompiling anything. Once registered, your custom resource is managed with kubectl just like a built-in one.

An application-specific controller that encodes human operational knowledge to manage a complex workload, such as a database. It pairs one or more CRDs with a controller that acts on them.

A control loop that watches resources and works to drive the actual state toward the desired state. Every operator is built around one or more custom controllers.

The continuous cycle a controller runs to compare desired state against observed state and take corrective action. It is the core pattern that makes Kubernetes self-healing.

A key on a resource that blocks deletion until a controller performs cleanup, such as releasing external resources. The object stays in a terminating state until the finalizer is removed.

A client-side cache and event mechanism that controllers use to watch resources efficiently. It avoids hammering the API server by caching objects and delivering change events.

The plugin standard Kubernetes uses to wire pods into the cluster network. Plugins like Calico, Cilium, and Flannel implement CNI to assign pod IPs and enforce connectivity.

A resource that controls which pods can talk to which, acting as a firewall at the pod level. By default all traffic is allowed; a policy switches the selected pods to deny-by-default for the directions it covers.

The node agent that programs the network rules making Service virtual IPs work. It uses iptables or IPVS to load-balance traffic across the pods behind a Service.

A pod that watches Ingress resources and configures a reverse proxy such as NGINX or Envoy to route external HTTP traffic to Services. The Ingress object is just rules; the controller does the work.

An infrastructure layer, often built on sidecar proxies, that handles service-to-service traffic with features like mutual TLS, retries, and fine-grained observability. Istio and Linkerd are common examples.

The in-cluster DNS server that resolves Service and pod names to their cluster IPs. It is what lets a pod reach another service by name instead of a hardcoded address.

The control-plane component that watches for unscheduled pods and picks a node for each one based on resource requests, constraints, and priorities. It only decides placement; the kubelet on the chosen node actually runs the pod.

A mark placed on a node that repels pods unless they explicitly tolerate it. Taints let you reserve nodes for specific workloads, such as GPU jobs or system components.

A pod-level setting that allows the pod to be scheduled onto nodes carrying a matching taint. A toleration permits placement but does not force it.

Rules that attract pods to nodes with matching labels, either as a hard requirement or a soft preference. It is the modern, expressive replacement for the older nodeSelector field.

Rules that place pods near or away from other pods based on labels. Anti-affinity is commonly used to spread replicas across nodes so one node failure does not take down the whole service.

A policy that evenly distributes pods across failure domains like zones or nodes to limit the blast radius of any single failure. It controls how skewed the spread is allowed to become.

A named priority value assigned to pods so the scheduler knows which pods matter most. Higher-priority pods can preempt lower-priority ones when the cluster is short on resources.

The act of evicting lower-priority pods to make room for a pending higher-priority pod that cannot otherwise be scheduled. It keeps critical workloads running under contention.

The authorization system that grants permissions through Roles and RoleBindings. It decides which users and service accounts can perform which actions on which resources.

Objects that define a set of allowed actions on resources. A Role is scoped to a single namespace, while a ClusterRole applies cluster-wide or to non-namespaced resources.

An identity used by pods to authenticate to the Kubernetes API and other services. Each pod runs under a service account whose permissions are set through RBAC.

A plugin that intercepts requests to the API server after authentication but before persistence, and can validate or mutate them. It is how policies like resource limits or image rules are enforced.

A set of predefined security profiles, Privileged, Baseline, and Restricted, that constrain what pods may do. They replace the deprecated PodSecurityPolicy and are enforced per namespace.

An external HTTP callback the API server invokes to validate or mutate resources dynamically. Validating webhooks accept or reject objects; mutating webhooks can change them before they are stored.

A cluster-level piece of storage provisioned by an administrator or dynamically by a StorageClass. It exists independently of any pod, so data survives pod restarts.

A request for storage made by a pod, specifying size and access mode. Kubernetes binds the claim to a matching PersistentVolume, decoupling apps from the underlying storage details.

A template that describes a type of storage and how to provision it on demand. Referencing a StorageClass in a claim triggers dynamic provisioning instead of pre-creating volumes by hand.

The standard plugin interface that lets storage vendors expose their systems to Kubernetes without changing core code. It is the storage equivalent of what CNI does for networking.

The automatic creation of a PersistentVolume when a claim asks for a StorageClass, so no volume has to be pre-created. It turns storage into an on-demand resource.

A property that defines how a volume can be mounted, such as ReadWriteOnce for one node, ReadOnlyMany, or ReadWriteMany across many nodes. Not every storage backend supports every mode.

A workload controller for stateful apps that gives each pod a stable identity and its own persistent storage. Pods are created and scaled in a predictable, ordered sequence.

A controller that ensures a copy of a pod runs on every node, or on a selected subset. It is the standard way to deploy node-level agents like log collectors and monitoring daemons.

A controller that adds or removes pod replicas based on observed metrics like CPU, memory, or custom values. It scales out under load and back in when demand drops.

A controller that recommends or automatically sets the CPU and memory requests of pods based on real usage. It right-sizes pods rather than changing their count.

A policy that limits how many pods of an application can be down at once during voluntary disruptions like node drains. It protects availability while allowing routine maintenance.

A container that runs to completion before the app containers in a pod start. It handles setup work such as waiting for a dependency or fetching configuration.

A helper container that runs alongside the main app container in the same pod, sharing its network and storage. Common uses include proxies, log shippers, and secret refreshers.