Private corporate batches, live online cohorts and 1-on-1 mentoring in Red Hat OpenShift — building, deploying, securing and operating Kubernetes clusters — 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 OpenShift as Kubernetes plus a specific set of deliberate constraints — Security Context Constraints, Projects, Routes, ImageStreams and Operators — so engineers can tell which behaviour is Kubernetes and which is Red Hat's, instead of learning the platform as one undifferentiated blob. Sessions run live against a cluster: charts are broken by SCCs and then fixed properly rather than by granting privileged access, builds are traced from source through S2I to a running pod, and administration is done through MachineSets and Operators rather than by editing nodes.
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 OpenShift that means a trainer who has run it in production — Red Hat OpenShift — building, deploying, securing and operating Kubernetes clusters — 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 OpenShift batchOpenShift is Red Hat's Kubernetes distribution and application platform. Underneath it is conformant Kubernetes — the same API objects, the same controllers, the same scheduler — but it ships with the parts most organisations otherwise have to assemble themselves: an integrated container registry, a build and image pipeline, an ingress router, a monitoring and logging stack, an authentication layer, and a security posture that is restrictive by default rather than permissive.
The differences that matter operationally are concrete. Projects are namespaces with additional lifecycle and access semantics. Routes predate and coexist with Ingress and the Gateway API. Security Context Constraints decide what a pod may do — and by default deny running as root, which is why community Helm charts frequently fail on OpenShift until they are adjusted. Source-to-Image builds a runnable container image directly from application source, and ImageStreams give deployments a stable reference that can trigger on a new image. Everything is managed by Operators, and OperatorHub is how the platform and its add-ons are installed and upgraded.
OpenShift also bundles the surrounding toolchain as supported components: OpenShift Pipelines built on Tekton, OpenShift GitOps built on Argo CD, OpenShift Serverless built on Knative, the Prometheus, Grafana and Alertmanager monitoring stack, and LokiStack for logs. That is the real proposition — a single supported platform where cluster installation, upgrades, authentication, CI/CD, observability and compliance are one product rather than a dozen integration projects.
OpenShift is where regulated enterprises run Kubernetes. Banks, insurers, telecoms, healthcare and public sector organisations buy it precisely because the platform arrives with a support contract, a defined upgrade path, an opinionated security model and an auditable compliance story — the things that are hardest to justify assembling from upstream components.
That creates a hiring pattern distinct from generic Kubernetes. Employers want engineers who know why a container that runs fine on a vanilla cluster is refused by a Security Context Constraint, how to install and upgrade a cluster through MachineSets and the Machine Config Operator rather than by touching nodes, how to wire OpenShift authentication to LDAP or SAML, and how to hand development teams a self-service project with quotas that hold. Kubernetes knowledge alone does not cover any of that.
The platform is also moving quickly, and the current version is materially different from what most training covers: the Gateway API alongside Routes, Deployments displacing DeploymentConfigs, MachineSets and node pools, LokiStack replacing older logging, and OADP for backup. Teams migrating from older releases need someone who can teach what changed and what has to be rewritten, not a course written against a version they have already left behind.
The honest comparison first. What is identical to upstream Kubernetes, what OpenShift adds, and what it deliberately restricts. Control plane and worker node architecture, the Operator pattern as the platform's own management mechanism, and Custom Resource Definitions as the extension model everything else is built on.
Topics: Introduction to OpenShift and Kubernetes differences — why OpenShift · OpenShift architecture: control plane, workers, etcd and the API server · Operators as the platform management model · Custom Resource Definitions and the extension mechanism · Red Hat CoreOS, the Machine Config Operator and immutable nodes · OpenShift editions, footprints and single-node deployments · Introduction to the OpenShift API and resource types
Working in the platform day to day. The Developer and Administrator console perspectives and who each is for, then the oc CLI in depth — login, context, resource creation and inspection. Projects as namespaces with lifecycle and self-provisioning behaviour, and the users, groups and role bindings that scope everything.
Topics: OpenShift Console — Developer versus Administrator views · oc basics: login, whoami, project, get, describe, explain · Creating and managing resources with oc create, apply and edit · Projects versus namespaces, project templates and self-provisioning · Users, groups, service accounts and identity providers · Roles, ClusterRoles, RoleBindings and ClusterRoleBindings · oc adm commands and cluster administration entry points
How code becomes a running pod on OpenShift. Source-to-Image builds and builder images, BuildConfigs and triggers, ImageStreams as the stable reference that decouples deployments from registry tags, then the DeploymentConfig versus Deployment decision and what rollbacks and lifecycle hooks look like on each.
Topics: Deploy applications using Source-to-Image (S2I) · BuildConfigs, build strategies and builder images · ImageStreams, image stream tags and triggers · Deploying containers: DeploymentConfig versus Deployment · Rollouts, rollbacks and deployment strategies · Application lifecycle management and image promotion between environments · The integrated registry and external registry integration
Making a workload reachable and configurable. Services and the OpenShift Router, Routes with edge, passthrough and re-encrypt TLS, then Ingress and the Gateway API that increasingly sits alongside them. Configuration and secrets injection, and horizontal autoscaling driven by real metrics.
Topics: Services, endpoints and the OpenShift Router · Routes: hostnames, path-based routing and TLS termination modes · Ingress and the Gateway API in current OpenShift networking · ConfigMaps, Secrets and environment variables · Mounting configuration and secrets as volumes · Scaling applications: manual scaling and the HorizontalPodAutoscaler · Readiness, liveness and startup probes · NetworkPolicy and traffic isolation between projects
CI/CD running inside the cluster rather than beside it. The Tekton object model — Tasks, Steps, Pipelines, workspaces and results — how OpenShift Pipelines packages it, and the triggers that connect a Git push to a pipeline run. Workspaces, secrets and image push permissions are where most real pipelines break, so they get the attention.
Topics: OpenShift Pipelines introduction and the Tekton model · Tasks, Steps, ClusterTasks and the Tekton Hub catalogue · Pipelines, workspaces, parameters and results · Triggers, EventListeners and TriggerBindings for Git webhooks · Service accounts, secrets and pushing to the internal registry · Pipeline runs, logs and failure diagnosis · Integrating tests, scanning and image signing into a pipeline
How a cluster comes into existence and how nodes are managed afterwards. Installer-provisioned versus user-provisioned infrastructure and when each applies, then MachineSets, node pools and the Machine Config Operator — the mechanism by which nodes are changed, since editing a node directly is not how OpenShift works.
Topics: OpenShift cluster installation overview — IPI versus UPI · install-config.yaml, the bootstrap process and installation troubleshooting · Node management with MachineSets and NodePools · Machine Config Operator, MachineConfigPools and node updates · Labels, taints, tolerations and node selectors · Cluster upgrades, channels and the upgrade path · Infrastructure nodes and workload placement
The platform's own extension and lifecycle model. What an Operator actually is — a controller plus CRDs encoding operational knowledge — how Operator Lifecycle Manager installs, versions and upgrades them, subscription and channel semantics, and how to evaluate an Operator before it becomes a dependency in production.
Topics: Understanding Operators and the Operator pattern · OperatorHub, catalogue sources and the certified catalogue · Operator Lifecycle Manager, subscriptions, channels and approval modes · Operator scope: namespace-scoped versus cluster-wide · Reading an Operator's CRDs and status conditions · Troubleshooting a failed Operator install or upgrade · When to build your own Operator, and when not to
Persistent state and resource fairness. StorageClasses, PVCs and the RWO versus RWX access mode decision that determines whether a workload can scale horizontally, an introduction to OpenShift Data Foundation, then the quota and limit machinery that keeps a shared cluster shared, and backup with Velero and OADP.
Topics: Storage management in OpenShift: PersistentVolumes, PVCs and StorageClasses · Access modes — RWO, RWX, ROX — and their practical consequences · Dynamic provisioning, volume expansion and snapshots · OpenShift Data Foundation introduction · ResourceQuota, LimitRange and ClusterResourceQuota · Requests, limits and Quality of Service classes · Backup and disaster recovery basics with Velero and OADP · etcd backup and cluster restore procedure
Declarative delivery and scale-to-zero workloads. Argo CD as OpenShift GitOps — Applications, projects, sync policies, drift detection and self-healing — and the repository patterns that make multi-cluster GitOps maintainable. Then Knative Serving and Eventing for request-driven services that cost nothing when idle.
Topics: OpenShift GitOps (Argo CD) — declarative application management · Applications, ApplicationSets, sync waves and hooks · Drift detection, self-healing and pruning · Repository structure for multi-environment and multi-cluster GitOps · Serverless on OpenShift — Knative Serving introduction · Knative revisions, traffic splitting and scale to zero · Knative Eventing, brokers and triggers
Knowing what the cluster is doing and fixing it when it is not. The built-in monitoring stack — Prometheus, Grafana, Alertmanager — including user-workload monitoring and custom alert rules; the logging stack with LokiStack and collection; then the practical debugging toolkit that resolves most real incidents.
Topics: OpenShift monitoring stack: Prometheus, Grafana and Alertmanager · Enabling user-workload monitoring and custom ServiceMonitors · PromQL for cluster and application questions · Alert rules, silences and receiver configuration · OpenShift Logging with LokiStack and log collection · Log queries, retention and forwarding to external systems · Debugging applications: oc debug, oc logs, oc rsh, oc port-forward · Events, must-gather and cluster health diagnosis
The part that separates OpenShift from a cluster someone assembled. Security Context Constraints and Pod Security Admission and why they reject images that run elsewhere, enterprise authentication through LDAP, SAML and OAuth, supply chain controls with scanning and Quay image signing, RBAC patterns for genuine multi-tenancy, and the autoscaling and tuning that keeps it economical.
Topics: Security in OpenShift: Security Context Constraints, PSPs and Pod Security Admission · Fixing workloads that fail SCC admission without granting privilege · OpenShift authentication integrations — LDAP, SAML and OAuth · Image security: vulnerability scanning and Quay image signing · Multi-tenancy and RBAC best practices · NetworkPolicy-based tenant isolation · Performance tuning, cluster autoscaler and machine autoscaler · Compliance Operator and audit posture
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake a running cluster and classify every resource, controller and behaviour you find as upstream Kubernetes or Red Hat addition, then justify each call from the API itself.
Deploy from source with Source-to-Image, wire an ImageStream trigger, push a commit and watch the rollout, then roll it back cleanly.
Install a community Helm chart that assumes root, watch the restricted SCC reject it, and fix it properly — non-root user, correct fsGroup, no privilege granted.
Build an OpenShift Pipeline triggered by a Git push that tests, builds, scans and pushes an image, and debug the service account permissions it fails on first.
Back up a stateful application with OADP, delete the project entirely, and restore it into a new one with its data intact.
Deliver a multi-tenant cluster with GitOps delivery, quotas, network isolation, external authentication, monitoring alerts and signed images.
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.
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.
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.
| 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.