Home > Communication Service Provider Solutions > Telecom Multicloud Foundation > Red Hat > Guides > Red Hat Open Shift Container Platform Guides > Reference Architecture Guide: Dell Technologies - Red Hat OpenShift Reference Architecture for Telecom > Red Hat OpenShift Container Platform
Red Hat OpenShift Container Platform 4.6 can host the development and run-time execution of containerized applications. The platform continues to mature and expand rapidly, providing access to the tools that are required to accelerate the transition to a modern open telecommunications network infrastructure.
OpenShift Container Platform is based on Kubernetes, the de facto automation and life cycle management platform for containerized workloads and services. Dell Technologies – Red Hat OpenShift Reference Architecture for Telecom includes Dell EMC servers, switches, and storage to enable you to develop, validate, and deploy your containerized applications.
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, in code, a configuration 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.6 is based on Kubernetes version 1.19, which includes native support for cluster snapshots that enable cluster backup and recovery. Also, OpenShift Container Platform 4.6 is the first extended user support release of OpenShift Container Platform, providing eighteen months of support. Built on top of Kubernetes, OpenShift Container Platform gives administrators and developers the tools they need to deploy and manage applications and services at scale.
This reference architecture includes support for the PowerProtect Data Manager solution, a highly scalable solution with inline, deduplication, and compression that extends data protection beyond the Kubernetes cluster to the complete OpenShift platform.
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:
Kubernetes provides an abstraction layer for application containers, deployments, and services and automates all container operations.
Developers and administrators manipulate Kubernetes object declarations and abstractions to achieve the preferred state of 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 is not just an “orchestration” platform for containers, which implies imperative, sequential actions. There is no imperative management of containers in Kubernetes. Rather, Kubernetes consists of independent control processes (state transition machines) that move the current state of the cluster towards the preferred state. This mechanism has fundamental implications for how cluster operations, application middleware, and more can be managed automatically (see Cluster automation).
Upstream Kubernetes has some fundamental limitations: 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 variety of projects that are compatible with Kubernetes.
OpenShift Container Platform fills the gaps that Kubernetes leaves open, such as:
OpenShift Container Platform is intended as a turnkey solution for production-grade environments. Among other benefits, OpenShift Container Platform:
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 towards the preferred state for the cluster.
Custom Resource Definitions (CRDs) can be used to specify new resource types, which can then be used to create Custom Resources (CRs). Middleware (typically, operators) can use this extensible mechanism to create resource types that Kubernetes and other middleware with appropriate access can manage and use.
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 EMC 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; therefore, 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: