Red Hat OpenShift Developer II: Building and Deploying Cloud-native Applications
- Section Red Hat OpenShift Container Platform Architecture
- Quiz: Red Hat OpenShift Container Platform Architecture
- Setting up the Developer Environment
- Guided Exercise: Setting up the Developer Environment
- Red Hat OpenShift Concepts and Terminology
- Quiz: Red Hat OpenShift Concepts and Terminology
- Summary
Abstract
| Goal |
Define the Red Hat OpenShift architecture, concepts and terminology, and set up the developer environment. |
| Objectives |
|
| Sections |
|
Red Hat OpenShift is a platform that is used to build, deploy, and manage applications at scale with speed and efficiency. Built on top of Kubernetes, Red Hat OpenShift extends the capabilities of the popular container orchestration platform, unlocking a collection of valuable additional benefits. As well as container orchestration, scaling, and management, Red Hat OpenShift provides organizations with streamlined workflows that meet wide-ranging business requirements, and essential, ready-to-use services that speed up IT operations and development.
 |
As a developer, Red Hat OpenShift equips you and your team with tools to manage the complete lifecycle of container-based applications, including, but not limited to, the following possibilities:
Interact with the platform via a web console, CLIs, IDE extensions, and Developer Sandbox.
Create continuous integration/continuous delivery (CI/CD) pipelines and apply GitOps best practices.
Simplify the build process of applications by using preconfigured Red Hat Runtimes base container images.
Use well-known and preconfigured systems to monitor and troubleshoot applications, such as Kibana, Elasticsearch, Grafana, and Prometheus.
Speed up the adoption of novel technologies, including AI/ML, IoT edge computing, and event-driven architectures.
Red Hat OpenShift can run on different infrastructure platforms, from bare-metal, on-premise servers, to private, public, and hybrid clouds. Based on your infrastructure needs, you can choose from various Red Hat OpenShift editions.
Red Hat OpenShift Container Platform (RHOCP) is one of the self-managed options, which you can install and configure on your own infrastructure. You can install RHOCP on Amazon Web Services (AWS), Microsoft Azure, and bare metal, among other options.
Red Hat OpenShift is also available as a fully managed service, under editions such as Red Hat OpenShift Dedicated, Microsoft Azure Red Hat OpenShift (ARO), and Red Hat OpenShift Service on AWS (ROSA).
Note
This lecture uses RHOCP as a reference to explain the principal architectural components of Red Hat OpenShift.
Managed editions of Red Hat OpenShift use the same code base as RHOCP, so general architecture concepts also apply to these editions. Note, however, that these editions are installed and configured in an opinionated way, so they might differ from RHOCP in some aspects.
Red Hat OpenShift runs on Red Hat Enterprise Linux CoreOS (RHCOS), an immutable operating system that is optimized for running containerized applications. The entire operating system is updated as a single image, instead of on a package-by-package basis, and both user applications and system components, such as network services, run as containers. RHCOS includes two components that are key elements in Red Hat OpenShift:
- Kubelet
The agent that runs on every Kubernetes cluster machine. Kubelet ensures that the containers that run as part of Kubernetes, including internal components and user applications, are up and running.
- CRI-O
A Kubernetes-native container runtime that integrates closely with the operating system to run, stop, and restart containers. CRI-O implements the Kubernetes Container Runtime Interface (CRI) to support any container compatible with the Open Container Initiative (OCI).
Note
RHCOS does not run Kubelet and CRI-O as containers, as opposed to other workloads.
Kubelet and CRI-O are critical components to run containers, so RHCOS runs these two components as systemd services.
Kubernetes is a container orchestration platform, which operates in a distributed fashion, spanning across multiple host machines to ensure high availability, resiliency, and scalability. These hosts are called nodes, and work collaboratively to form a Kubernetes cluster, providing users with distributed compute, network, and storage resources.
The nodes of a Kubernetes cluster can play two roles: control plane and worker.
- Control plane
The control plane is a set of Kubernetes core components that act as the orchestration layer of the cluster, managing the containers, their lifecycle, and controlling the cluster. For example, the control plane decides when a container must be created, executed, or deleted. The nodes that execute the control plane components are typically called control plane nodes.
- Worker nodes
A worker node, or compute node, runs user containers. For example, if you deploy an application to Kubernetes, then the application container runs on a worker node.
Note
A single node can act as both a worker and control plane node, but typically cluster administrators separate those roles for increased stability and high availability.
The control plane communicates with the cluster nodes through Kubelet, which runs on each node. Kubelet is primarily responsible for executing, using a container runtime, the requests that the control plane sends to the worker nodes.
 |
Red Hat OpenShift extends the regular Kubernetes control plane and worker nodes, with OpenShift-specific versions of those nodes, to extend the capabilities of Kubernetes.
Red Hat OpenShift follows the Kubernetes concepts of worker and control plane nodes, but sets up these nodes on machines that use RHCOS as the operating system. Additionally, Red Hat OpenShift combines the Kubernetes components with additional OpenShift-specific services that extend the default Kubernetes functionality on these nodes.
The following diagram illustrates how the main architectural components of Red Hat OpenShift are laid out:
 |
Red Hat OpenShift runs its own control plane, which extends the Kubernetes control plane with OpenShift-specific components. Therefore, the OpenShift control plane runs a combination of Kubernetes core components and OpenShift components:
- Kubernetes services
Because Kubernetes is the foundation of Red Hat OpenShift, the OpenShift control plane includes most of the original Kubernetes control plane elements:
etcd: the distributed key-value store, which Kubernetes uses to store configuration and state information about the containers and other resources inside the cluster.
kube-apiserver: validates and configures cluster objects, and provides the access point to the shared state of the cluster.kube-controller-manager: monitors etcd for changes and uses the Kubernetes API to apply changes to the cluster.kube-scheduler: selects the nodes where a workload must run.
- Infrastructure services
Internal and support services that make containers easier to use at scale, including applications such as Networking, Logging, and Monitoring. These applications are native Kubernetes applications, so Kubernetes can orchestrate them to run as any other workload across worker nodes.
- OpenShift Services
Red Hat OpenShift adds extended functionality on top of the control plane components of Kubernetes, such as a web console, a specific API server, and an improved lifecycle management. The following elements are the principal OpenShift control plane components:
OpenShift API server: configures OpenShift-specific resources, such as projects and routes.
OpenShift controller manager: monitors etcd for changes in OpenShift objects and uses cluster APIs to apply changes.
OpenShift OAuth components: validate and configure the data to authenticate to OpenShift, and issue authentication tokens.
Note
In Red Hat OpenShift, the control plane nodes run on Red Hat Enterprise Linux CoreOS.
Worker nodes, also called compute nodes, run the containerized applications that you deploy to Red Hat OpenShift. Similarly to Kubernetes worker nodes, the OpenShift worker nodes use Kubelet to fulfill the requests of the control plane. The container engine is CRI-O, and a service proxy manages communication for workloads across worker nodes.
Additionally, these nodes run the containerized workloads that provide many of the features that OpenShift offers to extend Kubernetes. The following components are examples of these workloads.
- Router
This component maps external URLs to the running workloads. Although Kubernetes implements ingress features to route traffic into the cluster, Red Hat OpenShift provides an enhanced solution.
- Image registry
A container image registry, which the cluster uses to store images that are built with the OpenShift-specific build processes.
- Monitoring and Logging
Monitoring and logging aggregation components to help developers and administrators inspect and troubleshoot applications. Red Hat OpenShift includes a preconfigured stack, with tools such as Prometheus, Grafana, Elasticsearch, and Kibana.
Note
In Red Hat OpenShift, worker nodes can run on Red Hat Enterprise Linux CoreOS and Red Hat Enterprise Linux.
To run applications on Red Hat OpenShift or Kubernetes, you must provide the cluster with configuration values that specify the desired state of your deployed application. These values typically contain information such as the application container image, or the URL and port where the cluster must publish the application.
To define the desired state, you must use the Kubernetes and the OpenShift APIs.
The Kubernetes API exposes endpoints, called resources, which are collections of Kubernetes objects.
A Kubernetes object is an entity, stored in etcd, that represents a piece of the state of the system.
For example, a Deployment object defines how to deploy a specific application.
Most objects contain information about both the current state and the desired state.
Note
The object and resource terms are often used interchangeably in Kubernetes.
The concept of state is at the core of Kubernetes, which continuously monitors and adjusts its applications and internal components to maintain them in their specified desired state. Kubernetes uses control loops, called controllers, to continuously verify the current state of the system and perform the necessary actions to reach the desired state. To define the desired state, you must interact with the Kubernetes and OpenShift APIs.
Note
Red Hat OpenShift provides a number of tools to simplify the interaction with the cluster APIs, such as the web console, and the oc and odo CLIs.
The OpenShift API also exposes resources, which are different from the standard Kubernetes resources, and extend the Kubernetes API.
These extensions of the Kubernetes API are called custom resources.
For example, Route is a custom resource, only available in Red Hat OpenShift.
Anyone can create custom resources to expand the Kubernetes capabilities. The practice of combining custom resources with controllers that manage these resources is known as the Operator pattern. This is a powerful technique that Red Hat OpenShift uses to extend Kubernetes.
As a developer, you can use Red Hat OpenShift by interacting with the default resources provided by Kubernetes or the custom resources provided by Red Hat OpenShift.
You can create and edit resources by using manifest files, in YAML or JSON format, or with the Red Hat OpenShift management tools.
Examples of these resources are Pod, Service, and Deployment, among others, and are covered in detail later in the course.
For your convenience, the following table summarizes common Kubernetes concepts used in this course.
| Term | Definition |
|---|---|
| Node | A host machine in a Kubernetes or a Red Hat OpenShift cluster. |
| Control plane node | A node that runs the control plane components. The control plane provides core cluster services such as APIs or controllers. |
| Worker node | A node that runs user workloads and OpenShift services. |
| Object | A Kubernetes entity, stored in etcd, that represents a piece of the state of the system. |
| Resource | An endpoint exposed in the Kubernetes API. Resources are collections of Kubernetes objects. By using resources, you can query, create, edit, and delete objects. |
| Custom resource | An extension of the Kubernetes API. Red Hat OpenShift extends Kubernetes by using custom resources. |
| Controller | A Kubernetes component that watches objects in etcd, and makes the required changes to transition from the current state to the desired state. |
| Operator | A Kubernetes plug-in component that can react to cluster events and control the state of custom resource resources. Red Hat OpenShift implements many custom controllers as Operators. |
| Console | A web UI, which Red Hat OpenShift provides, that allows developers and administrators to manage cluster resources. |
References
Understanding Kubernetes objects
For more information about the architecture of RHOCP, refer to the Architecture overview chapter in the Red Hat OpenShift Container Platform 4.12 Architecture documentation at https://access.redhat.com/documentation/en-us/openshift_container_platform/4.12/html-single/architecture/index#architecture-overview
For more information about the control plane, refer to the Control plane architecture chapter in the Red Hat OpenShift Container Platform 4.12 Architecture documentation at https://access.redhat.com/documentation/en-us/openshift_container_platform/4.12/html-single/architecture/index#control-plane
