Home > Workload Solutions > Container Platforms > Red Hat OpenShift Container Platform > Archive > Design Guide—Red Hat OpenShift Container Platform 4.8 on Dell Infrastructure > Red Hat OpenShift Container Platform
OpenShift Container Platform is an enterprise-grade declarative state machine that has been designed to automate application workload operations based on the upstream Kubernetes project. In a Kubernetes context, “declarative” means that developers can specify a configuration in code for an application or workload without knowing how that application is going to be deployed.
OpenShift Container Platform uses the OpenShift Kubernetes Engine, an enterprise-grade Kubernetes distribution, to provide production-oriented container and workload automation. OpenShift Container Platform 4.8 is based on Kubernetes version 1.21, which includes native support for cluster snapshots, enabling cluster backup and recovery. Built on top of Kubernetes, OpenShift Container Platform gives administrators and developers the tools that they need to deploy and manage applications and services at scale.
Note: OpenShift Container Platform is a certified Kubernetes distribution. Certification for Kubernetes distributions is provided by the Cloud Native Computing Foundation.
The following figure shows the OpenShift Container Platform architecture, along with OpenShift Platform Plus. While the focus of the design for OpenShift Container Platform 4.8 was on the validation of OpenShift Container Platform, OpenShift Platform Plus is available as an optional package that integrates Red Hat Advanced Cluster Management and Advanced Cluster Security for Kubernetes, Red Hat Quay, and OpenShift Data Foundation storage.
In Kubernetes, everything is an object. Every object has a current state, a preferred state, and a specification of how a state transition can be achieved. This specification includes everything from applications, deployments, and services to machine configuration and management of specific hardware resources. When a Kubernetes object is created, the cluster uses the object to transition toward the preferred state for the cluster.
Custom Resource Definitions (CRDs) are used to specify new resource types, which are then used to create Custom Resources (CRs). Middleware (typically, operators) uses this extensible mechanism to create resource types that Kubernetes and other middleware with appropriate access can manage and use.
Kubernetes provides an abstraction layer for application containers, deployments, and services and automates all container operations. Developers and administrators specify the needs of an application in a declarative manner, and Kubernetes automatically deploys, terminates, or restarts containers to converge on this preferred state.
Kubernetes consists of independent control processes (state transition machines) that move the current state of the cluster toward the preferred state (see Cluster automation).
Upstream Kubernetes has some limitations in that it does not build or deploy applications; provide logging, monitoring, or alerting mechanisms; and is not a self-healing, self-managing system. As an open-source project, Kubernetes must support various use cases and enable customers to use a wide variety of projects that are compatible with Kubernetes.
OpenShift Container Platform fills the gaps that Kubernetes leaves open, such as:
Among other benefits that it provides for production-grade environments, OpenShift Container Platform:
The operator framework gives vendors the ability to manage the life cycle of the middleware they provide—for example, the Dell CSI operator provides drivers for Dell storage products. Operators attempt to encode the operational knowledge that is required for various stateful applications. Depending on its complexity, the operator can be used to fully automate the life cycle management of various applications and middleware, automatically scale, and handle abnormalities gracefully. Like Helm, a universal package manager for Kubernetes, an operator can be used to configure and install middleware. Unlike Helm, operators are application-specific—an operator must be installed to manage each middleware application.
Operators are designed to simplify Day-2 operations by automatically deploying, updating, and maintaining specific application deployments. This simplification is achieved through the creation of CRDs that are managed through a control loop that is embedded in the operator.
The following figure shows the benefits that operators can provide, depending on their complexity: