openshift/openshift-docs
1
0
Fork 0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 21:46:22 +01:00
Code Issues Releases Activity

Enhance the content

Browse Source
This commit is contained in:
Servesha Dudhgaonkar
2022-11-24 15:49:37 +05:30
committed by openshift-cherrypick-robot
parent 3cf103f427
commit 267361cbfc
1 changed files with 12 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
post_installation_configuration/index.adoc
View File

@@ -18,12 +18,12 @@ After installing {product-title}, a cluster administrator can configure and cust
* Alerts and notifications
[id="post-install-tasks"]
== Performing post-installation configuration tasks
== Configuration tasks to perform after installation
Cluster administrators can perform the following post-installation configuration tasks:
* xref:../post_installation_configuration/machine-configuration-tasks.adoc#post-install-machine-configuration-tasks[Configure operating system features]:
Machine Config Operator (MCO) manages `MachineConfig` objects. By using MCO, you can perform the following on an {product-title} cluster:
Machine Config Operator (MCO) manages `MachineConfig` objects. By using MCO, you can perform the following tasks on an {product-title} cluster:
** Configure nodes by using `MachineConfig` objects
** Configure MCO-related custom resources
@@ -47,7 +47,7 @@ As a cluster administrator, you can modify the configuration resources of the ma
** Cloud provider credential management
* xref:../post_installation_configuration/configuring-private-cluster.adoc#configuring-private-cluster[Configure cluster components to be private]:
By default, the installation program provisions {product-title} by using a publicly accessible DNS and endpoints. If you want your cluster to be accessible from within an internal network only, configure the following components to be private:
By default, the installation program provisions {product-title} by using a publicly accessible DNS and endpoints. If you want your cluster to be accessible only from within an internal network, configure the following components to be private:
** DNS
** Ingress Controller
@@ -63,7 +63,7 @@ As a cluster administrator, you can perform the following operations with the ma
** Enable Device Manager
* xref:../post_installation_configuration/network-configuration.adoc#post-install-network-configuration[Configure network]:
After installing {product-title}, as a cluster administrator, you can configure the following:
After installing {product-title}, you can configure the following:
** Ingress cluster traffic
** Node port service range
@@ -71,15 +71,19 @@ After installing {product-title}, as a cluster administrator, you can configure
** Enabling the cluster-wide proxy
* xref:../post_installation_configuration/storage-configuration.adoc#post-install-storage-configuration[Configure storage]:
By default, containers operate using ephemeral storage or transient local storage. The ephemeral storage has a lifetime limitation, so you must configure persistent storage to store the data for a long time.
By default, containers operate using ephemeral storage or transient local storage. The ephemeral storage has a lifetime limitation. TO store the data for a long time, you must configure persistent storage.
You can configure storage by using one of the following methods:
** *Dynamic provisioning*: You can dynamically provision storage on demand by defining and creating storage classes that control different levels of storage, including storage access.
** *Static provisioning*: Cluster administrators can use Kubernetes persistent volumes to make existing storage available to a cluster by supporting various device configurations and mount options.
** *Static provisioning*: You can use Kubernetes persistent volumes to make existing storage available to a cluster. Static provisioning can support various device configurations and mount options.
* xref:../post_installation_configuration/preparing-for-users.adoc#post-install-preparing-for-users[Configure users]:
OAuth access tokens allow users to authenticate themselves to the API. As a cluster administrator, you can configure OAuth to specify an identity provider, use role-based access control to define and apply permissions to users, and install an Operator from OperatorHub.
OAuth access tokens allow users to authenticate themselves to the API. As a cluster administrator, you can configure OAuth to perform the following tasks:
+
* Specify an identity provider
* Use role-based access control to define and supply permissions to users
* Install an Operator from OperatorHub
* xref:../post_installation_configuration/configuring-alert-notifications.adoc#configuring-alert-notifications[Manage alerts and notifications]:
As a cluster administrator, you can view firing alerts by default from the Alerting UI of the web console. You can also configure {product-title} to send alert notifications to external systems so that you learn about important issues with your cluster.
By default, firing alerts are displayed on the Alerting UI of the web console. You can also configure {product-title} to send alert notifications to external systems.