🔴OpenShift
🔴 What is OpenShift?
›OpenShift vs Kubernetes
| Feature | Kubernetes (vanilla) | OpenShift (OCP) |
|---|---|---|
| Pod security | Pod Security Admission (optional) | SCC — enforced, cannot disable |
| HTTP routing | Ingress resource | Route resource (HAProxy backed) |
| Operator framework | Not built-in | OLM + OperatorHub built-in |
| Container registry | Not included | Internal registry included |
| Node OS | Any Linux | Red Hat CoreOS (immutable, operator-managed) |
| Web console | Basic (dashboard) | Full-featured developer + admin views |
| CLI | kubectl | oc (kubectl + OCP extensions) |
| Support | Community | Red Hat enterprise support |
OpenShift version check + cluster health
📁 Projects, Deployments & Routes
›Projects vs Namespaces
An OpenShift Project is a Kubernetes namespace with extra metadata and automatic RBAC defaults. oc new-project is the correct way to create namespaces — it applies the cluster's project template including network policies, LimitRanges, and ResourceQuotas automatically.
Deploy app + Routes + essential oc commands
🔐 SCC — Security Context Constraints
›Why SCC exists
In vanilla Kubernetes, containers can run as root by default. OpenShift blocks this. Every pod must match an SCC or it is rejected. This is the #1 source of friction when migrating apps from Kubernetes to OpenShift — and the #1 interview topic for OCP roles.
SCC Hierarchy (least to most privileged)
| SCC | Allows | Use for |
|---|---|---|
| restricted | Random UID, no root, no host access | Default — all well-written containers |
| nonroot | Any non-root UID | Apps needing specific UID but not root |
| anyuid | Any UID including root | Legacy apps — use only if necessary |
| hostnetwork | Host network namespace | Network tools, CNI plugins |
| privileged | Everything | Node agents (Datadog, Filebeat DaemonSets) |
SCC diagnosis and fix — complete workflow
⚙️ Operators & MachineConfig
›What an Operator actually does
Manual approach: you create StatefulSet, ConfigMap, Service, PodDisruptionBudget, CronJob for backups, monitoring rules — 10+ YAML files and ongoing operational toil. With an Operator: you create one custom resource (PostgreSQLCluster) and the Operator handles everything — provisioning, replication, backups, upgrades, failover. The Operator encodes the same knowledge a database DBA would have.
Install operator via OLM + MachineConfig
🔍 Troubleshooting
›SCC errors, ClusterOperator degraded, node issues, etcd
🔄 OpenShift vs AKS — Production Comparison
›When to choose OpenShift, when to choose AKS
| OpenShift (OCP) | AKS | |
|---|---|---|
| Security default | Locked down — no root, SCC enforced, requires explicit permissions | More permissive — teams must configure security themselves |
| Operator model | First-class — OperatorHub has 500+ operators | Available via Helm, less integrated |
| Developer experience | Built-in CI/CD (Tekton), image builds (S2I), developer console | Bare K8s — bring your own CI/CD |
| Enterprise support | Red Hat support contract — single vendor | Azure support — Microsoft backed |
| Cost | Higher — OpenShift subscription + compute | Lower — just compute + Azure managed control plane |
| Regulated industries | Common in banking, telco, healthcare — security by default | Growing — with Azure Policy + Defender |
| Multi-cloud | Runs on AWS, Azure, GCP, on-prem identically | Azure only |
OpenShift concepts that map to Kubernetes
| OpenShift | Kubernetes equivalent | Key difference |
|---|---|---|
| Project | Namespace | Project has built-in network isolation and admin role |
| Route | Ingress | Route is simpler, built-in TLS, HAProxy by default |
| DeploymentConfig | Deployment | Legacy OCP — use Deployment in OCP 4.x instead |
| SCC | PodSecurityPolicy (deprecated) | SCC is more flexible and actively maintained in OCP |
| ImageStream | No equivalent | Tracks image tags, triggers deployments on new tags |
| BuildConfig / S2I | No equivalent | Source-to-image builds inside OpenShift |
| OperatorHub | Helm charts (partial) | Operators manage full application lifecycle |
SCC — Security Context Constraints (the most common OCP interview topic)
SCC is OpenShift's policy that controls what a pod is allowed to do: run as root, access host filesystem, use specific capabilities. Every pod in OpenShift must satisfy an SCC to run. Built-in SCCs from most to least restrictive: restricted (default — no root, no host access), nonroot (any non-root UID), anyuid (any UID including root), privileged (full host access — only for infrastructure pods). Real scenario: deploying a third-party application that requires running as root. In plain Kubernetes this just works (by default). In OpenShift: you must grant the anyuid SCC to the service account. Best practice: grant the minimum SCC needed. Prefer building images that run as non-root.
🎯 Interview Questions
›OPENSHIFT · ENGINEER
How is OpenShift different from vanilla Kubernetes?
OpenShift adds enterprise security, operational tooling, and developer workflow on top of Kubernetes. Key differences: Security Context Constraints enforce that pods cannot run as root by default — stricter than vanilla K8s PodSecurityPolicy or Pod Security Admission. Routes are OpenShift's native HTTP routing resource (backed by HAProxy router) — richer TLS options than Kubernetes Ingress. Operator Lifecycle Manager is built-in for managing complex application lifecycle. Internal container registry is included out of the box. Image Streams are an OCP-native concept that automatically triggers deployments when an upstream image is updated. The oc CLI extends kubectl with OpenShift-specific commands. Web console has both developer and administrator perspectives. From an operational standpoint: OpenShift clusters are more opinionated and harder to customise than vanilla Kubernetes, but enterprise features (RBAC, audit logging, built-in registry, operator framework) save significant setup time. At HPE we ran OCP 4.x for the telecom SRO/COM/NBI platform — the SCC enforcement and Operator-based deployment model suited our enterprise compliance requirements.
OPENSHIFT · PRODUCTION
A pod fails with SCC error in OpenShift. Walk through the fix.
SCC (Security Context Constraints) error means the pod is requesting privileges that no assigned SCC allows. Step 1: read the error message carefully. oc describe pod failing-pod shows the exact SCC violation — usually running as root UID (0), using hostPath volumes, or requesting host network. Step 2: check what SCCs the pod's service account can use. oc adm policy scc-review -z service-account-name -n namespace. Step 3: choose the right fix. Correct fix: update the container to run as non-root. Add USER 1001 to the Dockerfile. This makes the container work with the default restricted SCC — no privilege escalation needed. Workaround for legacy apps: create a dedicated service account, grant the minimum SCC needed (nonroot before anyuid), use that service account in the deployment. Never use anyuid in production without a valid reason and never use privileged unless it is a node-level DaemonSet. Step 4: verify the fix. oc get pod fixed-pod -o jsonpath shows which SCC was assigned. At HPE: legacy telecom apps (TeMIP) needed anyuid because they were built to run as root. We isolated them in a dedicated namespace with tighter network policies to compensate.
OPENSHIFT · ARCHITECT
Explain OpenShift Operators and why they matter.
An Operator is a Kubernetes controller that encodes the operational knowledge of running a complex application. Instead of a human manually creating replicas, running backups, handling failover, and managing upgrades, an Operator does all of this automatically by watching custom resources. Example: a PostgreSQL Operator watches PostgreSQLCluster objects. When you create one, the Operator creates the StatefulSet, creates users, configures replication, sets up monitoring, schedules backups, and handles failover — things that would take hours of manual work. In OpenShift, Operator Lifecycle Manager is built-in and OperatorHub provides a catalogue of certified operators. Key objects: Subscription (which operator, which channel, auto or manual upgrade), ClusterServiceVersion (installed operator version + capabilities), InstallPlan (pending upgrades waiting for approval). Production best practice: always use Manual approval for operators in production. Auto-upgrade can break things. With Manual, you review the upgrade notes and approve during a maintenance window. At HPE: we used the OpenShift GitOps Operator (ArgoCD) and the Prometheus Operator — both managed through OLM with manual upgrade approval.
OPENSHIFT · ENGINEER
What is the difference between a Route and an Ingress in OpenShift?
Route is OpenShift's native HTTP routing resource, backed by the HAProxy-based OpenShift Router. Ingress is the standard Kubernetes resource that also works in OpenShift but routes to the same underlying router. Key differences: Routes have more TLS options natively — edge (TLS terminates at router, plain HTTP to pod), passthrough (TLS passes through to pod, end-to-end encryption), and reencrypt (TLS to router, new TLS to pod). Routes support custom certificates per route without needing cert-manager. Route status shows the exact hostname assigned. Ingress in OpenShift is converted to a Route internally. Use Routes when you want OpenShift-native features or when using the oc CLI and web console. Use Ingress when you want portability across Kubernetes distributions or when using Helm charts designed for vanilla K8s. The hostname format for Routes: app-name-namespace.apps.cluster-domain — automatically assigned if not specified.
Continue Learning