Kubernetes Tutorial: Learn K8s Basics & Deployment

This Kubernetes tutorial is for developers and operators who want to understand how K8s runs containerized apps, move past the terminology, and actually deploy real workloads. If you’ve heard words like pods, clusters, or deployments and felt a little lost, this guide breaks things down practically (and quickly). You’ll get conceptual clarity, hands-on steps, and common patterns I see on real projects — enough to start building and iterating with confidence.

What is Kubernetes and why it matters

Kubernetes (often called K8s) is an open-source platform for managing containers at scale. It automates deploying, scaling, and operating app containers across clusters of machines. The project began at Google and is now maintained by the Cloud Native Computing Foundation; for a quick background see Kubernetes on Wikipedia and the official docs at kubernetes.io.

Key Kubernetes concepts (plain language)

Short definitions first — here’s the vocabulary you should know.

• Container: a packaged app and its dependencies (Docker is common).
• Pod: the smallest deployable unit in K8s — one or more containers that share networking and storage.
• Node: a VM or physical host in the cluster that runs pods.
• Cluster: a set of nodes managed by Kubernetes.
• Deployment: a declarative way to manage replica sets of pods (updates, rollbacks).
• Service: stable network endpoint for pods (load balancing, discovery).

How Kubernetes works (high level)

Kubernetes uses a control plane to keep desired state in sync. You declare what you want (for example: three replicas of an app), and K8s schedules pods to nodes, ensures health checks, restarts crashed containers, and manages updates. Think of it as a supervisor that continuously reconciles the actual state to the desired state.

Control plane components

• API Server: central entrypoint for kubectl and controllers.
• Scheduler: assigns pods to nodes.
• Controller Manager: runs controllers that handle replication, endpoints, etc.
• etcd: key-value store for cluster state.

Common workload types: quick comparison

Not all workloads are equal. Pick the right controller type for the job.

Hands-on: Deploy a simple app (step-by-step)

These steps assume you have a working cluster (minikube, kind, or cloud provider). I’ll keep commands minimal.

• Create a deployment YAML or use kubectl create deployment nginx –image=nginx.
• Expose the deployment: kubectl expose deployment nginx –port=80 –type=ClusterIP.
• Scale: kubectl scale deployment nginx –replicas=3.
• Check status: kubectl get pods,svc.
• Update image (rolling): edit deployment or kubectl set image deployment/nginx nginx=nginx:1.19.

If you want a guided tutorial from the project itself, the official docs provide interactive examples at Kubernetes tutorials.

Services, networking, and ingress

A Service gives a stable DNS name to a set of pods. For external traffic, use a LoadBalancer service or an Ingress controller. In production you typically pair an ingress controller (NGINX, Traefik) with TLS certificates.

Quick note on DNS and service discovery

Pods talk to services via cluster DNS (e.g., my-service.default.svc.cluster.local). This makes microservice communication predictable even as pods move around.

Persistent storage

Stateful workloads need volumes. Use PersistentVolume (PV) and PersistentVolumeClaim (PVC) to request storage. Cloud providers have dynamic provisioners (AWS EBS, GCE PD). For a broader view see the storage section in the official docs at Kubernetes Storage.

CI/CD and GitOps patterns

I often see two practical choices: classic CI/CD (build image, push, update deployment) or GitOps (declare desired cluster state in Git; an operator applies it). Tools like Argo CD and Flux implement GitOps reliably; they reduce drift by making Git the source of truth.

Monitoring, logging, and troubleshooting

• Monitoring: Prometheus + Grafana for metrics.
• Logging: centralized logs with fluentd/Fluent Bit to Elasticsearch or cloud logging.
• Tracing: Jaeger/Zipkin for distributed tracing.

When something fails, start with kubectl describe pod and kubectl logs, then check events and node conditions. Common issues are image pull errors, insufficient resources, and failing readiness probes.

Security basics

• Use namespaces to separate environments.
• Apply RBAC to restrict API access.
• Run containers with least privilege; avoid running as root.
• Use network policies to control pod-to-pod traffic.

Costs and resource management

Set CPU and memory requests and limits for predictable scheduling and to avoid noisy neighbors. Use Horizontal Pod Autoscaler (HPA) for scaling based on CPU or custom metrics.

Practical example: autoscaling

Enable metrics-server and create an HPA that scales a deployment from 2 to 10 replicas based on CPU usage. This is a common pattern for web services handling variable load.

When to use managed Kubernetes

If you don’t want to manage control plane upgrades and etcd backups, consider managed offerings like GKE, EKS, or AKS. They remove operational burden and are a good fit for teams that want to focus on apps rather than cluster plumbing.

Resources and further reading

Official docs are the best source for up-to-date APIs: Kubernetes documentation. For background history and project context see Kubernetes on Wikipedia. For ecosystem governance and CNCF projects check Cloud Native Computing Foundation.

Final notes and next steps

Start small: run a dev cluster (minikube or kind), deploy a sample app, and iterate. Try adding monitoring and a CI pipeline once you’re comfortable. The learning curve is real, but the payoff — reliable, scalable deployments — is worth it.

Next actions: set up a local cluster, deploy a simple app, add a Service and scale it. Expect to debug a few things — that’s normal.