mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
169 lines
7.3 KiB
Plaintext
169 lines
7.3 KiB
Plaintext
|
|
// Module included in the following assemblies:
|
|
//
|
|
// * rosa_architecture/rosa_policy_service_definition/rosa-service-definition.adoc
|
|
// * rosa_architecture/rosa_policy_service_definition/rosa-hcp-service-definition.adoc
|
|
|
|
:_mod-docs-content-type: CONCEPT
|
|
[id="rosa-sdpolicy-platform_{context}"]
|
|
= Platform
|
|
:productwinc: Red{nbsp}Hat OpenShift support for Windows Containers
|
|
|
|
This section provides information about the service definition for the
|
|
ifdef::openshift-rosa-hcp[]
|
|
{hcp-title-first} platform.
|
|
endif::openshift-rosa-hcp[]
|
|
ifndef::openshift-rosa-hcp[]
|
|
{product-title} (ROSA) platform.
|
|
endif::openshift-rosa-hcp[]
|
|
|
|
[id="rosa-sdpolicy-autoscaling_{context}"]
|
|
== Autoscaling
|
|
Node autoscaling is available on
|
|
ifdef::openshift-rosa-hcp[]
|
|
{hcp-title}.
|
|
endif::openshift-rosa-hcp[]
|
|
ifndef::openshift-rosa-hcp[]
|
|
{product-title}.
|
|
endif::openshift-rosa-hcp[]
|
|
You can configure the autoscaler option to automatically scale the number of machines in a cluster.
|
|
|
|
ifdef::openshift-rosa[]
|
|
[id="rosa-sdpolicy-daemonsets_{context}"]
|
|
== Daemonsets
|
|
|
|
Customers can create and run daemonsets on{product-title}.
|
|
To restrict daemonsets to only running on worker nodes, use the following `nodeSelector`:
|
|
|
|
[source,yaml]
|
|
----
|
|
spec:
|
|
nodeSelector:
|
|
role: worker
|
|
----
|
|
endif::openshift-rosa[]
|
|
[id="rosa-sdpolicy-multiple-availability-zone_{context}"]
|
|
== Multiple availability zone
|
|
|
|
ifdef::openshift-rosa-hcp[]
|
|
Control plane components are always deployed across multiple availability zones, regardless of a customer's worker node configuration.
|
|
endif::openshift-rosa-hcp[]
|
|
ifndef::openshift-rosa-hcp[]
|
|
In a multiple availability zone cluster, control plane nodes are distributed across availability zones and at least one worker node is required in each availability zone.
|
|
endif::openshift-rosa-hcp[]
|
|
|
|
[id="rosa-sdpolicy-node-labels_{context}"]
|
|
== Node labels
|
|
Custom node labels are created by Red{nbsp}Hat during node creation and cannot be changed on
|
|
ifdef::openshift-rosa-hcp[]
|
|
{hcp-title}
|
|
endif::openshift-rosa-hcp[]
|
|
ifndef::openshift-rosa-hcp[]
|
|
{product-title}
|
|
endif::openshift-rosa-hcp[]
|
|
clusters at this time. However, custom labels are supported when creating new machine pools.
|
|
|
|
[id="rosa-sdpolicy-node-lifecycle_{context}"]
|
|
== Node lifecycle
|
|
|
|
Worker nodes are not guaranteed longevity, and may be replaced at any time as part of the normal operation and management of OpenShift.
|
|
|
|
A worker node might be replaced in the following circumstances:
|
|
|
|
* Machine health checks are deployed and configured to ensure that a worker node with a `NotReady` status is replaced to ensure smooth operation of the cluster.
|
|
* AWS EC2 instances may be terminated when AWS detects irreparable failure of the underlying hardware that hosts the instance.
|
|
ifdef::openshift-rosa[]
|
|
* During upgrades, a new node is first provisioned to account for any loss of cluster resources during the upgrade process. Once this new node has been successfully integrated into the cluster via the previously described automated health checks, an older node is then removed from the cluster.
|
|
endif::openshift-rosa[]
|
|
ifdef::openshift-rosa-hcp[]
|
|
* During upgrades, a new, upgraded node is first created and joined to the cluster. Once this new node has been successfully integrated into the cluster via the previously described automated health checks, an older node is then removed from the cluster.
|
|
endif::openshift-rosa-hcp[]
|
|
|
|
For all containerized workloads running on a Kubernetes based system, it is best practice to configure applications to be resilient of node replacements.
|
|
|
|
[id="rosa-sdpolicy-backup-policy_{context}"]
|
|
== Cluster backup policy
|
|
|
|
Red Hat recommends object-level backup solutions for ROSA clusters. OpenShift API for Data Protection (OADP) is included in OpenShift but not enabled by default. Customers can configure OADP on their clusters to achieve object-level backup and restore capabilities.
|
|
|
|
//Omitted until XCMSTRAT-480 is complete
|
|
//While Red Hat takes frequent backups of etcd, this is for use by Red Hat for maintenance and service restoration purposes, and is never provided to customers for any reason.
|
|
|
|
Red Hat does not back up customer applications or application data. Customers are solely responsible for applications and their data, and must put their own backup and restore capabilities in place.
|
|
|
|
[WARNING]
|
|
====
|
|
Customers are solely responsible for backing up and restoring their applications and application data. For more information about customer responsibilities, see "Shared responsibility matrix".
|
|
====
|
|
|
|
[id="rosa-sdpolicy-openshift-version_{context}"]
|
|
== OpenShift version
|
|
ifdef::openshift-rosa-hcp[]
|
|
{hcp-title}
|
|
endif::openshift-rosa-hcp[]
|
|
ifndef::openshift-rosa-hcp[]
|
|
{product-title}
|
|
endif::openshift-rosa-hcp[]
|
|
ifdef::openshift-rosa-hcp[]
|
|
is run as a service. Red{nbsp}Hat SRE team will force upgrade when end of life (EOL) is reached.
|
|
endif::openshift-rosa-hcp[]
|
|
ifdef::openshift-rosa[]
|
|
is run as a service and is kept up to date with
|
|
the latest OpenShift Container Platform version.
|
|
endif::openshift-rosa[]
|
|
Upgrade scheduling to the latest version is available.
|
|
|
|
[id="rosa-sdpolicy-upgrades_{context}"]
|
|
== Upgrades
|
|
Upgrades can be scheduled using the ROSA CLI, `rosa`, or through {cluster-manager}.
|
|
|
|
See the link:https://docs.openshift.com/rosa/rosa_policy/rosa-life-cycle.html[{product-title} Life Cycle] for more information on the upgrade policy and procedures.
|
|
|
|
[id="rosa-sdpolicy-window-containers_{context}"]
|
|
== Windows Containers
|
|
{productwinc} is not available on {product-title} at this time.
|
|
ifdef::openshift-rosa-hcp[]
|
|
Alternatively, it is supported to run Windows based virtual machines on OpenShift Virtualization running on a ROSA cluster.
|
|
endif::openshift-rosa-hcp[]
|
|
|
|
[id="rosa-sdpolicy-container-engine_{context}"]
|
|
== Container engine
|
|
ifdef::openshift-rosa-hcp[]
|
|
{hcp-title}
|
|
endif::openshift-rosa-hcp[]
|
|
ifndef::openshift-rosa-hcp[]
|
|
{product-title}
|
|
endif::openshift-rosa-hcp[]
|
|
runs on OpenShift 4 and uses link:https://www.redhat.com/en/blog/red-hat-openshift-container-platform-4-now-defaults-cri-o-underlying-container-engine[CRI-O] as the only available container engine
|
|
ifdef::openshift-rosa-hcp[]
|
|
(container runtime interface).
|
|
endif::openshift-rosa-hcp[]
|
|
[id="rosa-sdpolicy-operating-system_{context}"]
|
|
== Operating system
|
|
ifdef::openshift-rosa-hcp[]
|
|
{hcp-title}
|
|
endif::openshift-rosa-hcp[]
|
|
ifndef::openshift-rosa-hcp[]
|
|
{product-title}
|
|
endif::openshift-rosa-hcp[]
|
|
runs on OpenShift 4 and uses Red{nbsp}Hat CoreOS (RHCOS) as the operating system for all cluster nodes.
|
|
|
|
[id="rosa-sdpolicy-red-hat-operator_{context}"]
|
|
== Red{nbsp}Hat Operator support
|
|
Red{nbsp}Hat workloads typically refer to Red{nbsp}Hat-provided Operators made available through Operator Hub. Red{nbsp}Hat workloads are not managed by the Red{nbsp}Hat SRE team, and must be deployed on worker nodes. These Operators may require additional Red{nbsp}Hat subscriptions, and may incur additional cloud infrastructure costs. Examples of these Red{nbsp}Hat-provided Operators are:
|
|
|
|
* {rhq-short}
|
|
* Red{nbsp}Hat Advanced Cluster Management
|
|
* Red{nbsp}Hat Advanced Cluster Security
|
|
* {SMProductName}
|
|
* {ServerlessProductName}
|
|
* {logging-sd}
|
|
* {pipelines-title}
|
|
* {VirtProductName}
|
|
|
|
[id="rosa-sdpolicy-kubernetes-operator_{context}"]
|
|
== Kubernetes Operator support
|
|
|
|
All Operators listed in the software catalog marketplace should be available for installation. These Operators are considered customer workloads, and are not monitored nor managed by Red{nbsp}Hat SRE. Operators authored by Red{nbsp}Hat are supported by Red{nbsp}Hat.
|
|
|