Private corporate batches, live online cohorts and 1-on-1 mentoring in a Rust micro-proxy service mesh — automatic mTLS, golden metrics and authorization policy on Kubernetes — 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 Linkerd as a production system rather than a demo — the control plane split between destination, identity and proxy injector, how the Rust micro-proxy differs in cost and capability from an Envoy-based data plane, and how automatic mTLS actually works from ServiceAccount attestation through to short-lived certificate rotation. Sessions cover the parts that decide whether a mesh survives: trust anchor rotation before expiry, authorization policy toward default-deny, retries and timeouts that do not amplify failure, Flagger-driven canaries, multicluster service mirroring, and the linkerd check and tap workflow for diagnosis.
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 Linkerd that means a trainer who has run it in production — a Rust micro-proxy service mesh — automatic mTLS, golden metrics and authorization policy on Kubernetes — 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 Linkerd batchLinkerd is a service mesh for Kubernetes: a control plane running in the cluster plus a data plane of proxies injected beside every meshed workload. What distinguishes it is the proxy. Rather than adopting a general-purpose proxy, Linkerd ships linkerd2-proxy, a micro-proxy written in Rust for this one job — small memory footprint, no user-facing configuration language, and a deliberately narrow feature surface. The trade-off is explicit: less extensibility in exchange for far less operational complexity.
The control plane is three components. The destination service answers the proxies' questions about where a service lives and what policy applies; the identity service is a certificate authority that issues short-lived leaf certificates, using each pod's Kubernetes ServiceAccount token as the attestation; the proxy injector is a mutating webhook that adds the sidecar when a namespace or workload is annotated. From that, mutual TLS between meshed pods is automatic rather than configured — there is no step where an engineer writes a policy to turn encryption on.
Everything else builds on the proxy sitting in the request path. It records success rate, request rate and latency distribution for every meshed service, which the viz extension surfaces through Prometheus, a dashboard and the linkerd tap live request stream. Authorization is expressed with Server, HTTPRoute and AuthorizationPolicy resources, which support a genuine default-deny posture. Retries, timeouts and traffic splitting drive canary releases, usually with Flagger, and the multicluster extension mirrors services across clusters through a gateway so a remote service looks local.
Service mesh adoption stalled for a while because the first generation cost more to operate than the problems it solved. The reaction was not to abandon the model but to narrow it, and Linkerd is the clearest expression of that: encryption, identity, golden metrics and policy, without a configuration surface that needs its own specialist.
The pressure driving adoption is regulatory as much as architectural. Requirements for encryption in transit between workloads, and for a demonstrable identity on every connection, are difficult to satisfy with application-level TLS across a polyglot estate — every language needs its own certificate handling, rotation and verification. A mesh moves that to a uniform layer, and Linkerd's automatic mTLS with short-lived certificates gives a straightforward answer to an auditor.
The operational value shows up separately. Uniform success rate, latency and request volume for every service, without instrumenting any of them, changes what an incident looks like — the question moves from which team has metrics to which hop in the path degraded. That, plus retries and timeouts applied consistently rather than per-language, is usually what makes a mesh pay for itself.
Why a mesh exists before installing one. What moves out of application libraries, what the sidecar actually costs in latency and memory, and an honest comparison of Linkerd against Istio, Consul and doing nothing.
Topics: What a mesh takes over from application code · Sidecar cost: latency, memory and pod count · Linkerd against Istio and Consul on real criteria · Rust micro-proxy versus a general-purpose proxy · When a mesh is the wrong answer · Ingress is not a mesh
The components and what each does. Destination, identity and proxy injector; the linkerd2-proxy itself; and the traffic interception path through either an init container or the CNI plugin.
Topics: Destination service and service discovery · Identity service as a certificate authority · Proxy injector as a mutating webhook · linkerd2-proxy internals and resource profile · Traffic interception: init container versus CNI plugin · Extensions: viz, jaeger, multicluster · Namespace and workload annotations
Getting Linkerd into a cluster and keeping it there. CLI and Helm installation, high availability mode, meshing workloads incrementally, the check workflow, and the upgrade path that does not require a maintenance window.
Topics: linkerd install via CLI and via Helm · High availability mode and control plane sizing · Pre-install and post-install checks · Meshing by namespace and by workload annotation · Skipping ports and opaque ports · Upgrade sequence: CLI, control plane, data plane · Uninstalling and unmeshing cleanly · linkerd check as a diagnostic tool
The security core. Trust anchor and issuer certificates, how a pod proves who it is with its ServiceAccount token, short certificate lifetimes and automatic rotation — then the rotation procedures that must happen before expiry.
Topics: Trust anchor, issuer and leaf certificates · ServiceAccount token attestation · Certificate lifetime and automatic rotation · Verifying mTLS is actually in effect · Which traffic is and is not encrypted · Issuer rotation without downtime · Trust anchor rotation with cert-manager · Expiry monitoring and alerting
What the proxy gives you for free. Success rate, request rate and latency percentiles per service, route and pod; the viz extension and its Prometheus; live request inspection with tap; and distributed tracing through the jaeger extension.
Topics: Golden metrics: success rate, RPS, latency percentiles · viz extension architecture and Prometheus · linkerd viz stat, top, routes and edges · linkerd tap for live request inspection · Service profiles and per-route metrics · Exporting to an external Prometheus · Grafana dashboards · Tracing with the jaeger extension and context propagation
Reliability applied uniformly. Retry and timeout configuration through service profiles and HTTPRoute, retry budgets that prevent amplification, traffic splitting for progressive delivery, and Flagger driving canaries on real metrics.
Topics: Service profiles and route definitions · Retries, retry budgets and idempotency · Timeouts per route · HTTPRoute and the Gateway API model · Traffic splitting across backends · Flagger canary analysis and promotion · Automatic rollback on metric regression · Load balancing and request-level distribution
Turning identity into enforcement. Server and HTTPRoute resources, AuthorizationPolicy and MeshTLSAuthentication, and the incremental path from audit to default-deny without breaking traffic you forgot about.
Topics: Server resources and port-level policy · AuthorizationPolicy and required authentication · MeshTLSAuthentication and NetworkAuthentication · Route-level authorization with HTTPRoute · Default policy: all-unauthenticated to deny · Auditing before enforcing · Policy for unmeshed and external clients · Diagnosing a request denied by policy
Running the mesh beyond one cluster and beyond the first month. Service mirroring across clusters through a gateway, shared trust anchors, then the day-2 realities: resource tuning, failure modes, debugging and what breaks during upgrades.
Topics: Multicluster extension and the service mirror controller · Gateway topology and cross-cluster mTLS · Shared trust anchor across clusters · Failover across clusters · Proxy resource requests and limits at scale · Common failure modes and their signatures · linkerd diagnostics and proxy logs · Capacity planning and control plane scaling
We rebuild the agenda around the tools you actually run.
Request a custom agendaInject a live application namespace by namespace, then account for every added container, iptables rule and millisecond of latency.
Capture traffic to show encryption between meshed pods, then rotate the issuer certificate under load without a single failed request.
Use viz stat, edges, routes and tap to locate which service in a five-hop call chain is responsible for a latency regression.
Configure Flagger against mesh metrics, deploy a build with a raised error rate, and watch the analysis abort and revert the release.
Audit real traffic, write the minimal Server and AuthorizationPolicy set, then flip the namespace to default-deny and verify nothing broke.
Share a trust anchor, link two clusters, mirror services through the gateway, and fail traffic over from one cluster to the other.
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
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.
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.
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.
| 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.