For decades, monolithic architecture was considered the standard for software development. In monolithic architecture, an application is a unified unit, with all components connected within a single codebase. While this approach offers a lot of convenience early on in a project’s life for ease of code management, it quickly becomes a bottleneck for development and scaling. A minor change requires a complete rebuild and redeployment of the entire application, and a failure in one part can bring the whole system down.
The rigidity of monolithic architecture led to the creation of microservices architecture, which breaks applications into small, independent services. This design provides greater agility but creates a new challenge: managing a distributed system of dozens of services.
Addressing the management issues with microservices led to the rise of containerization. Technologies like Docker emerged to package each microservice and its dependencies into a lightweight, isolated container. Each service could run consistently and independently across different environments, from a developer’s laptop to a production server. The need to manage, deploy, and scale a massive number of containers gave rise to container orchestration platforms like Kubernetes and OpenShift.
In this article, we explore how Kubernetes and OpenShift address the challenges associated with microservices. We compare their strengths, trade‑offs, and ideal use cases to help you choose the right platform for your environment.
Summary of key considerations when choosing between OpenShift and Kubernetes
The following table provides an overview of the key aspects discussed in this article when deciding between OpenShift and Kubernetes as the container orchestration platform.
Consideration | Description |
Developer experience | Decide whether you want a bare Kubernetes setup that needs custom tooling or an integrated platform like OpenShift that has built‑in developer tools, such as a web console and source‑to‑image (S2I) capabilities. |
Security | Choose between configuring security and identity management yourself or using a platform that ships with a hardened, opinionated security model and integrated identity features. |
CI/CD, registry, and internal services | Assess whether you prefer to assemble your own toolchain for CI/CD, image registry, and supporting services, or you want to rely on OpenShift’s native, integrated components. |
Operational overhead and cost | Balance the lower license cost of upstream Kubernetes (at the price of more in‑house engineering and operations) against OpenShift’s commercial licensing that includes automation, support, and lifecycle management. |
Underlying OS updates | OpenShift uses an immutable, container-optimized OS with a managed update process, whereas Kubernetes is flexible enough to run on various Linux distributions, where the responsibility for OS updates and potential compatibility issues falls to the user. |
Automated Application-Centric Red Hat OpenShift Data Protection & Intelligent Recovery
Overview of Kubernetes
The concept of containers has evolved over the course of several decades, with plenty of players contributing along the way. Google launched process containers, which were later renamed cgroups, in 2006. LXC was initially developed by IBM in 2008. LMCTFY was released in 2013 as an open-source version of Google’s container stack, providing Linux application containers.
When Docker was introduced in 2013, it became so popular that the terms “container” and “Docker” began to be used interchangeably. However, while Docker revolutionized how applications were packaged and isolated via containerization, it quickly became apparent that simply creating containers wasn’t enough. The inherent complexity of deploying, scaling, and continuously managing hundreds of these individual containers across a distributed infrastructure presented a new, formidable challenge.
This is precisely where Kubernetes stepped in and rapidly established itself as the leading solution for orchestrating containers at scale. It provides the essential framework to transform a set of many independent containers into a cohesive, resilient, and highly available application platform, effectively solving the operational complexities introduced by the use of microservices at scale.
What is Kubernetes?
The roots of Kubernetes are deeply embedded in Google’s decades of experience with large-scale container management. Before Docker made containers accessible, huge Google applications—like Search and Gmail—were already running on a massive scale using proprietary, in-house technologies. These systems, named Borg and Omega, were developed to orchestrate and manage Google’s internal containerized infrastructure.
Google took the critical lessons and best practices learned from building and operating these platforms and, in 2014, created a new open-source platform. This new Kubernetes project was subsequently donated to the newly formed Cloud Native Computing Foundation (CNCF). By making Kubernetes open source, Google gave the broader tech community a robust and proven solution for the same challenges it had been solving internally for years, effectively democratizing container orchestration for everyone.
At its core, Kubernetes—often abbreviated as “K8s”—is a powerful, open-source platform designed to automate container deployment, scaling, and management. Over the years, Kubernetes has emerged as the de facto platform for deploying and managing cloud-native applications. It provides a framework for orchestrating containers across a cluster of machines, acting as a “container conductor” for applications. It ensures that services are always running, load-balanced, and resilient to failure.
Core functionalities and architecture
Kubernetes operates on a declarative model. Instead of telling it how to do something, users declare the desired state of their application, for example, “I want three instances of my web server running at all times.” Kubernetes’s control plane then tirelessly works to make the actual state of your cluster match your desired state.
The following figure depicts a high-level architecture of Kubernetes.
High-level Kubernetes architecture
As shown in the diagram, a Kubernetes cluster fundamentally relies on two types of nodes: the control plane and worker nodes.
Automated Red Hat OpenShift Data Protection & Intelligent Recovery
Perform secure application-centric backups of containers, VMs, helm & operators
Use pre-staged snapshots to instantly test, transform, and restore during recovery
Scale with fully automated policy-driven backup-and-restore workflows
Control plane
The control plane is responsible for managing the state of a Kubernetes cluster and is the brain behind all operations inside the cluster, making all global decisions and orchestrating the entire environment. It is responsible for maintaining the cluster’s desired state, encompassing tasks like scheduling workloads and reacting to system events.
The control plane hosts critical components such as the API server, etcd, scheduler, and controller manager, which collectively manage and coordinate all cluster operations, acting as the central nervous system for the Kubernetes ecosystem. The role of these components is as follows:
- API server: The API server acts as the central command post for the entire Kubernetes cluster. All internal and external communication to the cluster must pass through the API server, including interactions between internal system components and external user components. The API server exposes a RESTful API, allowing the submission of YAML configuration files (often referred to as manifests) over HTTPS. These YAML files describe the desired state of an application within the cluster.
- Cluster store (etcd): The cluster store is the only stateful part of the control plane and persistently stores the entire configuration and state of the cluster. As a vital component of every Kubernetes cluster, its failure would result in the loss of the cluster. The cluster store is based on etcd, a popular distributed database, which functions as the cluster’s distributed, consistent, and highly available key-value store. It is recommended that multiple etcd replicas be run for high availability and to back up data.
- Controller manager: The controller manager implements and runs a collection of various controllers that continuously monitor the cluster’s shared state through the API server. Each controller aims to move the cluster’s current state closer to the desired state.
- Scheduler: The scheduler is responsible for watching the API server for newly created pods with no assigned node and selecting an appropriate worker node to run on. The scheduler employs complex logic to filter out nodes incapable of running tasks and then ranks the remaining capable nodes. The node with the highest-ranking score is ultimately selected to run the task.
Worker nodes
Worker nodes are the machines where the actual containerized applications are executed, acting sort of like the “engine room” of the Kubernetes cluster. Application pods are scheduled on worker nodes, where they find the required computing, memory, and storage resources to run and a network to talk to each other and the outside world.
A pod is the smallest scheduling unit in Kubernetes: a logical collection of one or more containers scheduled together. Each worker node hosts crucial agents like the kubelet, kube-proxy, and a container runtime. This enables it to receive instructions from the control plane, manage network traffic, and ensure that containers are running and healthy on its allocated resources.
The following are the major components of a worker node:
- Kubelet: The kubelet acts as an agent running on each worker node, serving as the bridge between the node and the Kubernetes control plane. Its primary function is to ensure that the containers specified in a pod’s manifest run consistently and stay healthy. It receives instructions from the API server and reports the pods’ status, health, resource usage, and the state of the node itself back to the control plane.
- Kube-proxy: Kube-proxy is a network proxy that runs on every worker node, facilitating network communication for Kubernetes services. It maintains network rules on the node, allowing network access to pods from inside and outside the cluster. This component handles service discovery and load balancing for traffic directed to the correct backend pods.
- Container runtime: The container runtime is the foundational software for executing containers on the worker node. Kubernetes supports various runtimes like containerd, CRI-O, or Docker. This component is tasked with pulling container images from registries, unpacking them, and running the containers according to the specifications provided by the kubelet.
Unresolved challenges left by Kubernetes
It’s important to understand that while Kubernetes has revolutionized container orchestration, it is fundamentally a foundational platform. It provides the essential engine for managing containers at scale, but doesn’t offer a complete, ready-to-use application platform right out of the box. This distinction is necessary, and it means that teams adopting vanilla Kubernetes will inevitably face several significant challenges and need to invest substantial effort to build and maintain a truly production-ready orchestration platform.
Here are some of the major challenge areas:
- Security and compliance: Securing a Kubernetes cluster is multifaceted: It requires configuration of network policies to control traffic flow, robust role-based access control (RBAC) to manage who can do what within the cluster, and secure handling of sensitive data like API keys and passwords. Achieving and maintaining enterprise-grade security postures and compliance with various regulatory standards demands continuous vigilance, deep expertise, and significant custom tooling and policy enforcement.
- Lack of integrated observability: Containerized applications create monitoring challenges at a much greater pace than traditional monitoring tools can handle. While Kubernetes provides basic health checks and events, it doesn’t include a solution for monitoring, logging, and tracing applications. Cluster administrators must independently research, select, integrate, and configure various third-party tools (such as Prometheus for monitoring, Grafana for dashboards, and the ELK stack for logging). Aggregating and managing disparate observability tools adds complexity and operational overhead to ensure complete visibility into system behavior and application performance.
- Complex networking: Setting up the networking layer in Kubernetes, particularly for advanced requirements, is often a significant hurdle. This encompasses everything from configuring Container Network Interface (CNI) plugins for internal cluster communication and securely exposing applications to the outside world using ingress controllers.
- Underlying OS dependencies: One of the great strengths of Kubernetes is its flexibility, allowing it to run on almost any Linux distribution and even supporting nodes with different underlying operating systems. However, this flexibility also presents a challenge: Its components, including CNIs and container runtimes, are susceptible to issues with the underlying OS environment. Applying OS level updates, updating kernel versions, or making other system-level changes can often lead to compatibility issues, break network functionality, or cause unexpected downtime if not carefully managed. The challenges are significant enough that even major organizations with substantial expertise have encountered difficulties.
These gaps mean that Kubernetes is a complex foundation that often requires additional layers and tools to become a fully functional and developer-friendly platform.
Overview of OpenShift
The OpenShift Container Platform (OCP) is Red Hat’s enterprise-grade Kubernetes distribution that was designed to transform the foundational power of Kubernetes into a complete, integrated, and application-centric platform. While Kubernetes provides the foundation, OpenShift builds upon it with a vast ecosystem of tools and features to address the operational and developer experience gaps inherent in vanilla Kubernetes. It aims to provide a “batteries-included” platform for deploying and managing containerized applications across hybrid cloud environments.
How OpenShift extends Kubernetes capabilities
OpenShift builds on Kubernetes to provide business-class features that deliver a greater user experience and a wider tool set for enterprise needs. OpenShift leverages the extensibility of Kubernetes through operators and custom resource definitions (CRDs).
An operator is a method of packaging, deploying, and managing Kubernetes-native applications, automating complex operational tasks like upgrades, backups, and failovers for specific services. A CRD allows OpenShift to define new, custom resource types, extending the Kubernetes API to manage these higher-level application components directly within the cluster. This powerful combination enables OpenShift to provide deeply integrated services that feel native to the platform, abstracting away much of the underlying Kubernetes complexity.
A high-level overview of OpenShift is shown in the following figure.
OpenShift component stack
Some of the major features provided by OpenShift that aren’t included in vanilla Kubernetes are as follows:
- Integrated CI/CD: OpenShift comes with built-in or tightly integrated CI/CD capabilities, often leveraging tools like Tekton Pipelines (OpenShift Pipelines) and OpenShift GitOps (Argo CD) to automate application builds, testing, and deployments directly from source code. This eliminates the need for teams to piece together disparate CI/CD tools manually.
- Developer-centric tools: It offers a rich set of developer tools, including source to image (S2I) for building container images directly from application source code without writing Dockerfiles, integrated IDE experiences, and a streamlined web console designed for developers to manage their applications.
- Hardened security defaults: OpenShift enforces stricter security policies by default, requiring containers to run as non-root users, significantly improving applications’ security posture.
- Integrated identity management: OpenShift provides a robust, integrated identity and access management system, allowing seamless integration with enterprise directories (like LDAP or Active Directory) and offering sophisticated RBAC across the entire platform, not just Kubernetes resources.
- Integrated image registry: OpenShift includes an integrated image registry that functions as a centralized location for storing and managing container images.
- Out-of-the-box observability: OpenShift includes a preintegrated and configured observability stack, typically built on Prometheus for metrics, Grafana for dashboards, and the EFK stack (Elasticsearch, Fluentd, Kibana) for logging. This provides immediate, centralized insights into cluster health and application performance without extensive setup.
- Unified dashboards: A single, consolidated web console offers dashboards for monitoring the infrastructure and deployed applications, simplifying troubleshooting and operational oversight.
- Opinionated networking: OpenShift has a fully integrated and tested networking solution, including its own software-defined network (SDN) and an ingress controller for external access. This simplifies ingress management and provides consistent network behavior across the cluster.
- Underlying OS integration: Unlike vanilla Kubernetes, which runs on a general-purpose OS, OpenShift leverages Red Hat CoreOS (RHCOS) as its underlying operating system for worker nodes. RHCOS is an immutable, container-optimized OS specifically tailored and tested for OpenShift. This deep integration mitigates many compatibility issues, patching complexities, and stability concerns associated with running Kubernetes on general-purpose Linux distributions, providing a more stable and predictable environment.
In essence, OpenShift takes Kubernetes’s powerful but raw engine and adds necessary components, automation, and a prescriptive framework to deliver a truly enterprise-ready, full-stack application platform.
Comparing OpenShift and Kubernetes
The following table summarizes the differences between Kubernetes and OpenShift:
Feature | Kubernetes | OpenShift |
Maintainer | Developed by Google, now maintained by CNCF. | Developed and maintained by Red Hat. Commercial product with open-source components. |
Underlying OS | Runs on almost any Linux distribution but requires OS management. | Uses Red Hat CoreOS (RHCOS) as a hardened, immutable, container-optimized OS for nodes. |
Setup & Installation | Manual, complex setup with many choices for CNI, CRI, tools. Requires significant expertise. | Automated but resource-intensive. High entry barrier; requires min. 3 control nodes + 2 workers. |
Developer Experience | Requires deep Kubernetes knowledge (YAML, CLI). Fewer built-in dev tools. | Enhanced developer tools (S2I, web console, integrated CI/CD). Abstracts K8s complexity. |
Security | Highly configurable, but requires significant manual effort to secure. | Stronger security defaults, integrated identity management, and tighter SELinux policies by default. |
Networking | Requires choice and configuration of CNI. Does not include any ingress controller by default. | Integrated SDN and an opinionated router for ingress. |
Observability | No native, integrated stack. Requires manual integration of third-party tools (Prometheus, Grafana, EFK). | Built-in, preintegrated monitoring (Prometheus/Grafana) and logging (EFK stack) for cluster. |
CI/CD | Not integrated. Requires external tools (Jenkins, GitLab CI, Argo CD) to be manually connected. | Integrated CI/CD pipelines (Tekton, OpenShift GitOps), and image build capabilities (S2I). |
Registry | No built-in image registry. Relies on external registries. | Integrated Container Image Registry for internal use. |
Operational Overhead | Higher, due to the need to integrate, maintain, and secure various components. | Lower, due to integrated components, automation, and enterprise support. |
Cost | Free (open source), but significant operational costs for self-management. | Commercial licensing from Red Hat for support. |
Target Audience | Organizations with deep DevOps/SRE expertise willing to build and customize their stacks. | Enterprises seeking a comprehensive, secure, and supported platform with a focus on developer productivity. |
Modern DevOps architecture using OpenShift and Kubernetes
OpenShift and Kubernetes have transformed DevOps practices by simplifying application deployment and management. Kubernetes offers a powerful container orchestration platform, while OpenShift adds enterprise features that streamline CI/CD automation, scaling, and high availability. In this section, we demonstrate how to implement a modern DevOps CI/CD pipeline using Tekton pipelines on OpenShift and K8s, showcasing the ease of automation and deployment with this arrangement.
Deployment automation using CI/CD with Tekton
For the purpose of demonstration, we’ll use OpenShift Pipelines, the platform’s implementation of the open-source Tekton project. Tekton is a Kubernetes-native framework for creating CI/CD pipelines, using Kubernetes custom resources (CRs) to define the pipeline stages.
Unlike a standard Kubernetes cluster, which requires manual setup and configuration of Tekton, OpenShift simplifies matters by providing a Tekton operator via its OperatorHub. This allows for a one-click, secure installation and lifecycle management of the entire Tekton pipeline system. While the same pipeline can be run on a vanilla Kubernetes cluster, it would first require the setup of Tekton and its prerequisites, adding complexity.
Note: If you want to use Kubernetes for the demo, ensure that you have set up the Tekon pipeline in your cluster.
A typical Tekton pipeline in OpenShift automates the following steps:
- Source code integration: A Git event (e.g., a push to a repository) triggers the pipeline.
- Building the container image: A Tekton task uses tools like Buildah or Source to Image (S2I) to build a container image from the source code.
- Testing: The task can run unit or integration tests against the built image.
- Pushing the image: Once built and tested, the image is moved to internal OpenShift or external registry.
- Deployment: A final task applies a deployment manifest (e.g., a deployment or deployment config) to deploy the new image to the cluster.
Understanding the demo pipeline
A Tekton pipeline is a reusable blueprint that defines a sequence of tasks. Each task performs a specific action and they are chained together to form a complete workflow. The demo pipeline automates the entire process of getting application source code from a Git repository, building it into a container image, and deploying it to OpenShift.
Each task runs in its own pod and consists of one or more steps. This pipeline uses resolvers, which are prebuilt, reusable tasks available across the entire OpenShift cluster from the Tekton Hub.
The pipeline is composed of three distinct tasks that run in a specific order:
- fetch-repository: This task uses the git-clone resolver to retrieve source code from a specified Git repository and place it in a shared workspace. The workspace is a temporary shared volume that allows subsequent tasks to access the cloned files.
- build: This task uses the s2i-nodejs resolver, which leverages OpenShift’s built-in S2I capability. S2I injects the application source code into a prebuilt builder image for Node.js, which handles the compilation and packaging of the code into a runnable container image.
- deploy: This final task uses the openshift-client resolver, which provides a container with the oc command-line tool. It then executes the oc new-app command to create all the necessary OpenShift resources (e.g., a deployment, service, and route) and deploy the newly built image to the cluster.
You can list the available tasks in your cluster as follows. For instance, in this demo, we’re going to use tasks such as git-clone, which are already available in the cluster.
$ oc get task -n openshift-pipelines | grep "git-clone\|s2i-nodejs\|openshift-client"
git-clone 11d
git-clone-1-18-0 92d
git-clone-1-19-0 45d
openshift-client 11d
openshift-client-1-18-0 92d
openshift-client-1-19-0 45d
s2i-nodejs 11d
s2i-nodejs-1-18-0 92d
s2i-nodejs-1-19-0 45d
Tekton also provides a separate CLI tool tkn for managing pipelines. Make sure to first install the CLI. The available tasks can also be verified via the tkn CLI.
$ tkn task ls -n openshift-pipelines | grep "git-clone\|s2i-nodejs\|openshift-client"
git-clone This object represe... 1 week ago
git-clone-1-18-0 This object represe... 13 weeks ago
git-clone-1-19-0 This object represe... 6 weeks ago
openshift-client This task runs comm... 1 week ago
openshift-client-1-18-0 This task runs comm... 13 weeks ago
openshift-client-1-19-0 This task runs comm... 6 weeks ago
s2i-nodejs Builds the source c... 1 week ago
s2i-nodejs-1-18-0 Builds the source c... 13 weeks ago
s2i-nodejs-1-19-0 Builds the source c... 6 weeks ago
Let’s proceed to create the demo pipeline.
apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
name: demo-pipeline
spec:
params:
- name: IMAGE_NAME
type: string
- name: GIT_REPO
type: string
- name: GIT_REVISION
type: string
workspaces:
- name: workspace
tasks:
- name: fetch-repository
taskRef:
resolver: cluster
params:
- name: kind
value: task
- name: name
value: git-clone
- name: namespace
value: openshift-pipelines
workspaces:
- name: output
workspace: workspace
params:
- name: URL
value: $(params.GIT_REPO)
- name: REVISION
value: $(params.GIT_REVISION)
- name: SUBDIRECTORY
value: ''
- name: DELETE_EXISTING
value: 'true'
- name: build
taskRef:
resolver: cluster
params:
- name: kind
value: task
- name: name
value: s2i-nodejs
- name: namespace
value: openshift-pipelines
runAfter:
- fetch-repository
workspaces:
- name: source
workspace: workspace
params:
- name: IMAGE
value: $(params.IMAGE_NAME)
- name: TLS_VERIFY
value: 'false'
- name: deploy
taskRef:
resolver: cluster
params:
- name: kind
value: task
- name: name
value: openshift-client
- name: namespace
value: openshift-pipelines
runAfter:
- build
params:
- name: SCRIPT
value: |
oc new-app --docker-image $(params.IMAGE_NAME)
Apply the pipeline above with the command shown below.
$ oc apply -f pipeline.yaml
pipeline.tekton.dev/demo-pipeline created
$ tkn pipeline ls
NAME AGE LAST RUN STARTED DURATION STATUS
demo-pipeline 29 seconds ago --- --- --- ---
Note that to trigger this pipeline, you’ll need to define a PipelineRun manifest. The PipelineRun object tells Tekton to start a new instance of a pipeline and provides all the necessary information to run it. The pipeline run will perform the following tasks:
- Create a pod for each task in the pipeline.
- Dynamically provision a 1Gi volume based on the volumeClaimTemplate.
- Execute the tasks in the correct order, passing the params values to them and sharing the workspace.
apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
generateName: demo-pipelinerun-
spec:
pipelineRef:
name: demo-pipeline
workspaces:
- name: workspace
volumeClaimTemplate:
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
params:
- name: IMAGE_NAME
value: "image-registry.openshift-image-registry.svc:5000/mumer-prime-dev/my-nodejs-app:latest"
- name: GIT_REPO
value: "https://github.com/sclorg/nodejs-ex.git"
- name: GIT_REVISION
value: "master"
Trigger the pipeline with the following command:
$ oc create -f pipelinerun.yaml
pipelinerun.tekton.dev/demo-pipelinerun-xq924 created
You can monitor the status of the pipeline run as follows:
$ tkn pipelinerun logs demo-pipelinerun-xq924
[fetch-repository : prepare-and-run] Running Script /scripts/prepare.sh
[fetch-repository : prepare-and-run] ---> Phase: Preparing the filesystem before cloning the repository...
[fetch-repository : prepare-and-run] ---> Phase: Deleting all contents of checkout-dir '/workspace/output/'...
[fetch-repository : prepare-and-run] removed directory '/workspace/output//lost+found'
[fetch-repository : prepare-and-run] Running Script /scripts/git-run.sh
[fetch-repository : prepare-and-run] ---> Phase: Setting output workspace as safe directory ('/workspace/output')...
[fetch-repository : prepare-and-run] ---> Phase: Setting up HTTP_PROXY=''...
[fetch-repository : prepare-and-run] ---> Phase: Settting up HTTPS_PROXY=''...
[fetch-repository : prepare-and-run] ---> Phase: Setting up NO_PROXY=''...
[fetch-repository : prepare-and-run] ---> Phase: Cloning 'https://github.com/sclorg/nodejs-ex.git' into '/workspace/output/'...
[fetch-repository : prepare-and-run] + exec git-init -url=https://github.com/sclorg/nodejs-ex.git -revision=master -refspec= -path=/workspace/output/ -sslVerify=true -submodules=true -depth=1 -sparseCheckoutDirectories=
[..........]
deploy : oc] Tags: builder, nodejs, nodejs22
[deploy : oc]
[deploy : oc] * An image stream tag will be created as "my-nodejs-app:latest" that will track this image
[deploy : oc]
[deploy : oc] --> Creating resources ...
[deploy : oc] deployment.apps "my-nodejs-app" created
[deploy : oc] service "my-nodejs-app" created
[deploy : oc] --> Success
[deploy : oc] Application is not exposed. You can expose services to the outside world by executing one or more of the commands below:
[deploy : oc] 'oc expose service/my-nodejs-app'
[deploy : oc] Run 'oc status' to view your app.
Once the run completes, you can check the status and verify that the pipeline run has completed successfully.
$ tkn pipelinerun list
NAME STARTED DURATION STATUS
demo-pipelinerun-xq924 4 minutes ago 2m1s Succeeded
Verify that the application pods are up and running.
$ oc get all
NAME READY STATUS RESTARTS AGE
pod/demo-pipelinerun-xq924-build-pod 0/2 Completed 0 5m38s
pod/demo-pipelinerun-xq924-deploy-pod 0/1 Completed 0 4m1s
pod/demo-pipelinerun-xq924-fetch-repository-pod 0/1 Completed 0 5m55s
pod/my-nodejs-app-6d5659d7dc-4rj47 1/1 Running 0 3m55s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/my-nodejs-app ClusterIP 172.30.233.18 <none> 8080/TCP 3m55s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/my-nodejs-app 1/1 1 1 3m55s
NAME DESIRED CURRENT READY AGE
replicaset.apps/my-nodejs-app-6d5659d7dc 1 1 1 3m55s
The status of pipeline run can also be verified from the OpenShift console, by navigating to Pipelines -> PipelineRuns.
OpenShift pipeline
The demo shows that using OpenShift pipelines simplifies setup and management over a standard Kubernetes cluster. A Tekton pipeline can automate the entire CI/CD workflow, from fetching source code to building a container image with S2I process and deploying the application, ensuring a streamlined and repeatable process.
Backup and restore
Traditional backup methods for monolithic applications usually focus on a single server or a virtual machine. In contrast, backing up applications that follow the microservices paradigm is far more complex due to their distributed nature. Ensuring a consistent and restorable state requires an application-centric approach that captures all interdependent components, including code, Kubernetes manifests, and data from multiple persistent volumes. A sound strategy must be in place to recover from data corruption, accidental deletions, or a complete cluster failure.
A solid backup strategy follows the 3-2-1 rule:
- 3 copies of the data are needed.
- 2 different storage media should be used (e.g., disk and tape, or different cloud storage providers).
- 1 copy must be kept off-site in a remote location to protect against a localized disaster.
Backup solutions for Kubernetes and OpenShift
Several open-source and commercial solutions are available for backing up Kubernetes and OpenShift environments, but they often have limitations in the context of a comprehensive, application-aware strategy.
Some of the more popular solutions are discussed below:
- Trilio is a cloud-native, application-focused data protection platform designed specifically for Kubernetes and OpenShift environments. Unlike basic backup tools, Trilio captures the entire application, including data, metadata, and all associated Kubernetes objects, to ensure proper application consistency. Its deep integration with Red Hat Advanced Cluster Management (RHACM) allows for centralized, policy-driven data protection across hybrid, multi-cloud, and edge deployments.
- Velero is a widely used open-source tool for Kubernetes backup and migration. Velero backs up Kubernetes objects and persistent volumes. However, one of its significant limitations is that it often requires additional plugins or manual configuration to ensure application consistency during the backup process. It performs crash-consistent backups by default, which means all application data might not be captured, potentially leading to data inconsistencies upon restore. It also may not fully capture the complex interdependencies, and a complete restore may require manual intervention. The OpenShift API for Data Protection (OADP) operator installs and leverages Velero as its underlying backup and restore mechanism.
- Kasten by Veeam is a commercial solution that offers an application-centric approach. While Kasten provides a user-friendly interface and robust policy-based automation, it is a proprietary solution. Its cost and licensing model may be a barrier for some organizations, and it may not offer other platforms’ granular point-in-time recovery capabilities.
Trilio for Kubernetes: An application-centric solution
Trilio for Kubernetes is a cloud-native backup and recovery platform designed specifically for modern containerized applications. It focuses on several key capabilities that address the limitations of other solutions:
- Application-aware backup and restore: Trilio takes a snapshot of all the components of an application simultaneously, including the data, metadata (Kubernetes manifests), and persistent volumes. This ensures that the application is restored with all its configurations intact, eliminating the need to recreate resources manually. This is essential for a recoverable state.
- Continuous data protection: Trilio can continuously capture and track changes to your applications. This allows you to restore to a very granular point in time, minimizing data loss to mere seconds.
- Policy-based backup: Trilio allows you to define policies that automate the backup process instead of using manual backups. You can set schedules based on frequency (hourly, daily, or weekly) and retention policies, ensuring that backups are taken consistently and stored for the required duration.
- Multi-cluster backup, migration, and disaster recovery: This is a critical capability often overlooked in a single-cluster mindset. Kubernetes itself is unaware of other clusters; Trilio addresses this by enabling backups to be stored externally, allowing for seamless restoration to a different cluster. This functionality is essential for migrating applications between clusters or for executing a complete disaster recovery plan where the primary cluster is unavailable.
- Cloud-native and Red Hat ecosystem integration: Being built for Kubernetes, Trilio itself runs as an application on top of Kubernetes or OpenShift. This cloud native architecture allows it to be highly scalable and resilient. As a long-standing Red Hat partner, Trilio also offers specific integrations and customizations for the Red Hat ecosystem, including integrations with Red Hat Advanced Cluster Management (ACM).
Learn How To Best Backup & Restore Virtual Machines Running on OpenShift
Conclusion
If you have a strong platform engineering team that enjoys assembling tools, tuning configurations, and owning the full stack, Kubernetes gives you a highly flexible, vendor‑neutral base. You decide how opinionated or minimal the platform should be, which tools plug in where, and how fast you adopt new ecosystem projects.
If you’d rather focus engineering effort higher up the stack (on application features instead of platform provisioning), OpenShift offers a more curated experience. It layers developer tooling, security controls, and operational workflows on top of Kubernetes, trading some architectural freedom and license cost for speed, consistency, and a shared way of working across teams.
In practice, many organizations land somewhere in between. They might start with upstream Kubernetes for maximum flexibility, then adopt OpenShift or similar platforms where standardization, security, and operational simplicity matter most. In both cases, reliable backup, restore, and migration remain critical parts of the platform.
Trilio provides Kubernetes‑native backup and recovery that works across distributions—including upstream Kubernetes and OpenShift—so you can protect and move applications and data without tying your resilience strategy to a single vendor’s stack. If you’re evaluating how to run stateful workloads, migrate between environments, or harden your disaster recovery posture, try the Trilio demo to explore its capabilities first‑hand.
Like This Article?
Subscribe to our LinkedIn Newsletter to receive more educational content