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 | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
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
- https://www.redhat.com/en/technologies/cloud-computing/openshift
Supports
- OpenShift portfolio, supported hybrid-cloud positioning, and consumption models
- Official product homepage used by the manifest and Landscape
- https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html-single/architecture/index
Supports
- OpenShift as a Kubernetes application platform and its control-plane and compute-node architecture
- RHCOS, Ignition, CRI-O, kubelet, Operators, CVO, MCO, OLM, console, oc, registry, and update architecture
- Pods, Services, Routes, installation methods, restricted networks, and platform limitations
- https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/building_applications/index
Supports
- Application creation from source, images, manifests, Helm, and Operators
- Projects, Deployments, Services, application maintenance, and developer workflows
- Reference-path rationale for the building applications guide
- https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/building_applications/projects
Supports
- Project creation, membership, roles, isolation, quotas, and system-project restrictions
- https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html-single/project_apis/project_apis
Supports
- Project as an alternative representation of a Kubernetes namespace
- Projects as units of isolation and collaboration rather than separate clusters
- https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/network_apis/route-route-openshift-io-v1
Supports
- Route as public DNS and an HTTP or HTTPS aware proxy layer for Services
- Route TLS behavior and router-to-Service endpoint path
- https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/images/index
Supports
- Image and image-stream reference behavior and the Images reference-path rationale
- Source-to-Image as a build process
- https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/images/managing-image-streams
Supports
- Image streams as virtual views of related images rather than image data stores
- Image stream tags, change tracking, and build or deployment triggers
- https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html-single/updating_clusters/
Supports
- CVO, update service, channels, release image, Cluster Operator, and MCO update flow
- Update conditions, compatible Operators, failure behavior, and no supported rollback
- Reference-path rationale for the updating clusters guide
- https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/updating_clusters/performing-a-cluster-update
Supports
- Backups, capacity, disruption budgets, machine config pools, and update preconditions
- Pod eviction and node-drain blockers during updates
- https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/authentication_and_authorization/using-rbac
Supports
- Namespaced and cluster-wide roles, bindings, and least-scope authorization decisions
- https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html-single/security_apis/security_apis
Supports
- Security Context Constraints governing pod security-context requests
- https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html-single/tutorials/tutorials
Supports
- Guided project creation, image deployment, Service, and Route practice path
- Reference-path rationale for the tutorials
- https://github.com/sindresorhus/awesome
Supports
- Required discovery starting point and link to the curated Awesome Kubernetes list
- https://github.com/ramitsurana/awesome-kubernetes/wiki/Awesome---Kubernetes
Supports
- Curation presence of Helm, Kustomize, cert-manager, and K9s
- Awesome Links discovery decision
- https://helm.sh/docs/intro/introduction/
Supports
- Helm charts as versioned packages for defining, installing, upgrading, and rolling back Kubernetes applications
- Helm Awesome Link rationale
- https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/
Supports
- Kustomize bases, overlays, generators, and manifest customization
- Kustomize Awesome Link rationale
- https://cert-manager.io/docs/
Supports
- Certificate resources, issuers, Secrets, and automated renewal on Kubernetes and OpenShift
- cert-manager Awesome Link rationale
- https://k9scli.io/topics/commands/
Supports
- K9s resource, namespace, context, log, and read-only inspection capabilities
- K9s Awesome Link rationale
- https://www.rancher.com/products/rancher-platform
Supports
- Rancher Prime cluster provisioning, import, centralized policy, monitoring, and multi-distribution management
- Rancher Prime placement and licensing model in Landscape
- https://www.vmware.com/products/app-platform/tanzu
Supports
- Tanzu Platform private-cloud application platform, code-to-deployment, and platform operations focus
- Tanzu placement in the OpenShift Landscape comparison
- https://cloud.google.com/kubernetes-engine/enterprise
Supports
- GKE Enterprise fleet, policy, and managed Kubernetes platform role
- GKE Enterprise placement in the OpenShift Landscape comparison
- https://aws.amazon.com/rosa/
Supports
- ROSA as a managed OpenShift service integrated with AWS accounts and services
- ROSA placement in Landscape
- https://azure.microsoft.com/products/openshift
Supports
- Azure Red Hat OpenShift as a jointly operated managed OpenShift service
- ARO placement in Landscape
- https://www.ibm.com/products/openshift
Supports
- Red Hat OpenShift on IBM Cloud as a managed OpenShift service
- IBM Cloud placement in Landscape
- https://www.redhat.com/en/about/press-releases/red-hat-launches-openshift-dedicated-delivering-its-container-application-platform-public-cloud-offering
Supports
- November 2011 OpenShift Online launch date and original hosted PaaS model
- December 2015 OpenShift Dedicated general availability and consumption models
- https://www.redhat.com/en/blog/Announcing-OpenShift-Origin-Open-Source-Code-For-Platform-as-a-Service
Supports
- April 30, 2012 Origin source release, Apache License version 2, and upstream purpose
- https://www.redhat.com/en/blog/red-hat-collaborates-with-open-source-community-to-deliver-innovative-platform-as-a-service
Supports
- March 2013 Origin upstream relationship, pull-request model, and public continuous integration
- https://www.redhat.com/en/blog/openshift-kubernetes-where-weve-been-and-where-were-going-part-1
Supports
- 2014 decision to standardize OpenShift on Kubernetes and June 2015 OpenShift 3 launch
- https://www.redhat.com/en/about/press-releases/red-hat-delivers-openshift-enterprise-3-power-new-web-scale-distributed-application-platform
Supports
- June 24, 2015 OpenShift Enterprise 3 general availability
- Combination of Docker-format containers, Kubernetes, and RHEL 7
- https://www.redhat.com/en/blog/red-hat-openshift-container-platform-4-now-defaults-cri-o-underlying-container-engine
Supports
- CRI-O technology preview in OpenShift 3.7, general availability in 3.9, and default in OpenShift 4
- https://www.redhat.com/en/about/press-releases/red-hat-unveils-roadmap-coreos-integration-red-hat-openshift
Supports
- January 2018 CoreOS acquisition and integration of Tectonic, Container Linux, Quay, and Operator work
- https://www.redhat.com/en/about/press-releases/red-hat-redefines-enterprise-kubernetes-through-full-stack-automation-red-hat-openshift-4
Supports
- May 8, 2019 OpenShift 4 introduction and Operator-based full-stack automated operations
- https://aws.amazon.com/about-aws/whats-new/2021/03/amazon-and-red-hat-announce-general-availability-rosa/
Supports
- March 24, 2021 ROSA general availability, OpenShift APIs, AWS integration, and service procurement
- https://www.usenix.org/conference/srecon21/presentation/ratis
Supports
- Field Notes: Operators encode production practices and operational knowledge, so an installed Operator is an automation dependency rather than a passive package
- https://connect.redhat.com/en/blog/updating-your-operators-openshift-when-kubernetes-changes-apis
Supports
- Field Notes: Operators using removed Kubernetes APIs can block an OpenShift cluster upgrade and must be updated before the target platform release
- https://docs.redhat.com/en/documentation/openshift_container_platform/4.16/html-single/operators/operators
Supports
- Field Notes: Operator Lifecycle Manager InstallPlans can use automatic or manual approval, and Subscription status distinguishes current and installed CSV versions
- https://docs.redhat.com/en/documentation/openshift_container_platform/4.21/html/network_security/network-policy
Supports
- Field Notes: pods are accessible by default within a project until NetworkPolicy objects select and restrict them; NetworkPolicy does not cover host networking or resident-node traffic
