Others · OTC-12

Kubernetes (K8s) Orchestration

Kubernetes (K8s) Orchestration is a hands-on course in running containers on Kubernetes, from its internal architecture and the Twelve-Factor App to Deployments, probes, autoscaling, RBAC, Services, Gateway API, StatefulSets and Helm. It suits developers, DevOps engineers and system administrators who have used Docker, and you leave able to deploy a microservices system to a cluster yourself.

Updated 8 Oct 2026

From 8,550 THB / person 9,500 −10% excl. VAT 7% · group rates available

Corporate training quote Join the waiting list

PDFDownload the course outline

Duration18 hours · 3 days
FormatOnsite / live online
Next roundOn request
CertificateIncluded

Course overview

Kubernetes is the standard platform for running containerised applications, both in the cloud and in an organisation's own data centre. It lets systems heal themselves when something fails, scale with demand and roll out new versions without downtime. Yet many common examples still rely on Ingress NGINX, which its project no longer maintains, or on older YAML patterns that no longer match current practice.

This course takes learners through Kubernetes 1.37, starting with setting up tools on Mac and Windows, reviewing how to build containers that are ready for a cluster, and designing applications to the Twelve-Factor App principles. It then explores the internal architecture and gives hands-on practice with Pods, Deployments, ConfigMaps, Secrets, probes and autoscaling, access control with RBAC, exposing services with Services and Gateway API, persistent data with Persistent Volumes and StatefulSets, and packaging with Helm 4. The course closes by deploying a complete microservices system. (3 days, 6 hours per day, 18 hours in total, Intermediate level.)

What you’ll gain

Install and set up a Kubernetes practice environment on Mac and Windows
Design applications to the Twelve-Factor App principles for cloud-native systems
Explain the internal architecture of Kubernetes and how each component works
Manage Pods, Deployments, rolling updates and rollbacks confidently with kubectl
Separate configuration with ConfigMaps and Secrets, and set up probes and autoscaling
Expose services with Services and Gateway API instead of the older Ingress
Choose between stateless and stateful approaches with Persistent Volumes and StatefulSets
Package and install applications with Helm 4

Who this course is for

Software developers and web developers who need to run applications on Kubernetes
DevOps engineers and system administrators who look after container platforms
IT infrastructure engineers building a cloud-native platform for their organisation
Solution architects who design systems on Kubernetes
Anyone who learned an older version of Kubernetes and wants to catch up with current practice

Prerequisites

Basic Linux command-line skills
Some Docker experience, such as building images and running containers (reviewed during the course)
A basic understanding of web applications and networking, such as IP addresses, ports and DNS
A Mac or Windows laptop with at least 16 GB of RAM that can run Docker Desktop, with permission to install software

Curriculum

Course Details

This course is the 2026 edition of Kubernetes (K8s) Orchestration. It has been rewritten for Kubernetes 1.37, moves from Ingress to Gateway API as the Kubernetes project recommends, and adds ConfigMaps, Secrets, probes, autoscaling, RBAC, StatefulSets and Helm 4. It runs for 3 days, 6 hours per day (18 hours in total, 09:00-16:00), as lectures with labs on a local cluster on each learner's laptop. Intermediate level. Learners take home a lab guide plus the YAML files and Helm charts for every lab.

Day 1 Getting Ready and Cloud-Native Concepts

Section 1: Lab: Setting Up Tools on Mac and Windows

Install Docker Desktop on macOS, and on Windows through WSL 2
Install kubectl, kind or minikube, and k9s
Create a multi-node local cluster with kind
Set up kubeconfig, contexts and a default namespace
Lab: create a first cluster and check node status

Section 2: Reviewing Containers Ready for Kubernetes

Common Docker commands and the container lifecycle
Write multi-stage Dockerfiles that run as a non-root user
Tag images so versions can be traced, and stop relying on latest
Push images to a container registry and load them into a kind cluster
Lab: build an image for a sample web API

Section 3: Kubernetes Overview

What Kubernetes is and what it solves that Docker alone cannot
Key strengths: self-healing, autoscaling, rolling updates and bin packing
The Kubernetes release cycle and choosing a supported version
Managed Kubernetes in the cloud compared with self-installed clusters
An overview of the CNCF ecosystem used alongside Kubernetes

Section 4: The Twelve-Factor App

Codebase, dependencies and config kept separate from code
Backing services, and build, release, run
Stateless processes, port binding and concurrency
Disposability, dev/prod parity, logs and admin processes
Workshop: review a sample app against the twelve factors and plan fixes

Section 5: Kubernetes Architecture

Control plane: API server, etcd, scheduler and controller manager
Worker nodes: kubelet, kube-proxy and a container runtime such as containerd
Desired state and the reconciliation loop
The roles of CNI, CSI and CoreDNS in a cluster
Lab: explore cluster components with kubectl and k9s

Day 2 Workloads, Configuration and Access

Section 6: Lab: Pods, Labels and kubectl

Write declarative manifests and use kubectl apply
Labels, selectors and annotations for grouping resources
Multi-container Pods, init containers and sidecar containers
View logs, exec into containers and debug with kubectl debug
Lab: run the sample app's Pods and fix a failing Pod

Section 7: Lab: ReplicaSets and Deployments

How a ReplicaSet keeps the desired number of Pods
Create a Deployment and scale its replicas
Rolling updates with maxSurge and maxUnavailable
View rollout history and roll back to a previous version
Lab: update the app without downtime, then roll back when a problem appears

Section 8: ConfigMaps, Secrets and Resources

Separate configuration with ConfigMaps as environment variables or files
Store sensitive data in Secrets, and what to watch for with encryption
Set CPU and memory requests and limits, and QoS classes
Change CPU and memory of running Pods with in-place Pod resize
Lab: move the app's configuration out of the image, Twelve-Factor style

Section 9: Lab: Health Checks and Autoscaling

How liveness, readiness and startup probes differ
Install metrics-server and view resource use with kubectl top
Horizontal Pod Autoscaler on CPU and memory
PodDisruptionBudgets to keep services up during node maintenance
Lab: run a load test and watch Pods scale out and back automatically

Section 10: Namespaces, RBAC and Team Separation

Separate teams or environments with namespaces
ServiceAccounts, Roles, ClusterRoles and RoleBindings
Limit resources with ResourceQuotas and LimitRanges
Pod Security Admission and basic securityContext settings
Lab: create a namespace for a dev team with permissions and quotas

Day 3 Networking, Storage and Workshop

Section 11: Lab: Services and Service Discovery

When to use ClusterIP, NodePort and LoadBalancer
In-cluster DNS and calling services across namespaces
EndpointSlices and selecting Pods that are ready for traffic
Headless Services for systems that need to address individual Pods
Lab: connect a frontend, an API and a database through Services

Section 12: Lab: Gateway API Instead of Ingress

The frozen status of Ingress and the retirement of Ingress NGINX
How GatewayClass, Gateway and HTTPRoute split responsibilities between teams
Host and path routing, and weighted traffic splitting for canaries
HTTPS on a Gateway with cert-manager
Lab: migrate the sample app's existing Ingress to Gateway API

Section 13: Storage and Stateful Workloads

Volumes, PersistentVolumes and PersistentVolumeClaims
StorageClasses and dynamic provisioning
When to stay stateless and when you need stateful
StatefulSets for databases and caches with stable Pod names
Lab: run PostgreSQL as a StatefulSet and check that data survives

Section 14: Lab: Packaging Apps with Helm 4

Charts, values and releases in Helm
What changed in Helm 4, such as server-side apply by default
Separate values for dev, staging and production
Upgrade, roll back and check release status
Lab: turn the sample app's manifests into a Helm chart

Section 15: Workshop: Deploying a Microservices System

Design a sample system with a frontend, several APIs and a database
Deploy with Helm, including ConfigMaps, Secrets and probes
Expose it through Gateway API with HTTPS
Test autoscaling, rolling updates and recovery when Pods fail
A pre-production checklist and next steps towards GitOps

Schedule & training options

For individuals — public rounds

No public rounds are open right now. Join the waiting list and we will contact you first when the next round opens, or ask us on LINE. Or call 02-570-8449 or 088-807-9770

Join the waiting list Ask about rounds

For organisations — in-house / private

Tailor the content to your team’s tools and projects
Your dates, at your office or live online
Quotation with tax ID for procurement

Corporate training quote

Instructors

Samit KoyomFounder & CEO, IT Genius Engineering

Frequently asked questions

How are Kubernetes and Docker different?

Docker builds images and runs containers on a single machine, while Kubernetes manages many containers across many machines at once. It keeps the desired number of Pods running, restarts containers that fail, scales with demand and rolls out new versions without downtime. The two work together: you build images with Docker, and Kubernetes runs them through a container runtime such as containerd, which runs the standard OCI images Docker produces.

What is the difference between ClusterIP, NodePort and LoadBalancer Services in Kubernetes?

ClusterIP is the default and gives an internal address for services that talk to each other, such as an API calling a database. NodePort opens the same port on every node for outside access, which suits testing. LoadBalancer requests a load balancer from the cloud or an on-premises controller to get an external IP. For websites with several domains or paths, Gateway API is now commonly placed in front of Services to handle routing and HTTPS in one place.

Why should I move from Ingress to Gateway API?

The Kubernetes project has frozen the Ingress API. It still works and there are no plans to remove it, but Gateway API is recommended as its successor. Ingress NGINX, the most popular controller, has not been maintained since March 2026, so it no longer receives security patches. Gateway API separates platform and application responsibilities through GatewayClass, Gateway and HTTPRoute, and supports weighted traffic splitting natively. Migration is a one-time conversion of existing Ingress resources into HTTPRoutes.

Who is the Kubernetes (K8s) Orchestration course for, and what should I know beforehand?

It suits software developers, DevOps engineers, system administrators, IT infrastructure engineers and solution architects who need to run applications on Kubernetes or build a cloud-native platform, as well as people who learned an older version and want to catch up. You should be comfortable with the Linux command line, have some Docker experience, and understand the basics of web applications and networking, such as IP addresses, ports and DNS.

What will I be able to do after the Kubernetes (K8s) Orchestration course?

You will be able to set up a local development cluster, design apps to the Twelve-Factor App principles, manage Deployments with rolling updates and rollbacks, separate configuration with ConfigMaps and Secrets, set up probes and autoscaling, control access with RBAC, expose services through Services and Gateway API with HTTPS, run stateful workloads with StatefulSets and package apps with Helm 4. Participants who complete the training receive a Certificate of Completion with its own number, which can be verified online.

What tools do I need to prepare for the Kubernetes (K8s) Orchestration course?

Bring a macOS or Windows laptop with at least 16 GB of RAM and permission to install software, able to run Docker Desktop (with WSL 2 on Windows). In class you install kubectl, kind or minikube, k9s and Helm 4 step by step together. All the tools are open source or free, and the labs run on a local cluster, so no cloud account is needed.