KCNA: Kubernetes & Cloud Native Associate

What is the KCNA?

The Kubernetes and Cloud Native Associate (KCNA) exam is a pre-professional certification designed to test foundational knowledge of Kubernetes and the wider cloud-native ecosystem.

Unlike the practical CKA or CKAD, the KCNA is a multiple-choice exam consisting of 60 questions in 90 minutes.

KCNA Exam Domains

1. Kubernetes Fundamentals (46%)

- Core API primitives (Pods, Deployments, Services, ConfigMaps, Secrets, PVs/PVCs)

- Cluster architecture (Control Plane, Nodes, etcd, kube-apiserver, kubelet, container runtimes)

1. Container Orchestration (22%)

- Container orchestration basics (scaling, high availability, scheduling)

- Container runtimes (CRI, containerd, Docker shim history)

1. Cloud Native Architecture (16%)

- CNCF fundamentals (graduation levels, landscape areas)

- Serverless, cloud-native storage, and networking concepts

1. Cloud Native Observability (8%)

- Logging, metrics, tracing (Prometheus, OpenTelemetry)

1. Cloud Native Application Delivery (8%)

- GitOps concepts, CI/CD, Helm package management

Visualizing CRI Architecture

The Container Runtime Interface (CRI) abstractly decouples the Kubelet from the underlying container execution engines. Below is the workflow from API invocation down to container initiation:

+------------------+
|     Kubelet      |
+--------+---------+
         |
         | gRPC API (over UNIX Domain Socket)
         v
+------------------------------------+
| CRI Engine (containerd or CRI-O)  | <--- Manages Pod Sandbox, pulls images,
+--------+---------------------------+      networks setup, mounts volumes
         |
         | OCI Specification (JSON bundle)
         v
+------------------+
| OCI runc / crun  | <--- Lightweight CLI tool that executes container actions
+--------+---------+
         |
         | Linux Kernel system calls (clone, setns, unshare, pivot_root)
         v
+------------------------------------------+
| Linux Kernel (namespaces & cgroups v2)   | <--- Resource containment & isolation
+------------------------------------------+

Visualizing CNCF Project Maturity Funnel

Projects advance through the CNCF landscape based on strict adoption, governance, and stability criteria:

  +--------------------------------------------+
  |              CNCF Sandbox                  |  <-- Experimental, low barrier of entry,
  |  (e.g., Kube-vip, Cluster API, Radius)    |      intellectual property transferred.
  +--------------------+-----------------------+
                       |
                       v
  +--------------------+-----------------------+
  |             CNCF Incubating                |  <-- Production ready, healthy governance,
  | (e.g., Keda, Thanos, Dapr, Cilium, Knative) |      documented production adoption.
  +--------------------+-----------------------+
                       |
                       v
  +--------------------+-----------------------+
  |              CNCF Graduated                |  <-- Industry standards, high security bar,
  |  (e.g., Kubernetes, Prometheus, Helm, OTel) |      mature governance, multiple org maintainers.
  +--------------------------------------------+

Deep-Dive: Cloud Native Internals & the CNCF Landscape

#### 1. Container Runtime Interface (CRI) & OCI

Historically, Kubernetes communicated directly with Docker via the hardcoded dockershim inside the Kubelet. As other runtimes like CoreOS's rkt emerged, the community established the Container Runtime Interface (CRI) in Kubernetes v1.5. The CRI is a gRPC API specification comprising two primary services:

• RuntimeService: Manages the pod sandbox lifecycle (e.g., setting up namespaces, network interfaces) and container execution.
• ImageService: Manages pulling, storing, listing, and removing container images.

When the Kubelet schedules a Pod, it issues gRPC calls to the CRI runtime socket (e.g., unix:///run/containerd/containerd.sock). The CRI runtime (e.g., containerd, CRI-O) translates these instructions into filesystem structures conforming to the Open Container Initiative (OCI) runtime specification, and invokes an OCI-compliant runtime like runc or crun to spin up the actual Linux processes.

#### 2. CNCF Project Maturity Framework

The Cloud Native Computing Foundation (CNCF) organizes projects into three tiers to guide adopters on stability and production-readiness:

• Sandbox: A playground for experimental, promising technologies. Requires minimal validation.
• Incubating: Demonstrates solid production use cases, clear governance, a growing contributor base, and has undergone a formal security audit.
• Graduated: The gold standard. Must meet all incubating criteria, have multiple major organizations committing code, show vast production deployment scale, and pass a rigorous third-party security audit.

#### 3. Cloud Native Observability & OpenTelemetry (OTel)

Telemetry collection has evolved from fragmented agent architectures to a standardized approach via OpenTelemetry (OTel). OTel merges OpenTracing and OpenMetrics. The observability stack features three pillars:

• Metrics: Numeric values representing system performance over time (CPU utilization, HTTP error counts). Typically gathered pull-style by Prometheus.
• Logs: Timestamped lines of text representing structured or unstructured events. Collected via tools like FluentBit or Vector.
• Traces: End-to-end latency breakdowns representing a request traversing microservices (spans).

The OTel Collector pipeline consists of:

1. Receivers: How data gets into the collector (pull or push; e.g., OTLP, Prometheus, Jaeger protocols).
2. Processors: How data is mutated, batched, filtered, or scrubbed of PII.
3. Exporters: Where data is sent (e.g., Prometheus remote-write, Elasticsearch, Jaeger).

#### 4. GitOps & Cloud Native Application Delivery

GitOps is a paradigm where git repositories are the single source of truth for declarative infrastructure. A reconciliation loop compares the desired state in Git with the running state in the cluster.

• Pull-Based GitOps: An agent inside the cluster (e.g., ArgoCD or Flux) continuously monitors Git and pulls changes. This is highly secure, as credentials to modify the cluster do not leave the cluster.
• Push-Based GitOps: A traditional CI/CD pipeline (e.g., GitHub Actions, GitLab CI) triggers on a git push, executing kubectl apply using external cluster credentials. This is easier to set up but introduces a wider security perimeter.