5.1 Kubernetes Distributions, Installation Tools & Managed Services

5.1 Kubernetes Distributions, Installation Tools & Managed Services

Quick Answer: Kubernetes is upstream source code, not a product you install. You obtain a cluster either by building one (kubeadm, kubespray, Cluster API), by running a distribution (K3s, MicroK8s, OpenShift, Rancher), by spinning up a local sandbox (minikube, kind, k3d), or by renting a managed control plane (EKS, GKE, AKS). The CNCF Certified Kubernetes Conformance Program is what guarantees your manifests behave the same on all of them.

KCNA asks this from the platform-literacy angle: given a scenario — a laptop demo, an edge site, a regulated data centre, a startup with no platform team — which option fits, and who is responsible for what?

---

1. Certified Kubernetes Conformance

Before the options, the standard that unites them. The CNCF Certified Kubernetes Conformance Program runs an open-source test suite (Sonobuoy executes the upstream conformance tests) against a candidate platform. Passing means:

• All required Kubernetes APIs are present and behave as specified.
• No proprietary API has been substituted for a standard one.
• The vendor may use the Kubernetes trademark and the "Certified Kubernetes" mark.
• Certification is per minor version, and vendors must recertify to stay listed.

This programme is the practical meaning of "no vendor lock-in" in the cloud native world: a Deployment written against GKE applies unchanged to OpenShift or K3s. Over 100 vendors maintain certified offerings.

---

2. Local and Development Clusters

None of these are production tools — a single-node cluster has no failure domain, no HA control plane, and no real storage.

---

3. Building a Self-Managed Cluster

kubeadm

kubeadm is the upstream, officially supported way to bootstrap a conformant cluster. It generates certificates, writes the control plane as static Pods into /etc/kubernetes/manifests, configures kubelet, and issues join tokens for worker nodes.

# On the first control plane node
kubeadm init --pod-network-cidr=10.244.0.0/16

# On each worker
kubeadm join 10.0.0.10:6443 --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash>

What kubeadm deliberately does not do is a favourite exam point: it does not install a CNI plugin. Immediately after kubeadm init, nodes report NotReady and CoreDNS sits Pending, because there is no Pod network. You must apply Calico, Cilium, Flannel, or another CNI yourself. kubeadm also does not install an Ingress controller, a storage driver, or a monitoring stack — it deliberately stops at a minimum viable cluster.

Other Build Paths

• kubespray — Ansible playbooks that install and manage production clusters across bare metal and clouds.
• Cluster API (CAPI) — a CNCF project that manages clusters as Kubernetes objects, so a management cluster declaratively provisions and upgrades workload clusters. This is the modern GitOps-friendly answer to fleet management.
• kOps — an opinionated tool for building and maintaining production clusters, historically strongest on AWS.

---

4. Lightweight and Edge Distributions

These matter for KCNA because the exam frames cloud native as spanning public, private, hybrid, and edge environments — a full control plane is not viable on a retail store's gateway device.

---

5. Enterprise Distributions

Red Hat OpenShift, SUSE Rancher, VMware Tanzu, and Mirantis Kubernetes Engine package upstream Kubernetes with an opinionated set of additions: an integrated registry, a build system, developer consoles, hardened security defaults (OpenShift enforces non-root containers via SecurityContextConstraints), multi-cluster management, and commercial support. They are conformant, so standard manifests work — but they add proprietary CRDs (Route, BuildConfig, DeploymentConfig) that do not exist elsewhere.

---

6. Managed Kubernetes and Shared Responsibility

Amazon EKS, Google GKE, Azure AKS, and their peers run the control plane as a service. The single most important idea is the responsibility split:

┌───────────────────────────────────────────────────────────┐
│  CLOUD PROVIDER OWNS                                      │
│  • kube-apiserver, etcd (backup, HA, patching)            │
│  • kube-scheduler, kube-controller-manager                │
│  • control plane availability SLA and version upgrades    │
├───────────────────────────────────────────────────────────┤
│  YOU OWN                                                  │
│  • worker node pools, node OS patching, node autoscaling  │
│  • workloads, RBAC, NetworkPolicies, Secrets hygiene      │
│  • deciding when to trigger node upgrades                 │
│  • cost, quotas, and the add-ons you install              │
└───────────────────────────────────────────────────────────┘

Managed offerings usually also provide a serverless node option (EKS Fargate, GKE Autopilot, AKS virtual nodes) that removes worker-node management as well, at a higher per-Pod price and with tighter constraints on privileged workloads and DaemonSets.

---

7. Choosing