Private corporate batches, live online cohorts and 1-on-1 mentoring in production Kubernetes cluster provisioning and lifecycle management with Ansible — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches Kubespray as cluster lifecycle rather than a one-time install — inventory and group_vars design, CRI and CNI selection and their consequences, stacked versus external etcd, then the playbooks that matter after day one: scale.yml, remove-node.yml, upgrade-cluster.yml and certificate renewal. Sessions run against real multi-node hosts and deliberately include failed upgrades, lost etcd quorum and air-gapped installs, because those are the situations where Kubespray knowledge is actually tested.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For Kubespray that means a trainer who has run it in production — production Kubernetes cluster provisioning and lifecycle management with Ansible — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private Kubespray batchKubespray is a Kubernetes SIG project that provisions production-grade Kubernetes clusters using Ansible. It is not a new orchestrator and not an abstraction over kubeadm — it wraps kubeadm in a large, opinionated set of Ansible roles that handle everything around it: operating-system preparation, container runtime installation, certificate distribution, etcd, load balancing for the API server, the CNI plugin, CoreDNS, and the cluster add-ons most teams end up installing by hand anyway.
The interface is an Ansible inventory. You declare which hosts belong to the kube_control_plane, etcd and kube_node groups, override defaults in group_vars/k8s_cluster, and run cluster.yml. The same repository ships the playbooks for the rest of the cluster's life — scale.yml to add nodes, remove-node.yml to drain and evict one, upgrade-cluster.yml to move between minor versions serially, and reset.yml to tear the whole thing down. That lifecycle coverage is the reason teams choose Kubespray over a one-shot installer.
It targets the environments managed control planes do not reach: bare metal, vSphere, OpenStack, air-gapped data centres, regulated estates that require a specific CNI or a hardened kubelet configuration. Kubespray gives you containerd or CRI-O, Calico or Cilium or Flannel, stacked or external etcd, and a documented path to change any of those decisions later — at the cost of owning the cluster yourself.
Managed Kubernetes solved the easy case. What it did not solve is the estate that has to run on-premises for latency, data residency or regulatory reasons, and that population is not shrinking — it is growing as edge sites, sovereign cloud requirements and repatriated workloads pile up.
Kubespray is the tool most of those teams land on, because the alternatives are worse. Hand-rolled kubeadm scripts work until the first upgrade. Vendor distributions solve provisioning but bring a licence and a support boundary. Kubespray is a well-maintained SIG project, tracks upstream Kubernetes closely, and expresses the whole cluster as inventory and variables that live in your own Git repository.
The skills gap is specific and predictable. Teams can usually get cluster.yml to complete once. What they struggle with is the second year: upgrading across three minor versions without an outage, replacing a failed etcd member, rebuilding a control-plane node, running the whole thing air-gapped behind a local registry, and keeping the inventory reviewable when four clusters share one repository.
The provisioning landscape before the tool. What kubeadm does and deliberately does not do, how Kubespray layers Ansible on top of it, and an honest comparison against kops, cluster-api, vendor distributions and managed control planes — including the cases where Kubespray is the wrong answer.
Topics: What kubeadm handles and what it leaves to you · Kubespray architecture: Ansible roles over kubeadm · Kubespray vs kops vs Cluster API vs managed control planes · Supported platforms: bare metal, vSphere, OpenStack, public cloud · Version support policy and upstream tracking · Repository layout and the playbook set
Kubespray failures are usually Ansible failures. The subset of Ansible that matters here: inventory and group_vars precedence, connection and privilege escalation, tags, --limit, serial execution, and reading a failed task well enough to know whether to fix the host or the variable.
Topics: Control node setup and Python dependency pinning · Inventory files, host groups and group_vars precedence · SSH connectivity and become configuration · Tags and running a subset of roles · --limit and serial behaviour in Kubespray playbooks · Reading Ansible failure output and increasing verbosity
The part that decides whether the estate stays maintainable. Building an inventory from the sample, the meaning of the kube_control_plane, etcd and kube_node groups, HA topology choices, API server load balancing, and how to structure a repository that holds four clusters without copy-paste.
Topics: Creating an inventory from inventory/sample · kube_control_plane, etcd, kube_node and calico_rr groups · Stacked vs external etcd and how to choose · API server load balancing: kube-vip, HAProxy and keepalived, external LB · Sizing control plane and etcd for a workload · Multi-cluster repository layout and shared group_vars
Container runtime, network plugin and addressing are decided once and lived with. Working through k8s-cluster.yml and addons.yml properly: containerd versus CRI-O, Calico versus Cilium versus Flannel, pod and service CIDR sizing, DNS with CoreDNS and nodelocaldns, and the add-ons worth enabling at provision time.
Topics: container_manager: containerd and CRI-O configuration · kube_network_plugin and the CNI trade-offs · kube_pods_subnet, kube_service_addresses and CIDR sizing · CoreDNS, nodelocaldns and dns_mode · addons.yml: ingress-nginx, MetalLB, cert-manager, metrics-server, Helm · Kubelet, API server and audit configuration overrides
Running cluster.yml end to end against real hosts, then verifying the result rather than assuming it. Preflight requirements, what the run actually does in order, retrieving kubeconfig artifacts, and the failure modes that dominate first attempts.
Topics: Host preflight: kernel modules, swap, sysctl, firewall and time sync · Running cluster.yml and reading the phases · kubeconfig artifacts and remote access · Verifying control plane, etcd health and CNI connectivity · Common failure modes: download timeouts, mismatched Python, DNS, SELinux · Idempotency and safe re-runs
The work Kubespray is actually chosen for. Adding and removing nodes without disturbing workloads, upgrading across minor versions one step at a time, renewing certificates before they expire, and recovering etcd when a member or quorum is lost.
Topics: scale.yml and adding worker and control-plane nodes · remove-node.yml, drain behaviour and etcd member removal · upgrade-cluster.yml, serial upgrades and version skew rules · Graceful vs non-graceful upgrade paths · Certificate expiry and renewal · etcd backup, member replacement and quorum recovery · reset.yml and safe teardown
Kubespray in constrained environments. Running with no internet through a local registry and file mirror, applying the hardening variables for a security-reviewed cluster, and driving the whole thing from CI so cluster changes go through review like any other code.
Topics: Offline installs: local container registry and binary mirror · download_run_once, download_localhost and image caching · Hardening variables: kubelet, API server flags, audit policy, encryption at rest · Node labels, taints and role assignment from inventory · Testing changes with Vagrant and Molecule before production · Driving Kubespray from a CI pipeline with review gates · Secrets handling for cluster credentials
We rebuild the agenda around the tools you actually run.
Request a custom agendaBuild a shared-variable inventory layout covering a staging and a production cluster, with HA control plane groups and no duplicated configuration.
Run cluster.yml against fresh hosts, resolve the preflight failures it exposes, and verify control plane, etcd and CNI health before declaring it done.
Deploy the identical inventory with Calico and then Cilium, compare the pod-to-pod path, and document which one you would keep and why.
Upgrade a running cluster with upgrade-cluster.yml while a workload serves traffic, measuring disruption at each node.
Deliberately destroy an etcd member, restore quorum, remove the dead member and join a replacement without losing cluster state.
Stand up a local registry and binary mirror, cut external access, and provision a full cluster offline — then upgrade it the same way.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
Good discussion, helped us to understand different tools in SRE.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.