K8s
K8s is the conventional numeronym for Kubernetes: "K", then eight letters, then "s". It is pronounced "kates" and is used pervasively in tooling, namespaces, and documentation. It refers to the same project as the full word Kubernetes.
OCI
OCI stands for Open Container Initiative, the Linux Foundation project that standardises container formats. It publishes three specifications: image-spec (image layout), runtime-spec (how to run a container bundle), and distribution-spec (the registry push/pull API). Compliance with OCI is what makes images portable across tools.
CRI
CRI stands for Container Runtime Interface, the gRPC API the kubelet uses to talk to a container runtime. It decoupled Kubernetes from Docker specifically, allowing any compliant runtime (containerd, CRI-O) to be plugged in. The removal of the in-tree "dockershim" in Kubernetes 1.24 made CRI the only supported integration path.
CNI
CNI stands for Container Network Interface, the specification governing how networking is configured for containers. Kubernetes uses a CNI plugin to assign each Pod an IP and to wire up the cluster network. Common implementations include Calico, Cilium, and Flannel.
CSI
CSI stands for Container Storage Interface, the standard API for exposing block and file storage systems to container orchestrators. A CSI driver lets Kubernetes provision, attach, mount, and snapshot volumes from any compliant storage backend without in-tree code. It replaced the older in-tree volume plugins.
CRD
CRD stands for Custom Resource Definition, the mechanism for adding your own resource types to the Kubernetes API. Once registered, custom resources are managed with kubectl like built-in objects and are typically reconciled by a custom controller. CRDs are the foundation of the Operator pattern.
CR
CR stands for Custom Resource, an instance of a type defined by a CRD. It extends the Kubernetes API with domain-specific objects (for example a Database or a Certificate). A controller watches CRs and reconciles real-world state to match them.
RBAC
RBAC stands for Role-Based Access Control, Kubernetes' primary authorization model. Roles and ClusterRoles enumerate allowed verbs on resources, and bindings grant those roles to users, groups, or service accounts. It enforces least privilege on the API server.
HPA
HPA stands for Horizontal Pod Autoscaler, the controller that scales a workload's replica count based on metrics. It reads CPU, memory, or custom/external metrics and adjusts replicas within min/max bounds. It scales out (more Pods) rather than up (bigger Pods).
VPA
VPA stands for Vertical Pod Autoscaler, which recommends or sets CPU and memory requests and limits for containers based on usage. Unlike the HPA it changes the size of Pods, not their count, and applying changes usually requires recreating the Pod. The two autoscalers are generally not used on the same resource for the same metric.
CA
In a Kubernetes scaling context, CA stands for Cluster Autoscaler, which adds or removes nodes when Pods cannot be scheduled or nodes are underused. It complements the HPA: the HPA changes Pod count and the CA changes node count to fit them. (In a TLS context the same acronym means Certificate Authority.)
QoS
QoS stands for Quality of Service, the class Kubernetes assigns each Pod based on its resource requests and limits: Guaranteed, Burstable, or BestEffort. The class influences eviction order under node pressure, with BestEffort evicted first and Guaranteed last. Setting requests equal to limits yields the Guaranteed class.
OOM / OOMKilled
OOM stands for Out Of Memory; OOMKilled is the status shown when the Linux kernel terminates a container for exceeding its memory limit. It indicates the workload needs a higher memory limit or has a leak, not a transient error. Repeated OOMKills appear in Pod restart counts and events.
PV
PV stands for PersistentVolume, a cluster-level storage resource with a lifecycle independent of any Pod. It is provisioned statically by an admin or dynamically by a StorageClass. Pods consume it through a PersistentVolumeClaim.
PVC
PVC stands for PersistentVolumeClaim, a request for storage that binds to a PersistentVolume. It abstracts the storage backend from the workload, requesting only a size and access mode. With a StorageClass it triggers dynamic provisioning.
DNS (in-cluster)
In Kubernetes, in-cluster DNS (commonly CoreDNS) resolves Service and Pod names to their virtual IPs. A Service named "web" in namespace "shop" is reachable at "web.shop.svc.cluster.local". This stable naming lets workloads find each other without hardcoding IPs.
ETCD quorum
Quorum is the majority of etcd members that must agree to commit a write under the Raft consensus protocol. A cluster of N members tolerates the loss of (N-1)/2 members, which is why an odd member count (3 or 5) is recommended. Losing quorum makes the cluster read-only and unable to schedule changes.
ENTRYPOINT vs CMD
In a Dockerfile, ENTRYPOINT defines the executable that always runs, while CMD provides default arguments (or a default command) that are easy to override at run time. Combined, ENTRYPOINT sets the binary and CMD supplies overridable defaults. Using exec form (JSON array) avoids an extra shell and ensures signals reach the process.
ARG vs ENV
In a Dockerfile, ARG defines a build-time variable available only during the build, while ENV sets an environment variable persisted into the image and visible at run time. ARG values do not appear in the running container unless copied into an ENV. Secrets should use neither; use BuildKit secret mounts instead.
BuildKit
BuildKit is Docker's modern build engine, enabling parallel layer builds, efficient caching, build secrets, and SSH forwarding. It is the default builder in current Docker and is also exposed through the buildx plugin for multi-platform images. It improves both build speed and security over the legacy builder.
buildx
buildx is the Docker CLI plugin that drives BuildKit and adds multi-platform builds, multiple builder instances, and advanced cache export/import. It lets you build, for example, linux/amd64 and linux/arm64 images from one command. It is the standard tool for producing cross-architecture images.
Sidecar
A sidecar is a helper container that runs in the same Pod as the main application container to extend or augment it, sharing its network and volumes. Typical uses are log shippers, proxies, and config reloaders. Kubernetes 1.29+ supports native sidecar containers as a special kind of init container that stays running.
Init Container
An init container runs to completion before the app containers in a Pod start, in declared order. It is used for setup tasks such as waiting for a dependency, running migrations, or fetching configuration. App containers start only after all init containers succeed.
kubectl
kubectl is the command-line client for the Kubernetes API server, used to create, inspect, update, and delete cluster resources. It reads cluster connection details from a kubeconfig file and supports imperative commands and declarative apply. It is the primary human interface to a cluster.
kubeconfig
A kubeconfig is a YAML file that stores clusters, users (credentials), and contexts that bind a user to a cluster and namespace. kubectl and client libraries read it (by default from ~/.kube/config) to know which cluster to talk to and how to authenticate. Multiple contexts let one file manage several clusters.
GitOps
GitOps is an operating model in which the desired state of a cluster is declared in a Git repository and an in-cluster agent (such as Argo CD or Flux) continuously reconciles the live state to match. Git becomes the single source of truth and the audit log for changes. Rollbacks are a Git revert.
DaemonSet vs Deployment
A Deployment runs a chosen number of replicas placed anywhere the scheduler fits them, while a DaemonSet runs exactly one Pod per matching node. Deployments suit scalable stateless services; DaemonSets suit per-node agents like log and metrics collectors. They are different controllers for different placement intents.
Rolling Update
A rolling update replaces Pods of an old version with the new version gradually, governed by maxSurge (extra Pods allowed) and maxUnavailable (Pods that may be down). It enables zero-downtime deploys when paired with readiness probes. The alternative Recreate strategy stops all old Pods before starting new ones.
Namespace (Linux vs K8s)
The term namespace is overloaded: a Linux namespace is a kernel isolation primitive (pid, net, mnt, and others) used to build containers, while a Kubernetes Namespace is a logical partition of API objects within a cluster. They operate at completely different layers. Context determines which is meant.