EX280 – OpenShift Administrator Tips & Tricks (Part 4): Deployments and Reliability

EX280 – OpenShift Administrator Tips & Tricks (Part 4): Deployments and Reliability

Table of Contents

Welcome to the fourth part of my EX280 – OpenShift Administrator Tips & Tricks mini-series!
This time, we’re focusing on the heart of application management in OpenShift: Deployments and Reliability. These topics map directly into exam tasks and reflect real-world production responsibilities every OpenShift administrator must master.


🚀 Deployments: The Engine of Application Delivery

Deployments manage how your containerized application runs, updates, and scales.
Your EX280 exam expectations include:

  • Creating and modifying deployments
  • Updating images and strategies
  • Managing rollouts and rollbacks
  • Scaling applications (manually and automatically)

Let’s look at key operations:

Update a Deployment Image

oc set image deployment/myapp myapp=registry.redhat.io/ubi8/httpd-24

Check rollout status

oc rollout status deployment/myapp

Rollback to a previous version

oc rollout undo deployment/myapp

Pro Tip: Always verify labels and selectors — mismatches lead to unexpected scaling behavior.


📈 Scaling Applications

Scaling is essential for performance and resilience. The exam expects you to know both:

  • Manual scaling
  • Horizontal Pod Autoscaling (HPA)

Manual scaling

oc scale deployment/myapp --replicas=3

Autoscaling

oc autoscale deployment/myapp --min=1 --max=5 --cpu-percent=80

Then verify:

oc get hpa

Pro Tip: The HPA only works when metrics-server or the OpenShift monitoring is correctly configured. In the exam environment, assume it is ready unless stated otherwise.


❤️‍🔥 Probes: Liveness, Readiness, Startup

These three probes determine your application’s ability to run reliably in production.

Probe TypePurposeEffect on PodTriggers Restart?
readinessProbeDetermines if pod is ready to receive trafficRemoves pod from service endpoints❌ No
livenessProbeDetects if container is stuck or unhealthyRestarts container if probe fails✅ Yes
startupProbeUsed for slow-starting applications; gates liveness checksPrevents early restarts until startup is done✅ Yes (after startupProbe succeeds)

💡 YAML Patterns Are Similar for All Probes

The good news is that all three probes use almost identical YAML structure. You can swap between probe types using the same field patterns:

httpGet (API endpoint/health URL test)

tcpSocket (TCP port check)

exec (execute commands inside the container)

Readiness Probe

readinessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

Liveness Probe

livenessProbe:
  httpGet:
    path: /live
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 20

Startup Probe

startupProbe:
  httpGet:
    path: /startup
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

Pro Tip: Know when to use each probe — this is a direct scoring area in the exam.

Here’s a quick overview of supported probe types:

  • HTTP GET Test Checks if an API endpoint returns success. Example: /healthz, /live, /startup

  • TCP Socket Test Verifies if the application responds on a specific port.

  • Command Exec Test Runs a command inside the container and checks exit code.

Example Patterns for Each Probe Method

✅ HTTP GET probe:

httpGet:
  path: /healthz
  port: 8080

✅ TCP Socket probe:

tcpSocket:
  port: 8080

✅ Exec probe:

exec:
  command:
    - cat
    - /tmp/healthy

🔐 Security Context Constraints (SCC)

You may be required to run a deployment with specific privileges or use custom service accounts.

Create a service account

oc create sa custom-sa

Assign SCC

oc adm policy add-scc-to-user anyuid -z custom-sa

Then update the deployment:

serviceAccountName: custom-sa

Exam Tip: SCC misconfiguration commonly breaks pods — check oc describe pod for clues.


🧠 Exam Strategy

Here’s how to approach reliability tasks efficiently:

  • Practice writing probe definitions repeatedly
  • Understand when to use HPA vs manual scaling
  • Master oc rollout commands — especially status, undo, and history
  • Validate your deployment states using:
    oc describe deployment <name>
    
  • Use the web console only for visual confirmation — rely on the CLI for precision

If you can configure probes, scale deployments, and fix rollout issues in under 15 minutes, you’re exam-ready.


Coming Up Next…

In Part 5, we’ll wrap up the series with Developer Self-Service — quotas, limits, templates, and empowering users to work efficiently in OpenShift.

Practice smart, automate when possible, and continue operating like a production-grade OpenShift admin. 🚀

comments powered by Disqus

Related Posts

EX280 – OpenShift Administrator Tips & Tricks (Part 3): Storage (Storage Classes, PV, PVC, ConfigMaps & Secrets)

EX280 – OpenShift Administrator Tips & Tricks (Part 3): Storage (Storage Classes, PV, PVC, ConfigMaps & Secrets)

Welcome to the third part of my EX280 – OpenShift Administrator Tips & Tricks mini-series!
In this post, we’ll focus on Storage Management — one of the most practical and frequently tested areas in the EX280 exam. You’ll learn how to handle Persistent Volumes (PV), Persistent Volume Claims (PVC), Storage Classes, and configuration tools like ConfigMaps and Secrets.

Read More
Journey Through Generative AI: Reflections from the Google Cloud Generative AI Leader Exam

Journey Through Generative AI: Reflections from the Google Cloud Generative AI Leader Exam

Last evening, after passing the Google Cloud Generative AI Leader certification, a journey through the fascinating world of Generative AI unfolded — a story not just about technology, but about how AI is transforming creativity, business, and innovation.

Read More