Supercourse - Ultimate Advanced Kubernetes Bootcamp

Following URL points to the Lab Guide used throughout this course. Its an essential supporting document, which contains step by step instructions, just as you see in the demo videos.  Once you go through the demo videos, you could practically perform the tasks using this guide.

https://schoolofdevops.github.io/kubernetes-labguide/

Note:  You may notice discrepancy between instructions shown in the video lessons vs what you see in the Lab Guide. In such cases, always trust the lab guide as its been updated to support the newer versions of kubernetes, and also has many fixes.  You may also find new labs available in the lab guide for which I am planning to create video lessons. Treat the Lab Guide as the ultimate source of truth ! 

Docker and Docker Compose run your containers well, but only on a single host. Here you will see why that breaks down once you move to staging and production across many servers, and why manually tracking resources and scheduling on each machine does not scale. After this you will understand what a container orchestration engine actually solves: turning a pool of servers into one cluster you submit jobs to, with scheduling handled for you.

Compare the three main container orchestration engines: Docker Swarm, Kubernetes, and Apache Mesos with Marathon. You will learn where Swarm fits for quick, simple setups, why Mesos suits mixed workloads like Spark and cron jobs, and how Kubernetes pulls ahead on features and production use. By the end you will know why Kubernetes became the industry standard and when the other tools still make sense.

Clustering and scheduling are the core, but a good orchestration engine gives you much more out of the box. You will walk through the features that make Kubernetes powerful: dynamic provisioning, horizontal scaling with the pod autoscaler, built-in load balancing, fault tolerance at container and node level, and release strategies like rolling updates, canary, and blue-green. After this you will know what container-as-a-service really buys you before writing any config.

Kubernetes came out of Google's own cluster manager, Borg, and carries years of running infrastructure at scale. You will learn what makes it the default choice: it is battle-hardened in large production clusters, it works with multiple container runtimes, and it is open enough for tools like OpenShift to build on top. By the end you will understand why its huge community and integration points make it worth learning.

Kubernetes is powerful, but that power comes with real complexity. You will look at its honest downsides: setting up a cluster from scratch is still moderately hard, and the non-native interface means learning kubectl, new YAML specs, and new concepts instead of reusing Docker commands like you would with Swarm. After this you will have a balanced view of the learning curve and know why tools like kubeadm and managed services now soften it.

Namespaces let you partition one cluster into separate logical spaces, usually one per project. You will see how the control plane turns a pool of nodes into a single cluster interface, and how switching namespaces gives you a focused view of only that project's pods and services. After this you will know how to split workloads cleanly and apply network policies and resource quotas per namespace.

The unit of deployment in Kubernetes is the pod, not the container. You will learn the difference, why running two apps in one container is an anti-pattern, and how a pod co-locates containers on the same host while sharing the network namespace, hostname, and volumes but keeping process and filesystem isolation. Using an nginx-and-sync example plus a real pod spec, you will know when to use one container per pod and the rare cases for more.

Running bare pods in production is risky, so you use controllers on top of them. You will learn how replication gives you high availability, horizontal scaling, and self-healing through labels and selectors, why replica sets replaced the older replication controller, and how deployments add update strategies like rolling updates with batch size and surge control. After this you will know why deployment is the primitive you reach for and how it ties replica sets and update strategy together in code.

Pod IPs change every time you update, so hardcoding endpoints between apps falls apart fast. You will learn how a Kubernetes service gives you one stable cluster IP and DNS name that always points to the right pods using labels and selectors, and how it load-balances traffic across them. By the end you will know how to expose apps with NodePort, cloud load balancers, and ingress controllers for layer-7 routing, plus how to point a service at external endpoints outside the cluster.

Take a real five-tier application stack and map it onto Kubernetes step by step. You start by carving out a namespace for your project, adding resource quotas and network policies, then deploy your workloads with a deployment instead of raw pods so replica sets handle replication, availability, and rolling updates. After this you will know how to wire up service discovery and expose apps with a service, and when a service is not needed at all.

Go beyond deployments and pick up the supporting pieces you need in real clusters. You will learn when to inject configuration with ConfigMaps versus encrypted Secrets, how persistent volumes keep database data alive through pod and node crashes, and how CNI, network policies, RBAC, and Helm fit together. By the end you can package a full stack with Helm, secure it with roles and role bindings, and set up horizontal pod autoscaling with monitoring.

Deployment fits most apps, but some workloads need a different controller. This lecture shows you when to reach for a DaemonSet to run one agent on every node, a StatefulSet for stable pod names and sticky scheduling like a Cassandra cluster, and Jobs or CronJobs for one-off and scheduled tasks. You will understand why a StatefulSet needs a headless service and how it differs from a deployment, so you can match the right controller to the workload.

Walk through what actually happens when you run kubectl, from the API server down to the pods on your nodes. You will see how the control plane fits together, the controller manager running its control loops, the scheduler doing bin packing, and etcd holding the entire cluster state you must back up. On the node side you will understand the role of kubelet, the container runtime, and kube-proxy setting up iptables rules for services.

Design a Kubernetes control plane that survives failures. You will learn why you run multiple masters with an odd-numbered etcd cluster using the 2n+1 rule and raft consensus, and how a load balancer in front of the API servers keeps both kubectl and worker nodes talking to whichever master is available. The lecture also covers the extras a real production setup needs: external fault-tolerant storage, centralized logging, and a monitoring stack with Prometheus and Grafana.

Get a working Docker environment ready before you run anything. You will see where to install Docker CE for your operating system, how to spin up a free browser-based setup with Play with Docker when you have no server, and how to confirm the install with docker version and docker run hello-world. By the end you can read docker system info, tell the client from the daemon, and know your setup is healthy.

Run your first container from a Docker Hub image and understand what each part of the name means. Using a tiny Alpine image, you will see how registry, namespace, repository, and tag combine, and why only the repository is required. You will also learn the key idea that a container lives only as long as its command runs, and how to list stopped containers with docker ps -l and -a.

So far your containers exited the moment their command finished. Here you will use the -i, -t, and -d options to open an interactive shell inside a container and keep long-running apps alive in detached mode. Along the way you will see how a namespaced container gets its own pids, IPC, and network interface through a veth pair, and why -idt is the combination you will reach for again and again.

Learn the everyday commands you will use to work with running containers. You will list and rename containers, tail output with docker logs -f, get a shell inside with docker exec -it, and pull detailed config from docker inspect. The lecture also covers copying files with docker cp, checking changes with docker diff, and cleanly stopping and removing containers with docker stop and docker rm -f.

Make a containerized app reachable from outside using port mapping. Running an Nginx container, you will see how -P auto-assigns a host port and how lowercase -p lets you pin a specific one, mapping your host port to the container port. You will publish real apps like Ghost, understand how the host IP changes across Docker for Mac, Windows, and Toolbox, and how to stop and restart a container without losing its state.

Swap heavy virtual machines for lightweight Docker containers as your local dev environment. You will spin up Ubuntu and CentOS containers in under a minute, log in with docker exec, install packages, and edit files inside them. You will also see how to persist your changes across container and system restarts, and clean everything up with docker rm when you are done.

Manage your Docker environment from a browser instead of the CLI. You will set up Portainer with a persistent volume, connect it to the local Docker daemon, and use the web console to start, stop, and delete containers, open a shell, deploy new apps, and watch live CPU and memory usage. By the end you can inspect images, networks, and volumes, and even connect to remote Docker hosts from one dashboard.

Launch a full multi-container stack in one command instead of memorising dozens of docker run flags. Using a Prometheus stack with Grafana, Alertmanager, node exporter, and cAdvisor, you will see how a single docker-compose.yaml codifies every service, port, and volume, gives you built-in service discovery, and starts it all with docker compose up -d. You will also tear the whole stack down cleanly and share it with your team as one file.

Build a Docker image by hand, the same way you would snapshot a VM. You will start an Ubuntu container, install build tools, copy in source code with docker cp, compile a C application, then capture the result as an image with docker commit. You will inspect what changed using docker diff, tag the image with your own Docker Hub namespace, and push it to the registry with docker push.

Turn the manual build process into a repeatable one using a Dockerfile. You will check out the Dockerfile branch, run docker image build with a tag and build context, and watch Docker run each instruction automatically through intermediate containers. You will compare the layers against the hand-built image, use the build cache for faster rebuilds, run the app with docker run -P, and push the tagged image to Docker Hub.

Read a Dockerfile line by line and understand what each instruction actually does. You will learn how FROM sets the base image, how RUN, COPY, and WORKDIR build up the filesystem, and how EXPOSE and CMD set metadata used at runtime. You will also see why almost every instruction becomes a layer, and how to combine RUN commands to keep your image lean and within the layer limit.

Pick the right way to build your own Kubernetes learning environment before you start deploying pods. This intro walks through three options: a three-node cluster with kubeadm on VMs or bare metal, a single-node setup with Minikube or Docker Desktop, and a managed cluster on Google Kubernetes Engine using free cloud credit. You will leave knowing which path fits your setup and what to validate once the cluster is up.

Minikube offers one of the easiest zero to dev experience to setup a single node kubernetes cluster. Its also the ideal way to create a local dev environment to test kubernetes code on.

This document explains how to setup and work with single node kubernetes cluster with minikube.

Provision three Ubuntu nodes on DigitalOcean ready for a kubeadm cluster. You will create droplets, paste a setup script into the user data field so Docker, kubeadm, kubelet, kubectl, and the CNI plugins install automatically on boot, then SSH into each node to confirm the tools and versions are in place. By the end you have three prepared servers waiting for cluster initialisation.

Bring up a real Kubernetes control plane with kubeadm init. You will set the advertise address to the master's IP, join the two worker nodes using the kubeadm join token, and configure kubectl both on the server and on your own laptop by copying the admin config. You will check the cluster with kubectl get nodes, watch node status live, and recover the join token later with kubeadm token list.

Fix nodes stuck in NotReady by installing a container network interface. You will deploy the Weave Net CNI plugin so pods can talk across hosts, watch the per-node pods come up and the nodes turn Ready, and confirm DNS gets scheduled. You will also check cluster health with kubectl cluster-info, get componentstatus, and kubectl get events, and learn where Flannel and Calico fit as alternatives.

Deploy the Kubernetes Dashboard with a single apply command, and see the deployment and service it creates behind the scenes. You will learn how to find the NodePort with kubectl get svc, connect through any node's host IP, and switch to the kube-system namespace to inspect pods, nodes, workloads, and events. After this you can use the dashboard alongside kubectl to watch and manage your cluster.

Set up kube-ops-view, an open source cluster visualizer, by cloning the repo and running one command. You will expose it through its NodePort service, adjust the display scale, and watch nodes and pods light up in real time as you deploy things. You will also clone the course code repository and set up a watch-based kubectl monitoring console, so you can see cluster changes as they happen.

Learn how to tear down and rebuild a cluster with kubeadm reset when things go wrong. You will reset every node, re-initialize the control plane with the advertise address, rejoin the worker nodes with the same token, and reconfigure the weave network and dashboard. You will also copy the admin kubeconfig back to your laptop so your local kubectl talks to the fresh cluster again.

This section starts with the smallest building block in Kubernetes: the pod. You will learn what a pod is, what goes into it, and how to write a pod specification in YAML, since everything in Kubernetes is defined as code. It sets up the concepts you will use next, including the container spec, pod properties, volumes, and running multi-container pods.

Write your first pod spec in YAML for the voting app, a Python service. You will fill in the four building blocks every object has, apiVersion, kind, metadata, and spec, add labels to identify the pod, and define the container spec with its image from Docker Hub. You will also see why containerPort is informational only, and how it helps later when you expose the pod through a service.

Launch your pod with kubectl apply and learn why apply is better than create for ongoing changes. You will list pods with get, use -o wide to see the pod IP and node, and read full details with kubectl describe. You will also check container logs with kubectl logs and open a shell inside the pod using kubectl exec, so you can operate a running pod from the command line.

Learn the everyday tools for debugging a pod. You will set up a tunnel to a pod running on a remote host with kubectl port-forward, then break the image tag on purpose to trigger an ErrImagePull error. You will read the events from kubectl describe and pull the exact failure message from kubectl get pod -o yaml, which is the trick that points straight at what went wrong.

Attach a persistent volume to a database pod so the data survives even after the pod is gone. You will define a hostPath volume in the pod spec with the directoryOrCreate option, then mount it into the Postgres container using volumeMounts. You will verify the directory is created only on the node the pod runs on, delete the pod, and confirm the data persists. This is the simplest way to persist data before moving on to persistent volumes and claims.

Build a pod that runs two containers, an nginx web server and a sync sidecar, sharing the same emptyDir volume mounted at different paths. You will deploy it by uploading the YAML through the dashboard, watch the ready count climb from 0/2 to 2/2, and inspect both containers with kubectl describe. You will see how the containers share one IP and hostname, and why emptyDir is fine for testing but not production.

Learn how to connect to a specific container inside a multi-container pod using kubectl exec with the -c flag. You will compare the nginx and sync containers side by side and see what they share, the network namespace, IP, and hostname, and what stays separate, their process namespace, filesystem, and volume mount paths. You will also read per-container logs and see why a standalone pod has no fault tolerance, which sets up replica sets next.

A bare pod that dies stays dead. This section shows you how ReplicaSets and Replication Controllers keep your pods alive, rescheduling them when a pod or a node fails. By the end you will understand how Kubernetes gives you high availability, fault tolerance, and self-healing, and why ReplicaSets replaced the older Replication Controller.

Set up a dedicated namespace for the project and learn to move between namespaces cleanly. You will apply a namespace spec with kubectl apply, list them with kubectl get ns, then use kubectl config set-context to switch your active view. After this you can partition a cluster, scope your work to one namespace, and understand how contexts let you point kubectl at different clusters and accounts.

Write a ReplicaSet spec step by step, reusing your existing pod template inside it. You will set the number of replicas, add a selector, and learn the key difference from Replication Controllers: set-based selectors with matchLabels and matchExpressions. By the end you can author a working apps/v1 ReplicaSet, get labels and selectors matching correctly, and indent the nested pod template so it actually applies.

Apply your ReplicaSet, fix a YAML error using dry-run, and watch it adopt an existing pod through label selectors. You will see why editing a ReplicaSet does not roll out config changes, then delete pods and watch the control loop recreate them to hold the desired replica count. After this you understand how ReplicaSets deliver fault tolerance and why real updates need Deployments.

Your pods are running but nothing outside can reach them. This section introduces Kubernetes Services, the object that maps ports across many nodes to your pods. You will learn how a Service handles load balancing and service discovery, letting one application find another through a fixed cluster IP and DNS name instead of chasing pod IPs that keep changing.

Write a Service spec that exposes the vote application outside the cluster using a NodePort. You will set the selector that picks pods by label, choose the service type, and define the port and targetPort so traffic reaches the right container port. By the end you understand ClusterIP versus NodePort, the 30000 to 32767 node port range, and how a Service keeps finding healthy pods to route to.

Apply the Service and reach your app from outside the cluster. You will inspect it with kubectl describe svc, see the endpoints and the constant cluster IP, and test round-robin load balancing by refreshing the NodePort. You will also add an externalIP so the service answers on port 80 instead of a high node port, and learn why exposing many services needs an ingress controller.

Connect one application to another using Kubernetes service discovery. You will exec into a vote pod, watch it fail to resolve redis, then create a ClusterIP Service and see the DNS name resolve to the service cluster IP automatically. After adding backend pods through a Deployment, endpoints appear and the connection works. You will understand how internal DNS and cluster IPs let microservices find each other by name.

ReplicaSets cannot update a running application, so this section brings in Deployments. You will learn how a Deployment codifies your update strategy in YAML and keeps it under version control, replacing the old rolling-update command. By the end you understand the rolling update and recreate strategies, zero-downtime rollouts, and how to roll back to a previous version when something breaks, plus the base for canary and blue-green releases.

Turn your ReplicaSet into a Deployment, since a Deployment is a superset of it. You will change the kind, add a namespace, and define the rolling update strategy with maxSurge and maxUnavailable to control batch size during a rollout. You will also set revisionHistoryLimit and the pause option. After this you can write a declarative Deployment spec that manages ReplicaSets and controls exactly how new versions roll out.

Apply a Deployment spec and watch how it works underneath. You will see the pod-template-hash appear on labels, understand why each change spins up a fresh ReplicaSet, and track the rollout with kubectl rollout status. You will also scale pods up and down both from the command line and through the spec, so your desired state stays in version history.

See a rolling update run live as you push a new image version. You will learn how maxSurge and maxUnavailable set the batch size, why pods update a few at a time with zero downtime, and how a new ReplicaSet takes over from the old one. By the end you can read kubectl rollout history and inspect any past revision by number.

Deliberately break a Deployment with a bad image tag and watch the rollout get stuck on ImagePullBackOff while old pods stay live. You will use kubectl rollout history to read past revisions and kubectl rollout undo to roll back, either to the last working version or to a specific revision you pick. After this you can recover any Deployment when an update goes wrong.

In this project , you would write definitions for deploying the vote application stack with all components/tiers.

Start the voting-app project by deploying the worker, which needs only a Deployment and no Service since nothing connects to it. You will write the spec, do a dry run, and fix the image-pull errors and immutable-label problems that come up along the way. You will end with the worker running and waiting on Redis and the database, ready for the next pieces.

Bring up the Postgres database and wire it into the app with a ClusterIP Service. You will write the Service using the correct role=db selector and port 5432, apply it before the pods, and confirm endpoints appear once the Deployment matches. By the end the worker connects to both Redis and the database, and votes start processing through the full workflow.

Finish the voting app by deploying the results service and exposing it to the outside. You will reuse an existing Deployment spec, set the replicas and role labels, then add a NodePort Service, changing the port and node port to avoid conflicts. With results reachable in the browser, you register a vote and watch it update live, giving you a full end-to-end test of the app.