capabilities:
baselineCapabilitySet: v4.11 (1)
additionalEnabledCapabilities: (2)
- CSISnapshot
- Console
- Storage
Cluster administrators can use cluster capabilities to enable or disable optional components prior to installation. Cluster administrators can enable cluster capabilities at anytime after installation.
Cluster administrators cannot disable a cluster capability after it is enabled. |
If you are using an installation method that includes customizing your cluster by creating an install-config.yaml
file, you can select which cluster capabilities you want to make available on the cluster.
If you customize your cluster by enabling or disabling specific cluster capabilities, you must manually maintain your |
You can use the following configuration parameters to select cluster capabilities:
capabilities:
baselineCapabilitySet: v4.11 (1)
additionalEnabledCapabilities: (2)
- CSISnapshot
- Console
- Storage
1 | Defines a baseline set of capabilities to install. Valid values are None , vCurrent and v4.x . If you select None , all optional capabilities are disabled. The default value is vCurrent , which enables all optional capabilities.
|
||
2 | Defines a list of capabilities to explicitly enable. These capabilities are enabled in addition to the capabilities specified in baselineCapabilitySet .
|
The following table describes the baselineCapabilitySet
values.
Value | Description |
---|---|
|
Specify this option when you want to automatically add new, default capabilities that are introduced in new releases. |
|
Specify this option when you want to enable the default capabilities for OKD 4.11. By specifying |
|
Specify this option when you want to enable the default capabilities for OKD 4.12. By specifying |
|
Specify this option when you want to enable the default capabilities for OKD 4.13. By specifying |
|
Specify this option when you want to enable the default capabilities for OKD 4.14. By specifying |
|
Specify this option when you want to enable the default capabilities for OKD 4.15. By specifying |
|
Specify this option when you want to enable the default capabilities for OKD 4.16. By specifying |
|
Specify when the other sets are too large, and you do not need any capabilities or want to fine-tune via |
Currently, cluster Operators provide the features for these optional capabilities. The following summarizes the features provided by each capability and what functionality you lose if it is disabled.
The Cluster Baremetal Operator provides the features for the baremetal
capability.
The Cluster Baremetal Operator (CBO) deploys all the components necessary to take a bare-metal server to a fully functioning worker node ready to run OKD compute nodes. The CBO ensures that the metal3 deployment, which consists of the Bare Metal Operator (BMO) and Ironic containers, runs on one of the control plane nodes within the OKD cluster. The CBO also listens for OKD updates to resources that it watches and takes appropriate action.
The bare-metal capability is required for deployments using installer-provisioned infrastructure. Disabling the bare-metal capability can result in unexpected problems with these deployments.
It is recommended that cluster administrators only disable the bare-metal capability during installations with user-provisioned infrastructure that do not have any BareMetalHost
resources in the cluster.
If the bare-metal capability is disabled, the cluster cannot provision or manage bare-metal nodes. Only disable the capability if there are no |
The Build
capability enables the Build
API. The Build
API manages the lifecycle of Build
and BuildConfig
objects.
If you disable the
Disable the |
The Cloud Controller Manager Operator provides features for the CloudControllerManager
capability.
Currently, disabling the |
You can determine if your cluster supports disabling the CloudControllerManager
capability by checking values in the installation configuration (install-config.yaml
) file for your cluster.
In the install-config.yaml
file, locate the platform
parameter.
If the value of the platform
parameter is Baremetal
or None
, you can disable the CloudControllerManager
capability on your cluster.
If the value of the platform
parameter is External
, locate the platform.external.cloudControllerManager
parameter.
If the value of the platform.external.cloudControllerManager
parameter is None
, you can disable the CloudControllerManager
capability on your cluster.
If these parameters contain any other values than those listed, you cannot disable the |
The status of this Operator is General Availability for Amazon Web Services (AWS), Google Cloud Platform (GCP), IBM Cloud®, global Microsoft Azure, Microsoft Azure Stack Hub, Nutanix, OpenStack, and VMware vSphere. The Operator is available as a Technology Preview for IBM Power® Virtual Server. |
The Cloud Controller Manager Operator manages and updates the cloud controller managers deployed on top of OKD. The Operator is based on the Kubebuilder framework and controller-runtime
libraries. It is installed via the Cluster Version Operator (CVO).
It contains the following components:
Operator
Cloud configuration observer
By default, the Operator exposes Prometheus metrics through the metrics
service.
The Cloud Credential Operator provides features for the CloudCredential
capability.
Currently, disabling the |
The Cloud Credential Operator (CCO) manages cloud provider credentials as Kubernetes custom resource definitions (CRDs). The CCO syncs on CredentialsRequest
custom resources (CRs) to allow OKD components to request cloud provider credentials with the specific permissions that are required for the cluster to run.
By setting different values for the credentialsMode
parameter in the install-config.yaml
file, the CCO can be configured to operate in several different modes. If no mode is specified, or the credentialsMode
parameter is set to an empty string (""
), the CCO operates in its default mode.
The Cluster Image Registry Operator provides features for the ImageRegistry
capability.
The Cluster Image Registry Operator manages a singleton instance of the OpenShift image registry. It manages all configuration of the registry, including creating storage.
On initial start up, the Operator creates a default image-registry
resource instance based on the configuration detected in the cluster. This indicates what cloud storage type to use based on the cloud provider.
If insufficient information is available to define a complete image-registry
resource, then an incomplete resource is defined and the Operator updates the resource status with information about what is missing.
The Cluster Image Registry Operator runs in the openshift-image-registry
namespace and it also manages the registry instance in that location. All configuration and workload resources for the registry reside in that namespace.
In order to integrate the image registry into the cluster’s user authentication and authorization system, an image pull secret is generated for each service account in the cluster.
If you disable the |
If you disable the ImageRegistry
capability, you can reduce the overall resource footprint of OKD in resource-constrained environments. Depending on your deployment, you can disable this component if you do not need it.
The Cluster Storage Operator provides the features for the Storage
capability.
The Cluster Storage Operator sets OKD cluster-wide storage defaults. It ensures a default storageclass
exists for OKD clusters. It also installs Container Storage Interface (CSI) drivers which enable your cluster to use various storage backends.
If the cluster storage capability is disabled, the cluster will not have a default |
The storage class that the Operator creates can be made non-default by editing its annotation, but this storage class cannot be deleted as long as the Operator runs.
The Console Operator provides the features for the Console
capability.
The Console Operator installs and maintains the OKD web console on a cluster. The Console Operator is installed by default and automatically maintains a console.
The Cluster CSI Snapshot Controller Operator provides the features for the CSISnapshot
capability.
The Cluster CSI Snapshot Controller Operator installs and maintains the CSI Snapshot Controller. The CSI Snapshot Controller is responsible for watching the VolumeSnapshot
CRD objects and manages the creation and deletion lifecycle of volume snapshots.
The DeploymentConfig
capability enables and manages the DeploymentConfig
API.
If you disable the
Disable the |
The Ingress Operator provides the features for the Ingress
capability.
The Ingress Operator configures and manages the OKD router.
clusteringresses.ingress.openshift.io
Scope: Namespaced
CR: clusteringresses
Validation: No
Cluster config
Type Name: clusteringresses.ingress.openshift.io
Instance Name: default
View Command:
$ oc get clusteringresses.ingress.openshift.io -n openshift-ingress-operator default -o yaml
The Ingress Operator sets up the router in the openshift-ingress
project and creates the deployment for the router:
$ oc get deployment -n openshift-ingress
The Ingress Operator uses the clusterNetwork[].cidr
from the network/cluster
status to determine what mode (IPv4, IPv6, or dual stack) the managed Ingress Controller (router) should operate in. For example, if clusterNetwork
contains only a v6 cidr
, then the Ingress Controller operates in IPv6-only mode.
In the following example, Ingress Controllers managed by the Ingress Operator will run in IPv4-only mode because only one cluster network exists and the network is an IPv4 cidr
:
$ oc get network/cluster -o jsonpath='{.status.clusterNetwork[*]}'
map[cidr:10.128.0.0/14 hostPrefix:23]
The Insights Operator provides the features for the Insights
capability.
The Insights Operator gathers OKD configuration data and sends it to Red Hat. The data is used to produce proactive insights recommendations about potential issues that a cluster might be exposed to. These insights are communicated to cluster administrators through Insights Advisor on console.redhat.com.
Insights Operator complements OKD Telemetry.
The machine-api-operator
, cluster-autoscaler-operator
, and cluster-control-plane-machine-set-operator
Operators provide the features for the MachineAPI
capability. You can disable this capability only if you install a cluster with user-provisioned infrastructure.
The Machine API capability is responsible for all machine configuration and management in the cluster. If you disable the Machine API capability during installation, you need to manage all machine-related tasks manually.
The Marketplace Operator provides the features for the marketplace
capability.
The Marketplace Operator simplifies the process for bringing off-cluster Operators to your cluster by using a set of default Operator Lifecycle Manager (OLM) catalogs on the cluster. When the Marketplace Operator is installed, it creates the openshift-marketplace
namespace. OLM ensures catalog sources installed in the openshift-marketplace
namespace are available for all namespaces on the cluster.
If you disable the marketplace
capability, the Marketplace Operator does not create the openshift-marketplace
namespace. Catalog sources can still be configured and managed on the cluster manually, but OLM depends on the openshift-marketplace
namespace in order to make catalogs available to all namespaces on the cluster. Users with elevated permissions to create namespaces prefixed with openshift-
, such as system or cluster administrators, can manually create the openshift-marketplace
namespace.
If you enable the marketplace
capability, you can enable and disable individual catalogs by configuring the Marketplace Operator.
The Node Tuning Operator provides features for the NodeTuning
capability.
The Node Tuning Operator helps you manage node-level tuning by orchestrating the TuneD daemon and achieves low latency performance by using the Performance Profile controller. The majority of high-performance applications require some level of kernel tuning. The Node Tuning Operator provides a unified management interface to users of node-level sysctls and more flexibility to add custom tuning specified by user needs.
If you disable the NodeTuning capability, some default tuning settings will not be applied to the control-plane nodes. This might limit the scalability and performance of large clusters with over 900 nodes or 900 routes.
The Cluster Samples Operator provides the features for the openshift-samples
capability.
The Cluster Samples Operator manages the sample image streams and templates stored in the openshift
namespace.
On initial start up, the Operator creates the default samples configuration resource to initiate the creation of the image streams and templates. The configuration object is a cluster scoped object with the key cluster
and type configs.samples
.
The image streams are the Fedora CoreOS (FCOS)-based OKD image streams pointing to images on registry.redhat.io
. Similarly, the templates are those categorized as OKD templates.
If you disable the samples capability, users cannot access the image streams, samples, and templates it provides. Depending on your deployment, you might want to disable this component if you do not need it.
Operator Lifecycle Manager (OLM) helps users install, update, and manage the lifecycle of Kubernetes native applications (Operators) and their associated services running across their OKD clusters. It is part of the Operator Framework, an open source toolkit designed to manage Operators in an effective, automated, and scalable way.
If an Operator requires any of the following APIs, then you must enable the OperatorLifecycleManager
capability:
ClusterServiceVersion
CatalogSource
Subscription
InstallPlan
OperatorGroup
The |
As a cluster administrator, you can view the capabilities by using the clusterversion
resource status.
You have installed the OpenShift CLI (oc
).
To view the status of the cluster capabilities, run the following command:
$ oc get clusterversion version -o jsonpath='{.spec.capabilities}{"\n"}{.status.capabilities}{"\n"}'
{"additionalEnabledCapabilities":["openshift-samples"],"baselineCapabilitySet":"None"}
{"enabledCapabilities":["openshift-samples"],"knownCapabilities":["CSISnapshot","Console","Insights","Storage","baremetal","marketplace","openshift-samples"]}
As a cluster administrator, you can enable cluster capabilities any time after a OKD installation by setting the baselineCapabilitySet
configuration parameter.
You have installed the OpenShift CLI (oc
).
To set the baselineCapabilitySet
configuration parameter, run the following command:
$ oc patch clusterversion version --type merge -p '{"spec":{"capabilities":{"baselineCapabilitySet":"vCurrent"}}}' (1)
1 | For baselineCapabilitySet you can specify vCurrent , v4 , or None . |
As a cluster administrator, you can enable cluster capabilities any time after a OKD installation by setting the additionalEnabledCapabilities
configuration parameter.
You have installed the OpenShift CLI (oc
).
View the additional enabled capabilities by running the following command:
$ oc get clusterversion version -o jsonpath='{.spec.capabilities.additionalEnabledCapabilities}{"\n"}'
["openshift-samples"]
To set the additionalEnabledCapabilities
configuration parameter, run the following command:
$ oc patch clusterversion/version --type merge -p '{"spec":{"capabilities":{"additionalEnabledCapabilities":["openshift-samples", "marketplace"]}}}'
It is not possible to disable a capability which is already enabled in a cluster. The cluster version Operator (CVO) continues to reconcile the capability which is already enabled in the cluster. |
If you try to disable a capability, then CVO shows the divergent spec:
$ oc get clusterversion version -o jsonpath='{.status.conditions[?(@.type=="ImplicitlyEnabledCapabilities")]}{"\n"}'
{"lastTransitionTime":"2022-07-22T03:14:35Z","message":"The following capabilities could not be disabled: openshift-samples","reason":"CapabilitiesImplicitlyEnabled","status":"True","type":"ImplicitlyEnabledCapabilities"}
During the cluster upgrades, it is possible that a given capability could be implicitly enabled. If a resource was already running on the cluster before the upgrade, then any capabilities that is part of the resource will be enabled. For example, during a cluster upgrade, a resource that is already running on the cluster has been changed to be part of the |