> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Course Introduction
> Introductory Kubernetes course covering containers, static pod manifests, control plane troubleshooting, and hands-on browser-accessible lab environments for practical debugging and kubectl workflows.
My name is Mumshad Mannambeth, and I'll be your instructor.
Kubernetes is the de facto platform for hosting production-grade applications. As companies adopt cloud-native architectures, demand for engineers with Kubernetes skills is rising. This lesson builds a strong foundation by starting with containers and then progressing into core Kubernetes concepts and real-world troubleshooting.
We emphasize hands-on practice. You will solve Kubernetes coding challenges in a live browser-accessible Kubernetes environment. You don't need a powerful laptop or a cloud account — the course provides access to real clusters from your browser.
You get browser-accessible, hands-on environments that run real Kubernetes clusters. This lets you practice commands and debugging without installing or paying for cloud resources.
## What you'll learn in this module
* Container basics and running multiple containers locally
* Mapping containers and volumes for simple app topologies
* Reading and editing static pod manifests (control plane components)
* Common control-plane troubleshooting workflows using kubectl
* Practical debugging techniques you can use in production clusters
## Example: running multiple containers locally
Run example application containers (detached):
```bash theme={null}
# Run sample application containers (detached)
docker run -d --name python1 python-app
docker run -d --name python2 python-app
# Run helper containers and link them to the app containers (legacy --link used here for illustration)
# Note: --link is a legacy Docker feature and not recommended for new deployments; use user-defined networks instead.
docker run -d --name helper1 --link python1:app1 helper
docker run -d --name helper2 --link python2:app2 helper
```
The `--link` flag is a legacy Docker feature. For modern local development and production deployments, prefer user-defined Docker networks or service discovery mechanisms. Using `--link` can introduce brittle dependencies between containers.
Simple mapping representation:
| Component | Role | Volume |
| -: | - | :-: |
| Python1 | App1 | Vol1 |
| Python2 | App2 | Vol2 |
| helper1 | Helper | — |
| helper2 | Helper | — |
## Kubernetes manifests and control-plane troubleshooting
Below is an example snippet of a static pod manifest (illustrative; e.g., a kube-scheduler static pod). It mounts a kubeconfig, uses host networking, and sets a cluster-critical priority class.
```yaml theme={null}
apiVersion: v1
kind: Pod
metadata:
name: kube-scheduler
spec:
hostNetwork: true
priorityClassName: system-cluster-critical
containers:
- name: kube-scheduler
# image and command shown illustratively; actual manifests may vary by distro/version
image: k8s.gcr.io/kube-scheduler:v1.20.0
command:
- kube-scheduler
- --kubeconfig=/etc/kubernetes/scheduler.conf
volumeMounts:
- mountPath: /etc/kubernetes/scheduler.conf
name: kubeconfig
readOnly: true
volumes:
- name: kubeconfig
hostPath:
path: /etc/kubernetes/scheduler.conf
type: FileOrCreate
status: {}
```
Key manifest fields (quick reference):
| Field | Purpose | Example / Notes |
| - | - | - |
| `hostNetwork` | Use host's network namespace | `true` for control-plane components |
| `priorityClassName` | Scheduling priority for pods | `system-cluster-critical` |
| `volumeMounts` | Where volumes are mounted inside the container | `mountPath: /etc/kubernetes/scheduler.conf` |
| `volumes` | Declares hostPath or other volume sources | `hostPath.path: /etc/kubernetes/scheduler.conf` |
## Common diagnostic workflow on a control-plane node
When a control-plane component (like kube-scheduler) fails to come up, a typical workflow is:
1. Inspect and edit the static pod manifest (e.g., fix paths, permissions, or config flags):
```bash theme={null}
root@controlplane:~# vi /etc/kubernetes/manifests/kube-scheduler.yaml
root@controlplane:~#
```
2. Check pod status in the `kube-system` namespace to see current state and events:
```bash theme={null}
root@controlplane:~# kubectl get pods -n kube-system
NAME READY STATUS RESTARTS AGE
coredns-74ff55c5b-fz97g 1/1 Running 0 24m
coredns-74ff55c5b-wfmdz 1/1 Running 0 24m
etcd-controlplane 1/1 Running 0 24m
kube-apiserver-controlplane 1/1 Running 0 24m
kube-controller-manager-controlplane 1/1 Running 0 24m
kube-flannel-ds-b85q5 1/1 Running 0 24m
kube-proxy-pthlt 1/1 Running 0 24m
kube-scheduler-controlplane 0/1 ContainerCreating 0 15s
```
After fixing the manifest (for example, correcting file paths or adjusting permissions), the scheduler pod should transition to Running:
```bash theme={null}
root@controlplane:~# kubectl get pods -n kube-system
NAME READY STATUS RESTARTS AGE
coredns-74ff55c5b-fz97g 1/1 Running 0 24m
coredns-74ff55c5b-wfmdz 1/1 Running 0 24m
etcd-controlplane 1/1 Running 0 24m
kube-apiserver-controlplane 1/1 Running 0 24m
kube-controller-manager-controlplane 1/1 Running 0 24m
kube-flannel-ds-b85q5 1/1 Running 0 24m
kube-proxy-pthlt 1/1 Running 0 24m
kube-scheduler-controlplane 1/1 Running 0 15s
root@controlplane:~#
```
We will walk you through these steps, plus how to use `kubectl describe`, `kubectl logs`, and node-level checks (file permissions, SELinux/AppArmor contexts, and hostPath validity) to systematically identify and resolve issues.
## Links and references
* [Kubernetes Documentation](https://kubernetes.io/docs/)
* [Docker Documentation](https://docs.docker.com/)
* [Kubernetes Scheduling](https://kubernetes.io/docs/concepts/scheduling-eviction/)
* [kube-scheduler static pods and manifests (example)](https://kubernetes.io/docs/tasks/administer-cluster/static-pod/)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.