CKA (Certified Kubernetes Administrator)
FHG University prepares you for this exam on the Infrastructure track. Here are the modules mapped to its published objectives, and the opening of one to read now.
Examination preparation — these exams are set and awarded by their issuers. FHG prepares you for them and cannot grant them.
The modules mapped to it
7 modules · about 12 h 15 min estimated in all
Bare Metal to Kubernetes: A Migration Field Guide
Decide whether Kubernetes earns its operating cost, then build and run a self-managed cluster the way the CKA’s Cluster Architecture, Installation & Configuration domain expects: infrastructure prep, kubeadm with a highly available control plane, CNI, load balancing and storage on bare metal, Helm, Kustomize and operators, RBAC, and the etcd, upgrade and certificate lifecycle. It closes with a staged migration path and a free kind-based lab.
Decide Whether Kubernetes Earns Its Cost
Start with the situation, not the platform. A team asks to "move to Kubernetes" because deployments are slow, servers are snowflakes, or a vendor ships its product as a Helm chart. Each of those is a real problem, but only some of them are Kubernetes problems. Kubernetes orchestrates many independently deployable containers: it schedules them onto nodes, restarts them when they fail, rolls out new versions gradually, and gives them stable network names. On bare metal you also become the operator of everything a cloud provider would otherwise run for you: the control plane, etcd, load balancing, storage and upgrades.
Gather evidence before deciding. Useful evidence is the team's own records: how many separately deployed services exist, how often each ships, how often a deploy causes an outage, how much load varies across a day or season, and who will be on call for the platform itself.
| Signal in your records | Points toward Kubernetes | Points toward well-automated VMs |
|---|---|---|
| Number of independently deployed services | Many, owned by different teams | A few, often one monolith |
| Release frequency | Frequent releases that need gradual rollout and fast rollback | Scheduled releases that tolerate a maintenance window |
| Load pattern | Varies enough that adding and removing replicas saves real capacity | Stable and predictable |
| Platform staffing | People who can own upgrades, etcd, networking and storage | No one with time to run a control plane |
| Vendor packaging | Key software ships as container images or Helm charts | Key software is supported only on specific OS builds |
The reasoning: Kubernetes trades a large fixed operating cost for lower per-service effort. That trade pays when there are enough services and enough change to spread the fixed cost across. There is no published service count where the line falls, so treat the table as a structured conversation, not a score. If most answers sit in the right-hand column, configuration management (Ansible, systemd units, a CI/CD pipeline and golden images) may serve the business better, with far less to operate.
The action is a written decision: which workloads move, which stay on VMs, who owns the platform, and what would make you revisit the call. The limit: this table cannot tell you how hard a specific application will be to containerize. That only shows up when you try, which is why the migration path later in this module starts with one low-risk service.
Members · the rest of this module
You’ve read 1 of 10 sections.
Members read the rest of this module and every module listed above, in their track’s order, and each one they finish is logged in hours with a content outline. $25 a month, cancel any time.
Already a member? Sign in, then pick up from your dashboard.
Add FHG to how you study. Keep every hour on record.
Members keep a record of the modules they finish and the study time each one takes.
Preparation means the material maps to the published objectives. It is not a promise of a pass, and Linux Foundation / CNCF sets, administers and awards the exam.