This Kubernetes tutorial introduces the architecture, objects, commands, and workflows used to deploy and manage containerized applications. The learning path starts with Pods, Deployments, and Services before covering configuration, storage, security, scaling, monitoring, and troubleshooting.
What Is Kubernetes?
Kubernetes, commonly abbreviated as K8s, is an open-source system for automating the deployment, scaling, and management of containerized applications. It schedules workloads across machines, monitors their state, replaces failed instances, and keeps the running environment aligned with the configuration declared by the user.
Kubernetes originated at Google and is now maintained as a Cloud Native Computing Foundation project. The name comes from a Greek word meaning “helmsman” or “pilot.” Kubernetes is not a container image builder or container runtime. It coordinates workloads that run through a compatible runtime such as containerd or CRI-O.
What Kubernetes Manages
- Containerized application workloads and their desired replica count
- Placement of Pods on available worker nodes
- Stable service discovery and network endpoints
- Rolling application updates and rollbacks
- Application configuration and sensitive values
- Persistent storage requested by workloads
- Health checks, container restarts, and Pod replacement
Kubernetes Concepts for Beginners
Kubernetes uses API objects to describe the desired state of an application. These objects are commonly defined in YAML manifests and managed with the kubectl command-line tool.
| Kubernetes object | Purpose |
|---|---|
| Cluster | A control plane and a collection of worker nodes managed as one system. |
| Node | A physical or virtual machine that runs Kubernetes workloads. |
| Pod | The smallest deployable Kubernetes unit, containing one or more closely related containers. |
| Deployment | Manages stateless application replicas and controlled updates. |
| ReplicaSet | Maintains a specified number of matching Pod replicas, normally through a Deployment. |
| Service | Provides a stable network endpoint for a changing set of Pods. |
| Namespace | Creates a logical scope for resource names, permissions, and organization. |
| ConfigMap | Stores non-confidential application configuration. |
| Secret | Stores sensitive values for controlled use by applications. |
| PersistentVolumeClaim | Requests persistent storage for a workload. |
| Ingress | Defines HTTP or HTTPS routing rules when an Ingress controller is installed. |
Declarative State and Kubernetes Reconciliation
A Kubernetes manifest states what should exist, such as three application replicas using a particular container image. After the manifest is submitted to the API server, Kubernetes controllers compare the desired state with the actual state and make changes until they match.
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: nginx:1.27
ports:
- containerPort: 80
This manifest creates a Deployment named web. The Deployment maintains three Pods and replaces a Pod when one is removed or fails. Production manifests should also define suitable resource requests, limits, health probes, security settings, and an approved image tag or immutable image digest.
Kubernetes Architecture: Control Plane and Worker Nodes
A Kubernetes cluster contains a control plane that manages cluster state and one or more worker nodes that run application workloads. Older tutorials may use the term “master node,” but current Kubernetes documentation uses “control plane.”
Kubernetes Control Plane Components
- kube-apiserver: Exposes the Kubernetes API and processes API requests.
- etcd: Stores Kubernetes cluster data in a consistent key-value database.
- kube-scheduler: Selects a suitable worker node for each unscheduled Pod.
- kube-controller-manager: Runs controllers that reconcile resources such as nodes, replicas, endpoints, and jobs.
- cloud-controller-manager: Integrates supported cloud-provider resources when the cluster runs in a cloud environment.
Kubernetes Worker Node Components
- kubelet: Watches Pod specifications assigned to the node and coordinates with the container runtime.
- Container runtime: Pulls container images and runs containers. Common Kubernetes-compatible runtimes include containerd and CRI-O.
- kube-proxy: Implements Service networking rules in clusters that use it. Some networking implementations provide equivalent behavior without kube-proxy.
- Container Network Interface plugin: Connects Pods to the cluster network and may enforce network policies.
How Kubernetes Schedules a Deployment
- A user submits a manifest through
kubectlor another Kubernetes API client. - The API server authenticates, authorizes, validates, and stores the accepted object.
- A controller creates the required ReplicaSet and Pod objects.
- The scheduler selects an appropriate worker node for each pending Pod.
- The kubelet asks the container runtime to pull the image and start the container.
- Controllers and node agents continue reporting status and reconciling differences.
Kubernetes Deployment, Scaling, and Rollouts
Deployments manage stateless application replicas and support controlled rollouts. Changing the Pod template, such as updating a container image, creates a new ReplicaSet and gradually replaces old Pods according to the Deployment strategy.
A rollout can be inspected, paused, resumed, or undone when revision history is available. Manual scaling directly changes the replica count, while the Horizontal Pod Autoscaler can adjust replicas from observed metrics when the required metrics pipeline and resource requests are configured.
Vertical Pod Autoscaler is a separate Kubernetes project or add-on that recommends or adjusts CPU and memory requests. Depending on its operating mode, applying updated resources can require Pods to be replaced.
Kubernetes Self-Healing and Health Probes
Kubernetes restarts failed containers according to their restart policy, replaces missing Pods managed by controllers, and reschedules workloads when nodes become unavailable. Probes help Kubernetes decide whether a container has started, remains healthy, or is ready to receive traffic.
- Startup probe: Gives a slow-starting application time to initialize before liveness checks begin.
- Liveness probe: Indicates whether Kubernetes should restart a container.
- Readiness probe: Controls whether a Pod endpoint should receive Service traffic.
Self-healing does not fix application logic, repair external dependencies, or guarantee zero downtime. Availability also depends on replica count, disruption settings, scheduling capacity, storage, networking, and application design.
Kubernetes Services and Application Networking
Pod IP addresses can change when Pods are recreated. A Kubernetes Service selects Pods by label and provides a stable virtual IP address and DNS name. Common Service types include ClusterIP, NodePort, LoadBalancer, and ExternalName.
- ClusterIP: Exposes the Service only inside the cluster.
- NodePort: Opens a port on each node and forwards traffic to the Service.
- LoadBalancer: Requests an external load balancer from a supported environment.
- ExternalName: Maps the Service to an external DNS name.
For HTTP and HTTPS applications, an Ingress resource can define host and path routing rules, but an Ingress controller must be installed. Kubernetes also supports the Gateway API through implementations that install the required controllers and custom resources.
Kubernetes ConfigMaps and Secrets
ConfigMaps hold non-sensitive configuration, while Secrets hold sensitive values such as tokens, passwords, and certificates. Both can be exposed to containers as environment variables or mounted as files.
Kubernetes Secrets are base64-encoded in API representations, but base64 is not encryption. Protect Secrets with least-privilege role-based access control, encryption at rest where required, restricted API access, audit logging, secure backups, and an external secrets system when appropriate.
Applications should also account for how configuration changes are delivered. Mounted values and environment variables do not update in exactly the same way, and an application may need a restart or a configuration reload mechanism.
Kubernetes Persistent Storage
PersistentVolumes represent storage available to the cluster, while PersistentVolumeClaims request storage for workloads. A StorageClass can enable dynamic provisioning through a Container Storage Interface driver.
A claim can specify capacity, access mode, and a StorageClass. The storage system and driver determine which capabilities are supported. StatefulSets are commonly used when Pods require stable identities or stable per-replica storage.
Storage does not automatically grow because an application adds replicas. Volume expansion requires support from the StorageClass and storage driver, and a stateful application may need one claim for each replica.
Set Up Kubernetes for Local Tutorial Practice
Beginners can learn Kubernetes with a local cluster instead of provisioning production infrastructure. Common local options include Minikube, kind, Docker Desktop Kubernetes, and Rancher Desktop. Their behavior differs for features such as load balancers, storage, Ingress, and multi-node networking.
Install kubectl, create or start a local cluster, and confirm that the active context points to the intended environment.
kubectl config current-context
kubectl cluster-info
kubectl get nodes
kubectl get namespaces
Use a supported Kubernetes release and keep the kubectl client reasonably aligned with the cluster version. Installation commands vary by operating system and local cluster tool, so follow the current documentation for the selected tool.
Create Your First Kubernetes Deployment
The following commands create a Deployment, expose it through an internal Service, inspect the resources, and remove them after practice. A Kubernetes cluster must already be running.
kubectl create deployment hello-kubernetes --image=nginx:1.27
kubectl get deployments
kubectl get pods
kubectl expose deployment hello-kubernetes --port=80 --target-port=80
kubectl get services
kubectl describe deployment hello-kubernetes
kubectl logs deployment/hello-kubernetes
The generated Service uses the ClusterIP type by default and is reachable only inside the cluster. For temporary local access, use port forwarding:
kubectl port-forward service/hello-kubernetes 8080:80
While the command is running, open http://localhost:8080 in a browser. Port forwarding is intended for development and troubleshooting, not as a production exposure method.
Remove the tutorial resources when they are no longer required:
kubectl delete service hello-kubernetes
kubectl delete deployment hello-kubernetes
Apply a Kubernetes YAML Manifest
Declarative files are easier to review, version, and reproduce than a sequence of imperative commands. Save the earlier Deployment example as deployment.yaml, and then run:
kubectl apply -f deployment.yaml
kubectl get deployment web
kubectl get pods -l app=web
kubectl rollout status deployment/web
kubectl delete -f deployment.yaml
Essential kubectl Commands
| Kubernetes task | Command |
|---|---|
| List Pods in the current namespace | kubectl get pods |
| List Pods in every namespace | kubectl get pods -A |
| Show detailed Pod information | kubectl describe pod <pod-name> |
| Read container logs | kubectl logs <pod-name> |
| Follow container logs | kubectl logs -f <pod-name> |
| Run a shell inside a container | kubectl exec -it <pod-name> -- sh |
| View namespace events | kubectl get events --sort-by=.metadata.creationTimestamp |
| List supported API resources | kubectl api-resources |
| Explain a resource field | kubectl explain deployment.spec |
| Scale a Deployment | kubectl scale deployment/<name> --replicas=3 |
| Review rollout history | kubectl rollout history deployment/<name> |
| Undo the latest rollout | kubectl rollout undo deployment/<name> |
Many commands operate within the current namespace. Add -n <namespace> when a resource is located elsewhere, and verify the active context before changing a cluster.
Kubernetes Benefits and Operational Trade-Offs
Where Kubernetes Helps
- Declarative operations: Teams describe application state as manifests and let controllers reconcile it.
- Repeatable deployments: Workloads can follow a consistent API model across compatible environments.
- Service discovery: Services and cluster DNS provide stable names for changing Pod endpoints.
- Controlled updates: Deployments support rolling replacement and rollback workflows.
- Resource scheduling: Requests, limits, affinity rules, taints, and tolerations influence workload placement.
- Extensibility: Custom resources, controllers, operators, and admission policies extend the platform.
When Kubernetes May Add Unnecessary Complexity
Kubernetes introduces an API-driven operating model, networking layers, access controls, upgrades, observability requirements, and many configuration choices. A small application with simple deployment needs may be easier to operate with a managed application platform, a container service, or a smaller orchestration solution.
The decision should reflect workload scale, availability requirements, team experience, compliance needs, and the continuing cost of operating the platform.
Kubernetes Tutorial Learning Path
Use this sequence to progress from basic cluster navigation to production-oriented Kubernetes topics. Complete hands-on exercises after each group instead of learning only command syntax.
Kubernetes Getting Started Tutorials
Kubernetes Architecture
Learn how the control plane, worker nodes, scheduler, controllers, kubelet, networking, and container runtime work together.
Kubernetes Setup in Mac
Install the required tools, start a local Kubernetes environment on macOS, and verify the active cluster context.
Kubernetes Setup in Windows 10
Kubernetes Pods, Services, Deployments, and Configuration
- Kubernetes Pods: Understand Pod lifecycle, labels, container status, and multi-container patterns.
- Kubernetes Services: Expose Pods through stable discovery and network endpoints.
- Kubernetes Deployments: Manage replicas, image updates, rollout status, and rollback.
- Kubernetes ConfigMaps and Secrets: Separate runtime configuration from images and protect sensitive values.
Kubernetes Deployment and Release Workflows
- Kubernetes – Create Your First Deployment
- Kubernetes – Scaling Applications
- Kubernetes – Rolling Updates and Rollbacks
Kubernetes Networking and Traffic Management
- Kubernetes Service Types and Cluster DNS
- Kubernetes Ingress Controllers and HTTP Routing
- Kubernetes Network Policies
- Gateway API Concepts for Kubernetes Traffic Management
Kubernetes Storage and Stateful Workloads
- Kubernetes Persistent Volumes and Persistent Volume Claims
- Kubernetes StorageClasses and Dynamic Provisioning
- Kubernetes StatefulSets for Stateful Applications
- Kubernetes Jobs and CronJobs for Batch Processing
Kubernetes Security and Access Control
- Managing Access with Kubernetes Role-Based Access Control
- Kubernetes Service Accounts and Workload Identity
- Protecting Kubernetes Secrets
- Kubernetes Security Contexts and Pod Security Standards
- Kubernetes Network Segmentation and Admission Policies
Kubernetes Monitoring and Troubleshooting
- Debugging Kubernetes Pods and Containers
- Understanding Kubernetes Events and Logs
- Troubleshooting Pending, CrashLoopBackOff, and ImagePullBackOff Pods
- Kubernetes Resource Metrics and Autoscaling
- Kubernetes Monitoring with Prometheus and Grafana
Kubernetes Packaging and Automation
- Helm Charts for Packaging Kubernetes Applications
- Kustomize for Kubernetes Manifest Customization
- Kubernetes Operators and Custom Resources
- Integrating Kubernetes with CI/CD Pipelines
- GitOps Workflows for Kubernetes
Managed Kubernetes Cloud Platforms
- Running Kubernetes on AWS with Amazon EKS
- Running Kubernetes on Azure with Azure Kubernetes Service
- Running Kubernetes on Google Cloud with Google Kubernetes Engine
- Comparing Managed Kubernetes with Self-Managed Clusters
Kubernetes Application Use Cases
- Hosting a Web Application with Kubernetes
- Managing Microservices with Kubernetes
- Running Databases in Kubernetes
- Processing Scheduled and Batch Jobs
- Using Kubernetes for Local Development
- Serverless Workloads on Kubernetes with Knative
Common Kubernetes Beginner Mistakes
- Editing generated Pods directly: Change the owning Deployment, StatefulSet, Job, or other controller instead.
- Using an unversioned latest image tag: Prefer a controlled version tag or image digest so rollouts are reproducible.
- Omitting resource requests: Scheduling and autoscaling decisions become less reliable without realistic requests.
- Confusing readiness with liveness: Readiness removes a Pod from traffic, while liveness may restart its container.
- Assuming every Service is public: A ClusterIP Service is internal to the cluster.
- Treating base64 as Secret encryption: Base64 only encodes data.
- Ignoring namespaces and contexts: A correct command can affect the wrong environment when the active context is not checked.
- Running stateful software without a storage plan: Define persistence, backup, restore, disruption, and recovery requirements first.
Kubernetes Tutorial FAQs
Is Kubernetes the same as Docker?
No. Docker tools can build and run containers, while Kubernetes orchestrates containerized workloads across a cluster. Kubernetes communicates with a CRI-compatible container runtime and does not require Docker Engine on worker nodes.
What should a beginner learn before Kubernetes?
A beginner should understand containers, images, registries, ports, basic Linux commands, YAML, HTTP networking, and command-line usage. Familiarity with application logs and resource usage also helps with troubleshooting.
Can Kubernetes run on one machine?
Yes. Local learning tools can run a single-node or locally simulated multi-node cluster on one computer. A local cluster is suitable for tutorials and development but does not reproduce every production behavior.
What is the difference between a Pod and a Deployment?
A Pod is a running unit that contains one or more containers. A Deployment is a higher-level controller that manages stateless Pod replicas, replaces missing Pods, and coordinates rolling updates.
Do I need Kubernetes for every containerized application?
No. Kubernetes is useful when its scheduling, reconciliation, networking, scaling, policy, and extensibility features justify the operational complexity. Smaller applications may be simpler to run with a managed platform or basic container service.
Kubernetes Tutorial Editorial QA Checklist
- Verify that examples use supported Kubernetes API versions and valid resource fields.
- Confirm that each command states the required cluster, namespace, or local-tool assumption.
- Use control plane terminology instead of outdated “master node” wording except when explaining older material.
- Do not describe Docker Engine as the default Kubernetes worker runtime.
- Do not claim that Kubernetes Secrets are encrypted merely because values are base64-encoded.
- Distinguish startup, liveness, and readiness probes accurately.
- State that Ingress requires an Ingress controller and that storage behavior depends on the driver and StorageClass.
- Test YAML indentation, selectors, labels, image references, cleanup commands, and resource names before publication.
TutorialKart.com