18 OpenShift in Practice

From Concepts to Day-to-Day Use

This chapter connects the concepts from earlier modules to what actually happens when people use OpenShift in real teams and organizations. The focus here is on patterns of work, how different roles use the platform, and what “normal” looks like on a real cluster.

You’ll see recurring workflows rather than isolated commands: how applications move from a laptop to a shared cluster, how teams collaborate, and how responsibilities are split between developers, platform engineers, and operations.

Typical Roles and Responsibilities

In practice, OpenShift is rarely “just a cluster.” It is a platform shared by multiple roles:

Platform / Cluster Administrators

Typical responsibilities:

• Provision and upgrade clusters (on-prem, cloud, or managed).
• Configure cluster-wide networking, storage, and security defaults.
• Manage access (who can do what, in which projects).
• Operate shared services via Operators (logging, monitoring, service mesh, databases, etc.).
• Ensure capacity, availability, and compliance.

They mostly:

• Work in “infrastructure” or “system” projects.
• Use oc with elevated permissions.
• Manage MachineSets, StorageClasses, Operators, and policies.
• Automate cluster lifecycle and configuration (e.g., GitOps, infrastructure-as-code).

Application Developers

Typical responsibilities:

• Design and implement application code.
• Define application manifests (Deployments, Routes, ConfigMaps, Secrets, etc.).
• Build container images or use S2I.
• Use CI/CD pipelines to deploy into dev/test/prod projects.
• Monitor application behavior and troubleshoot issues at the pod and application level.

They mostly:

• Work within one or more “application” projects.
• Use the web console and oc for day-to-day tasks.
• Interact with pipelines, logs, metrics, and application configs.

DevOps / Platform Engineers

Typical responsibilities:

• Design and maintain CI/CD pipelines.
• Implement GitOps workflows.
• Standardize application templates and Helm charts or Operator usage.
• Integrate external tools (artifact registries, security scanners, secrets managers).
• Bridge between app teams and platform admins.

They mostly:

• Work across multiple projects.
• Own shared tooling repositories (pipelines, libraries, templates).
• Define conventions and guardrails: labels, annotations, naming, resource limits, etc.

Typical OpenShift Resource Organization

A common pattern is to align OpenShift projects (namespaces) with environments and applications.

Common strategies:

• Per-environment per-application:
• myapp-dev, myapp-test, myapp-prod
• Per-team environment with multiple apps:
• team1-dev, team1-prod, with labels to distinguish apps
• Shared infrastructure projects:
• openshift-* system projects (cluster-internal)
• logging, monitoring, service-mesh, shared-db

Typical conventions:

• Labels and annotations:
• app=<name>, team=<team>, env=<dev|test|prod>
• Used for network policies, metrics aggregation, and RBAC policies.
• Resource quotas and limits:
• Stricter in shared or production projects.
• Naming:
• Standard prefixes/suffixes for ConfigMaps, Secrets, and Services to reduce confusion across environments.

A Day in the Life: Developer Workflow

Below is a typical end-to-end flow from code to production as experienced by a developer team using OpenShift. Details like exact manifests or pipeline technology are covered in other chapters; here the focus is on how things fit together.

1. Start from Source Code

Developers:

• Work in a Git repository with:
• Application code.
• Dockerfile or S2I configuration (if using S2I).
• Kubernetes/OpenShift manifests or templates (e.g., Deployment, Service, Route).
• CI/CD pipeline definition (e.g., Tekton Pipeline/PipelineRun, GitHub Actions, Jenkinsfile, etc.).

OpenShift-specific aspects:

• Image is eventually pushed to a registry accessible by the cluster (often the integrated OpenShift registry).
• Manifests are usually parameterized so they can be reused across environments (dev/test/prod).

2. Build Images

Common practices:

• Cluster-side build:
• Use S2I Builds or BuildConfigs to build directly on the cluster.
• Benefits: build environment is standardized, build resources are on cluster.
• External build:
• Use external CI (GitHub Actions, GitLab CI, Jenkins, etc.) to build and push images to a registry.
• Cluster just pulls the ready-made image.

In practice:

• Many organizations migrate from cluster-side to external builds over time for performance and security reasons.
• Build logs and statuses are integrated into OpenShift web console or external CI dashboards.

3. Deploy to a Development Project

Once an image is available:

• A deployment manifest (Deployment or DeploymentConfig) references this image.
• Configuration and secrets are provided via:
• ConfigMaps (non-sensitive), Secrets (sensitive), environment variables.
• Service and Route expose the application internally or externally.

Typical developer tasks:

• Check pods status and logs in the web console.
• Port-forward temporarily to debug, or use Routes for HTTP/HTTPS access.
• Use oc to:
• oc get resources.
• Apply configuration changes.
• Trigger rollouts or rollbacks.

4. Automated Promotion to Higher Environments

Promotion to test/stage/prod often follows one of these patterns:

• Image promotion:
• Same manifests, different image tags or image streams per environment.
• Config promotion:
• Common base manifests with environment-specific overlays (e.g., via Kustomize, Helm values, or Argo CD applications).
• GitOps:
• Each environment has its own Git repo or directory.
• Changes are made via pull requests; Argo CD/Tekton applies them to the cluster.

Developers mainly interact with:

• Pull requests.
• Pipeline status.
• Observing rollouts in higher environments (without direct admin access).

5. Operate and Observe Applications

In real usage, constant activities include:

• Checking pod health, restarts, and events.
• Viewing logs and metrics to track errors, latency, and throughput.
• Responding to alerts (e.g., crash loops, high error rate, increased latency).
• Performing rollbacks when a new release causes issues.

Common OpenShift-based tools in practice:

• Web console: quick visual check of deployments, pods, logs.
• Integrated metrics and logging stacks (or external tools like Prometheus, Grafana, Loki, ELK).
• oc and application-specific troubleshooting (e.g., exec into a pod for diagnostic commands).

Typical Platform Operations Workflows

From the platform side, a few recurring workflows show up across organizations.

Onboarding a New Team or Application

Steps often include:

1. Create projects:
• myapp-dev, myapp-prod (or team-based projects).
2. Set RBAC:
• Grant developer groups access to these projects.
• Give read-only access to other stakeholders if needed.
3. Define quotas and limits:
• CPU/memory quotas per project.
• Default resource requests/limits for pods.
4. Apply baseline policies:
• NetworkPolicies (which namespaces/pods can talk to which).
• Pod Security settings (via Security Context Constraints or Pod Security Admission).
5. Install required Operators (if needed):
• Databases, message brokers, monitoring add-ons, etc.

Result:

• Teams get a “ready-to-use” space where they can create deployments and services following agreed standards.

Maintaining Cluster Health

Routine operational tasks:

• Monitor cluster capacity:
• Node and pod resource usage.
• Persistent storage consumption.
• Manage node lifecycle:
• Replace failing nodes.
• Perform rolling maintenance without downtime (cordon/drain).
• Keep Operators and cluster version up to date.
• Enforce security:
• Regularly review role bindings and permissions.
• Ensure images comply with corporate policies.

Typically these are automated:

• Infrastructure-as-code for provisioning and configuration (e.g., Terraform, Ansible).
• GitOps for cluster configuration and platform services.

Common Patterns in Real Deployments

Certain patterns repeat across many OpenShift installations, regardless of industry.

Multi-Environment Separation

Most organizations maintain at least:

• dev: for active development, frequent deployments.
• test or stage: for QA, performance tests, integration.
• prod: for end users, strict controls.

Practices:

• Different access permissions per environment.
• Different scaling and resource allocations.
• Different routes/hostnames, but similar internal architecture.

Multitenancy and Isolation

When many teams share a cluster:

• Projects/namespaces isolate resources and RBAC.
• NetworkPolicies restrict cross-team traffic.
• Quotas prevent a single team from exhausting cluster resources.
• Shared services (e.g., logging, monitoring, ingress) are maintained by platform teams.

Template and Blueprint Usage

To ensure consistency, teams often use:

• Application templates (YAML, Helm charts, Kustomize bases).
• “Golden” base images that are security-reviewed.
• Common CI/CD pipeline templates.

The goal is to reduce one-off customization and increase repeatability.

Example: End-to-End Lifecycle Across Environments

Here is a simplified flow that ties the above ideas together:

1. Developer commits code to git and opens a pull request.
2. CI builds image, runs tests, and pushes the image to a registry.
3. CI or GitOps updates a configuration git repo (e.g., bumping the image tag in dev manifests).
4. Argo CD or a pipeline deploys the change to the dev project on OpenShift.
5. Team verifies results in dev:
• Check logs, metrics, basic functionality.
6. Promotion to test/stage:
• Approve a pull request that updates the manifests for the higher environment.
7. Non-functional tests (performance, security scans) run in test/stage.
8. Change is promoted to prod:
• Usually after sign-offs and possibly a change management process.
9. Production monitoring:
• Watch alerts, dashboards, error logs.
10. Rollback if needed:
• Revert the manifest or image tag and redeploy.

OpenShift is the runtime and management platform at the center of this lifecycle; other tools integrate with it for build, testing, security, and change management.

Working Efficiently with OpenShift in Daily Practice

To be effective on OpenShift, practitioners adopt certain habits:

• Use version control for everything:
• Application code, deployment manifests, config, policies, and sometimes even RBAC.
• Prefer automation to manual steps:
• Scripting with oc, pipelines for builds and deployments, and GitOps for configuration.
• Standardize naming, labels, and annotations:
• Makes it easier to search, filter, monitor, and secure resources.
• Observe before changing:
• Check pod events, logs, and metrics before making changes.
• Test changes in lower environments:
• Mimic production as closely as possible.

These patterns transform OpenShift from “a cluster you log into” into “a platform that reliably runs many applications and teams.”