Madhuopen lab

§6 Learn · a course

The Kubernetes Ninja Path

Thirty-five posts for an engineer coming back to work after time away, who remembers basic Linux and nothing else.

35 chaptersabout 15 hours243 recall cardsnot startedBegin chapter 1 →

Track 1 — Kubernetes from the ground up

01From Containers to Kubernetes — Why Orchestration ExistsImagine an airport with one runway and one person on the tarmac, waving flags to guide a single plane in and out. That works fine for a tiny airstrip. Now picture Heathrow: hundreds of planes, dozens of gates, constant delays and reroutes. You can't run that with one person and two flags. You need a control tower watching everything at once, all the time, and adjusting as things change. That's the exact same leap we're making in this post — from running one container by hand to running a whole fleet of them with Kubernetes.6 min read 02Kubernetes Architecture — Control Plane, Nodes, and How They TalkQuick recap from Post 1: Kubernetes constantly checks what's actually happening in your cluster against what you asked for, and fixes any gap it finds. That's the whole game. But something has to do that checking, and something has to actually run your containers. Today we open the hood and meet the real pieces that do this work — and by the end, you'll point at each one running live on your own minikube cluster.6 min read 03Pods — The Smallest Deployable UnitIn Post 2, you learned the kubelet runs containers because the API server tells it to. Here's the twist: the kubelet never actually runs a bare container. It runs something called a Pod. What is a Pod, and why does Kubernetes bother with this extra layer?6 min read 04ReplicaSets & Deployments — Self-Healing, Scaling AppsYou already know a Pod can die and nobody will notice until your users do. Time to fix that with the two objects you'll actually use every single day in Kubernetes.6 min read 05Services & Networking — How Pods Find Each OtherImagine calling a company and getting a different phone number every time: Monday it's an intern's cell phone, Tuesday a desk phone three rooms over, Wednesday that person already quit. You'd never get through. Kubernetes has this exact problem. Every time a Deployment replaces a pod, the replacement shows up with a brand new IP address. So how does your frontend pod reliably reach "the backend" when its address keeps changing under it? That's what we solve today.6 min read 06ConfigMaps & Secrets — Managing App ConfigurationSomewhere in your app's code right now there's probably a line like const dbHost = "prod-db.internal". It made sense the day you wrote it. It's been quietly causing pain ever since. Let's fix that the Kubernetes way.5 min read 07Volumes & Persistent StorageQuick check: if a container restarts right now, does the file it just wrote survive? What if the whole Pod gets rescheduled to a different node? The answers are "sometimes" and "no" — knowing exactly why is the line between a toy app and one that can run a real database.5 min read 08Namespaces, Labels, Selectors & Organizing a ClusterSo far, every Pod, Deployment, and Service you've created has lived in one shared space. That's fine when you're the only one using the cluster. A real cluster hosts several teams and several environments on the same hardware, at the same time. It needs three things: walls to keep things apart, tags to describe what things are, and a way to find things by tag. That's this whole post.5 min read 09Scheduling, Health Probes & Resource ManagementBack in Post 2, we called the kube-scheduler "the dispatcher" and left it at that. Time to open that box: how does it know a node has room, what happens when a container uses more than it's allowed, and how does Kubernetes know a running container is actually okay? Same idea underneath all three: Kubernetes never just trusts your app to be fine — it checks.6 min read 10Ingress & Load Balancing — The Front Door to Your ClusterPicture a mall where every store — the shoe shop, the electronics store, the food court stall — insisted on its own separate building, street entrance, and parking lot. You'd need twenty addresses memorized for one afternoon of errands. That's what you're doing right now exposing twenty microservices with twenty LoadBalancer Services. There's a saner way to run a mall, and a saner way to run a cluster. Let's fix it.6 min read 11RBAC & Security Basics — Who Can Do WhatBack in Post 2, you met the kube-apiserver as the front door everything talks through. But a front door with no lock isn't security, it's just a hallway. Today you're installing the lock: who's allowed through this door, and once they're in, what are they actually allowed to touch?6 min read 12Helm — The Package Manager for KubernetesYou've hand-written Deployments, Services, ConfigMaps, PVCs, Ingress rules, and RBAC objects. Now imagine doing that for one real application, times three environments, every single time you deploy. There's a better way — and you already know the pattern. You've been using it since your first day on Linux.5 min read 13StatefulSets, Jobs & CronJobs — Beyond Stateless AppsSo far, every Pod you've deployed has been a clone — a Deployment can kill any Pod and replace it with an identical twin, and nothing breaks. But some workloads don't work that way. What if Pod-0 is the leader of a database cluster, holding data that Pod-1 and Pod-2 don't have? A Deployment has no concept of "this specific Pod matters." This post covers the three workload types built for exactly that case.6 min read 14Troubleshooting Like a Ninja, Tooling, Microservices & Your CKA Exam PlaybookThirteen posts ago you barely remembered what a container was. Since then you've built a mental model of the control plane, deployed Pods, wired up Services and Ingress, locked things down with RBAC, packaged releases with Helm, and run StatefulSets and Jobs. Today isn't a new object to learn — it's turning everything you've read into reflexes, and pointing those reflexes straight at the CKA exam.8 min read 15Lens & FreeLens — Making Kubernetes VisualPost 14 mentioned Lens in two sentences and moved on, because the exam doesn't care about it. Your job does. This post is the deep dive that was missing: what Lens actually shows you, why the tool split into three names in the last few years, and the exact daily workflows where a GUI beats fifteen years of muscle-memory kubectl — without ever replacing it.9 min read 16Kubernetes Interview Questions — The Concept ReferenceThis isn't a fifteenth lesson — it's the drawer you pull open the night before an interview. Every answer below is deliberately short: the goal is to jog the full mental model you already built in Posts 1–15, not re-teach it. Where a topic needs more than three sentences to actually understand, the answer points back to the post that already did that work. Read this one straight through once, then skim it again the morning of.14 min read 17Kubernetes Troubleshooting & Scenario Interview QuestionsPost 16 covered the vocabulary. This one covers the actual interview moment that trips up people who only studied definitions: "Walk me through how you'd debug this." A returning engineer's biggest edge here isn't remembering more facts than a newcomer — it's already having the calm, ordered instinct for where to look first. Post 14 built that instinct. This post rehearses it against the specific scenarios interviewers reach for most in 2026.12 min read

Track 2 — OpenShift, EKS and the platform job

18The Job Decoded: OpenShift Platform Engineer at a BankThe requisition says "OpenShift Support Engineer." The bullets underneath describe a different job: upgrade production clusters, design EKS landing zones, write Terraform, run GitOps, remediate vulnerabilities, lead incident response. That is platform engineering with a modest title, and the interview will be graded like one. This post turns the job description into a study map for Posts 19–35, explains how a vendor-to-bank interview loop runs, and gives you the regulated-environment vocabulary that separates "has used OpenShift" from "has operated OpenShift for a bank." By the end you will know what every JD line is really asking, which post answers it, and the 25 questions to have ready before you walk in.15 min read 19OpenShift Architecture: What Red Hat Adds on Top of KubernetesYou already know Kubernetes: pods, deployments, services, RBAC, ingress, the whole of Posts 01–17. OpenShift is that same Kubernetes, but wrapped in an opinionated, supported, integrated platform where the operating system, the container runtime, the networking, the registry, the login flow, the monitoring stack and the upgrade path all ship together and are all managed by the cluster itself. Interviewers for an OpenShift platform role rarely ask "what is a pod?" They ask "where does Kubernetes end and OpenShift begin?", and they listen for whether you can name the pieces Red Hat added, why they exist, and which command you type first when one of them breaks. After this post you will be able to draw the OpenShift 4 stack on a whiteboard, read oc get co like a dashboard, walk through the openshift-* namespaces, describe a bank-scale reference architecture out loud, and translate any Kubernetes concept into its OpenShift equivalent in one sentence.28 min read 20Cluster Lifecycle: Nodes, MachineConfig, Upgrades and etcdTwo bullets on the job description decide whether you're a platform engineer or someone who deploys apps onto a platform: "perform cluster upgrades, patching, lifecycle management and platform maintenance" and "manage MachineConfig". Every interviewer for this role will ask some version of "walk me through upgrading production" and "how do you back up and restore etcd", and they'll listen for whether you've done it under a change ticket with a rollback plan or only read about it. After this post you'll be able to describe, in order and with the exact commands, how you'd upgrade a production OpenShift cluster at a bank, how you'd change the operating system on 200 nodes without ever typing ssh, and what you'd do at 3 a.m. when etcd has lost quorum.30 min read 21OpenShift Networking and Storage, End to EndPull the ticket queue of any bank's OpenShift platform team and two titles dominate: "my route returns 503" and "my pod can't reach the database". A third, "my PVC is stuck Pending", is not far behind. None of these are hard once you have an ordered method and know which OpenShift-specific object sits at each hop. This post gives you that map: OVN-Kubernetes underneath every pod, the Ingress Operator and its HAProxy routers, Routes and their three TLS modes, cluster DNS, NetworkPolicy and egress control the way a regulated environment actually uses them, and then the storage side: CSI, OpenShift Data Foundation, the platform components that quietly need disks, and the storage failures you will be paged for. By the end you will be able to walk an interviewer from a browser to a pod, and from a pod to a Ceph OSD, naming the command you would run at every step.30 min read 22OpenShift Security: SCCs, RBAC, OAuth and HardeningThe first thing almost every developer hits on OpenShift is a pod that refuses to start with a message about running as root. The second thing they do is open a ticket that says "please give my app the privileged SCC". How you answer that ticket, calmly and with a better option, is most of the job of an OpenShift platform engineer at a bank. This post gives you the whole security stack in the order an interviewer will ask about it: Security Context Constraints in real depth (the single most-asked OpenShift topic), how to make images that just work under the default policy, Pod Security Admission and how OpenShift bridges it to SCCs, the OAuth server and LDAP/Active Directory integration, RBAC with OpenShift's default roles, secrets and etcd encryption, and the hardening switches you turn on a regulated cluster. By the end you can explain "why won't my container run as root" in thirty seconds, fix it in five minutes, and describe the governance around it like someone who has owned a production platform.28 min read 23Operators and OLM: How OpenShift Extends ItselfAsk an OpenShift administrator what they did today and the answer almost always contains the word "operator". The ingress controller they tuned, the logging stack they upgraded, the cert-manager install that sat in Pending for an hour, the storage cluster that refused to follow the cluster to the next minor: every one is an operator, and the machinery that installs, upgrades and heals them is the Operator Lifecycle Manager. The job description compresses this into "manage OpenShift Operators". In practice it means knowing six API objects by heart, having an ordered method for the ways an install gets stuck, and explaining how a bank decides which operators are allowed on the cluster at all. After this post you can do all three, with the exact commands.22 min read 24Monitoring and Logging: Prometheus, Alertmanager, Loki and InsightsAt a bank, the sentence "we didn't get an alert" is not an excuse in a post-incident review. It is a finding, with an owner and a due date, and the owner is the platform team. Monitoring and logging on OpenShift are not something the app teams bolt on later; they are platform services you run, size, secure and are paged for. This post takes you through the whole stack as it ships in OpenShift 4.14–4.19: the built-in Prometheus and Alertmanager, user workload monitoring for app teams, the alerts you page on and the PromQL you read at 3 a.m., Loki-based logging with ClusterLogForwarder pipelines into Splunk, API audit logs as a compliance control, and the rest of the observability family (Insights, Network Observability, tracing). By the end you'll be able to explain each piece, configure it from YAML, troubleshoot the stack itself, and describe how it supports incident response in a regulated environment.28 min read 25The OpenShift Troubleshooting Playbook and Incident ResponseThe job description for this role says two things in plain language: "comfortable leading troubleshooting efforts and supporting critical production environments" and "production incident response, root cause analysis." Every other post in this track teaches you a subsystem. This one teaches you what to do at 2 a.m. when the payments team says the platform is broken and a director is on the bridge. By the end you will have a single ordered method you can state in one sentence, the exact commands for each layer, ten worked incidents with their root causes, and the vocabulary a bank uses to run an incident from first page to postmortem. That combination is what separates a candidate who has read about OpenShift from one who has been on call for it.32 min read 26Onboarding Application Teams: Projects, Quotas and Golden PathsA cluster that only the platform team knows how to deploy to is a science project, not a platform. A bank runs hundreds of application teams, and every one of them has to land on OpenShift the same way: through a request that leaves an audit trail, into a project that already carries the right guardrails, using a deployment pattern that passes every policy on the first try. This post walks the whole path from intake form to first deploy. After it you will be able to describe the onboarding workflow end to end, name the exact objects the platform stamps into every project, defend the defaults with numbers, and explain how a "golden path" lets a team ship without ever filing a ticket that says "please give me root".24 min read 27Amazon EKS Part 1: Architecture, Networking and IAMThe job description asks for two things that rarely live in one person: someone who can run Red Hat OpenShift on-prem, and someone who can "design, deploy, and manage Amazon EKS clusters" with the "networking, IAM integration, security controls" that a bank needs in AWS. The interviewer will not ask you to recite the EKS console. They will probe one question in ten different shapes: do you know exactly what AWS manages, what you manage, and where the seam is? You used EKS years ago. Since then, access entries replaced aws-auth, Pod Identity arrived next to IRSA, Karpenter replaced Cluster Autoscaler on most teams, and EKS Auto Mode appeared. This post brings you current and leaves you able to draw a bank-grade EKS platform on a whiteboard: VPC, subnets, CNI, data plane, authentication, pod IAM, add-ons, ingress, DNS, storage, and the OpenShift-to-EKS translation the interviewer is really testing.30 min read 28Amazon EKS Part 2: Operations, Upgrades, Security, Observability and CostCreating an EKS cluster takes about fifteen minutes and one Terraform apply. Running that cluster for three years, through nine Kubernetes versions, a hundred AMI patches, three audits and a regulator's visit, with zero customer-visible downtime: that is the job the JD is describing. Post 27 gave you the architecture, the VPC CNI and the IAM model. This post is day two onward: who owns what, how an upgrade really goes, how nodes live and die, which security controls a bank's auditors will ask you to prove, how you see what the cluster is doing, what it costs, and how you argue for the platform's next step. After reading it you will be able to walk an interviewer through a bank-grade EKS upgrade from change ticket to rollback plan, name the AWS service behind every line of the security checklist, and answer "the pods can't get IPs" without a pause.28 min read 29Terraform for Platform Engineers: State, Modules, EKS and PipelinesIn a bank, nobody clicks in the console. If a VPC, an IAM role or an EKS cluster is not described in Terraform, reviewed in a pull request and applied by a pipeline with an approval record, then as far as the auditors are concerned it does not exist. You have used Terraform before, so this post does not teach you what a resource block is. It makes you interview-sharp on the four things a platform team actually gets grilled on: state, modules, the EKS and OpenShift specifics, and the pipeline that turns a PR into infrastructure. By the end you will be able to sketch a complete EKS build on a whiteboard, explain exactly where state lives and why, and describe a Terraform pipeline that would pass a change-management audit.26 min read 30CI/CD for Containers and GitOps with Argo CDYou have built Jenkins and GitHub Actions pipelines before, so this post does not teach you what a stage is. It teaches the two things the JD is really asking about: how a pipeline builds and proves a container image (scan, SBOM, signature, immutable tag), and how GitOps with Argo CD makes a cluster match Git instead of letting a pipeline push whatever it wants. A bank loves GitOps for one reason above all: every production change becomes a reviewed commit with an audit trail, and the cluster corrects itself when someone drifts from it. After this post you can draw the Argo CD architecture on a whiteboard, write an Application and an ApplicationSet from memory, explain sync waves versus hooks, handle secrets without ever committing one, and debug an app that is stuck OutOfSync.26 min read 31Security, Compliance and Hardening for a Regulated PlatformIn a bank, the platform team is audited. Internal audit, external auditors and the regulator all ask the same three questions about every control on the cluster: who owns it, where is the evidence it works, and how fast is it fixed when it fails. Post 22 gave you the OpenShift mechanisms (SCCs, RBAC, OAuth) and Post 28 the EKS controls. This post is the program-level view above both: threat model, frameworks, the hardening checklist, a vulnerability lifecycle you can run, image standards, admission policy, secrets, audit logging, compliance automation, governance and security incident response. Interviewers listen for whether you speak the language of controls, evidence and SLAs. After this post, you will.26 min read 32Automation for Platform Ops: Python, Shell, Ansible and the Kubernetes APIEvery platform JD now carries the phrase "automation-first mindset", and every interviewer has a version of the same question: "Tell me about something you automated." A vague answer ("I wrote some scripts") loses the round; five specific answers with a measurable result each win it. You already write Python and shell. This post turns that into a portfolio of platform automations you can describe from memory: a cluster health check, a pre-upgrade gate, a compliance report, a quota report, a certificate-expiry alert, plus the scheduling, RBAC and engineering habits that make an interviewer believe you have run these in a regulated production environment. All the code is real enough to put in a repo tonight.22 min read 33OpenShift, EKS, Terraform and GitOps Interview Question BankThis is the drawer you open the night before. Posts 19–32 did the teaching; this post compresses the whole track into roughly 175 questions with answers written the way a strong candidate says them out loud: a one-line definition, the object or command that proves you have done it, and the bank angle where it matters. Use it in two passes. First, read straight through once and mark every answer you could not have produced yourself; those marks tell you which post to reopen. Second, on the morning of the interview, skim only the "Ten interview traps" section at the end. It is the final checklist of the mistakes that separate people who have operated a platform from people who have read about one. Everything here assumes the Kubernetes reference in Post 16; nothing from Track 1 is repeated.35 min read 34Scenario Interviews: OpenShift and EKS Production IncidentsPost 33 gave you the vocabulary. This post is the round that actually decides the offer for a platform role at a bank: the interviewer describes a symptom from a real pager and says "walk me through it." They are not checking whether you know the fix. They are checking whether you have an ordered method, whether you mitigate before you investigate, whether you confirm before you act, and whether you close every story with prevention. After this post you will have 38 rehearsed scenarios across OpenShift, EKS, Terraform, Argo CD and security, each with the commands, the likely root causes, and the sentence that turns a fix into an RCA.30 min read 35Behavioral Round: STAR Stories, the Bank Context and Questions to AskThe technical rounds decide whether you can do the job. The behavioral round decides whether they want you on the bridge call at 2 a.m., whether they trust you with a change ticket against a cluster that clears payments, and whether application teams will enjoy being onboarded by you. At a bank there is a third thing being graded that most candidates miss: process discipline. Every story you tell is listened to for evidence that you follow change management when nobody is watching, write things down, and stay calm while a Sev-1 is open. This post gives you a STAR format that fits in two minutes, twelve story prompts mapped to the job description, dignified answers for the awkward questions, twelve questions that make you sound like the senior person in the room, and a plan for the day itself.17 min read