Product Architecture Architecture OpenShift Container Platform 4.13
Product Architecture Architecture OpenShift Container Platform 4.13
Product Architecture Architecture OpenShift Container Platform 4.13
1 of 9 10.10.23, 02:48 pm
Product architecture | Architecture | OpenShift Container Platform 4.13 https://docs.openshift.com/container-platform/4.13/architecture/architect...
2 of 9 10.10.23, 02:48 pm
Product architecture | Architecture | OpenShift Container Platform 4.13 https://docs.openshift.com/container-platform/4.13/architecture/architect...
About Kubernetes
Although container images and the containers that run from them are the primary
building blocks for modern application development, to run them at scale requires a
reliable and flexible distribution system. Kubernetes is the defacto standard for
orchestrating containers.
▪ Start with one or more worker nodes to run the container workloads.
▪ Manage the deployment of those workloads from one or more control plane
nodes.
▪ Wrap containers in a deployment unit called a pod. Using pods provides extra
metadata with the container and offers the ability to group several containers in a
single deployment entity.
▪ Create special kinds of assets. For example, services are represented by a set of
pods and a policy that defines how they are accessed. This policy allows
containers to connect to the services that they need even if they do not have the
specific IP addresses for the services. Replication controllers are another special
asset that indicates how many pod replicas are required to run at a time. You can
use this capability to automatically scale your application to adapt to its current
demand.
In only a few years, Kubernetes has seen massive cloud and on-premise adoption. The
open source development model allows many people to extend Kubernetes by
implementing different technologies for components such as networking, storage, and
authentication.
3 of 9 10.10.23, 02:48 pm
Product architecture | Architecture | OpenShift Container Platform 4.13 https://docs.openshift.com/container-platform/4.13/architecture/architect...
Because each container uses a dedicated operating system, you can deploy
applications that require conflicting software dependencies on the same host. Each
container carries its own dependent software and manages its own interfaces, such as
networking and file systems, so applications never need to compete for those assets.
You can also deploy and test a new version of an application alongside the existing
version. If the container passes your tests, simply deploy more new containers and
remove the old ones.
4 of 9 10.10.23, 02:48 pm
Product architecture | Architecture | OpenShift Container Platform 4.13 https://docs.openshift.com/container-platform/4.13/architecture/architect...
Since all the software dependencies for an application are resolved within the
container itself, you can use a standardized operating system on each host in your data
center. You do not need to configure a specific operating system for each application
host. When your data center needs more capacity, you can deploy another generic
host system.
5 of 9 10.10.23, 02:48 pm
Product architecture | Architecture | OpenShift Container Platform 4.13 https://docs.openshift.com/container-platform/4.13/architecture/architect...
RHCOS includes:
▪ Kubelet, the primary node agent for Kubernetes that is responsible for launching
and monitoring containers.
In OpenShift Container Platform 4.13, you must use RHCOS for all control plane
machines, but you can use Red Hat Enterprise Linux (RHEL) as the operating system
for compute machines, which are also known as worker machines. If you choose to use
RHEL workers, you must perform more system maintenance than if you use RHCOS
for all of the cluster machines.
6 of 9 10.10.23, 02:48 pm
Product architecture | Architecture | OpenShift Container Platform 4.13 https://docs.openshift.com/container-platform/4.13/architecture/architect...
For clusters that use RHCOS for all machines, updating, or upgrading, OpenShift
Container Platform is a simple, highly-automated process. Because OpenShift
Container Platform completely controls the systems and services that run on each
machine, including the operating system itself, from a central control plane, upgrades
are designed to become automatic events. If your cluster contains RHEL worker
machines, the control plane benefits from the streamlined update process, but you
must perform more tasks to upgrade the RHEL machines.
Operator Lifecycle Manager (OLM) and the OperatorHub provide facilities for storing
and distributing Operators to people developing and deploying applications.
The Red Hat Quay Container Registry is a Quay.io container registry that serves most
of the container images and Operators to OpenShift Container Platform clusters.
Quay.io is a public registry version of Red Hat Quay that stores millions of images and
tags.
7 of 9 10.10.23, 02:48 pm
Product architecture | Architecture | OpenShift Container Platform 4.13 https://docs.openshift.com/container-platform/4.13/architecture/architect...
▪ Scaling up applications
▪ Access Quay.io to obtain the packages that are required to install your cluster.
8 of 9 10.10.23, 02:48 pm
Product architecture | Architecture | OpenShift Container Platform 4.13 https://docs.openshift.com/container-platform/4.13/architecture/architect...
If your cluster cannot have direct internet access, you can perform a
restricted network installation on some types of infrastructure that you
provision. During that process, you download the required content and
use it to populate a mirror registry with the installation packages. With
some installation types, the environment that you install your cluster in
will not require internet access. Before you update the cluster, you
update the content of the mirror registry.
9 of 9 10.10.23, 02:48 pm