OpenShift is Red Hat's enterprise Kubernetes platform for building, deploying, securing, operating, and scaling containerized applications.
If Kubernetes provides the orchestration foundation, OpenShift adds an integrated platform around it: security controls, Operators, networking and Routes, a web console, image/build workflows, cluster lifecycle management, monitoring, and enterprise-oriented administration. OpenShift Container Platform 4.20 is built on Kubernetes and uses Red Hat Enterprise Linux CoreOS (RHCOS) and CRI-O as core node technologies.
This guide covers OpenShift from fundamentals through architecture, administration, application deployment, networking, storage, security, Operators, CI/CD, troubleshooting, and production design.
1. What Is OpenShift?
At its simplest:
Kubernetes + Enterprise platform capabilities + Security + Developer tooling + Operators + Integrated networking + Cluster lifecycle management + Web console = OpenShift
OpenShift is therefore not a completely separate alternative to Kubernetes.
It is a Kubernetes-based platform that adds significant functionality and opinionated operational components around Kubernetes. Red Hat describes OpenShift Container Platform as a Kubernetes platform for building, deploying, and managing enterprise container workloads.
2. Kubernetes vs OpenShift
A useful mental model is:
OpenShift ┌──────────────────────────────────────────┐ │ Web Console │ │ Developer Tools │ │ Routes │ │ Operators / OperatorHub │ │ Builds / ImageStreams │ │ SCC / Security │ │ Monitoring │ │ Authentication │ │ Cluster Lifecycle │ ├──────────────────────────────────────────┤ │ Kubernetes │ │ Pods / Deployments / Services │ │ Scheduling / Controllers / API │ ├──────────────────────────────────────────┤ │ Container Runtime │ │ CRI-O │ ├──────────────────────────────────────────┤ │ RHCOS │ └──────────────────────────────────────────┘
OpenShift retains Kubernetes concepts such as:
- Pods
- Deployments
- ReplicaSets
- Services
- ConfigMaps
- Secrets
- PersistentVolumeClaims
- StatefulSets
- Jobs
- CronJobs
- RBAC
- NetworkPolicy
while adding OpenShift-specific APIs and platform components.
3. OpenShift Architecture
A simplified architecture looks like this:
OpenShift Cluster │ ┌─────────────────┴─────────────────┐ │ │ Control Plane Workers │ │ ┌────────┼────────┐ ┌────────┼────────┐ │ │ │ │ │ │ API Server etcd Scheduler Node Node Node │ ├── Kubernetes Controllers ├── OpenShift APIs └── Operators
OpenShift's control plane manages compute nodes and workloads. Operators are fundamental to OpenShift's platform architecture and are used extensively to manage cluster components and applications.
4. Major OpenShift Components
Important components include:
| Component | Purpose |
|---|---|
| Kubernetes API Server | Kubernetes API |
| OpenShift API | OpenShift-specific APIs |
| etcd | Cluster state |
| Scheduler | Pod placement |
| Controller Manager | Desired-state reconciliation |
| kubelet | Node agent |
| CRI-O | Container runtime |
| RHCOS | Container-optimized node OS |
| Operators | Lifecycle management |
| Machine Config Operator | Node OS/configuration management |
| Cluster Version Operator | Cluster upgrades |
| OVN-Kubernetes | Cluster networking |
| OpenShift Router | External HTTP/HTTPS routing |
| Integrated Registry | Container image storage |
| Web Console | GUI administration |
oc | OpenShift CLI |
5. RHCOS
OpenShift 4.x commonly uses Red Hat Enterprise Linux CoreOS (RHCOS) as its node operating system.
RHCOS is designed specifically for containerized infrastructure.
OpenShift uses:
RHCOS │ ├── Linux kernel ├── SELinux ├── kubelet ├── CRI-O └── Ignition
OpenShift manages RHCOS updates through its cluster management mechanisms rather than treating every node like an independently administered traditional Linux server.
6. CRI-O
OpenShift uses CRI-O as its container runtime on RHCOS nodes.
The relationship is approximately:
OpenShift ↓ Kubernetes ↓ kubelet ↓ CRI ↓ CRI-O ↓ OCI Containers
This is important when moving from a Docker-centric environment to OpenShift.
You don't generally manage production OpenShift nodes by treating Docker Engine as the primary runtime.
7. The oc CLI
Kubernetes provides:
kubectl
OpenShift provides:
oc
oc includes Kubernetes CLI functionality plus OpenShift-specific functionality.
For example:
oc get pods
oc get nodes
oc get projects
oc get routes
oc get builds
oc get imagestreams
8. oc vs kubectl
A useful relationship:
kubectl │ └── Kubernetes operations oc │ ├── Kubernetes operations └── OpenShift-specific operations
Many kubectl commands work with OpenShift because OpenShift is Kubernetes-based.
For example:
oc get pods
and:
kubectl get pods
can both query Pods.
But:
oc get routes
uses an OpenShift-specific resource.
9. Logging Into OpenShift
Typical login:
oc login https://api.example.com:6443
Depending on the authentication configuration, you may be prompted for credentials or use a token.
Check the current user:
oc whoami
Check the current project:
oc project
10. Projects
One of the most visible OpenShift concepts is the Project.
A Project is closely related to a Kubernetes namespace but provides an OpenShift-oriented user experience and additional project-related functionality.
Example:
OpenShift Cluster │ ├── project: development │ ├── project: testing │ └── project: production
Create:
oc new-project myapp-dev
Switch:
oc project myapp-dev
List:
oc get projects
11. Pods
Just like Kubernetes, the basic workload execution unit is the Pod.
Pod ├── Container ├── Network └── Volumes
Create:
oc run nginx --image=nginx:latest
Check:
oc get pods
Detailed information:
oc describe pod nginx
Logs:
oc logs nginx
12. Deployments
For modern OpenShift applications, Kubernetes Deployment objects are generally preferred.
Example:
apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.28 ports: - containerPort: 80
Apply:
oc apply -f deployment.yaml
Check:
oc get deployment
13. DeploymentConfig — Important Legacy Knowledge
If you're working with older OpenShift environments, you will encounter:
DeploymentConfig
It is an OpenShift-specific workload object.
However, DeploymentConfig has been deprecated since OpenShift 4.14 and is not recommended for new installations. Red Hat recommends Kubernetes Deployment objects or other declarative alternatives for new workloads.
Therefore:
Old OpenShift ↓ DeploymentConfig Modern OpenShift ↓ Deployment
This is particularly important for administrators maintaining legacy OpenShift clusters.
14. Services
Services work essentially as they do in Kubernetes.
Service │ ┌────────┼────────┐ ▼ ▼ ▼ Pod Pod Pod
Example:
apiVersion: v1 kind: Service metadata: name: nginx spec: selector: app: nginx ports: - port: 80 targetPort: 80
15. Routes — One of OpenShift's Most Important Concepts
This is where OpenShift differs significantly from vanilla Kubernetes workflows.
A Route exposes a Service outside the cluster, typically for HTTP/HTTPS traffic.
Architecture:
Internet │ ▼ OpenShift Router │ ▼ Route │ ▼ Service │ ▼ Pods
Example:
oc expose service nginx
Check:
oc get route
You might see:
NAME HOST/PORT nginx nginx-myapp.apps.example.com
16. Route vs Ingress
Kubernetes has:
Ingress
OpenShift has:
Route
OpenShift also supports Kubernetes networking APIs such as Ingress.
Conceptually:
Kubernetes ↓ Ingress OpenShift ↓ Route + Ingress / Gateway APIs
Routes are a particularly recognizable OpenShift abstraction.
17. Route Example
apiVersion: route.openshift.io/v1 kind: Route metadata: name: myapp spec: to: kind: Service name: myapp port: targetPort: 8080 tls: termination: edge
This can provide HTTPS termination at the OpenShift router.
18. OpenShift Networking
Modern OpenShift uses OVN-Kubernetes as the default network plugin. It provides the cluster's virtualized Pod and Service networking and supports capabilities such as network policies, egress IPs, firewalls, IPsec, IPv6, and routing.
Conceptually:
OVN-Kubernetes │ ┌────────────────┼────────────────┐ ▼ ▼ ▼ Node 1 Node 2 Node 3 │ │ │ Pods Pods Pods
OVN-Kubernetes uses Open Virtual Network and Open vSwitch technology to implement the network topology.
19. NetworkPolicy
OpenShift supports Kubernetes NetworkPolicy.
For example:
Frontend │ ▼ Backend │ ▼ Database Frontend ─────────X────────> Database
A NetworkPolicy can restrict which Pods are allowed to communicate.
This is an important part of a zero-trust-oriented application architecture.
20. Multiple Networks
OpenShift can support additional networks beyond the primary cluster network.
This is useful for workloads requiring:
Application Network + Storage Network + Management Network
OpenShift 4.20 supports user-defined networks and NetworkAttachmentDefinitions for additional network connectivity.
This becomes particularly interesting for:
- Telco workloads
- NFV
- High-performance networking
- Storage systems
- OpenShift Virtualization
- Specialized enterprise workloads
21. OpenShift Storage
OpenShift uses Kubernetes storage abstractions.
Typical architecture:
Pod │ ▼ PersistentVolumeClaim │ ▼ StorageClass │ ▼ CSI Driver │ ▼ Storage System
Examples include:
- Ceph
- SAN
- Cloud block storage
- Cloud file storage
- NFS-based solutions
- Other CSI-compatible systems
22. PersistentVolumeClaim
Example:
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: app-data spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi
Check:
oc get pvc
23. Security — A Major OpenShift Feature
Security is one of the areas where OpenShift adds significant platform behavior.
Important concepts include:
Authentication ↓ Authorization ↓ RBAC ↓ SCC ↓ SELinux ↓ Network Policy ↓ Container Security
24. Security Context Constraints — SCC
Security Context Constraints (SCCs) control security-related permissions for Pods.
They can govern things such as:
- Privileged containers
- Linux capabilities
- Host directory access
- SELinux contexts
- Container UID
- Host namespaces
- Filesystem permissions
- Volume types
- Seccomp profiles
Red Hat specifically documents SCC as a mechanism for controlling what conditions a Pod must satisfy before being admitted.
25. SCC and Randomized UIDs
This is a common OpenShift issue for developers coming from Docker.
A container may assume:
UID 1000
or:
root
But OpenShift security policies may cause an application to run with a dynamically assigned non-root UID.
Therefore applications should ideally be designed to:
- Not require root
- Write to appropriate directories
- Avoid hard-coded UID assumptions
- Make required directories group-writable where appropriate
- Use arbitrary UIDs safely
For example, a poorly designed application may try:
/app/data
but fail because the runtime UID cannot write there.
26. Don't Disable Security Just to Make an Application Work
A common anti-pattern is:
oc adm policy add-scc-to-user privileged ...
simply because an application doesn't run correctly.
That may make the immediate error disappear while creating a much larger security problem.
Instead, determine why the application requires the permission.
OpenShift recommends creating and modifying custom SCCs rather than modifying the default SCC definitions.
27. RBAC
OpenShift uses Kubernetes RBAC.
You can inspect roles:
oc get roles
Cluster roles:
oc get clusterroles
Role bindings:
oc get rolebindings
Cluster role bindings:
oc get clusterrolebindings
Example:
oc adm policy add-role-to-user edit developer -n myapp
Always apply least privilege.
28. ServiceAccounts
Applications generally run under ServiceAccounts.
Check:
oc get serviceaccounts
Example:
spec: serviceAccountName: myapp
Avoid giving application ServiceAccounts unnecessary permissions.
29. Authentication
OpenShift supports configurable authentication mechanisms.
Depending on deployment, authentication may integrate with:
- LDAP
- Active Directory
- OAuth providers
- Identity providers
- Enterprise identity systems
The important architecture is:
User │ ▼ Identity Provider │ ▼ OpenShift OAuth │ ▼ RBAC │ ▼ Project / Cluster Resources
30. Operators
Operators are one of the defining characteristics of OpenShift.
An Operator packages operational knowledge into software.
Instead of manually performing:
Install Configure Upgrade Backup Recover Scale Monitor
an Operator can automate some or all of those lifecycle activities.
Red Hat describes Operators as foundational OpenShift extensions used to package, deploy, manage, monitor, and update services.
31. Operator Example
Imagine PostgreSQL.
Without an Operator:
Install PostgreSQL Configure replication Configure storage Create users Configure backups Monitor Upgrade Recover
With a suitable Operator:
PostgreSQL Custom Resource │ ▼ PostgreSQL Operator │ ┌─────┼─────┐ ▼ ▼ ▼ Storage Backup HA
The Operator watches the Kubernetes API and reconciles the desired state.
32. OperatorHub
OpenShift provides an Operator catalog experience through the web console and associated Operator tooling.
Typical workflow:
Operator Catalog ↓ Select Operator ↓ Install ↓ Create Custom Resource ↓ Operator Reconciles ↓ Application Running
Operators are particularly useful for enterprise middleware and platform services.
33. Custom Resources
An Operator commonly introduces a Custom Resource Definition (CRD).
For example:
apiVersion: database.example.com/v1 kind: PostgreSQLCluster metadata: name: production-db spec: replicas: 3 storage: 500Gi
The Operator interprets this object.
Conceptually:
Custom Resource ↓ Operator ↓ Kubernetes Resources ↓ Running Service
34. Cluster Version Operator
OpenShift's cluster lifecycle is heavily Operator-driven.
The Cluster Version Operator (CVO) coordinates OpenShift cluster version updates and platform components.
The architecture is approximately:
OpenShift Release │ ▼ Cluster Version Operator │ ├── Platform Operators ├── API ├── Networking ├── Storage └── Other components
This contributes to OpenShift's integrated cluster upgrade model.
35. Machine Config Operator
The Machine Config Operator (MCO) manages operating-system and node-level configuration.
It can manage aspects such as:
- systemd
- CRI-O
- kubelet
- kernel configuration
- NetworkManager
- host files
- OS updates
OpenShift's MachineConfig objects describe desired node configuration, which the MCO applies to Machine Config Pools.
36. MachineConfigPool
Nodes are grouped into MachineConfigPools.
Typical:
MachineConfigPool │ ├── master └── worker
You can create additional worker pools for specialized nodes.
For example:
worker │ ├── worker-general │ ├── worker-gpu │ └── worker-high-memory
OpenShift's documentation notes that nodes belong to a single MachineConfigPool and that custom pools can be used for specialized worker configurations.
37. MachineConfig
Example conceptual MachineConfig:
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: name: 99-worker-custom spec: config: ignition: version: 3.4.0
MachineConfig changes can cause affected nodes to be drained and rebooted as the Machine Config Operator applies them.
Therefore:
MachineConfig changes are infrastructure changes, not ordinary application configuration.
Plan them carefully.
38. Ignition
RHCOS uses Ignition during initial provisioning.
It can configure:
- Files
- Disks
- Users
- System configuration
Conceptually:
OpenShift Installer ↓ Ignition Configuration ↓ RHCOS First Boot ↓ Node Configuration
OpenShift uses Ignition as part of its machine provisioning and configuration lifecycle.
39. Builds in OpenShift
OpenShift includes native build concepts.
Historically common strategies include:
Docker strategy Source-to-Image (S2I) Custom strategy Pipeline-based approaches
OpenShift's BuildConfig/build APIs can produce container images and push them to a configured registry or ImageStream.
40. Source-to-Image — S2I
S2I stands for:
Source-to-Image
The idea:
Application Source + Builder Image ↓ S2I Build ↓ Container Image
For example:
Python Source + Python Builder Image ↓ Python Application Image
This can reduce the amount of Dockerfile work required for supported application stacks.
41. BuildConfig
A BuildConfig describes how OpenShift should perform a build.
Conceptually:
Git │ ▼ BuildConfig │ ▼ Build │ ▼ Container Image │ ▼ Image Registry / ImageStream
Although BuildConfig remains part of OpenShift, modern platform teams may also use external CI/CD systems such as Tekton-based pipelines and GitOps workflows depending on requirements.
42. ImageStreams
An ImageStream is an OpenShift abstraction for tracking container images and tags.
Conceptually:
Registry │ ▼ ImageStream │ ├── latest ├── 1.0 └── 1.1
Build output can be directed to an ImageStreamTag.
43. Integrated Image Registry
OpenShift can provide an integrated image registry.
Typical flow:
Developer │ ▼ Build │ ▼ OpenShift Image Registry │ ▼ ImageStream │ ▼ Deployment
In production, organizations may also use external registries such as Red Hat Quay or cloud/container registries.
44. OpenShift Web Console
OpenShift provides a comprehensive web console.
It provides views for:
- Projects
- Pods
- Deployments
- Services
- Routes
- Operators
- Storage
- Builds
- Monitoring
- Networking
- Cluster administration
This is particularly useful for teams where not everyone wants to operate Kubernetes entirely through CLI commands.
45. Developer Perspective
A developer might experience OpenShift as:
Git Repository │ ▼ Build │ ▼ Container Image │ ▼ Deployment │ ▼ Service │ ▼ Route │ ▼ Application
46. Administrator Perspective
An administrator sees something much larger:
Cluster │ ├── Control Plane ├── Worker Nodes ├── Operators ├── MachineConfig ├── Networking ├── Storage ├── Authentication ├── RBAC ├── Security ├── Monitoring ├── Logging ├── Registry └── Lifecycle Management
This distinction is important.
47. Monitoring
OpenShift includes integrated monitoring capabilities.
A production environment commonly monitors:
Cluster │ ├── API Server ├── Nodes ├── Pods ├── CPU ├── Memory ├── Network ├── Storage ├── Operators └── Applications
Prometheus-based metrics and Grafana-compatible visualization are common components of Kubernetes/OpenShift observability architectures.
48. Logging
A centralized logging architecture might look like:
Pod stdout/stderr │ ▼ Log Collector │ ▼ Central Log Store │ ▼ Search / Visualization
Common ecosystem technologies include:
- Vector
- Loki
- OpenSearch
- Elasticsearch-compatible systems
- OpenTelemetry
The exact supported architecture depends on the OpenShift version and installed operators.
49. Tracing
Distributed applications often require tracing.
For example:
User Request │ ▼ Frontend │ ▼ API │ ├── Redis │ └── Database
Tracing helps determine where latency is introduced.
OpenTelemetry is increasingly used as a vendor-neutral instrumentation and telemetry framework.
50. Autoscaling
OpenShift supports Kubernetes autoscaling concepts.
Horizontal Pod Autoscaler
Traffic ↑ ↓ CPU / Metrics ↑ ↓ HPA ↓ Pod count ↑
Example:
oc autoscale deployment myapp \ --min=2 \ --max=10 \ --cpu-percent=70
For production workloads, resource requests and appropriate metrics configuration are essential.
51. ResourceQuota
A Project can have resource quotas.
For example:
Project │ ├── CPU limit ├── Memory limit ├── Pod count ├── PVC count └── Storage limit
Example:
apiVersion: v1 kind: ResourceQuota metadata: name: project-quota spec: hard: pods: "50" requests.cpu: "20" requests.memory: 40Gi
This prevents one project from consuming unlimited cluster resources.
52. LimitRange
A LimitRange can establish defaults and constraints for resources inside a namespace/project.
For example:
Default CPU request Default memory request Maximum CPU Maximum memory
This helps enforce consistent resource behavior.
53. OpenShift CI/CD
A modern OpenShift delivery pipeline can look like:
Developer │ ▼ Git │ ▼ CI Pipeline │ ├── Unit Tests ├── Build ├── Security Scan └── Image Push │ ▼ Registry │ ▼ GitOps │ ▼ OpenShift
OpenShift environments may use technologies such as:
- Tekton
- OpenShift Pipelines
- Argo CD
- OpenShift GitOps
- External CI systems
- Red Hat Quay
54. GitOps
A mature OpenShift environment often separates:
Application Source
from:
Deployment Configuration
For example:
Application Repository │ ▼ Container Image Deployment Repository │ ▼ Helm / Kustomize / YAML │ ▼ GitOps Controller │ ▼ OpenShift
This creates a strong audit trail for configuration changes.
55. Helm
Helm is widely used with Kubernetes and OpenShift.
Typical chart:
myapp/ ├── Chart.yaml ├── values.yaml └── templates/ ├── deployment.yaml ├── service.yaml └── route.yaml
Install:
helm install myapp ./myapp
Upgrade:
helm upgrade myapp ./myapp
OpenShift's Route object can be included as part of the chart.
56. Kustomize
Kustomize can be used to maintain environment-specific configuration.
base/ │ ├── deployment.yaml ├── service.yaml └── route.yaml overlays/ ├── dev ├── staging └── production
This works particularly well with GitOps.
57. OpenShift Virtualization
OpenShift can also run virtual machines through OpenShift Virtualization.
This changes the picture:
OpenShift │ ┌──────────┴──────────┐ ▼ ▼ Containers VMs │ │ └──────────┬──────────┘ ▼ Common Platform
This can be useful when organizations want to manage VM and container workloads through a common platform.
58. OpenShift AI
OpenShift can also serve as a platform for AI/ML workloads.
A conceptual architecture:
OpenShift │ ├── Data Science Workbench ├── Model Training ├── Model Serving ├── GPU Nodes ├── Model Registry ├── Object Storage └── Monitoring
GPU nodes can be isolated using:
Labels Taints Tolerations Node affinity GPU resources
59. OpenShift for Big Data
OpenShift can host a variety of data workloads:
OpenShift │ ├── Kafka ├── Spark ├── Trino ├── Airflow ├── Databases ├── Data APIs └── ML platforms
For someone coming from Hadoop administration, the conceptual transition is:
Traditional Hadoop │ ├── YARN ├── HDFS └── Cluster Managers
versus:
OpenShift │ ├── Kubernetes Scheduler ├── Persistent Storage ├── Operators ├── Container Images └── Kubernetes APIs
The underlying data architecture still matters; Kubernetes/OpenShift doesn't automatically replace every Hadoop component or solve distributed data storage requirements.
60. OpenShift and Hadoop Migration
A common migration pattern might be:
On-Prem Hadoop │ ├── Spark ├── Kafka ├── HBase ├── Hive └── Airflow │ ▼ Containerize Selected Workloads │ ▼ OpenShift │ ├── Spark Operator / Platform ├── Kafka Operator ├── HBase-compatible architecture ├── Data APIs └── Airflow
However, the migration should be workload-specific.
Some components are easy to containerize.
Others require careful consideration of:
- Persistent storage
- Network throughput
- Stateful replication
- Data locality
- Security
- Kerberos
- Performance
- Licensing
- Operational tooling
61. Troubleshooting OpenShift
A structured troubleshooting workflow is essential.
Start with:
oc get nodes
Then:
oc get pods -A
Check cluster operators:
oc get clusteroperators
This is an especially important OpenShift command.
You can inspect:
oc describe clusteroperator <name>
62. Cluster Operators
OpenShift itself is heavily Operator-driven.
Check:
oc get clusteroperators
You'll see platform components such as networking, authentication, ingress, storage, monitoring, etc.
Conceptually:
ClusterOperator │ ▼ Operator │ ▼ Platform Component │ ▼ Desired State
If a ClusterOperator reports degraded or unavailable status, it can provide an important clue during cluster troubleshooting.
63. Node Troubleshooting
oc get nodes
Look for:
Ready NotReady SchedulingDisabled
Detailed:
oc describe node <node>
Check resource usage:
oc adm top nodes
Pod resource usage:
oc adm top pods
64. Pod Troubleshooting
oc get pods
Then:
oc describe pod <pod>
Logs:
oc logs <pod>
Previous crashed container:
oc logs <pod> --previous
Enter the container:
oc rsh <pod>
or:
oc exec -it <pod> -- /bin/sh
65. Common OpenShift Errors
CrashLoopBackOff
Usually means the container starts and repeatedly crashes.
Check:
oc logs <pod>
and:
oc describe pod <pod>
ImagePullBackOff
Potential causes:
- Wrong image
- Wrong tag
- Registry unavailable
- Authentication problem
- Image pull secret problem
Permission Denied
This is especially common when moving applications from Docker environments to OpenShift.
Check:
UID GID SCC Filesystem permissions SELinux Read-only filesystem
66. OpenShift Security Troubleshooting
Check which SCC applies:
oc get pod <pod> -o yaml
Look for security context information.
You can also inspect SCCs:
oc get scc
Detailed:
oc describe scc restricted-v2
Don't immediately grant:
privileged
Instead determine what permission the application actually needs.
67. Route Troubleshooting
Check:
oc get route
Then:
oc describe route <route>
Check the Service:
oc get svc
Check endpoints:
oc get endpoints
or:
oc get endpointslices
The flow should be:
DNS ↓ Router ↓ Route ↓ Service ↓ Endpoint ↓ Pod
If any layer is broken, traffic fails.
68. Useful OpenShift Commands
Cluster
oc cluster-info oc get nodes oc get clusterversion oc get clusteroperators
Projects
oc get projects oc project oc project myproject
Pods
oc get pods oc get pods -o wide oc describe pod <pod> oc logs <pod> oc rsh <pod>
Deployments
oc get deployment oc rollout status deployment/<name> oc rollout history deployment/<name> oc rollout undo deployment/<name>
Services
oc get svc oc describe svc <service>
Routes
oc get routes oc describe route <route>
Storage
oc get pv oc get pvc oc get storageclass
Security
oc get scc oc get rolebindings oc get clusterrolebindings
Operators
oc get operators oc get csv oc get subscriptions
69. OpenShift Application Deployment Flow
A modern application might follow:
Developer │ ▼ Git │ ▼ CI │ ┌──────┴──────┐ ▼ ▼ Testing Security │ │ └──────┬──────┘ ▼ Container Build │ ▼ Registry │ ▼ GitOps │ ▼ OpenShift │ ┌──────────┴──────────┐ ▼ ▼ Deployment Service │ │ ▼ ▼ Pods Route │ ▼ Internet
70. OpenShift Production Architecture
A typical enterprise deployment might look like:
Users │ ▼ DNS / WAF / CDN │ ▼ Load Balancer │ ▼ OpenShift Router │ ┌────────────┴────────────┐ ▼ ▼ Frontend Route API Route │ │ ▼ ▼ Frontend Service Backend Service │ │ ▼ ▼ Pods Pods │ ┌─────────┼─────────┐ ▼ ▼ ▼ Redis Kafka Database OpenShift Cluster │ ┌──────────────────────┼──────────────────────┐ ▼ ▼ ▼ Monitoring Logging Tracing │ │ │ └──────────────────────┼──────────────────────┘ ▼ Operations
71. OpenShift Best Practices
Application
Use:
- Immutable images
- Versioned images
- Health probes
- Resource requests
- Resource limits
- Graceful shutdown
- Non-root-compatible applications
Security
Use:
- Least-privilege RBAC
- Restricted SCCs
- NetworkPolicy
- Image scanning
- Secret management
- TLS
- Regular patching
Infrastructure
Use:
- MachineConfig for supported node configuration
- MachineConfigPools for specialized worker nodes
- Automated upgrades
- Cluster monitoring
- Capacity planning
OpenShift's MCO is specifically designed to manage node-level OS and configuration changes, so manually modifying managed node configuration is generally discouraged.
72. Things You Should Avoid
Don't manually modify RHCOS nodes
Prefer:
MachineConfig
over manually changing managed node configuration.
Don't modify default SCCs casually
Create custom SCCs when necessary.
Don't build new applications around DeploymentConfig
Use:
Deployment
unless you have a specific legacy requirement.
Don't hard-code Pod IPs
Use:
Service
Don't store passwords in Git
Use:
Secrets / external secret management
Don't give every application privileged
Understand the actual security requirement.
73. OpenShift vs Vanilla Kubernetes
| Capability | Kubernetes | OpenShift |
|---|---|---|
| Pods | ✅ | ✅ |
| Deployments | ✅ | ✅ |
| Services | ✅ | ✅ |
| StatefulSets | ✅ | ✅ |
| ConfigMaps | ✅ | ✅ |
| Secrets | ✅ | ✅ |
| RBAC | ✅ | ✅ |
| NetworkPolicy | ✅ | ✅ |
| Operators | Ecosystem | Deeply integrated |
| Web Console | Ecosystem-dependent | Integrated |
kubectl | ✅ | ✅ |
oc | ❌ | ✅ |
| Routes | ❌ | ✅ |
| SCC | ❌ | OpenShift-specific |
| MachineConfig | ❌ | OpenShift-specific |
| RHCOS integration | ❌ | ✅ |
| Integrated lifecycle | Distribution-dependent | Strongly integrated |
| OpenShift Builds/S2I | ❌ | ✅ |
| ImageStreams | ❌ | ✅ |
74. The Biggest Conceptual Difference
Kubernetes gives you the orchestration primitives.
OpenShift attempts to provide a more integrated platform around them.
Think:
Kubernetes = Container Orchestration Platform
while:
OpenShift = Kubernetes + Enterprise Platform + Security + Networking + Developer Experience + Operators + Lifecycle Management + Integrated Administration
This is why OpenShift environments can feel substantially more opinionated than a minimal Kubernetes installation.
75. OpenShift Learning Roadmap
If you're already familiar with Docker and Kubernetes, learn OpenShift in this order:
1. Kubernetes Fundamentals ↓ 2. oc CLI ↓ 3. Projects ↓ 4. Deployments ↓ 5. Services ↓ 6. Routes ↓ 7. ConfigMaps / Secrets ↓ 8. PVC / StorageClasses ↓ 9. SCC ↓ 10. RBAC ↓ 11. Operators ↓ 12. ClusterOperators ↓ 13. MachineConfig / MCP ↓ 14. OVN-Kubernetes ↓ 15. Builds / ImageStreams / S2I ↓ 16. Monitoring / Logging ↓ 17. GitOps ↓ 18. Cluster upgrades ↓ 19. Production troubleshooting ↓ 20. Architecture & capacity planning
76. OpenShift Mental Model
The most useful mental model is:
OPENSHIFT │ ┌───────────────────┼───────────────────┐ │ │ │ Develop Deploy Operate │ │ │ Builds Pods Operators S2I Deployments MCO Images Services CVO Registry Routes Monitoring │ │ │ └───────────────────┼───────────────────┘ │ Kubernetes │ ┌─────────────┼─────────────┐ ▼ ▼ ▼ Pods Services Storage │ ▼ Containers │ ▼ CRI-O │ ▼ RHCOS
77. Final Takeaway
If Docker teaches you:
“How do I package and run an application?”
Kubernetes teaches:
“How do I orchestrate thousands of containers?”
OpenShift takes that further:
“How do I provide an integrated enterprise platform for developers, operators, security teams, and administrators to build, deploy, secure, operate, and upgrade containerized workloads?”
The OpenShift concepts worth mastering are:
OPENSHIFT │ ┌─────────────────┼─────────────────┐ ▼ ▼ ▼ Kubernetes Security Operations │ │ │ ├── Pods ├── SCC ├── Operators ├── Deployments ├── RBAC ├── MCO ├── Services ├── SELinux ├── CVO └── Storage └── NetworkPolicy └── Monitoring │ ▼ Networking │ OVN-Kubernetes │ ▼ Routes │ ▼ Applications
For someone with a Hadoop/Big Data + Kubernetes + cloud infrastructure background, the particularly valuable OpenShift areas to go deep on are Operators, SCC/RBAC, OVN-Kubernetes, MachineConfig/MachineConfigPool, Routes/Ingress, storage/CSI, cluster upgrades, monitoring, GitOps, and production troubleshooting. These are the areas where OpenShift administration moves beyond basic Kubernetes command usage.
One important current-version note: this guide reflects the OpenShift Container Platform 4.20 architecture/documentation available now; OpenShift evolves rapidly, so specific APIs, supported integrations, and deprecated features should always be checked against the version actually running in your environment.
No comments:
Post a Comment
Thank you for Commenting Will reply soon ......