Introduction to Red Hat OpenShift

OpenShift builds on Kubernetes and adds platform APIs and coordinated operating workflows. You map the web console, oc CLI, projects, routes, builds, ImageStreams, SCCs, and Operators to one architecture. In the DevNinjas Dojo, our cloud learning environment, you distinguish unchanged Kubernetes resources from OpenShift-specific extensions and clarify the responsibilities of each layer.

Since OpenShift 4.19, the web console perspectives are unified; the Developer perspective is no longer enabled by default but can be enabled by cluster administrators. You log in with oc and inspect the same resources, logs, and events through the console and CLI. You compare how the console and CLI present the same cluster resources.

An OpenShift project extends a Kubernetes namespace with metadata and acts as a boundary for access, quotas, and service accounts. You create projects, assign view, edit, and admin roles to users, and verify permissions with oc. You trace the resulting RoleBindings and distinguish project permissions from cluster permissions.

OpenShift supports application delivery through the catalog, CLI, and declarative manifests. You deploy the same sample application through the web console, CLI, and a declarative manifest. You then observe the rollout, pods, logs, and events and compare in the lab which of the three delivery paths fits each specific task.

An OpenShift route exposes a service under a hostname and can terminate TLS in different ways. You create a route and compare the three TLS variants: edge, passthrough, and re-encrypt. You then observe traffic forwarding through the router in the lab and distinguish routes from Kubernetes ingress.

BuildConfig resources connect source code, a build strategy, and an output image. You create a Source-to-Image build from a Git repository and compare it with a Dockerfile-based build. You inspect the builder image, build logs, parameters, and result and treat multi-stage pipeline workflows as a separate extension.

ImageStreams track container image references and tags within OpenShift. You create an ImageStream, connect it to a BuildConfig, and configure webhook and ImageChange triggers for code and image changes. You then trigger a build through these inputs and follow its status without treating the workflow as a complete external CI pipeline.

Standard Kubernetes Deployments control ReplicaSets and support RollingUpdate and Recreate. You work with Deployments and configure both strategies for different update requirements. You treat DeploymentConfigs as supported but deprecated OpenShift legacy resources and compare their main differences and the migration path to Deployments for new workloads.

ConfigMaps and secrets separate runtime configuration from the container image but do not automatically protect their values from all access. You create both resources, consume keys as environment variables and files, and update an application deliberately. Using a sample application, you see how ConfigMaps and secrets jointly control runtime configuration inside the pod.

PersistentVolumeClaims request storage through a StorageClass and decouple workloads from the concrete backend. You create a claim, attach it to an application, and verify data persistence after a pod replacement. You then relate dynamic provisioning through StorageClasses to OpenShift's automatic volume creation and distinguish block, file, and object storage in the OpenShift context.

RBAC determines who may use a Security Context Constraint; the SCC then evaluates the pod configuration. You bind roles to users and service accounts, inspect restricted-v2, and test admitted and rejected workloads. You correct an incompatible container image without granting broadly elevated permissions as a shortcut.

ResourceQuota, LimitRange, and HorizontalPodAutoscaler set boundaries at different layers. You define project budgets and suitable defaults, add requests and limits to a workload, and configure an HPA. You then generate controlled load and inspect how metrics, the scaling decision, and remaining quota jointly determine behavior.

The OpenShift software catalog makes Operators discoverable; Operator Lifecycle Manager manages installation and subscriptions. You select an Operator, inspect its install mode, channel, and permissions, and then create a custom resource. You observe the controller and status and compare the operating model with a one-time package installation.

Helm charts and OpenShift templates provide applications through reusable descriptions. You install a Helm chart through the web console, adjust values, and compare this workflow with the Operator approach. You examine templates as an older OpenShift concept for context, while the practical focus remains on Helm and its release management.

OpenShift collects platform metrics with Prometheus and routes alerts through Alertmanager. You use the Observe area of the web console, query metrics, and inspect an alert rule and its destination. You conclude by assessing user workload monitoring, GitOps, service mesh, and multi-cluster management as possible next topics.