Private corporate batches, live online cohorts and 1-on-1 mentoring in traffic management, mutual TLS, authorization and telemetry across a Kubernetes service mesh — 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 Istio through the proxy rather than the manifest — every VirtualService and AuthorizationPolicy is checked against the Envoy configuration it actually produces with istioctl proxy-config and proxy-status, so engineers learn to verify intent instead of assuming it. Sessions run live on a real mesh: mTLS is enabled and then proved with a capture, authorization policies are written until the wrong caller is genuinely refused, and traffic is shifted, mirrored and deliberately faulted so failure behaviour is observed rather than described.
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 Istio that means a trainer who has run it in production — traffic management, mutual TLS, authorization and telemetry across a Kubernetes service mesh — 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 Istio batchIstio is a service mesh for Kubernetes. It moves the cross-cutting concerns of service-to-service communication — retries, timeouts, load balancing, mutual TLS, authorization, and telemetry — out of application code and into the infrastructure layer, where they are configured declaratively and applied uniformly regardless of what language each service is written in.
The architecture has two planes. The control plane, istiod, watches Kubernetes and Istio configuration, converts it into Envoy xDS configuration, and issues the SPIFFE-format workload identities that mutual TLS depends on. The data plane is Envoy: historically a sidecar proxy injected into every pod, and in ambient mode a per-node ztunnel for identity and mTLS with optional per-namespace waypoint proxies for layer seven policy. Every request between meshed workloads passes through a proxy, which is what makes uniform policy and telemetry possible without touching application code.
Configuration is a small set of custom resources with well-defined roles. Gateway and VirtualService control how traffic enters and how it is routed and split; DestinationRule defines subsets, load balancing, connection pools and outlier detection; ServiceEntry brings external dependencies into the mesh; PeerAuthentication sets mTLS mode; RequestAuthentication validates JWTs; and AuthorizationPolicy decides who may call what. Istio increasingly supports the Kubernetes Gateway API as the standard replacement for its own ingress objects, and the Telemetry API governs metrics, tracing and access logs consumed through Prometheus, Grafana, Jaeger and Kiali.
Microservice estates reach a point where the same problems recur in every service: a retry storm that amplifies an outage, an unencrypted internal hop that fails an audit, a latency regression nobody can attribute, and authorization logic reimplemented differently in six languages. Solving those in application libraries means every team must upgrade in step, which never happens. Istio moves them into infrastructure, which is why it keeps reappearing on platform engineering roadmaps despite its reputation for complexity.
Regulation has become the strongest driver. Zero-trust mandates and internal audit requirements increasingly ask for encryption in transit between every workload and identity-based authorization rather than network-based, and mutual TLS with SPIFFE identities issued per workload is the most practical way to satisfy that on Kubernetes without changing applications. Progressive delivery is the second driver: percentage-based traffic shifting, mirroring and header-based routing are mesh features that make canary releases a configuration change rather than a deployment pipeline rewrite.
Istio has also changed materially, and much of the available material has not kept up. Ambient mode removes sidecars entirely for many workloads, the Gateway API is replacing Istio's own ingress resources, and revision-based canary upgrades are the supported path rather than in-place ones. Teams need someone who can teach the version they are running and the migration path to the one they are not.
What a mesh is for, stated honestly — including where it is the wrong answer and the cost it adds. Then the architecture: istiod and its responsibilities, Envoy as the data plane, the xDS protocol between them, and the difference between sidecar and ambient modes with a clear-eyed comparison of what each gives up.
Topics: Cross-cutting concerns in microservices and why libraries fail to solve them · Istio architecture: istiod, Envoy proxies and the xDS protocol · Sidecar injection — automatic, manual and namespace labels · Ambient mode: ztunnel, waypoint proxies and when to use it · The resource model: Gateway, VirtualService, DestinationRule, ServiceEntry · Kubernetes Gateway API and its relationship to Istio's own resources · The cost of a mesh: latency, resources and operational overhead · When not to adopt a service mesh
Getting Istio into a cluster in a way you can get it back out of. istioctl and Helm installation, configuration profiles and IstioOperator, then the part that matters most in production: revisions, revision tags, and canary upgrades that move workloads onto a new control plane namespace by namespace rather than restarting the entire mesh.
Topics: Installing with istioctl, Helm charts and configuration profiles · IstioOperator resource and MeshConfig options · Revisions and revision tags · Canary control plane upgrades and workload migration · Sidecar injection control: labels, annotations and exclusions · Resource sizing for istiod and the proxies · Uninstalling cleanly and removing a mesh from a cluster · Multi-version coexistence during migration
The routing layer, which is where most people start and where most misconfiguration lives. Gateways for ingress, VirtualServices for matching and routing, DestinationRules for subsets and load balancing, and ServiceEntry for external dependencies. Every rule is verified against the Envoy configuration it produces, because a VirtualService that looks right and matches nothing is the single most common Istio problem.
Topics: Gateway resources, ingress gateways and TLS termination modes · VirtualService: hosts, match conditions, precedence and rewrites · DestinationRule subsets and load balancing policies · Weighted traffic splitting and header-based routing · Traffic mirroring for shadow testing · ServiceEntry and controlling access to external services · Egress gateways and forcing outbound traffic through a control point · Verifying routes with istioctl proxy-config routes and clusters
Making failure boring. Timeouts and retries, and the retry budgets that stop them amplifying an outage; circuit breaking through connection pool limits and outlier detection that ejects unhealthy endpoints; then fault injection to prove that the resilience configured actually works. The module ends with mesh-driven canary and blue-green delivery.
Topics: Timeouts and per-try timeouts · Retries, retry conditions and why naive retries amplify outages · Connection pool settings and circuit breaking · Outlier detection and endpoint ejection · Fault injection: delays and aborts · Locality-aware load balancing and failover · Canary and blue-green delivery driven by mesh routing · Integrating with Argo Rollouts or Flagger for automated progressive delivery
The reason many organisations adopt Istio at all. Workload identity in SPIFFE format and how istiod issues and rotates certificates, PeerAuthentication and the strict, permissive and disabled modes, migrating an existing estate to strict mTLS without an outage, and integrating an external or intermediate certificate authority.
Topics: Workload identity, SPIFFE and the certificate lifecycle · PeerAuthentication: strict, permissive and disable modes · Migrating to strict mTLS namespace by namespace without downtime · Certificate rotation and istiod as a certificate authority · Plugging in an external or intermediate CA · Ingress TLS: simple, mutual and passthrough · Verifying encryption with istioctl and packet capture · Interaction with NetworkPolicy and defence in depth
Deciding who may call what. AuthorizationPolicy structure — selectors, actions, rules, and the evaluation order in which DENY, ALLOW and CUSTOM interact — then RequestAuthentication for JWT validation, principal-based rules using mesh identities, and external authorization for integrating an existing policy engine.
Topics: AuthorizationPolicy: selectors, actions, rules and scope · Policy evaluation order — DENY before ALLOW, and CUSTOM actions · Source principals, namespaces and identity-based rules · Operations and conditions: paths, methods, headers and IP blocks · RequestAuthentication and JWT validation at the edge · Combining request authentication with authorization rules · External authorization and integrating an existing policy engine · Default-deny posture and rolling it out safely
Running Istio once it carries production traffic. The Telemetry API for metrics, tracing and access logs; the standard metrics Envoy emits and how to read them; Kiali, Grafana and Jaeger; then the operational realities — sidecar resource scoping, performance tuning, multi-cluster topologies and a systematic debugging method.
Topics: Telemetry API: metrics, tracing and access logging configuration · Standard Envoy metrics, Prometheus scraping and cardinality control · Distributed tracing, context propagation and sampling rates · Kiali for topology and configuration validation, Grafana dashboards · istioctl analyze, proxy-status and proxy-config as a debugging method · Sidecar resource scoping and reducing proxy configuration size · Performance tuning: concurrency, resource limits and latency budgets · Multi-cluster meshes — primary-remote and multi-primary topologies · Common failure modes and how each presents
We rebuild the agenda around the tools you actually run.
Request a custom agendaDeploy a routing configuration that looks correct and silently does nothing, then find the fault using istioctl proxy-config routes rather than by editing YAML at random.
Run two versions side by side, shift traffic progressively by weight, mirror production traffic to the new version, and roll back in seconds when the metrics turn.
Configure timeouts, retries, connection pools and outlier detection, then inject delays and aborts until the mesh's behaviour under failure is observed rather than assumed.
Migrate a running application from permissive to strict mutual TLS namespace by namespace, with no failed requests, and prove the encryption with a packet capture.
Lock a namespace to deny-all, then write identity-based AuthorizationPolicies until exactly the intended calls succeed and every other one is refused.
Deliver a production-shaped mesh: revision-based upgrade path, strict mTLS, zero-trust authorization, scoped sidecars, dashboards, alerts and a debugging runbook.
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
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.
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.
| 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.