Compendium

OCI / Container-Runtime / Cloud-Native Specification DSLs Family Index

12 min read

OCI / Container-Runtime / Cloud-Native DSLs Family Index

type: language-family-index family: oci-cloud-native languages_catalogued: 28 tags: [language-reference, family-index, oci-cloud-native, oci, cri, cni, csi, cdi, helm, kustomize, kcl, cue, crd, gitops, service-mesh]

OCI / Container-Runtime / Cloud-Native Specification — Family Index

Family overview

This family covers the formal specifications that define how container images are packaged, how container runtimes are configured, how registries serve content, how Kubernetes extends its API, and how the surrounding cloud-native ecosystem (service meshes, GitOps, observability, runtime security, serverless) declares intent. Where the sibling build-devops family covers the production of artifacts (Make, Bazel, GitHub Actions YAML) and config-management covers system configuration (Ansible, Puppet, NixOS), this family covers the runtime contracts that the resulting artifacts execute against.

The foundational layer is the Open Container Initiative (OCI) spec triplet, established under the Linux Foundation in 2015 and now mature. The OCI Image Specification v1.1 (released 2024-02-15) introduced first-class artifact manifests for Helm charts, SBOMs, signatures, and attestations; the OCI Runtime Specification v1.2.0 (2024-02-18, followed by v1.2.1) added the org.containers.image reserved annotation and CPU-affinity controls; the OCI Distribution Specification v1.1 (2024) standardised the registry referrers API and clarified manifest size limits with a recommended 4 MiB minimum. These three specs are the rails on which Docker, containerd, CRI-O, podman, and every modern registry run.

Above the OCI layer sit Kubernetes’ four runtime-extension interfaces: CRI (kubelet ↔ container runtime, protobuf, the contract behind containerd and CRI-O), CNI v1.1.0 (pod networking, JSON, the contract behind Cilium/Calico/Flannel), CSI (storage drivers, gRPC, currently around v1.11), and CDI v0.7 (device injection — GPUs, FPGAs — the contract behind NVIDIA’s GPU operator). Above that sits the most prolific extension language in cloud-native: the CustomResourceDefinition (CRD), whose OpenAPI v3 structural schema plus CEL validation rules (graduated in K8s 1.25) lets any project introduce typed YAML resources — which is exactly how Argo CD, FluxCD, Istio, Knative, Crossplane, Tetragon, and Falco are written.

A parallel packaging / config wave has played out atop CRDs: Helm 3 (apiVersion: v2, Go templates), Kustomize (overlay-based, no templating), and the modern typed challengers KCL 0.11 (CNCF Sandbox, structured-config language with schema + lambdas) and CUE 0.13/0.14 (Google-origin, lattice-based unification; the eval-v3 evaluator became default in 0.13). Service meshes (Istio, Linkerd, Envoy XDS), GitOps (Argo CD 3.0, FluxCD v2), eBPF runtime security (Cilium Tetragon TracingPolicy, Falco rules), serverless (Knative Serving/Eventing), and the event-envelope spec CloudEvents 1.0 (CNCF Graduated 2024-01-25) round out the family.

In our deep library

No standalone deep-library notes exist for these specs — they are language-adjacent contracts, not host languages. The relevant deep notes for the implementations are go (kubelet, containerd, CRI-O, Helm, Kustomize, Crossplane, Tetragon, Knative, FluxCD, Argo CD are all written in Go) and rust (youki, krustlet, increasingly used in CNI/CSI plugins).

Cross-reference:

  • build-devops — sibling; covers build/CI graph DSLs (Make, Bazel, GitHub Actions, Tekton Pipelines, Argo Workflows). Tekton and Argo Workflows are themselves CRD-defined and could be dual-listed.
  • config-management — sibling; covers Ansible/Puppet/Chef/Salt + NixOS/Talos. Some YAML overlap (Helm values, Ansible inventory) but different audience.
  • api-description — heavily used by this family; OpenAPI v3 is the schema language behind every CRD, and gRPC/protobuf is the wire format for CRI and CSI.
  • identity-auth-policy — Kubernetes ValidatingAdmissionPolicy is CEL-based and catalogued there; OPA Rego is the dominant external policy engine.
  • network-protocol-dsls — sibling for eBPF programs (Cilium, Tetragon, Falco modern driver all use eBPF underneath the YAML).
  • notation-spec — sibling for formal specification grammars in general.
  • graph-log-event-query — OpenTelemetry semantic conventions are a vocabulary spec; cross-referenced there.

Tier 3 family table — OCI core specifications

FormatFirst appearedOriginTypeStatus (2026)URL
OCI Image Specification2016 (v1.0 in 2017)Open Container Initiative / Linux Foundation (Docker, CoreOS, et al., 2015)JSON manifests + config; tar layer formatActive; v1.1.0 released 2024-02-15 (first minor bump since 2017; adds artifact manifest, reference type, subject field)https://github.com/opencontainers/image-spec
OCI Runtime Specification2016 (v1.0 in 2017)Open Container InitiativeJSON config.json runtime contractActive; v1.2.0 released 2024-02-18, v1.2.1 followed with CPU-affinity additionshttps://github.com/opencontainers/runtime-spec
OCI Distribution Specification2018 (v1.0 in 2021)Open Container InitiativeHTTP+JSON registry API contractActive; v1.1 (2024) adds referrers API, clarifies 413 on oversized manifests, recommends 4 MiB minimumhttps://github.com/opencontainers/distribution-spec
OCI Artifact Manifest2024OCI image-spec v1.1 (rolled into image manifest, not a separate spec after WG decision)JSON manifest with artifactType media typeActive; the canonical mechanism for storing Helm charts, SBOMs (CycloneDX, SPDX), Notary v2 / Cosign signatures, and attestations in OCI registrieshttps://github.com/opencontainers/image-spec/blob/main/manifest.md

Tier 3 family table — Kubernetes runtime interfaces

FormatFirst appearedOriginTypeStatus (2026)URL
CRI (Container Runtime Interface)2016 (K8s 1.5)Kubernetes SIG-Node (Google, Red Hat)Protobuf / gRPC; kubelet ↔ container runtimeActive; the contract implemented by containerd, CRI-O, Docker (via cri-dockerd shim)https://github.com/kubernetes/cri-api
CNI (Container Network Interface)2015CoreOS → CNCF (2017)JSON config + executable plugin contractActive; current spec v1.1.0 (operations: ADD, DEL, CHECK, GC, VERSION); behind Cilium, Calico, Flannel, AWS VPC CNI, Multushttps://www.cni.dev/docs/spec/
CSI (Container Storage Interface)2017 (v0.1), 2018 (v1.0)CNCF (Kubernetes, Mesos, Cloud Foundry, Docker)Protobuf / gRPCActive; recent releases around v1.11.0 with GA VolumeGroupSnapshothttps://github.com/container-storage-interface/spec
CDI (Container Device Interface)2021CNCF / containerd / NVIDIAJSON device-injection specActive; current spec around v0.7.0; the modern replacement for ad-hoc device plugin shims for GPUs, FPGAs, and DPUshttps://github.com/cncf-tags/container-device-interface

Tier 3 family table — Kubernetes packaging / config

FormatFirst appearedOriginTypeStatus (2026)URL
Helm Chart.yaml + values.yaml + templates/2016 (Helm 1), 2019 (Helm 3)Deis → CNCF (Helm graduated 2020)YAML + Go text/template (Sprig functions)Active; current Chart apiVersion: v2 (Helm 3+); Helm 3 charts are forward-compatible with Helm 4https://helm.sh/docs/topics/charts/
Kustomize kustomization.yaml2017 (separate), 2019 (built into kubectl)Google (Phil Wittrock et al.)YAML overlay; no templating, only declarative patchesActive; the official “templateless” alternative to Helm, ships as kubectl kustomizehttps://kustomize.io/
CRD (CustomResourceDefinition) OpenAPI Schema2018 (K8s 1.7 had ThirdPartyResource; 1.9 stabilised CRD; 1.16 GA)Kubernetes SIG-API-MachineryOpenAPI v3 structural schema + x-kubernetes-validations (CEL)Active; CEL validation graduated to beta in K8s 1.25 (2022), GA later; validation ratcheting added in 2026https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/
Kubernetes API conventions (OpenAPI v3)~2015Kubernetes SIG-API-MachineryGenerated OpenAPI v3 from Go types via kubebuilder/controller-genActive; the source of kubectl explain output and client-go typed clientshttps://kubernetes.io/docs/reference/using-api/api-concepts/
KCL (KusionStack KCL)2022 (v0.4 OSS)Ant Group → CNCF SandboxStatically-typed structured-config language; schema + lambda + unitsActive; current series 0.11/0.12 (2026); used by KusionStack platform engineeringhttps://www.kcl-lang.io/
CUE (Configure, Unify, Execute)2018Marcel van Lohuizen (ex-Google, after BCL/GCL experience)Lattice-based unified typed config; superset of JSON, constraints + values in one syntaxActive; v0.13 made the eval-v3 evaluator default; v0.14 (Mar 2026) added cue get crd for CRD-from-cluster extraction; still pre-1.0https://cuelang.org/
ytt (Carvel)2019VMware Tanzu (Carvel)YAML-templating with starlark-like @ annotationsActive within Carvel ecosystem (kbld, imgpkg, kapp); niche outsidehttps://carvel.dev/ytt/

Tier 3 family table — Service mesh / proxy / serverless

FormatFirst appearedOriginTypeStatus (2026)URL
Istio VirtualService / DestinationRule / Gateway / EnvoyFilter2017Google, IBM, Lyft (now Istio Foundation / CNCF Graduated 2025)CRD YAML on top of Envoy data planeActive; the dominant L7 service mesh; ambient mesh mode (waypoint proxies) increasingly defaulthttps://istio.io/latest/docs/reference/config/
Envoy proxy config (Bootstrap, XDS, Listener filters)2017Lyft → CNCFYAML / JSON / protobuf; xDS-API for dynamic config (LDS, RDS, CDS, EDS, ADS)Active; the de facto edge/sidecar proxy spec used by Istio, Linkerd2-proxy (no), Consul, AWS App Meshhttps://www.envoyproxy.io/docs/envoy/latest/configuration/configuration
Linkerd ServiceProfile / HTTPRoute2018Buoyant → CNCF Graduated 2021CRD YAML; smaller surface than Istio by designActive; “the simpler mesh”; ServiceProfile + Gateway API HTTPRoute for traffic policyhttps://linkerd.io/2/reference/service-profiles/
Knative Serving / Eventing CRDs2018Google → CNCF IncubatingCRD YAML (serving.knative.dev/v1, eventing.knative.dev/v1, messaging.knative.dev/v1)Active; eventing CRDs regenerated in 2026 add EventTransform APIhttps://knative.dev/docs/eventing/reference/eventing-api/

Tier 3 family table — GitOps / observability / policy / cloud resources

FormatFirst appearedOriginTypeStatus (2026)URL
Argo CD Application + ApplicationSet2018Intuit / Applatix → CNCF Graduated 2022CRD YAML (argoproj.io/v1alpha1)Active; Argo CD 3.0 (2025/2026) adds real-time drift detection; Helm chart is the recommended install pathhttps://argo-cd.readthedocs.io/
FluxCD Kustomization + HelmRelease + GitRepository + OCIRepository2019 (Flux v1), 2021 (Flux v2 GA)Weaveworks → CNCF Graduated 2023CRD YAML (kustomize.toolkit.fluxcd.io/v1, helm.toolkit.fluxcd.io/v2, source.toolkit.fluxcd.io/v1)Active; the GitOps Toolkit’s composable reconciler modelhttps://fluxcd.io/flux/components/
Crossplane Composition + CompositeResourceDefinition (XRD)2018Upbound → CNCF Incubating (now Graduated track)CRD YAML; Crossplane v2 uses apiextensions.crossplane.io/v2, namespaced by defaultActive; v2 (2025/2026) drops Claims, simplifies the XRD scope modelhttps://docs.crossplane.io/latest/composition/composite-resource-definitions/
Cilium Tetragon TracingPolicy2022Isovalent → Cisco (Cilium project, CNCF Graduated 2023)CRD YAML mapping to eBPF kprobes / tracepoints / LSM hooksActive; the eBPF runtime-security DSL; supports kernel + userspace stack traces in Post actions (2026)https://tetragon.io/docs/concepts/tracing-policy/
Cilium NetworkPolicy / CiliumClusterwideNetworkPolicy2018Isovalent → CiscoCRD YAML; superset of K8s NetworkPolicy with L7, DNS, identity-based rulesActive; the dominant eBPF-native network-policy DSLhttps://docs.cilium.io/en/stable/security/policy/
Falco rules YAML2016Sysdig → CNCF Graduated 2024YAML rules/macros/lists evaluated against eBPF or kernel-module syscall streamActive; current v0.43.0 (January 2026)https://falco.org/docs/rules/
OpenTelemetry Semantic Conventions2021 (merger of OpenTracing + OpenCensus)CNCF (OTel Incubating, now Graduated track)Vocabulary spec for span/metric/log attributes; YAML “semconv” registry compiled to per-language SDKsActive; HTTP, RPC, gen-ai, and DB conventions reached stable in 2024–2026https://opentelemetry.io/docs/specs/semconv/
OpenSLO2021 (v1.0 in 2022)Nobl9 + communityYAML SLI/SLO/AlertPolicy resources, Kubernetes-compatible shapeActive; v1 split into SLI/SLO/AlertCondition/AlertPolicy/AlertNotificationTarget objectshttps://openslo.com/
CloudEvents2018 (v0.1), 2019-10-24 (v1.0)CNCF (incubating 2019, Graduated 2024-01-25)JSON / protobuf / Avro event envelope; HTTP, Kafka, AMQP, MQTT bindingsActive; spec stays at 1.0 series (1.0.2, 2022); community focus is now extensions, bindings, and CloudEvents SQL (v1 reached July 2024)https://cloudevents.io/

Notable threads

  • OCI’s three-spec triptych as the load-bearing foundation. From 2015 to 2024 OCI was “the boring foundation” — Image v1.0 had been frozen since 2017 — and then 2024 brought the simultaneous v1.1/v1.2/v1.1 bumps to image, runtime, and distribution. The single highest-impact change was the artifact manifest formalisation in image-spec v1.1: by adding a subject field and artifactType, OCI registries became general-purpose content-addressable stores for anything (Helm charts via application/vnd.cncf.helm.config.v1+json, SBOMs, cosign signatures, attestations), which obsoleted half a decade of registry-extension hacks. The runtime-spec v1.2 changes were smaller (CPU affinity, org.containers.image annotation, potentiallyUnsafeConfigAnnotations) but unblocked CDI and improved isolation reporting.

  • The four-pillar K8s extension model. Almost everything K8s does at runtime flows through four interfaces — CRI talks to the runtime (containerd, CRI-O); CNI configures the pod network (Cilium, Calico); CSI mounts storage (EBS, Ceph, Portworx); and CDI injects devices (NVIDIA GPUs, FPGAs). They have different shapes (protobuf for CRI/CSI, JSON+exec for CNI, JSON files for CDI) for historical reasons, but together they are why a Kubernetes node can be a pluggable substrate rather than a hard-coded Linux runtime. The 2020-2024 maturation of CDI was the missing leg: device plugins had been ad-hoc and runtime-specific, and CDI turned them into a declarative cross-runtime contract that containerd, CRI-O, and Podman now all honour.

  • The Helm vs Kustomize vs KCL/CUE config wars. Helm (Go templates over YAML) has the largest ecosystem but is criticised for “YAML that’s actually generated text” — easy to break with whitespace. Kustomize is the official Kubernetes “no templating, only declarative overlays” answer; it composes cleanly but lacks computation. KCL and CUE represent the modern typed-config wave: structured-config languages where schemas are first-class, computation is sound (CUE’s lattice gives commutative unification), and the output is still YAML/JSON. CUE v0.13’s eval-v3 evaluator was a major correctness/performance jump; v0.14 added cue get crd so CUE can directly consume Kubernetes CRD schemas. KCL hit CNCF Sandbox status and is increasingly used in Chinese cloud-native shops (Ant Group, Huawei) as the KusionStack default.

  • CRDs as Kubernetes’ universal extension language. Argo CD, FluxCD, Istio, Linkerd, Knative, Crossplane, Tetragon, Cilium, Falco, OpenSLO, KEDA — the entire cloud-native ecosystem is built as CRDs because the CRD model gives you typed YAML, OpenAPI v3 validation, optional CEL rules (graduated K8s 1.25), webhook conversion, and a reconciler loop for free. Validation ratcheting (2026) is the latest refinement: API server accepts updates that don’t worsen validation, which lets operators evolve schemas without breaking existing resources. This makes the CRD effectively the dominant typed-YAML language of the 2020s.

  • Service mesh DSL convergence on Envoy + Gateway API. Istio (VirtualService, DestinationRule, EnvoyFilter, Gateway) was the maximal expression; Linkerd ServiceProfile is the minimal one. The 2024-2026 trend is convergence on the Kubernetes Gateway API (HTTPRoute, GRPCRoute, TLSRoute) as the cross-mesh portable surface, with mesh-specific CRDs reserved for mesh-internal features. Envoy’s xDS API (LDS/RDS/CDS/EDS/ADS) remains the universal data-plane control protocol underneath — Istio, Consul, App Mesh, and even gateways like Emissary and Contour all speak xDS to Envoy.

  • eBPF-native runtime security as a YAML DSL. Cilium Tetragon’s TracingPolicy CRD is the most powerful example: you declare kprobe/tracepoint/LSM-hook attachment points, filter expressions, and selectors (process, namespace, capability) in YAML, and Tetragon compiles that to eBPF programs that run in-kernel with near-zero overhead. Falco rules YAML occupies a similar niche but with a higher-level expression language (evt.type / proc.name / fd.name macros). The 2026 trend: TracingPolicy moving from “observability” to “enforcement” (block-on-match via Override/Sigkill actions), bringing kernel-level policy enforcement into the same declarative GitOps loop as everything else.

  • GitOps DSL split: Argo CD vs FluxCD. Both are CNCF graduates, both reconcile from Git/OCI to cluster state, but they made different DSL choices. Argo CD: monolithic Application and ApplicationSet CRDs with a polished web UI and AppProjects for RBAC. FluxCD: composable Toolkit (GitRepository/OCIRepository/Bucket → Kustomization/HelmRelease → notification controllers) with no first-party UI. The split tracks audience — Argo CD wins with platform teams that want a dashboard, Flux wins with infrastructure teams that want pure-YAML composability. Both increasingly pull from OCI registries (the OCIRepository source) because OCI v1.1 made artifact storage so good.

  • CloudEvents as the universal event envelope, post-graduation. CloudEvents reached CNCF Graduated status on 2024-01-25 after locking the v1.0 spec in 2019. The community deliberately chose not to make a “v2” — instead, all new work is extensions (Distributed Tracing, Partitioning, Auth Context) and bindings (Kafka, NATS, MQTT 5, AMQP). CloudEvents SQL v1 (July 2024) added a query language over event streams. This is the rare CNCF success story of a small spec staying small and being widely adopted across AWS EventBridge, Azure Event Grid, Google Eventarc, Knative Eventing, and Argo Events.

Citations

Graph View