OpenShift operations: platform Operators, admission rules and application routing
Explain OpenShift platform ownership through cluster Operators, SCC admission and Routes. Diagnose a workload that cannot start or receive traffic without weakening cluster-wide controls.
TL;DR: OpenShift adds an operated platform around Kubernetes, including cluster lifecycle controllers, security admission and application routing. Diagnose the boundary that rejected or failed the workload before changing platform policy or restarting components.
Identify who owns the failing component
A Kubernetes Deployment describes application replicas. An OpenShift cluster also contains Operators that maintain platform services. Changing an Operator-managed operand directly can produce a brief apparent fix followed by reconciliation back to the declared configuration. Find the supported API that owns the setting.
The OpenShift Container Platform 4.20 control-plane documentation distinguishes cluster Operators managed through the Cluster Version Operator from optional Operators managed through Operator Lifecycle Manager. Installing an application Operator does not make OLM responsible for the cluster's own release lifecycle. Check the deployed product version before borrowing commands or upgrade assumptions from another environment.
A project provides an application workspace with policies and resource ownership. It does not automatically isolate every network path. Teams still need appropriate network policy, resource limits and identity assignments. A shared cluster remains a shared operational dependency even when each team has its own project.
| Boundary | Object or evidence to inspect | What success does not establish |
|---|---|---|
| Platform reconciliation | ClusterOperator conditions and owning configuration | Every application is healthy |
| Pod admission | Events, service account and applicable SCC | The image starts successfully |
| Application execution | Pod status, logs and readiness | External DNS and routing work |
| External request path | Route, Service and ready endpoints | A useful business response |
A service account can be authorized and still fail admission
RBAC answers whether an identity may perform an API operation. Security context constraints, or SCCs, constrain how a Pod may execute: requested user identity, capabilities, host access and related settings. Authorization to create a Deployment does not grant every execution privilege its Pod template requests.
In a fictional migration, a container image hardcodes UID 1000 and writes startup files to a directory owned only by that UID. The target project's permitted UID range excludes 1000. The ReplicaSet records an admission failure before an application container ever starts. Looking for application logs cannot explain a process that was never launched.
Read the admission message and requested security context. Prefer adapting the image to the platform's permitted execution identity and writable paths. If a workload needs a justified exception, scope it to the required service account and capabilities. A broad privileged grant changes far more than the one UID constraint. Red Hat's SCC guide also warns against editing default SCCs, whose settings can be restored by upgrades.
This separates rejection before execution from failure after startup. Scheduler placement and image retrieval can still fail between admission and readiness.
Trace the route after the workload becomes ready
A Route exposes a Service through the platform's ingress path. Its existence does not prove that the Service selects the intended Pods or has ready endpoints. The architecture overview places Routes and platform APIs alongside the Kubernetes resources underneath them.
Continue the migration example: the corrected Pod is ready, but users receive an unavailable-service response. Check the Route's target Service, Service selectors, endpoint membership and target port. A manifest can name port 8080 while the application listens on 8081. DNS and TLS investigation belongs later if traffic has already reached the intended router and the immediate failure is an empty backend set.
For an authorized project, these are read-only starting points; replace the example project and application names with actual values:
oc -n orders get deployment,replicaset,pod,service,route
oc -n orders get events --sort-by=.metadata.creationTimestamp
oc -n orders get endpointslice \
-l kubernetes.io/service-name=orders-api
oc get clusteroperators
Read the conditions and messages, not just the number of objects. The last command requires cluster visibility and provides platform context; an application team may instead need its platform operator to supply that evidence. Avoid assigning cluster-admin access merely to complete a diagnostic checklist.
Keep recovery at the right scope
A degraded ingress Operator affecting many projects warrants a platform investigation. One application with no ready endpoints warrants a workload investigation first. Compare an unaffected service on the same ingress path before escalating from a local defect to a cluster-wide action.
Self-check: a developer can create Deployments but their new Pod is rejected for a requested capability. Does granting edit access again solve it? No. Inspect the SCC decision and the workload's requirement. Correct the request or authorize a narrow, reviewed exception; RBAC permission to submit the object and admission permission to run it are separate controls.