---
title: "Kubernetes Advanced"
description: "Advanced Kubernetes terms covering scheduling, networking, storage, security, extensibility, and workloads for platform engineers."
author: "Mohammad Abu Mattar"
canonical: https://mkabumattar.com/glossary/post/kubernetes-advanced
---

# Kubernetes Advanced

This glossary covers the advanced Kubernetes terminology platform engineers rely on, from scheduling and networking to storage, security, extensibility, and the workload controllers that keep applications running at scale.

## Terms

### Scheduler (kube-scheduler) (Scheduling)

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.

### Taint (Scheduling)

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.

```
# Taint a node so only tolerant pods land on it
kubectl taint nodes node1 gpu=true:NoSchedule

```

### Toleration (Scheduling)

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.

### Node Affinity (Scheduling)

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.

**Example:** Require pods to run only on nodes labeled topology.kubernetes.io/zone=us-east-1a.

### Pod Affinity and Anti-Affinity (Scheduling)

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.

### Topology Spread Constraints (Scheduling)

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.

### Priority Class (Scheduling)

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.

### Preemption (Scheduling)

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.

### CNI (Container Network Interface) (Networking)

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.

### NetworkPolicy (Networking)

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.

**Example:** Allow ingress to the database pods only from the API pods and nothing else.

### kube-proxy (Networking)

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.

### Ingress Controller (Networking)

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.

### Service Mesh (Networking)

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.

### CoreDNS (Networking)

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.

### PersistentVolume (PV) (Storage)

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.

### PersistentVolumeClaim (PVC) (Storage)

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.

### StorageClass (Storage)

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.

```
# A claim that dynamically provisions a fast SSD volume
spec:
  storageClassName: fast-ssd
  accessModes: ['ReadWriteOnce']
  resources:
    requests:
      storage: 20Gi

```

### CSI (Container Storage Interface) (Storage)

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.

### Dynamic Provisioning (Storage)

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.

### Access Mode (Storage)

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.

### RBAC (Role-Based Access Control) (Security)

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

```
# Check whether a service account may list pods
kubectl auth can-i list pods --as=system:serviceaccount:dev:app

```

### Role and ClusterRole (Security)

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.

### Service Account (Security)

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.

### Admission Controller (Security)

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.

### Pod Security Standards (Security)

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.

### Webhook (Admission Webhook) (Security)

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.

### CRD (Custom Resource Definition) (Extensibility)

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.

**Example:** Define a Certificate resource so cert-manager can manage TLS certificates as first-class objects.

### Operator (Extensibility)

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.

### Custom Controller (Extensibility)

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.

### Reconciliation Loop (Extensibility)

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.

### Finalizer (Extensibility)

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.

### Informer (Extensibility)

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.

### StatefulSet (Workloads)

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.

**Example:** Run a three-node database where each replica keeps its own volume and a fixed hostname.

### DaemonSet (Workloads)

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.

### HPA (Horizontal Pod Autoscaler) (Workloads)

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.

```
# Autoscale a deployment between 2 and 10 pods at 70% CPU
kubectl autoscale deployment web --min=2 --max=10 --cpu-percent=70

```

### VPA (Vertical Pod Autoscaler) (Workloads)

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.

### PodDisruptionBudget (PDB) (Workloads)

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.

### Init Container (Workloads)

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.

### Sidecar Container (Workloads)

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.