:_mod-docs-content-type: ASSEMBLY
[id="architecture-overview"]
= Architecture overview
include::_attributes/common-attributes.adoc[]
ifdef::openshift-dedicated,openshift-rosa[]
include::_attributes/attributes-openshift-dedicated.adoc[]
endif::openshift-dedicated,openshift-rosa[]
:context: architecture-overview

toc::[]

{product-title} is a cloud-based Kubernetes container platform.
The foundation of {product-title} is based on Kubernetes and therefore shares the same technology.
To learn more about {product-title} and Kubernetes, see xref:../architecture/architecture.adoc#architecture[product architecture].

include::modules/openshift-architecture-common-terms.adoc[leveloffset=+1]

[role="_additional-resources"]
.Additional resources

// Topic not included in the OSD/ROSA docs
ifndef::openshift-dedicated,openshift-rosa[]
* For more information on networking, see xref:../networking/understanding-networking.adoc#understanding-networking[{product-title} networking].
endif::openshift-dedicated,openshift-rosa[]
* For more information on storage, see xref:../storage/index.adoc#index[{product-title} storage].
* For more information on authentication, see xref:../authentication/index.adoc#index[{product-title} authentication].
* For more information on Operator Lifecycle Manager (OLM), see xref:../operators/understanding/olm/olm-understanding-olm.adoc#olm-understanding-olm[OLM].
* For more information on logging, see xref:../observability/logging/cluster-logging.adoc#cluster-logging[About Logging].
// Topic not included in the OSD/ROSA docs
ifndef::openshift-dedicated,openshift-rosa[]
* For more information on over-the-air (OTA) updates, see xref:../updating/understanding_updates/intro-to-updates.adoc#understanding-openshift-updates[Introduction to OpenShift updates].
endif::openshift-dedicated,openshift-rosa[]

ifdef::openshift-dedicated,openshift-rosa[]
include::modules/sd-vs-ocp.adoc[leveloffset=+1]
endif::openshift-dedicated,openshift-rosa[]

ifndef::openshift-dedicated,openshift-rosa[]
[id="about-installation-and-updates"]
== About installation and updates

As a cluster administrator, you can use the {product-title} xref:../architecture/architecture-installation.adoc#architecture-installation[installation program] to install and deploy a cluster by using one of the following methods:

* Installer-provisioned infrastructure
* User-provisioned infrastructure
endif::openshift-dedicated,openshift-rosa[]

[id="about-control-planes"]
== About the control plane

The xref:../architecture/control-plane.adoc#control-plane[control plane] manages the worker nodes and the pods in your cluster. You can configure nodes with the use of machine config pools (MCPs).
MCPs are groups of machines, such as control plane components or user workloads, that are based on the resources that they handle.
{product-title} assigns different roles to hosts. These roles define the function of a machine in a cluster.
The cluster contains definitions for the standard control plane and worker role types.

You can use Operators to package, deploy, and manage services on the control plane.
Operators are important components in {product-title} because they provide the following services:

* Perform health checks
* Provide ways to watch applications
* Manage over-the-air updates
* Ensure applications stay in the specified state

ifndef::openshift-dedicated,openshift-rosa[]
[role="_additional-resources"]
.Additional resources

* xref:../hosted_control_planes/index.adoc#hcp-overview[{hcp-capital} overview]
endif::openshift-dedicated,openshift-rosa[]

[id="about-containerized-applications-for-developers"]
== About containerized applications for developers

As a developer, you can use different tools, methods, and formats to xref:../architecture/understanding-development.adoc#understanding-development[develop your containerized application] based on your unique requirements, for example:

* Use various build-tool, base-image, and registry options to build a simple container application.
* Use supporting components such as OperatorHub and templates to develop your application.
* Package and deploy your application as an Operator.

You can also create a Kubernetes manifest and store it in a Git repository.
Kubernetes works on basic units called pods. A pod is a single instance of a running process in your cluster. Pods can contain one or more containers.
You can create a service by grouping a set of pods and their access policies.
Services provide permanent internal IP addresses and host names for other applications to use as pods are created and destroyed. Kubernetes defines workloads based on the type of your application.

ifndef::openshift-dedicated,openshift-rosa[]
[id="coreos-and-ignition"]
== About {op-system-first} and Ignition

As a cluster administrator, you can perform the following {op-system-first} tasks:

** Learn about the next generation of xref:../architecture/architecture-rhcos.adoc#architecture-rhcos[single-purpose container operating system technology].
** Choose how to configure {op-system-first}
** Choose how to deploy {op-system-first}:
*** Installer-provisioned deployment
*** User-provisioned deployment

The {product-title} installation program creates the Ignition configuration files that you need to deploy your cluster.
{op-system-first} uses Ignition during the initial configuration to perform common disk tasks, such as partitioning, formatting, writing files, and configuring users.
During the first boot, Ignition reads its configuration from the installation media or the location that you specify and applies the configuration to the machines.

You can learn how xref:../architecture/architecture-rhcos.adoc#architecture-rhcos[Ignition works], the process for a {op-system-first} machine in an {product-title} cluster, view Ignition configuration files, and change Ignition configuration after an installation.
endif::openshift-dedicated,openshift-rosa[]

[id="about-admission-plug-ins"]
== About admission plugins
You can use xref:../architecture/admission-plug-ins.adoc#admission-plug-ins[admission plugins] to regulate how {product-title} functions. After a resource request is authenticated and authorized, admission plugins intercept the resource request to the master API to validate resource requests and to ensure that scaling policies are adhered to. Admission plugins are used to enforce security policies, resource limitations, configuration requirements, and other settings.
