Private corporate batches, live online cohorts and 1-on-1 mentoring in extending Kubernetes orchestration and device management to the network edge — 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 KubeEdge from the connectivity model outward — CloudCore and EdgeCore internals, the EdgeHub to CloudHub tunnel, and what MetaManager actually caches, before any workload is deployed. The syllabus then covers device management as a first-class topic: DeviceModel and Device CRDs, DeviceTwin desired versus reported state, and mappers over MQTT. Sessions run against real edge nodes and include deliberately cutting the link, because a KubeEdge deployment is only understood once you have watched it survive being offline.
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 KubeEdge that means a trainer who has run it in production — extending Kubernetes orchestration and device management to the network edge — 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 KubeEdge batchKubeEdge is a CNCF project that extends Kubernetes orchestration out to edge nodes — factory floors, retail sites, vehicles, base stations — where the network is slow, expensive or frequently absent. It keeps the Kubernetes API as the single control surface but changes the assumption that every node can reach the API server continuously.
The architecture splits across two sides. On the cloud side, CloudCore runs EdgeController, DeviceController and CloudHub. On the edge side, EdgeCore runs EdgeHub, Edged, MetaManager, DeviceTwin, EventBus and ServiceBus. EdgeHub and CloudHub hold a persistent WebSocket or QUIC tunnel rather than having every edge node speak directly to the API server, which cuts the connection count and the bandwidth. MetaManager caches the metadata an edge node needs in a local datastore, so when the link drops the node keeps running its pods, restarts them if they die, and reconciles when connectivity returns. That offline autonomy is the single most important thing KubeEdge adds.
The second half of the project is device management, which plain Kubernetes has no answer for. DeviceModel and Device custom resources describe physical equipment; mappers translate between the device protocol — Modbus, Bluetooth, OPC-UA — and MQTT; DeviceTwin holds desired and reported state so an operator can drive a sensor or actuator through kubectl. EdgeMesh then provides service discovery and pod-to-pod traffic between edge nodes that have no shared overlay network.
Edge deployments have moved from pilots to fleets. Manufacturing, energy, retail, logistics and telecoms all now run compute at hundreds or thousands of sites, and the operational question is the same everywhere: how do you manage that estate without inventing a bespoke deployment system per site?
Kubernetes is the obvious answer and a bad fit out of the box. Its control loop assumes a reliable, low-latency link to the API server; a node that cannot reach the control plane for six hours gets its pods evicted. Nodes at the edge are also small, sometimes ARM, sometimes behind NAT with no inbound path, and they are attached to physical equipment that has no Kubernetes representation at all.
KubeEdge exists to close exactly those gaps, and the skills it needs are not the skills a cloud-native Kubernetes team already has. Sizing EdgeCore for a constrained device, reasoning about what survives a disconnection, designing DeviceModels for real protocols, and upgrading a fleet of edge nodes you cannot SSH into are all specific problems with specific answers — and they are what teams get wrong on the first production rollout.
The constraints that define edge workloads — latency budgets, bandwidth cost, intermittent links, constrained and heterogeneous hardware, physical equipment — and how each one breaks an assumption in the standard Kubernetes control loop. Then an honest comparison of the approaches available.
Topics: Edge workload constraints: latency, bandwidth, disconnection, hardware · Kubernetes assumptions that fail at the edge · KubeEdge vs K3s vs OpenYurt vs SuperEdge · The KubeEdge project scope: orchestration plus device management · Reference use cases: industrial, retail, telco, transport · Sizing and hardware expectations for edge nodes
The component model in detail, because every later troubleshooting session depends on it. What EdgeController, DeviceController and CloudHub do on the cloud side; what EdgeHub, Edged, MetaManager, DeviceTwin, EventBus and ServiceBus do on the edge; and how the WebSocket or QUIC tunnel replaces direct API server access.
Topics: CloudCore modules: EdgeController, DeviceController, CloudHub · EdgeCore modules: EdgeHub, Edged, MetaManager, DeviceTwin, EventBus, ServiceBus · The CloudHub to EdgeHub tunnel: WebSocket and QUIC · Message routing and the beehive module framework · MetaManager and the local metadata store · Version skew between cloud and edge components
Standing up a working cloud side and joining real edge nodes. keadm init on an existing cluster, token generation, keadm join from the edge, the certificate bootstrap that most first installs get wrong, and the container runtime configuration for constrained nodes.
Topics: Prerequisites on the cloud cluster and on edge hosts · keadm init, keadm gettoken and keadm join · Certificate bootstrap and rotation · Configuring the edge container runtime · cloudcore.yaml and edgecore.yaml configuration · CloudCore high availability and exposure options · Diagnosing a node that joins but never becomes Ready
Scheduling and lifecycle when the node may be unreachable. Targeting edge nodes with labels and affinity, what the standard eviction and tolerance behaviour does to a disconnected node, and how MetaManager lets pods keep running and restarting through an outage.
Topics: Labelling and targeting edge nodes · Node affinity, tolerations and eviction behaviour · DaemonSets and per-site workloads · Offline autonomy: what MetaManager caches and what it does not · Image pull strategy on bandwidth-constrained links · Resource limits on small nodes · Reconciliation behaviour when the link returns
The part of KubeEdge that has no Kubernetes equivalent. Describing physical equipment as custom resources, the desired-versus-reported state model in DeviceTwin, and the MQTT message flow through EventBus that connects a sensor or actuator to the Kubernetes API.
Topics: DeviceModel: properties, data types and access modes · Device instances and node binding · DeviceTwin: desired vs reported state and update flow · EventBus and the MQTT broker topology · Message topics and payload formats · Driving an actuator through kubectl · Handling devices that are offline or reporting stale values
Connecting real protocols and real services. What a mapper is and how it bridges Modbus, Bluetooth or OPC-UA to MQTT, then EdgeMesh for service discovery and pod-to-pod traffic between edge nodes that share no overlay network, plus ServiceBus and Router for custom message paths.
Topics: Mapper architecture and the mapper framework · Modbus, Bluetooth and OPC-UA mappers · Writing a custom mapper for an unsupported protocol · EdgeMesh: service discovery and cross-node traffic · ServiceBus for HTTP access to edge-local services · Router and custom message delivery · Debugging MQTT topic and payload mismatches
The work that starts once there are two hundred sites instead of two. Upgrading edge nodes you cannot log into, rotating certificates before they expire, collecting telemetry over a thin link, securing the tunnel, and building a rollout process that fails safely at one site rather than all of them.
Topics: Upgrading CloudCore and EdgeCore, and version compatibility · Remote edge node upgrade strategies and staged rollout · Certificate lifetime and rotation across a fleet · Observability on constrained nodes and bandwidth-aware telemetry · Securing the tunnel and edge node identity · Backup, re-provisioning and site replacement · Structured troubleshooting: cloud side, tunnel, edge side, device layer
We rebuild the agenda around the tools you actually run.
Request a custom agendaInstall CloudCore on a cluster, join two edge nodes with keadm, and verify the tunnel, certificates and node registration in both directions.
Deploy a site workload, cut the cloud link, kill the pod, and prove that Edged restarts it from the MetaManager cache with no control plane reachable.
Define a DeviceModel and Device for a simulated sensor and actuator, then drive desired state through the API and watch reported state converge.
Wire an existing protocol mapper to a simulated device, verify the MQTT topics and payloads, and consume the readings from an edge workload.
Use EdgeMesh to reach a service running on one edge node from a pod on another, then break DNS and diagnose it.
Upgrade CloudCore and a set of edge nodes in waves, verify each wave, and produce the runbook and rollback position for a real fleet.
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
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
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.
| 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.