Kubernetes Tutorial

In this Kubernetes tutorial, you will learn what Kubernetes is, how a Kubernetes cluster is organized, which objects beginners should learn first, and how to run a small application using Deployment and Service manifests.

---

Kubernetes tutorial roadmap for beginners

Kubernetes is easier to understand when you learn it in layers. First, understand why container orchestration is needed. Then learn the cluster architecture, the common Kubernetes objects, and the basic kubectl workflow. After that, move to networking, configuration, storage, scaling, and troubleshooting.

This tutorial focuses on the core concepts you need before using a managed Kubernetes service or preparing for hands-on Kubernetes labs. You do not need to know every advanced feature on day one, but you should understand how Kubernetes keeps the actual state of an application close to the desired state you define.

• Start with containers: Kubernetes manages applications packaged as container images.
• Learn Pods and Deployments: Pods run containers, while Deployments manage replicas and rollouts.
• Use Services for access: Services provide stable networking for changing groups of Pods.
• Separate configuration: ConfigMaps and Secrets keep environment-specific values outside the container image.
• Add persistence carefully: PersistentVolumes and PersistentVolumeClaims are used when applications need durable data.

---

What Kubernetes does for containerized applications

Kubernetes, often written as K8s, is an open-source platform for deploying, scaling, and managing containerized applications. Instead of manually starting containers on individual servers, you describe the desired state of your application, and Kubernetes works to maintain that state across a cluster of machines.

For example, you can define that a web application should run with three replicas. Kubernetes schedules those replicas on available nodes, replaces failed Pods, and provides stable service discovery so other applications can reach them. If you update the application image, Kubernetes can roll out the change gradually and roll back if needed.

The name Kubernetes comes from a Greek word meaning “helmsman” or “pilot.” The idea is similar: Kubernetes steers application workloads across a distributed environment while developers and operators define the direction through configuration.

Kubernetes cluster architecture: control plane, nodes, and Pods

A Kubernetes cluster has two main parts: the control plane and one or more worker nodes. The control plane makes cluster-wide decisions. Worker nodes run the application Pods.

• kube-apiserver: The front door of the Kubernetes control plane. Tools such as kubectl communicate with the API server.
• etcd: A distributed key-value store that holds cluster state and configuration data.
• kube-scheduler: Selects suitable nodes for newly created Pods based on resource needs and scheduling rules.
• kube-controller-manager: Runs controllers that watch the cluster and move the current state toward the desired state.
• kubelet: Runs on each node and makes sure the required containers are running in Pods.
• kube-proxy: Handles network rules used by Services to route traffic to Pods.
• container runtime: Runs containers on the node. Common runtimes include containerd and CRI-O.

A Pod is the smallest deployable unit in Kubernetes. A Pod usually contains one application container, though it can contain multiple tightly related containers that share networking and storage. In most real projects, you do not create standalone Pods directly; you create a higher-level object such as a Deployment, which manages Pods for you.

Kubernetes objects beginners should learn first

Kubernetes represents application configuration through API objects. These objects are usually written in YAML files and applied to the cluster. The following objects appear in many beginner Kubernetes tutorials and production deployments.

Kubernetes object	What it is used for	Beginner note
Pod	Runs one or more containers	Usually managed by a Deployment, Job, or StatefulSet
Deployment	Manages replicas and rolling updates for stateless applications	Best first object for a web app or API
ReplicaSet	Keeps a specified number of Pod replicas running	Normally created and managed by a Deployment
Service	Provides stable networking to a set of Pods	Required because Pod IPs can change
ConfigMap	Stores non-confidential configuration values	Use for settings such as feature flags or URLs
Secret	Stores sensitive values such as tokens or passwords	Use RBAC and encryption at rest where required
PersistentVolumeClaim	Requests persistent storage for a workload	Commonly used by databases and stateful apps
Namespace	Groups resources inside a cluster	Useful for separating teams, environments, or apps

Minimal Kubernetes Deployment YAML for a web application

The example below defines a Deployment that runs three replicas of an NGINX container. Kubernetes will try to keep three matching Pods available. If one Pod fails, the Deployment controller creates a replacement Pod.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-web
  labels:
    app: hello-web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello-web
  template:
    metadata:
      labels:
        app: hello-web
    spec:
      containers:
        - name: nginx
          image: nginx:stable
          ports:
            - containerPort: 80

The important fields in this manifest are:

• apiVersion and kind tell Kubernetes which type of object you are creating.
• metadata.name gives the object a name inside the namespace.
• spec.replicas asks Kubernetes to run three Pods.
• selector.matchLabels tells the Deployment which Pods it owns.
• template describes the Pods that the Deployment should create.

Kubernetes Service YAML for stable access to Pods

Pods are replaceable, so you should not depend on a specific Pod IP address. A Kubernetes Service provides a stable endpoint and forwards traffic to matching Pods.

apiVersion: v1
kind: Service
metadata:
  name: hello-web-service
spec:
  type: ClusterIP
  selector:
    app: hello-web
  ports:
    - port: 80
      targetPort: 80

This Service uses selector: app: hello-web, which matches the label on the Pods created by the Deployment. The Service receives traffic on port 80 and forwards it to port 80 inside the selected Pods.

Running a first Kubernetes example with kubectl

To run the example, you need a Kubernetes cluster and kubectl configured to point to that cluster. For local practice, many learners use Minikube, kind, Docker Desktop Kubernetes, or a managed cloud Kubernetes cluster.

Save the Deployment YAML as deployment.yaml and the Service YAML as service.yaml. Then apply both files:

kubectl apply -f deployment.yaml
kubectl apply -f service.yaml

Check whether the Deployment, Pods, and Service were created:

kubectl get deployments
kubectl get pods
kubectl get services

A typical result looks similar to this. Names, ages, and IP addresses will vary in your cluster.

NAME        READY   UP-TO-DATE   AVAILABLE   AGE
hello-web   3/3     3            3           1m

NAME                             READY   STATUS    RESTARTS   AGE
hello-web-6f7c9d9c4b-4p2xg       1/1     Running   0          1m
hello-web-6f7c9d9c4b-9q8zm       1/1     Running   0          1m
hello-web-6f7c9d9c4b-vm7tc       1/1     Running   0          1m

NAME                TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
hello-web-service   ClusterIP   10.96.120.10    <none>        80/TCP    1m

To remove the resources after practice, delete the YAML files from the cluster:

kubectl delete -f service.yaml
kubectl delete -f deployment.yaml

Kubernetes networking basics: Services, NodePort, LoadBalancer, and Ingress

Kubernetes networking is one of the first areas beginners should understand. Pods can come and go, but applications still need reliable communication. Kubernetes solves this by using labels, selectors, Services, and optional Ingress rules.

• ClusterIP Service: Exposes the application only inside the cluster. This is the default Service type.
• NodePort Service: Exposes the Service on a port on each node. It is useful for simple testing but not usually the final production entry point.
• LoadBalancer Service: Requests an external load balancer from the infrastructure provider when supported.
• Ingress: Routes HTTP or HTTPS traffic to Services based on hostnames and paths. It requires an Ingress controller to work.

For a beginner, the key idea is that a Service does not run your application. It provides a stable network path to Pods that match its selector.

Configuration in Kubernetes using ConfigMaps and Secrets

Container images should usually be the same across environments, while configuration changes between development, staging, and production. Kubernetes supports this separation with ConfigMaps and Secrets.

• ConfigMap: Use it for non-sensitive values such as log levels, public URLs, feature flags, or application modes.
• Secret: Use it for sensitive values such as passwords, API keys, private tokens, and certificates.

A Secret is not the same as a complete security solution by itself. Use Kubernetes RBAC, limit who can read Secrets, avoid printing Secret values in logs, and configure encryption at rest when your environment requires it.

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_MODE: production
  LOG_LEVEL: info

A Pod or Deployment can consume ConfigMap values as environment variables, command-line arguments, or mounted files. This keeps the application image reusable across environments.

Storage in Kubernetes with PersistentVolumes and PersistentVolumeClaims

Containers are often replaceable, but some applications need durable data. Kubernetes storage uses PersistentVolumes and PersistentVolumeClaims to connect workloads with storage resources.

• PersistentVolume (PV): Represents storage available to the cluster.
• PersistentVolumeClaim (PVC): Represents a workload’s request for storage size and access mode.
• StorageClass: Defines how storage is dynamically provisioned, often by a cloud or storage provider.

Stateless applications such as many web APIs can run without persistent storage. Databases, queues, and file-processing systems usually need a storage plan. In production, choose storage based on backup, restore, latency, access mode, and failure-domain requirements.

Scaling, rollouts, and self-healing in Kubernetes Deployments

Kubernetes Deployments help manage stateless applications by keeping the requested number of replicas running. You can scale a Deployment manually, update its image, and inspect rollout status using kubectl.

kubectl scale deployment hello-web --replicas=5
kubectl rollout status deployment hello-web
kubectl set image deployment/hello-web nginx=nginx:stable
kubectl rollout history deployment hello-web

Self-healing in Kubernetes comes from controllers continuously watching the cluster. If a Pod managed by a Deployment is deleted or fails, Kubernetes creates another Pod to match the desired replica count. If a node becomes unavailable, Kubernetes can schedule replacement Pods on healthy nodes, depending on the workload and cluster conditions.

For application-level health, use readiness probes and liveness probes. A readiness probe tells Kubernetes whether a container is ready to receive traffic. A liveness probe helps Kubernetes decide when a container should be restarted.

Kubernetes benefits for containerized applications and DevOps teams

Kubernetes is useful when an application has multiple services, changing traffic, frequent deployments, or a need for consistent operations across environments. The main benefits are practical rather than magical.

• Consistent deployment model: Teams define workloads using Kubernetes API objects instead of server-specific steps.
• Scaling options: Applications can be scaled manually or with autoscaling when metrics are configured.
• Rolling updates: Deployments can update Pods gradually instead of replacing everything at once.
• Service discovery: Services provide stable names and network access for changing Pods.
• Portability: Kubernetes can run on local machines, on-premises infrastructure, and cloud platforms, though each environment still has operational differences.

When Kubernetes may be too much for a small application

Kubernetes is powerful, but it also adds operational overhead. A small static website, a simple script, or a single low-traffic application may be easier to run on a virtual machine, a platform-as-a-service, or a managed container service without operating a Kubernetes cluster.

Before choosing Kubernetes, check whether your team is ready to manage cluster upgrades, networking, storage, observability, access control, backups, and security policies. Managed Kubernetes services reduce some infrastructure work, but they do not remove the need to understand Kubernetes objects and runtime behavior.

Common Kubernetes beginner mistakes to avoid

• Creating standalone Pods for long-running apps: Use Deployments for stateless applications so Kubernetes can replace failed Pods.
• Forgetting labels and selectors: Services and Deployments depend on labels matching correctly.
• Putting passwords in ConfigMaps: Use Secrets for sensitive values and restrict access.
• Ignoring resource requests and limits: Without resource settings, scheduling and workload isolation become harder to predict.
• Assuming a Service exposes the app publicly: A default ClusterIP Service is reachable inside the cluster, not from the public internet.
• Skipping health probes: Without readiness and liveness probes, Kubernetes has less information about application health.

Official Kubernetes references for deeper study

The official Kubernetes documentation is the best reference when you want exact behavior and current API details. These pages are useful after completing this beginner Kubernetes tutorial:

• Kubernetes Tutorials for guided hands-on learning.
• Learn Kubernetes Basics for an official beginner path.
• Kubernetes Concepts Overview for core ideas and terminology.
• Kubernetes Components for control plane and node component details.
• Kubernetes Deployments for rollout and replica management.

Kubernetes tutorial QA checklist before practice or publishing

1. Confirm that every Kubernetes YAML example has matching labels and selectors.
2. Check that command examples use kubectl against the intended cluster context.
3. Verify that Secret examples do not expose real passwords, tokens, certificates, or keys.
4. Explain whether a Service is internal-only, node-level, or externally load balanced.
5. State whether the workload is stateless or needs persistent storage before recommending a Deployment, StatefulSet, or PVC.
6. Include cleanup commands for practice resources so learners do not leave unused objects running.

---

Kubernetes tutorial FAQs

Is Kubernetes the same as Docker?

No. Docker is commonly used to build and run containers, while Kubernetes orchestrates containerized workloads across a cluster. Kubernetes can run containers using supported container runtimes such as containerd or CRI-O.

Do beginners need YAML to learn Kubernetes?

Yes, at least the basics. Kubernetes objects are commonly declared in YAML, so beginners should learn fields such as apiVersion, kind, metadata, and spec. You can use commands for quick tests, but YAML is better for repeatable deployments.

What is the difference between a Pod and a Deployment in Kubernetes?

A Pod runs one or more containers. A Deployment manages Pods for a stateless application, keeps the desired number of replicas running, and supports rolling updates. For long-running web applications, beginners should usually start with a Deployment instead of a standalone Pod.

How does Kubernetes expose an application to users?

Kubernetes usually exposes applications through Services and, for HTTP or HTTPS traffic, Ingress. A ClusterIP Service is internal to the cluster, NodePort exposes a port on each node, LoadBalancer requests an external load balancer when supported, and Ingress routes web traffic to Services.

When should I use Kubernetes persistent storage?

Use persistent storage when the application must keep data after a Pod is replaced. Examples include databases, file uploads, and queue data. In Kubernetes, this is usually handled with PersistentVolumes, PersistentVolumeClaims, and a suitable StorageClass.

---

Kubernetes is best learned by combining concepts with small practical examples. Start with a Deployment and Service, inspect the objects with kubectl, change the replica count, observe how Pods are replaced, and then move to configuration, storage, and networking one topic at a time.