Overview

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 deployed. OpenShift Container Platform uses the enterprise-grade Kubernetes distribution, called the OpenShift Kubernetes Engine, 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, enabling cluster backup and recovery. On top of the Kubernetes Engine, OpenShift Container Platform provides administrators and developers with the tools they require to deploy and manage applications and services at scale, as shown in the following figure.

Note: OpenShift Container Platform is a certified Kubernetes distribution.

Figure 1.                  OpenShift Container Platform architecture

What Kubernetes is

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 desired state of operations. Developers and administrators can specify the needs of an application in a declarative manner, and Kubernetes automatically deploys, terminates, or restarts containers to converge on this desired state.

What Kubernetes is not

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 desired 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 in that it does not build or deploy applications, does not provide logging, monitoring, or alerting mechanisms, and is not a self-healing, self-managing system. As an open-source project, Kubernetes must support a variety of use cases and enable users to use a wide variety of projects that are compatible with Kubernetes.

Why OpenShift?

OpenShift Container Platform fills the gaps that Kubernetes leaves open:

• Platform-level services including building and packaging applications
• Integrated logging and monitoring solutions (Prometheus and Grafana)
• Integrated web console

OpenShift Container Platform is intended as a turnkey solution for production-grade environments. Among other benefits, OpenShift Container Platform:

• Eliminates the complexity of installing Kubernetes and of adding authentication, management, logging, security, and networking.
• Provides additional self-management capabilities that are not found in Kubernetes due to the tightly coupled toolchain: the default containers-first operating system (Red Hat CoreOS), a Kubernetes-first container runtime (CRI-O), and a rigorous testing and certification process for additional Red Hat and vendor middleware.

Kubernetes concepts

In Kubernetes, everything is an object. Every object has a current state, a desired 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 desired 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.

Cluster automation

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. Like Helm, an Operator can be used to configure and install middleware; however, depending on the complexity of the Operator, the Operator can fully automate an application’s life cycle management. Operators are application-specific, and therefore an Operator must be installed to manage each middleware application. In contrast, Helm is a universal package manager for Kubernetes.

The following figure shows the benefits that Operators can provide, depending on the complexity of the Operator:

Figure 2.                  Operator maturity

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. More complex Operators can be used to fully automate the life cycle management of various applications and middleware, scaling, and handling abnormalities gracefully.