OpenShift architecture

The OpenShift Container platform is both simple and complex when it comes to OpenShift components and overall architecture. It is complex in that it involves a lot of components interconnected with each other, but OpenShift is simple in the sense that all its components work independently of each other, and work seamlessly if something fails.

OpenShift and Kubernetes have most architecture components in common, such as:

• OpenShift masters
• OpenShift nodes
• Etcd as a key-value store

Components that are unique to OpenShift are:

• Router as ingress traffic control
• OpenShift Internal Registry

The following diagram describes the OpenShift container platform from an architectural point of view:

What Is the OpenShift Container Platform Architecture?

OpenShift Container Platform has a microservices-based architecture of smaller, decoupled units that work together. It runs on top of a Kubernetes cluster, with data about the objects stored in etcd, a reliable clustered key-value store. Those services are broken down by function:

• REST APIs, which expose each of the core objects.
• Controllers, which read those APIs, apply changes to other objects, and report status or write back to the object.

Users make calls to the REST API to change the state of the system. Controllers use the REST API to read the user’s desired state, and then try to bring the other parts of the system into sync. For example, when a user requests a build they create a “build” object. The build controller sees that a new build has been created, and runs a process on the cluster to perform that build. When the build completes, the controller updates the build object via the REST API and the user sees that their build is complete.

The controller pattern means that much of the functionality in OpenShift Container Platform is extensible. The way that builds are run and launched can be customized independently of how images are managed, or how deployments happen. The controllers are performing the “business logic” of the system, taking user actions and transforming them into reality. By customizing those controllers or replacing them with your own logic, different behaviors can be implemented. From a system administration perspective, this also means the API can be used to script common administrative actions on a repeating schedule. Those scripts are also controllers that watch for changes and take action. OpenShift Container Platform makes the ability to customize the cluster in this way a first-class behavior.

To make this possible, controllers leverage a reliable stream of changes to the system to sync their view of the system with what users are doing. This event stream pushes changes from etcd to the REST API and then to the controllers as soon as changes occur, so changes can ripple out through the system very quickly and efficiently. However, since failures can occur at any time, the controllers must also be able to get the latest state of the system at startup, and confirm that everything is in the right state. This resynchronization is important, because it means that even if something goes wrong, then the operator can restart the affected components, and the system double checks everything before continuing. The system should eventually converge to the user’s intent, since the controllers can always bring the system into sync.

OpenShift is built on top of Docker and Kubernetes, sometimes referred to as Kubernetes++. In addition to the Docker and Kubernetes solution, OpenShift brings additional capabilities and features required to provide a stable and production-ready PaaS platform. These new capabilities and features are:

(a)Authentication: OpenShift has several built-in authentication methods to allow granular access to OpenShift projects:

Local authentication

LDAP authentication

Request header authentication

Keystone authentication

GitHub authentication

(b)Multi-tenancy: OpenShift’s powerful functionalities allow granular multiuser and multi-project access control, a must-have feature for medium and large organizations that allows collaboration and access control for different groups.

(c)Internal Image Registry: OpenShift uses an internal registry to store images in OpenShift that are ready to be deployed on OpenShift nodes. It is also used for S2I builds.

(d)GUI and web console: OpenShift provides an easy-to-use web interface, powerful enough to create, build, deploy, update, and troubleshoot OpenShift projects and microservice applications running inside OpenShift.

(e)SCM Integration: OpenShift has built-in integration with Git. This solution is tightly coupled with an image builder.

(f)Image builders: Process that is used to transform image parameters or source code into a runnable image.

(g)CI/CD Integration: OpenShift provides very flexible integration with Jenkins for Continuous Integration and Continuous Delivery pipelines. It scales the pipeline execution through Jenkins provisioning in containers. This allows Jenkins to run as many jobs in parallel as required and scales solutions on demand out of the box.

(h)Additional Kubernetes resource extensions: There is a set of resources added to Kubernetes by OpenShift: Deployment Configurations (DC): This is a set of pods created from the same container image. Build Configurations (BC): Primarily used by S2I to build an image from source code in Git. Routes: DNS hostname service used by the OpenShift router as an ingress point for OpenShift applications.

(i)REST API: In addition to the Kubernetes API, Openshift provides its own API interface to leverage all the features of automation and seamless integration with external platforms, other automation frameworks, and DevOps solutions.