The cloud native ecosystem has developed its own vocabulary at a staggering pace. New engineers encounter an alphabet soup of acronyms and jargon that can be overwhelming: CRI, CSI, CNI, OCI, CNCF, SRE, SLO, SLI. This glossary defines 100 essential terms organized by category, providing both clear definitions and practical context for when you will encounter each concept.

Containers and Runtimes (1-15)

1. Container - A lightweight, standalone unit of software that packages an application and its dependencies together. Technically, a Linux process with its own namespaces and cgroup resource limits. Unlike a virtual machine, a container shares the host's kernel.

2. Container Image - A read-only template containing the filesystem, libraries, and configuration needed to create a container. Images are composed of layers, each representing a Dockerfile instruction. Images are identified by repository name, tag, and digest.

3. Container Runtime - The software responsible for actually running containers. Low-level runtimes (runc, crun) interact directly with the kernel. High-level runtimes (containerd, CRI-O) manage the full container lifecycle including image pulling and storage.

4. OCI (Open Container Initiative) - A Linux Foundation project that defines open standards for container formats and runtimes. The OCI Runtime Specification and Image Specification ensure interoperability between container tools.

5. Docker - The platform that popularized containers in 2013. Docker includes a CLI, daemon, build system (BuildKit), and image registry (Docker Hub). While Docker is no longer required for running containers in production, it remains the most common development tool for building images.

6. containerd - A CNCF graduated container runtime daemon that manages the complete container lifecycle on a host system. It is the runtime used by Docker Engine internally and is the default runtime for Kubernetes.

7. runc - The OCI reference implementation for running containers. It is a CLI tool that spawns and runs containers according to the OCI Runtime Specification. Both Docker and containerd use runc as their default low-level runtime.

8. Podman - A daemonless container engine developed by Red Hat. It is compatible with Docker CLI commands but does not require a running daemon, supports rootless containers natively, and can generate systemd unit files for container management.

9. Dockerfile - A text file containing instructions for building a container image. Each instruction (FROM, RUN, COPY, etc.) creates a new image layer. Dockerfiles provide reproducible, version-controlled image definitions.

10. Registry - A storage and distribution service for container images. Docker Hub is the largest public registry. Private registries include Harbor, GitLab Container Registry, AWS ECR, Google Artifact Registry, and Azure Container Registry.

11. Image Layer - A read-only filesystem delta representing a single instruction in a Dockerfile. Layers are cached and shared between images, reducing storage and network transfer. The final container adds a thin writable layer on top.

12. Union Filesystem - A filesystem service that combines multiple directories (layers) into a single unified view. Docker uses overlay2, which stacks image layers with a writable container layer using Linux's OverlayFS.

13. Namespace - A Linux kernel feature that partitions system resources so that one set of processes sees one set of resources while another set sees a different set. Docker uses mount, UTS, IPC, PID, network, user, and cgroup namespaces.

14. cgroup (Control Group) - A Linux kernel feature that limits, accounts for, and isolates the resource usage (CPU, memory, disk I/O, network) of a collection of processes. cgroups v2 is the current version used by modern container runtimes.

15. Rootless Container - A container that runs entirely without root privileges, including the container runtime itself. This eliminates the risk of container escape leading to root access on the host.

Orchestration (16-30)

16. Container Orchestration - The automated management of containerized applications across multiple hosts, including deployment, scaling, networking, load balancing, and self-healing. Kubernetes is the dominant orchestration platform.

17. Kubernetes (K8s) - An open-source container orchestration platform originally developed by Google. It automates deployment, scaling, and management of containerized applications. Kubernetes uses a declarative model where you describe the desired state and the system converges toward it.

18. Docker Swarm - Docker's built-in orchestration mode. It uses the same Docker CLI and Compose file format, making it simpler than Kubernetes for smaller deployments. Swarm provides service discovery, load balancing, rolling updates, and secret management.

19. Pod - The smallest deployable unit in Kubernetes. A pod contains one or more containers that share network namespace, storage volumes, and lifecycle. Containers in a pod communicate over localhost.

20. Deployment - A Kubernetes resource that declares the desired state for a set of pods, including the number of replicas, the container image, and update strategy. The Deployment controller ensures the actual state matches the declared state.

21. Service (Kubernetes) - An abstraction that defines a logical set of pods and a policy for accessing them. Services provide stable IP addresses and DNS names for a set of pods, enabling load balancing and service discovery.

22. Ingress - A Kubernetes resource that manages external access to services, typically HTTP. It provides URL-based routing, SSL termination, and name-based virtual hosting. Ingress requires an Ingress Controller (nginx, Traefik, etc.) to function.

23. Helm - A package manager for Kubernetes that defines, installs, and upgrades applications using charts. A Helm chart is a collection of templates and values that generate Kubernetes manifests.

24. Operator - A Kubernetes-native application that extends the API to manage complex stateful applications. Operators encode operational knowledge (backup, restore, scaling, upgrades) into software using Custom Resource Definitions (CRDs).

25. StatefulSet - A Kubernetes resource for managing stateful applications. Unlike Deployments, StatefulSets maintain a sticky identity for each pod, provide ordered deployment/scaling, and support stable persistent storage.

26. DaemonSet - A Kubernetes resource that ensures a copy of a pod runs on every node (or a selected subset). Common uses include log collectors, monitoring agents, and network plugins.

27. CRI (Container Runtime Interface) - A Kubernetes interface that defines how the kubelet communicates with container runtimes. containerd and CRI-O both implement CRI, allowing Kubernetes to use them interchangeably.

28. CSI (Container Storage Interface) - A standard for exposing storage systems to container orchestrators. CSI drivers allow Kubernetes to use any storage backend (AWS EBS, GCP PD, Ceph, NFS) through a uniform interface.

29. CNI (Container Network Interface) - A specification for configuring network interfaces in Linux containers. CNI plugins (Calico, Cilium, Flannel, Weave) implement pod networking in Kubernetes.

30. Scheduler - The component that assigns pods to nodes based on resource requirements, constraints, affinity rules, and available capacity. The Kubernetes scheduler is pluggable and extensible.

Microservices and Architecture (31-45)

31. Microservices - An architectural style that structures an application as a collection of small, independent services that communicate over APIs. Each service is independently deployable, scalable, and maintainable.

32. Monolith - A traditional application architecture where all functionality is built as a single, tightly coupled unit. Monoliths are simpler to develop initially but harder to scale and maintain as they grow.

33. Service Mesh - An infrastructure layer that handles service-to-service communication, providing traffic management, security (mTLS), and observability without requiring application code changes. Examples: Istio, Linkerd, Consul Connect.

34. Sidecar Pattern - A design pattern where a helper container runs alongside the primary container in the same pod, providing supplementary functionality such as logging, monitoring, or network proxying without modifying the primary application.

35. API Gateway - A service that sits between clients and backend services, providing a single entry point for API requests. It handles routing, authentication, rate limiting, and protocol translation. Examples: Kong, Ambassador, APISIX.

36. Service Discovery - The mechanism by which services locate each other in a dynamic environment. In Kubernetes, this is handled by DNS (CoreDNS) and the Service resource. In Docker, the embedded DNS server resolves container names.

37. Circuit Breaker - A design pattern that prevents cascading failures by stopping requests to a failing service after a threshold of errors. When the circuit is "open," requests fail fast instead of waiting for timeouts.

38. Load Balancing - Distributing incoming requests across multiple instances of a service. Kubernetes Services provide built-in L4 load balancing. L7 load balancing is handled by Ingress controllers or service mesh.

39. 12-Factor App - A methodology for building software-as-a-service applications, defined by Heroku. The twelve factors cover codebase, dependencies, config, backing services, build/release/run, processes, port binding, concurrency, disposability, dev/prod parity, logs, and admin processes.

40. Event-Driven Architecture - A pattern where services communicate by producing and consuming events asynchronously. This decouples producers from consumers and enables temporal decoupling. Commonly implemented with Kafka, NATS, or RabbitMQ.

41. Domain-Driven Design (DDD) - A software design approach that models complex software based on the business domain. Bounded contexts in DDD often map naturally to microservice boundaries.

42. gRPC - A high-performance RPC framework developed by Google that uses Protocol Buffers for serialization and HTTP/2 for transport. It supports streaming, multiplexing, and code generation for multiple languages.

43. Message Queue - An asynchronous communication mechanism where messages are stored in a queue until consumed. Examples include RabbitMQ, Apache Kafka, NATS JetStream, and Amazon SQS. Queues provide buffering, ordering, and delivery guarantees.

44. Saga Pattern - A pattern for managing data consistency across multiple microservices without distributed transactions. Each service performs its local transaction and publishes an event to trigger the next step, with compensating transactions for rollback.

45. Strangler Fig Pattern - A migration strategy where a legacy monolith is incrementally replaced by microservices. New functionality is built as services, and existing functionality is gradually extracted, with the old system eventually decommissioned.

CI/CD and Deployment (46-60)

46. CI (Continuous Integration) - The practice of frequently merging code changes into a shared repository, with automated builds and tests running on every commit. CI catches integration issues early and maintains a consistently buildable codebase.

47. CD (Continuous Delivery/Deployment) - Continuous Delivery ensures code is always in a deployable state. Continuous Deployment goes further by automatically deploying every change that passes the pipeline to production.

48. Pipeline - A defined sequence of stages (build, test, scan, deploy) that code changes pass through from commit to production. Pipeline-as-code (Jenkinsfile, .gitlab-ci.yml, GitHub Actions) stores pipeline definitions in the repository.

49. GitOps - An operational framework where Git repositories are the single source of truth for declarative infrastructure and application configuration. Changes are applied by pull request, and a reconciliation controller ensures the live state matches the repository.

50. Blue-Green Deployment - A deployment strategy that maintains two identical production environments (blue and green). New versions are deployed to the inactive environment, tested, and traffic is switched over atomically. Rollback is instant by switching back.

51. Canary Deployment - A strategy where a new version is rolled out to a small subset of users or traffic before full deployment. If the canary shows no issues (based on metrics and error rates), the rollout continues progressively.

52. Rolling Update - A deployment strategy that gradually replaces instances of the old version with the new version. Docker Swarm and Kubernetes both support rolling updates with configurable parallelism, delay, and failure thresholds.

53. Feature Flag - A technique that decouples deployment from release by wrapping new features in conditional logic. Features can be enabled or disabled at runtime without deploying new code. Tools: LaunchDarkly, Unleash, Flagsmith.

54. Artifact - A versioned, immutable output of a build process. Container images are artifacts. Artifacts are stored in registries or artifact repositories (Artifactory, Nexus) and promoted through environments.

55. Infrastructure as Code (IaC) - Managing infrastructure through machine-readable configuration files rather than manual processes. Tools include Terraform, Pulumi, AWS CloudFormation, and Ansible. IaC enables version control, code review, and automated provisioning.

56. Immutable Infrastructure - A paradigm where servers are never modified after deployment. Updates are performed by replacing the entire server or container with a new version. This eliminates configuration drift and ensures reproducibility.

57. ArgoCD - A declarative GitOps continuous delivery tool for Kubernetes. It monitors Git repositories and automatically synchronizes the desired state defined in Git with the live state in the cluster.

58. Flux - A set of GitOps tools for Kubernetes, maintained by the CNCF. Flux monitors Git repositories and container registries, and automatically reconciles the cluster state with the declared configuration.

59. Tekton - A cloud-native CI/CD framework for Kubernetes that defines pipelines as Kubernetes custom resources. Tekton is the foundation for several CI/CD platforms including OpenShift Pipelines.

60. Semantic Versioning (SemVer) - A versioning scheme (MAJOR.MINOR.PATCH) that communicates the nature of changes. Major versions indicate breaking changes, minor versions add functionality, and patch versions fix bugs. Critical for container image tagging.

Observability (61-75)

61. Observability - The ability to understand the internal state of a system from its external outputs. The three pillars of observability are metrics, logs, and traces.

62. Metrics - Numerical measurements collected over time. Container metrics include CPU usage, memory consumption, network I/O, and request rates. Prometheus is the dominant metrics collection system in cloud native environments.

63. Logging - The practice of recording events and messages from applications and infrastructure. Centralized logging aggregates logs from all containers and services into a searchable system. Tools: ELK stack, Grafana Loki, Fluentd.

64. Distributed Tracing - Tracking requests as they flow through multiple services, providing end-to-end visibility into latency and errors. Each service adds a span to the trace. Tools: Jaeger, Zipkin, Tempo, OpenTelemetry.

65. OpenTelemetry (OTel) - A CNCF project that provides a unified set of APIs, libraries, and agents for collecting metrics, logs, and traces. It is the convergence of OpenTracing and OpenCensus and is becoming the standard instrumentation framework.

66. Prometheus - An open-source monitoring system and time-series database. It uses a pull model to scrape metrics from instrumented applications and supports powerful query language (PromQL) and alerting rules.

67. Grafana - An open-source visualization and analytics platform. Grafana connects to multiple data sources (Prometheus, Loki, Elasticsearch) and provides dashboards, alerts, and annotations. It is the standard visualization tool for cloud native monitoring.

68. SLO (Service Level Objective) - A target value for a service level indicator, such as "99.9% of requests will complete in under 200ms." SLOs define reliability targets and are used to balance feature velocity against operational stability.

69. SLI (Service Level Indicator) - A quantitative measurement of a service's behavior, such as request latency, error rate, or throughput. SLIs are the raw data that determine whether SLOs are being met.

70. SLA (Service Level Agreement) - A contractual commitment between a service provider and customer, typically defined in terms of SLOs with financial penalties for violations. SLAs are looser than internal SLOs to provide a buffer.

71. Error Budget - The acceptable amount of unreliability derived from an SLO. If your SLO is 99.9% availability, your monthly error budget is 43.2 minutes of downtime. When the budget is exhausted, operations are prioritized over features.

72. Alerting - Automated notifications triggered when metrics cross defined thresholds or anomalies are detected. Effective alerting targets symptoms over causes and alerts on SLO burn rate rather than individual metric thresholds.

73. Health Check - A mechanism for determining whether a service instance is healthy and able to handle requests. Docker supports HEALTHCHECK instructions in Dockerfiles. Kubernetes uses liveness, readiness, and startup probes.

74. cAdvisor - Container Advisor, a Google-developed tool that collects resource usage and performance data from running containers. It is embedded in the Kubernetes kubelet and exports metrics in Prometheus format.

75. Chaos Engineering - The practice of intentionally introducing failures into a system to test its resilience. Tools like Chaos Monkey, Litmus, and Chaos Mesh simulate network partitions, container kills, and resource exhaustion in controlled experiments.

Security (76-85)

76. Zero Trust - A security model that requires strict identity verification for every person and device accessing resources, regardless of network location. In cloud native, this means mutual TLS between services, identity-based access, and no implicit trust for any network.

77. RBAC (Role-Based Access Control) - An authorization model where permissions are assigned to roles, and roles are assigned to users. Kubernetes RBAC controls API access. Container management platforms like usulnet implement RBAC for Docker operations.

78. Network Policy - A Kubernetes resource that controls traffic flow between pods. Network policies act as a firewall at the pod level, defining which pods can communicate with each other and on which ports.

79. Pod Security Standards - Kubernetes-defined security profiles (Privileged, Baseline, Restricted) that control what pods are allowed to do. They replace the deprecated PodSecurityPolicy and are enforced by the Pod Security Admission controller.

80. Image Scanning - The process of analyzing container images for known vulnerabilities (CVEs), misconfigurations, and embedded secrets. Tools include Trivy, Grype, Snyk, and Docker Scout. Scanning should be integrated into CI/CD pipelines.

81. mTLS (Mutual TLS) - A TLS connection where both the client and server present certificates, providing mutual authentication. Service meshes (Istio, Linkerd) automate mTLS between services without application code changes.

82. Secret - Sensitive configuration data such as passwords, API keys, and TLS certificates. Kubernetes Secrets, Docker Swarm secrets, and external vaults (HashiCorp Vault) provide mechanisms for securely distributing secrets to containers.

83. OPA (Open Policy Agent) - A general-purpose policy engine that enables fine-grained authorization decisions. In Kubernetes, OPA Gatekeeper enforces custom policies on cluster resources at admission time.

84. Supply Chain Security - Protecting the software supply chain from source code to deployed artifact. Includes signed commits, reproducible builds, signed images (Cosign/Sigstore), SBOMs, and provenance attestations (SLSA).

85. SBOM (Software Bill of Materials) - A complete inventory of all software components in a container image, including libraries, dependencies, and their versions. SBOMs enable rapid vulnerability assessment when new CVEs are disclosed. Formats include SPDX and CycloneDX.

Infrastructure and Networking (86-100)

86. Overlay Network - A virtual network built on top of an existing network infrastructure, enabling containers on different hosts to communicate as if they were on the same LAN. Docker Swarm and Kubernetes use overlay networks (VXLAN, Geneve) for cross-host pod communication.

87. Service Proxy - A network proxy that intercepts and manages traffic to and from services. Envoy is the most common service proxy in cloud native environments, used by Istio, Ambassador, and Contour.

88. Reverse Proxy - A server that sits in front of backend services and forwards client requests. In container environments, reverse proxies (nginx, Traefik, Caddy) provide TLS termination, routing, and load balancing.

89. DNS (Domain Name System) - In container orchestration, DNS provides service discovery. Kubernetes uses CoreDNS to resolve service names to cluster IPs. Docker uses an embedded DNS server for container name resolution within networks.

90. Persistent Volume - A Kubernetes resource representing a piece of storage provisioned by an administrator or dynamically via a StorageClass. Persistent Volumes decouple storage lifecycle from pod lifecycle.

91. ConfigMap - A Kubernetes object that stores non-confidential configuration data as key-value pairs. ConfigMaps can be consumed as environment variables, command-line arguments, or configuration files mounted into pods.

92. Horizontal Pod Autoscaler (HPA) - A Kubernetes resource that automatically scales the number of pod replicas based on CPU utilization, memory usage, or custom metrics. HPA checks metrics at configurable intervals and adjusts the replica count.

93. Vertical Pod Autoscaler (VPA) - A Kubernetes component that automatically adjusts CPU and memory resource requests for pods based on historical usage patterns. VPA complements HPA by right-sizing individual pods.

94. etcd - A distributed, consistent key-value store used as Kubernetes' backing store for all cluster data. etcd stores the cluster state, configuration, and secrets. Its health is critical to cluster operation.

95. CoreDNS - A flexible, extensible DNS server that is the default DNS service in Kubernetes. It provides service discovery within the cluster and can be extended with plugins for custom behavior.

96. Site Reliability Engineering (SRE) - A discipline that applies software engineering principles to operations, originated at Google. SREs focus on reliability, automation, and eliminating toil. Key concepts include error budgets, SLOs, and postmortems.

97. Toil - Manual, repetitive, automatable work related to running a production service that scales linearly with the service. SRE teams aim to keep toil below 50% of their work, automating the rest.

98. Postmortem - A blameless analysis conducted after an incident to understand what happened, why, and how to prevent recurrence. Postmortems document the timeline, root cause, impact, and action items.

99. FinOps - A practice that brings financial accountability to cloud spending. FinOps teams optimize container infrastructure costs through right-sizing, spot instances, reserved capacity, and resource usage analysis.

100. Platform Engineering - The discipline of designing and building internal developer platforms (IDPs) that provide self-service capabilities for developers. Platform engineers create golden paths for deployment, monitoring, and operations, reducing cognitive load on development teams.

Tip: Bookmark this glossary as a reference. Cloud native terminology evolves rapidly, and having precise definitions helps avoid miscommunication between development, operations, and security teams.

Note: The CNCF maintains an official Cloud Native Glossary that tracks emerging terms. This article covers the foundational terms you will encounter most frequently in day-to-day work with containers, orchestration, and cloud native infrastructure.