---
title: "Containers & Kubernetes"
description: "Essential terms every DevOps engineer should know about containers and Kubernetes."
author: "Mohammad Abu Mattar"
canonical: https://mkabumattar.com/glossary/post/containers-and-kubernetes
---

# Containers & Kubernetes

This glossary covers essential terms for working with containers and Kubernetes, from building Docker images to managing workloads, networking, storage, scaling, and security in a Kubernetes cluster.

## Terms

### Container (Containers)

A lightweight, standalone, executable package that includes everything needed to run a piece of software   code, runtime, libraries, and settings   isolated from the host system.

**Example:** Running an Nginx web server inside a Docker container without installing Nginx on the host.

```
docker run -d -p 80:80 nginx
```

### Docker (Containers)

An open platform for building, shipping, and running applications inside containers, providing tooling to create images, manage containers, and interact with registries.

**Example:** Building a custom Node.js application image using a Dockerfile.

```
docker build -t myapp:latest .
```

### Dockerfile (Containers)

A text file containing ordered instructions that Docker follows to automatically build a container image, layer by layer.

**Example:** A Dockerfile that sets up a Python Flask application with all its dependencies.

```
```dockerfile
FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "app.py"]
```
```

### Docker Image (Containers)

A read-only, layered template used to create containers. Built from a Dockerfile and stored in a registry. Each layer represents a set of filesystem changes.

**Example:** Pulling the official PostgreSQL 15 image from Docker Hub to use as a base.

```
docker pull postgres:15
```

### Docker Layer (Containers)

Each instruction in a Dockerfile creates a read-only layer in the resulting image. Layers are cached and reused across builds to improve performance.

**Example:** A RUN apt-get install layer is cached and not rebuilt if the instruction has not changed.

```
```dockerfile
RUN apt-get update && apt-get install -y curl
# This becomes one cached layer
```
```

### Docker Compose (Containers)

A tool for defining and running multi-container Docker applications using a YAML file, allowing you to start all services with a single command.

**Example:** Running a web app, a Redis cache, and a PostgreSQL database together with docker compose up.

```
```yaml
services:
  web:
    image: myapp
    ports:
      - "8080:8080"
  db:
    image: postgres:15
```
```

### Container Registry (Containers)

A storage and distribution service for Docker images, allowing teams to push, pull, version, and share images across environments.

**Example:** Pushing a built image to Amazon ECR after a successful CI pipeline run.

```
docker push 123456789.dkr.ecr.us-east-1.amazonaws.com/myapp:latest
```

### Docker Hub (Containers)

The default public container registry provided by Docker, hosting official images for popular software as well as user-published images.

**Example:** Pulling the official Node.js image from Docker Hub as a base for a custom application.

```
docker pull node:18-alpine
```

### Base Image (Containers)

The starting point for a Dockerfile, specified in the FROM instruction. It provides the OS and runtime environment on top of which your application is built.

**Example:** Using node:18-alpine as a base image to keep the final image small.

```
FROM node:18-alpine
```

### Multi-stage Build (Containers)

A Dockerfile technique that uses multiple FROM instructions to separate the build environment from the final runtime image, reducing the size of the produced image.

**Example:** Compiling a Go binary in one stage and copying only the binary into a minimal final image.

```
```dockerfile
FROM golang:1.21 AS builder
RUN go build -o app .

FROM alpine:3.18
COPY --from=builder /app /app
CMD ["/app"]
```
```

### Container Runtime (Containers)

The low-level software responsible for running containers on a host, managing their lifecycle including starting, stopping, and isolating them using OS primitives.

**Example:** containerd and CRI-O are common container runtimes used by Kubernetes nodes.

```
systemctl status containerd
```

### Volume (Containers)

A mechanism for persisting data generated by and used by Docker containers, existing outside the container lifecycle so data survives container restarts or deletion.

**Example:** Mounting a named volume to persist a PostgreSQL database across container restarts.

```
docker run -v pgdata:/var/lib/postgresql/data postgres:15
```

### Bind Mount (Containers)

A type of Docker mount that maps a specific file or directory on the host machine directly into a container, enabling live file sharing between host and container.

**Example:** Mounting a local source code directory into a development container to enable hot reloading.

```
docker run -v $(pwd):/app myapp:dev
```

### Container Network (Containers)

A virtual network that Docker creates to allow containers to communicate with each other and with the outside world, with different drivers supporting different topologies.

**Example:** Creating a bridge network so that a web container can reach a database container by name.

```
docker network create mynetwork
```

### .dockerignore (Containers)

A file that specifies patterns of files and directories to exclude from the Docker build context, reducing build time and preventing secrets from being included in images.

**Example:** Excluding node_modules and .env files from the Docker build context.

```
```
node_modules
.env
*.log
.git
```
```

### Container Orchestration (Containers)

The automated management of containerized workloads across multiple hosts, handling deployment, scaling, networking, and self-healing of containers at scale.

**Example:** Kubernetes automatically restarting a failed container and rescheduling it on a healthy node.

```
kubectl get pods --watch
```

### Kubernetes (K8s) (Kubernetes Core)

An open-source container orchestration platform originally developed by Google that automates deploying, scaling, and managing containerized applications across clusters.

**Example:** Running a production web application across 10 nodes with automatic scaling and self-healing.

```
kubectl cluster-info
```

### Cluster (Kubernetes Core)

A set of machines (nodes) that run containerized applications managed by Kubernetes, consisting of at least one control plane and one or more worker nodes.

**Example:** A production EKS cluster with 3 control plane nodes and 10 worker nodes across 3 availability zones.

```
kubectl get nodes
```

### Control Plane (Kubernetes Core)

The set of components that manage the overall state of the Kubernetes cluster, including scheduling workloads, maintaining desired state, and serving the API.

**Example:** The control plane detects that a pod has crashed and schedules a replacement on a healthy node.

```
kubectl get componentstatuses
```

### Node (Kubernetes Core)

A physical or virtual machine in a Kubernetes cluster that runs workloads. Each node contains a kubelet, container runtime, and kube-proxy.

**Example:** A worker node running five pods across two namespaces.

```
kubectl describe node my-node
```

### Pod (Kubernetes Core)

The smallest deployable unit in Kubernetes, consisting of one or more tightly coupled containers that share the same network namespace, IP address, and storage volumes.

**Example:** A pod containing an application container and a sidecar container for log shipping.

```
```yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: app
    image: myapp:latest
```
```

### Deployment (Kubernetes Workloads)

A Kubernetes resource that declaratively manages a set of identical, stateless pod replicas, supporting rolling updates, rollbacks, and scaling.

**Example:** Scaling a web application from 3 to 10 replicas during peak traffic.

```
kubectl scale deployment my-app --replicas=10
```

### ReplicaSet (Kubernetes Workloads)

A Kubernetes resource that ensures a specified number of pod replicas are running at any given time. Usually managed by a Deployment rather than directly.

**Example:** A ReplicaSet maintaining exactly 3 running replicas of a web server pod.

```
kubectl get replicasets
```

### StatefulSet (Kubernetes Workloads)

A Kubernetes workload resource for managing stateful applications, providing stable pod identities, ordered deployment, and persistent storage per pod.

**Example:** Running a 3-node Kafka cluster using a StatefulSet with persistent volumes for each broker.

```
```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: kafka
spec:
  serviceName: kafka
  replicas: 3
```
```

### DaemonSet (Kubernetes Workloads)

A Kubernetes resource that ensures a copy of a specific pod runs on every node (or a subset of nodes) in the cluster, commonly used for logging and monitoring agents.

**Example:** Deploying a Fluentd log collector pod on every node using a DaemonSet.

```
```yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
```
```

### Job (Kubernetes Workloads)

A Kubernetes resource that creates one or more pods to execute a finite task and ensures they run to successful completion, then terminates.

**Example:** Running a database migration script as a Kubernetes Job before deploying a new application version.

```
```yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: db-migration
```
```

### CronJob (Kubernetes Workloads)

A Kubernetes resource that creates Jobs on a repeating schedule defined using cron syntax, useful for periodic batch tasks like backups or report generation.

**Example:** Running a nightly database backup job at 2:00 AM using a CronJob.

```
```yaml
apiVersion: batch/v1
kind: CronJob
spec:
  schedule: "0 2 * * *"
```
```

### Service (Kubernetes Networking)

A Kubernetes abstraction that provides a stable network endpoint for accessing a set of pods, with built-in load balancing and DNS-based service discovery.

**Example:** Exposing a backend deployment internally to other services using a ClusterIP Service.

```
```yaml
apiVersion: v1
kind: Service
spec:
  selector:
    app: backend
  ports:
  - port: 80
    targetPort: 8080
```
```

### ClusterIP (Kubernetes Networking)

The default Kubernetes Service type that exposes the service on an internal cluster IP, making it reachable only from within the cluster.

**Example:** A database service exposed only internally to application pods in the same cluster.

```
```yaml
spec:
  type: ClusterIP
  ports:
  - port: 5432
```
```

### NodePort (Kubernetes Networking)

A Kubernetes Service type that exposes the service on a static port on each node's IP, making it accessible from outside the cluster via any node's IP and that port.

**Example:** Exposing a development application externally on port 30080 for testing.

```
```yaml
spec:
  type: NodePort
  ports:
  - port: 80
    nodePort: 30080
```
```

### LoadBalancer (Kubernetes Networking)

A Kubernetes Service type that provisions an external cloud load balancer and assigns a public IP, forwarding traffic into the cluster's pods.

**Example:** Exposing a production web application publicly using a LoadBalancer Service on AWS EKS.

```
```yaml
spec:
  type: LoadBalancer
  ports:
  - port: 443
```
```

### Ingress (Kubernetes Networking)

A Kubernetes API object that manages external HTTP and HTTPS access to services, providing routing rules, TLS termination, and virtual hosting in one place.

**Example:** Routing traffic to different microservices based on URL path using an Nginx Ingress controller.

```
```yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /api
        backend:
          service:
            name: api-service
```
```

### Ingress Controller (Kubernetes Networking)

A pod that runs inside the cluster and implements the Ingress rules, acting as a reverse proxy and load balancer for incoming traffic. Common options include Nginx and Traefik.

**Example:** Installing the Nginx Ingress Controller via Helm to handle all incoming HTTP traffic.

```
helm install ingress-nginx ingress-nginx/ingress-nginx
```

### Namespace (Kubernetes Core)

A Kubernetes mechanism for isolating groups of resources within a single cluster, providing scope for names, resource quotas, and access control policies.

**Example:** Using separate namespaces for dev, staging, and production environments in the same cluster.

```
kubectl create namespace staging
```

### ConfigMap (Kubernetes Configuration)

A Kubernetes object used to store non-sensitive configuration data as key-value pairs, decoupling configuration from container images.

**Example:** Storing application feature flags and environment-specific settings in a ConfigMap.

```
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: "info"
  MAX_CONNECTIONS: "100"
```
```

### Secret (Kubernetes Configuration)

A Kubernetes object that stores sensitive data such as passwords, tokens, and TLS certificates, keeping them separate from application code and pod specs.

**Example:** Storing a database password as a Kubernetes Secret and injecting it as an environment variable.

```
kubectl create secret generic db-secret --from-literal=password=mypassword
```

### PersistentVolume (PV) (Kubernetes Storage)

A piece of storage in the cluster provisioned by an administrator or dynamically by a StorageClass, with a lifecycle independent of any pod that uses it.

**Example:** A 100Gi EBS volume provisioned as a PersistentVolume for a PostgreSQL StatefulSet.

```
```yaml
apiVersion: v1
kind: PersistentVolume
spec:
  capacity:
    storage: 100Gi
  accessModes:
    - ReadWriteOnce
```
```

### PersistentVolumeClaim (PVC) (Kubernetes Storage)

A request for storage by a user that consumes a PersistentVolume, specifying size and access mode. Kubernetes binds the PVC to a suitable PV automatically.

**Example:** A pod requesting 10Gi of storage via a PVC that Kubernetes binds to an available PV.

```
```yaml
apiVersion: v1
kind: PersistentVolumeClaim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
```
```

### StorageClass (Kubernetes Storage)

A Kubernetes resource that defines different classes of storage with their provisioner and parameters, enabling dynamic provisioning of PersistentVolumes on demand.

**Example:** A StorageClass backed by AWS gp3 EBS volumes that auto-provisions storage when a PVC is created.

```
```yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
```
```

### ResourceQuota (Kubernetes Configuration)

A Kubernetes policy that limits the aggregate resource consumption per namespace, controlling how much CPU, memory, and object count a team can use.

**Example:** Limiting the staging namespace to a maximum of 8 CPU cores and 16Gi of memory.

```
```yaml
apiVersion: v1
kind: ResourceQuota
spec:
  hard:
    requests.cpu: "8"
    requests.memory: 16Gi
```
```

### LimitRange (Kubernetes Configuration)

A Kubernetes policy that sets default and maximum resource requests and limits for containers in a namespace, preventing unbounded resource consumption.

**Example:** Setting a default memory limit of 512Mi for all containers in the dev namespace.

```
```yaml
apiVersion: v1
kind: LimitRange
spec:
  limits:
  - default:
      memory: 512Mi
    type: Container
```
```

### HorizontalPodAutoscaler (HPA) (Kubernetes Scaling)

A Kubernetes resource that automatically scales the number of pod replicas in a Deployment based on observed CPU utilization or custom metrics.

**Example:** Automatically scaling a web deployment from 2 to 20 replicas based on CPU usage exceeding 60%.

```
kubectl autoscale deployment my-app --cpu-percent=60 --min=2 --max=20
```

### VerticalPodAutoscaler (VPA) (Kubernetes Scaling)

A Kubernetes component that automatically adjusts the CPU and memory resource requests and limits of containers based on historical usage patterns.

**Example:** Using VPA to right-size a memory-hungry container that was over-provisioned at initial deployment.

```
```yaml
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
spec:
  updatePolicy:
    updateMode: Auto
```
```

### Cluster Autoscaler (Kubernetes Scaling)

A Kubernetes component that automatically adjusts the number of nodes in a cluster when pods cannot be scheduled due to resource constraints or nodes are underutilized.

**Example:** The Cluster Autoscaler adding a new node to AWS EKS when pending pods cannot be scheduled.

```
kubectl -n kube-system logs deployment/cluster-autoscaler
```

### Liveness Probe (Kubernetes Reliability)

A Kubernetes health check that determines if a container is still running correctly. If the probe fails, Kubernetes restarts the container automatically.

**Example:** A liveness probe hitting /healthz every 10 seconds and restarting the container if it fails 3 times.

```
```yaml
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 10
```
```

### Readiness Probe (Kubernetes Reliability)

A Kubernetes health check that determines if a container is ready to accept traffic. Pods that fail the readiness probe are removed from Service endpoints until they recover.

**Example:** A readiness probe preventing traffic from reaching a pod while it initializes its database connection.

```
```yaml
readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5
```
```

### Startup Probe (Kubernetes Reliability)

A Kubernetes health check that gives slow-starting containers extra time to initialize before liveness and readiness probes take over, preventing premature restarts.

**Example:** A startup probe allowing a legacy Java application up to 3 minutes to start before checking health.

```
```yaml
startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 10
```
```

### Taint & Toleration (Kubernetes Scheduling)

A Kubernetes mechanism where taints are applied to nodes to repel pods, and tolerations are applied to pods to allow them to schedule onto tainted nodes.

**Example:** Tainting GPU nodes so only ML workloads with the correct toleration can be scheduled on them.

```
```yaml
tolerations:
- key: "gpu"
  operator: "Equal"
  value: "true"
  effect: "NoSchedule"
```
```

### Node Affinity (Kubernetes Scheduling)

A Kubernetes scheduling rule that constrains which nodes a pod can be scheduled onto based on node labels, offering more expressive rules than node selectors.

**Example:** Scheduling data-intensive pods exclusively onto nodes in the us-east-1a availability zone.

```
```yaml
affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: topology.kubernetes.io/zone
          operator: In
          values: [us-east-1a]
```
```

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

A Kubernetes authorization mechanism that regulates access to cluster resources based on the roles assigned to users or service accounts.

**Example:** Granting a CI/CD service account permission to deploy to the production namespace only.

```
```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "update"]
```
```

### ServiceAccount (Kubernetes Security)

A Kubernetes identity assigned to pods, allowing them to authenticate to the Kubernetes API and interact with cluster resources according to their RBAC permissions.

**Example:** Assigning a ServiceAccount to a pod that needs to list other pods in the same namespace.

```
```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-service-account
  namespace: production
```
```

### NetworkPolicy (Kubernetes Security)

A Kubernetes resource that controls the traffic flow at the IP address or port level between pods and external endpoints, acting as a firewall within the cluster.

**Example:** Restricting a database pod to only accept connections from pods with the label app=backend.

```
```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend
```
```

### Helm (Kubernetes Tooling)

A package manager for Kubernetes that uses charts to define, install, and upgrade complex Kubernetes applications, simplifying repeatable deployments.

**Example:** Installing a full Prometheus + Grafana monitoring stack with a single Helm install command.

```
helm install monitoring prometheus-community/kube-prometheus-stack
```

### Helm Chart (Kubernetes Tooling)

A collection of files that describe a related set of Kubernetes resources, packaged together with configurable values to enable reusable and versioned application deployments.

**Example:** A Helm chart for a web application with configurable replicas, image tag, and ingress hostname.

```
```
mychart/
  Chart.yaml
  values.yaml
  templates/
    deployment.yaml
    service.yaml
```
```

### kubectl (Kubernetes Tooling)

The command-line tool for interacting with Kubernetes clusters, allowing you to deploy applications, inspect resources, and manage cluster operations.

**Example:** Using kubectl to view all pods across all namespaces and their current status.

```
kubectl get pods --all-namespaces
```

### kubeconfig (Kubernetes Tooling)

A YAML file that stores cluster connection details, credentials, and context configurations, used by kubectl to authenticate and communicate with Kubernetes clusters.

**Example:** Switching between a staging and production cluster context using kubectl.

```
kubectl config use-context production-cluster
```

### etcd (Kubernetes Core)

A distributed key-value store used by Kubernetes as its primary backing store for all cluster state and configuration data.

**Example:** All Kubernetes objects   pods, services, configmaps   are persisted in etcd.

```
etcdctl get /registry/pods/default/my-pod
```

### kube-scheduler (Kubernetes Core)

The Kubernetes control plane component responsible for assigning newly created pods to nodes, based on resource requirements, constraints, and policies.

**Example:** The scheduler placing a pod with 4 CPU requests on a node that has sufficient available capacity.

```
kubectl -n kube-system get pod -l component=kube-scheduler
```

### kube-proxy (Kubernetes Core)

A network component that runs on each node and maintains network rules to forward traffic destined for Services to the correct pod endpoints.

**Example:** kube-proxy updating iptables rules when a new pod is added to a Service endpoint.

```
kubectl -n kube-system get pod -l k8s-app=kube-proxy
```

### Rolling Update (Kubernetes Reliability)

A Kubernetes Deployment strategy that gradually replaces old pod replicas with new ones, ensuring zero downtime by keeping some replicas available throughout the update.

**Example:** Deploying a new application version by replacing pods one at a time while maintaining availability.

```
```yaml
strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0
```
```

### Init Container (Kubernetes Workloads)

A specialized container that runs to completion before app containers in a pod start, used for setup tasks such as waiting for a dependency or initializing config files.

**Example:** An init container waiting for a database to be ready before the main application container starts.

```
```yaml
initContainers:
- name: wait-for-db
  image: busybox
  command: ['sh', '-c', 'until nc -z db 5432; do sleep 2; done']
```
```

### Sidecar Container (Kubernetes Workloads)

A helper container that runs alongside the main application container in the same pod, augmenting or supporting its functionality without modifying the main image.

**Example:** A Fluentd sidecar container collecting and forwarding logs from the main application container.

```
```yaml
containers:
- name: app
  image: myapp
- name: log-shipper
  image: fluentd
```
```

### Pod Disruption Budget (PDB) (Kubernetes Reliability)

A Kubernetes policy that limits the number of pods of a replicated application that can be simultaneously unavailable during voluntary disruptions such as node drains.

**Example:** Ensuring at least 2 replicas of a web service are always available during a node upgrade.

```
```yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: my-web
```
```