Private corporate batches, live online cohorts and 1-on-1 mentoring in provisioning, managing and operating fleets of Kubernetes clusters with Rancher — 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 Rancher as a fleet problem rather than a UI tour — the server and downstream agent architecture first, so that when a cluster shows Unavailable engineers know whether to look at the tunnel, the API server, the kubelet or etcd. Sessions run against real clusters built with RKE: nodes are deliberately failed and recovered, etcd snapshots are restored, Rancher itself is backed up and rebuilt, and Projects, quotas and RBAC are configured until multi-team sharing genuinely holds under test.
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 Rancher that means a trainer who has run it in production — provisioning, managing and operating fleets of Kubernetes clusters with Rancher — 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 Rancher batchRancher is an open-source management platform for Kubernetes. It is not a Kubernetes distribution competing with the cluster you already run — it sits above clusters and gives one control plane for all of them, whether they are clusters Rancher provisioned itself, managed services such as EKS, AKS and GKE that were imported, or bare-metal clusters registered by an agent. That multi-cluster position is the whole point: authentication, RBAC, monitoring, logging, policy and application catalogues are configured once and projected down into every cluster under management.
The architecture has two halves. The Rancher server holds the management state and presents the UI, API and kubectl proxy; a cluster agent and node agents in each downstream cluster maintain an outbound tunnel back to it, which is why Rancher can manage clusters behind NAT without inbound firewall rules. Rancher's own installation is itself a Kubernetes workload in the supported topology, so backup, restore and upgrade of the management plane follow the same rules as any other application.
Rancher also ships its own distributions and the operational tooling around them. RKE builds a cluster from Docker containers on prepared nodes using a single declarative cluster.yml; RKE2 and K3s cover the security-hardened and lightweight edge cases; and cluster templates, node templates and cloud credentials make provisioning repeatable. On top sit the features engineers use daily — Projects as a grouping of namespaces with shared quota and RBAC, integrated monitoring with Prometheus and Grafana, logging, alerting, and an application catalogue built on Helm.
Almost no organisation now runs one Kubernetes cluster. Between environments, regions, regulatory boundaries, edge sites and acquired estates, cluster count grows faster than the platform team does, and the operational problem shifts from running Kubernetes to running many Kubernetes consistently. That is the problem Rancher exists to solve, and it is why it keeps appearing in platform engineering job specifications alongside — not instead of — Kubernetes itself.
The edge and on-premises story has strengthened the case further. K3s and RKE2 put conformant Kubernetes on hardware where a full control plane never fitted, and Rancher is how hundreds of those clusters are registered, upgraded and observed from one place. Retail, manufacturing, telecom and industrial estates are exactly where this shows up, and they are estates that cannot be re-platformed onto a single managed service.
What employers are actually hiring for is the operational depth. Provisioning a cluster from the Rancher UI takes minutes; knowing how the downstream agent tunnel works when a cluster goes unavailable, how to back up and restore both Rancher and etcd, how to plan a Kubernetes version upgrade across a fleet, and how to structure Projects so twenty teams share clusters without stepping on each other is the part that takes experience — and the part interviews probe.
How Rancher is built, because every later diagnosis depends on it. The server components and what each owns, the agent-initiated tunnel that lets Rancher manage clusters it cannot reach inbound, and the architectural decisions that determine whether a Rancher deployment stays supportable — sizing, high availability, and the separation between the management cluster and the workload clusters it manages.
Topics: Learning the Rancher architecture and its components · Rancher server components and their responsibilities · Communication with downstream clusters — cluster agents, node agents and the tunnel · Architectural best practices and supported topologies · Local management cluster versus downstream clusters · High availability and sizing for the Rancher server · Authentication flow and the kubectl proxy
Rancher Kubernetes Engine from the ground up. Installing RKE, preparing nodes so the installation actually succeeds, then the cluster configuration file that defines the whole cluster declaratively — nodes, roles, network plugin, addons — and the certificate options that decide how the cluster's PKI is managed.
Topics: Installing RKE and the supporting tooling · Preparing nodes for Kubernetes — kernel, runtime, ports and users · Creating the cluster configuration file (cluster.yml) · Node roles: etcd, controlplane and worker · Certificate options and custom certificate authorities · Deploying Kubernetes with rke up · Reading kube_config and the cluster state file · RKE2 and K3s as the current distribution options
Keeping a cluster alive after it exists. Protecting the installation files and state without which recovery is impossible, etcd snapshots and a genuine restore, Kubernetes version upgrades and what happens to workloads during them, certificate rotation before expiry becomes an outage, and adding or removing nodes without disrupting quorum.
Topics: Secure the installation files and cluster state · Backups and disaster recovery — etcd snapshots and restore · Upgrading Kubernetes with RKE and the upgrade strategy options · Certificate management and rotation · Adding and removing nodes, and etcd quorum implications · Draining and cordoning nodes for maintenance · Validating cluster health after every operation
The management plane itself, in both supported shapes. The single-container Docker installation for evaluation and small estates, and the Helm-based installation into a Kubernetes cluster for production. Backups, restores and upgrades are treated as the core of the module, because losing Rancher without a backup means rebuilding every cluster relationship by hand.
Topics: Installing Rancher with Docker — single-node deployment · Making and restoring backups of a Docker-based Rancher · Upgrading a Docker-based Rancher installation · Installing Rancher with Kubernetes — deploying into RKE with Helm · Certificates, ingress and load balancer requirements · Making backups with the Rancher Backup Operator · Restoring Rancher from a backup into a new cluster · Upgrading Rancher and version compatibility with downstream clusters
The decisions taken before any cluster is created. Where a cluster should live and what that choice costs, the limitations that come with each cluster type, node resource requirements that are realistic rather than minimal, the networking and port requirements that break installations when missed, and how cluster roles should be distributed.
Topics: Where will my cluster live — cloud, on-premises, hosted or edge · Limitations within certain cluster types · Node resource requirements and sizing · Networking and port requirements between Rancher and downstream nodes · Cluster roles and control plane distribution · Imported clusters versus Rancher-provisioned clusters · Managed services — EKS, AKS, GKE — under Rancher management
Repeatable provisioning rather than one-off builds. RKE configuration options exposed through Rancher, cluster templates that enforce a standard across teams, node templates and cloud credentials that let Rancher create infrastructure itself, and the cloud provider integration that gives clusters load balancers and storage.
Topics: RKE configuration options in the Rancher UI and API · RKE templates and enforcing standards across teams · Node templates and node pools · Cloud credentials and secure credential handling · Cloud providers and their integration points · Deploying a cluster end to end from Rancher · Custom clusters using the registration command · Cluster labels, annotations and organisation at fleet scale
The module that pays for the course. A layered diagnostic method — what could possibly go wrong, and in what order to check it — worked through the whole stack: Rancher's API server, the container runtime, node conditions, the kubelet, then the harder layer of etcd, control plane components, nginx-proxy and container networking.
Topics: What could possibly go wrong — a systematic triage order · Rancher's API server and management plane failures · Docker and container runtime problems on nodes · Node conditions: disk pressure, memory pressure, network unavailable · Kubelet and worker node diagnosis · etcd — quorum, latency, disk and defragmentation · Control plane component failures · nginx-proxy and the downstream connection path · Container network and CNI troubleshooting
Ongoing cluster management once the fleet exists. Editing cluster options safely and knowing which changes trigger a node replacement, planning and executing Kubernetes upgrades across managed clusters, then the two command line tools — kubectl through the Rancher proxy, and the Rancher CLI for management-plane operations.
Topics: Editing cluster options and the effect of each change · Upgrading Kubernetes on Rancher-managed clusters · Upgrade strategy, drain settings and maintenance windows · kubectl through the Rancher kubeconfig and proxy · Rancher CLI: installation, contexts and common operations · Managing multiple clusters from one context · Automating cluster operations through the Rancher API
Observability projected across the fleet from one place. Enabling the advanced monitoring stack and what it deploys, using and extending the supplied Grafana dashboards, then configuring notifiers and alerts so that a problem reaches a human, and shipping logs off the cluster before a node failure takes them with it.
Topics: Enable advanced monitoring — Prometheus and the monitoring stack · Use the Grafana dashboards and add your own · PromQL basics for cluster and workload questions · Configure notifiers — Slack, email, PagerDuty, webhooks · Configure alerts at cluster and project level · Configure logging and log destinations · Retention, cardinality and the cost of monitoring at fleet scale
How several teams share clusters without interfering with each other. Namespaces as the Kubernetes primitive, then Rancher Projects as a grouping of namespaces carrying shared RBAC, quota and monitoring. Resource quotas and limits are the enforcement mechanism, and project-level monitoring, alerts and logging are what make a Project a genuine tenancy boundary.
Topics: Namespace overview and lifecycle · Projects as namespace groups · Project security, members and role bindings · Resource quotas at project and namespace level · Resource limits, requests and default limit ranges · Namespace management inside a project · Project monitoring, alerts and logging · Designing a tenancy model for many teams
Getting applications onto the clusters. Deploying workloads through Rancher and through manifests, upgrading them with controlled rollout strategies, rolling back when a release is wrong, then persistent storage — provisioning it, classing it, and using it from a workload that must survive a pod being rescheduled.
Topics: Deploy workloads through the Rancher UI and from manifests · Upgrading workloads and rollout strategies · Rolling back workloads and revision history · Provisioning storage — StorageClasses and dynamic provisioning · Using persistent volumes and claims from a workload · Access modes and their consequences for scaling · Longhorn and storage options for on-premises clusters · Stateful workloads, StatefulSets and volume lifecycle
The remaining pieces of a working platform. ConfigMaps, secrets, certificates and registry credentials, and the naming discipline that keeps them manageable. Then service discovery and load balancing — the layer four versus layer seven distinction, LoadBalancer services and Ingress — and the Helm-backed catalog that turns applications into something teams can self-serve.
Topics: ConfigMaps and dynamic application configuration · Secrets, certificates and registry credentials · Resource naming conventions and why they matter at scale · Services in Rancher and how discovery works · Layer 4 versus layer 7 load balancing · LoadBalancer services and Ingress controllers · The Rancher application catalog and how it works · Catalog scope, global catalogs and adding custom Helm repositories · Using catalog apps and managing their upgrades
We rebuild the agenda around the tools you actually run.
Request a custom agendaPrepare nodes, write cluster.yml by hand, deploy with rke up, and verify every control plane, etcd and worker component is healthy before anything else is installed.
Take an etcd snapshot, destroy the cluster, restore from the snapshot, and confirm workloads and state returned intact.
Back up a Kubernetes-based Rancher installation, delete it, restore into a fresh cluster and watch every downstream cluster reconnect.
Diagnose clusters failing at different layers — agent tunnel, kubelet, etcd quorum and CNI — using a triage order rather than guesswork.
Build projects with quotas, limits and scoped RBAC, then attempt to break the boundaries under load and confirm they hold.
Deliver provisioned clusters from a template, tenanted projects, monitoring and alerting, a custom Helm catalog and a stateful application behind ingress.
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
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
Very good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
| 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.