Introduction to Red Hat OpenShift

Working with Kubernetes means dealing with challenges like configuring Ingress, setting up CI/CD yourself, and managing security policies manually. This module shows which components OpenShift adds on top: an integrated image registry, Routes instead of Ingress, Source-to-Image (S2I) for automated builds, and a strict security model with SCCs. You will understand when OpenShift makes sense compared to a self-managed Kubernetes cluster.

OpenShift provides two ways to interact with the cluster: the Web Console with its Developer and Administrator perspectives, and the command line via oc. You will switch between both views, create your first project, and compare how oc differs from kubectl. By the end, you navigate confidently through dashboards, logs, and events, both graphically and in the terminal.

Projects are OpenShift's extension of Kubernetes Namespaces: they come with automatic network isolation and default policies. You will create Projects, set up local users, and assign roles like view, edit, and admin. You experience first-hand how permissions affect access in both the Console and CLI.

Time to get practical: you deploy a container application using three approaches. First via the Web Console catalog, then with oc new-app on the command line, and finally with a Kubernetes manifest (YAML). You watch the rollout in real time and inspect pod status, logs, and events. Afterward, you know which approach fits which situation.

In vanilla Kubernetes, you need an Ingress Controller plus configuration. OpenShift Routes replace that with a single command: oc expose. You create a Route, configure TLS termination (Edge, Passthrough, Re-encrypt) and see how the built-in HAProxy Router distributes traffic. Comparing Routes to Ingress shows why Routes often get you to a working result faster in practice.

How does source code become a running container? OpenShift offers three approaches: Source-to-Image (S2I) builds directly from a Git repository without writing a Dockerfile. Docker Build uses an existing Dockerfile. And Pipelines (Tekton-based) enable multi-stage CI/CD workflows. You try S2I and Docker Build hands-on and learn when each strategy is the right choice.

ImageStreams have no equivalent in vanilla Kubernetes. They abstract container images and enable automatic rebuilds when a base image changes. You create an ImageStream, link it to a BuildConfig, and configure triggers: on code changes (Webhook), image updates, or configuration changes. The result is an automated build pipeline without any external CI tool.

OpenShift relied on its own DeploymentConfigs for years, but since version 4.14 they are deprecated. In this module, you work with standard Kubernetes Deployments and configure rollout strategies: RollingUpdate for zero-downtime updates and Recreate for scenarios requiring exclusive database access. If you need to migrate existing DeploymentConfigs, you learn the key differences and the migration path.

Configuration does not belong inside a container image. You create ConfigMaps for application settings and Secrets for credentials, mount them as files or environment variables in Pods, and see how the OpenShift Web Console simplifies management. Hands-on exercise: an application whose database connection is fully controlled via ConfigMaps and Secrets.

Containers are ephemeral, but databases need persistent storage. You create PersistentVolumeClaims, attach them to Pods, and verify that data survives a Pod restart. Then you configure Dynamic Provisioning with StorageClasses so OpenShift creates volumes automatically. By the end, you understand the difference between block, file, and object storage in the OpenShift context.

OpenShift is more restrictive than vanilla Kubernetes: containers run without root privileges by default. You create Roles and ClusterRoles, bind them to users and ServiceAccounts, and test what happens when a Pod requests more privileges than its assigned SCC allows. This module explains why some container images fail to start on OpenShift and how to selectively loosen or tighten SCCs.

In multi-tenant environments, no team should consume the entire cluster. You configure ResourceQuotas per Project, set LimitRanges as guardrails for CPU and memory, and set up a Horizontal Pod Autoscaler (HPA) that scales Pods automatically under load. Then you watch live how OpenShift responds to a load test.

Operators are the backbone of the OpenShift ecosystem: they automate installation, updates, and lifecycle management of complex software. You install an Operator from the OperatorHub (e.g. a database), observe how it creates and manages Custom Resources, and understand the maturity levels (Basic Install through Auto Pilot). Afterward, you know when an Operator is the better choice over a Helm Chart.

In addition to Operators, OpenShift supports Helm Charts and its own Templates. You install an application via Helm through the Web Console, customize values, and compare the workflow with the Operator approach. You learn about Templates as an older OpenShift concept for context, but the focus is on Helm as the standard for reusable Kubernetes packages. You can go deeper in our Helm training.

OpenShift ships with Prometheus and Grafana as a built-in monitoring stack. You open the pre-installed dashboards, explore cluster and pod metrics, and create a first alert rule. To wrap up, we look ahead at advanced topics: GitOps with ArgoCD, Service Mesh, Advanced Cluster Management, and the path to EX280 certification.