OpenShift Container Platform 4 Architecture
Red Hat OpenShift Container Platform 4 (RHOCP 4) is a set of modular components and services built on top of Red Hat CoreOS and Kubernetes.
One of the main advantages of using OpenShift is that it uses several nodes to ensure the resiliency and scalability of its managed applications. OpenShift forms a cluster of node servers that run containers and are centrally managed by a set of master servers.
The following diagram illustrates the high-level logical overview of the OpenShift Container Platform 4 architecture.
The following diagram illustrates the OpenShift Container Platform stack.
From bottom to top, and from left to right, this shows the basic container infrastructure, integrated and enhanced by Red Hat:
- Red Hat CoreOS is the base OS on top which OpenShift runs. Red Hat CoreOS is a Linux distribution focused on providing an immutable operating system for container execution.
- CRI-O is an implementation of the Kubernetes Container Runtime Interface (CRI) to enable using Open Container Initiative (OCI) compatible runtimes
- Kubernetes manages a cluster of hosts, physical or virtual, running containers. It uses resources that describe multicontainer applications composed of multiple resources, and how they interconnect
- etcd is a distributed key-value store, used by Kubernetes to store configuration and state information about the containers and other resources inside the Kubernetes cluster
- Custom Resource Definitions (CRDs) are resource types stored in etcd and managed by Kubernetes. These resource types form the state and configuration of all resources managed by OpenShift.
- Containerized services fulfill many PaaS infrastructure functions, such as networking and authorization. RHOCP uses the basic container infrastructure from Kubernetes and the underlying container runtime for most internal functions.
- Runtimes and xPaaS are base container images ready for use by developers, each preconfigured with a particular runtime language or database.
- DevOps Tools and User Experience: RHOCP provides web UI and CLI management tools for managing user applications and RHOCP services.
The following table lists some of the most commonly used terminology when you work with OpenShift.
| Term | Definition |
|---|---|
| Node | A server that hosts applications in an OpenShift cluster |
| Master Node | A node server that manages the control plane in an OpenShift cluster. Master nodes provide basic cluster services such as APIs or controllers. |
| Worker Node | Worker nodes execute workloads for the cluster. Application pods are scheduled onto worker nodes. |
| Resource | Resources are any kind of component definition managed by OpenShift. |
| Controller | A controller is an OpenShift component that watches resources and makes changes attempting to move the current state towards the desired state. |
| Label | A key-value pair that can be assigned to any OpenShift resource. |
| Namespace or Project | A scope for OpenShift resources and processes, so that resources with the same name can be used in different contexts. |
| Console | A web UI provided by OpenShift that allows developers and administrators to manage cluster resources. |
New Features in RHOCP 4
RHOCP 4 includes new features, such as:
- CoreOS as the default operating system for all nodes, offering an immutable infrastructure optimized for containers
- A new cluster installer, which simplifies the process of installing and updating the masters and worker nodes in the cluster
- A self-managing platform, able to automatically apply cluster updates and recoveries without disruption.
- A redesigned web console based on the concept of "personas", targeting both platform administrators and developers
- An Operator SDK to build, test, and package Operators.
Describing OpenShift Resource Types
- Pods (pod) are the basic unit of work for OpenShift.
- Services (svc) Specific IP/port combinations that provides access to a pool of pods. By default, services connect clients to pods in a round-robin fashion.
- Replication Controllers (rc) OpenShift resources that define how pods are replicated (horizontally scaled) to different nodes.
- Persistent Volumes (pv) Storage areas to be used by pods.
- Persistent Volume Claims (pvc) Requests for storage by a pod. A pvc links a pv to a pod so its containers can make use of it, usually by mounting the storage into the container's file system.
- Config Maps (cm) A set of keys and values that can be used by other resources. ConfigMaps and Secrets are usually used to centralize configuration values used by several resources. Secrets differ from ConfigMaps maps in that Secrets are used to store sensitive data (usually encrypted), and their access is restricted to fewer authorized users.
- Deployment Configs (dc) A set of containers included in a pod, and the deployment strategies to be used. A dc also provides a basic but extensible continuous delivery workflow.
- Build Configs (bc) A process to be executed in the OpenShift project. The OpenShift Source-to-Image (S2I) feature uses BuildConfigs to build a container image from application source code stored in a Git repository. A bc works together with a dc to provide a basic but extensible continuous integration and continuous delivery workflows.
- Routes DNS host names recognized by the OpenShift router as an ingress point for various applications and microservices deployed on the cluster.
- Image Streams (is) An image stream and its tags provide an abstraction for referencing container images from within OpenShift Container Platform. The image stream and its tags allow you to track what images are available and ensure that you are using the specific image you need even if the image in the repository changes. Image streams do not contain actual image data, but present a virtual view of related images, similar to an image repository.
Latest comments (0)