openskills.info
OpenShift Fundamentals logoCourse Preview

OpenShift Fundamentals

OpenShift is Red Hat's Kubernetes-based application platform. It combines container orchestration with integrated tools for building, exposing, securing, updating, and operating applications across datacenters and public clouds.

itVirtualization, containers, and orchestration

Don't Panic — OpenShift Fundamentals

OpenShift is Kubernetes with a great deal of platform work already assembled around it. Kubernetes keeps containers in the state described through its API. OpenShift adds the node operating system, updates, security controls, build paths, routing, a console, and a supported way to keep that assembly from becoming a pile of individually interesting problems.

The useful picture has four layers. People and automation ask the API for a change. The control plane records that desired state and sends work toward compute nodes. Those nodes run pods through kubelet and CRI-O. Controllers then keep comparing the request with reality, which is a busy job for software and an even busier job for anyone who tries to do it with a spreadsheet.

An Operator is the part that turns operating knowledge into a controller. Cluster Operators look after core services. The Cluster Version Operator steers the platform release. The Machine Config Operator rolls operating-system and node changes. Operator Lifecycle Manager handles optional Operators. Similar names, different jobs; the terminology has clearly been issued a uniform before being allowed into public.

For an application, keep the route through the platform in order. Build or select an image. Run it as pods with a Deployment. Put a Service in front so changing pods still have one internal address. Add a Route when HTTP or HTTPS traffic needs to arrive from outside. An image stream tracks image references; it is not where the image bytes sleep at night.

A Project is a shared working boundary, not a miniature independent cluster. It collects namespaced resources, membership, roles, quotas, and policy. It does not provide a separate control plane or make a workload resilient because its name is different. The same rule explains why a managed OpenShift service changes who operates the platform but does not adopt the application's security, capacity, data protection, or recovery decisions.

Updates are declared-state work as well. The chosen release moves through the Cluster Version Operator, Cluster Operators, and node rollout. Conditions tell you whether those components are available, progressing, degraded, or blocked from upgrade. They do not certify the application itself. Capacity, probes, disruption budgets, backups, and failure-domain choices still decide whether a rollout is merely orderly or actually safe.

Start with the intro for the architecture and responsibility split. Use the slides when the component relationships need a quick map. Keep the cheatsheet nearby when a Route, Service, image stream, or Operator condition becomes part of a real diagnosis. The reference tab is the path from this map into the official details, where the acronyms multiply but the control loop remains the same.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources