mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
OSDOCS-16572: first batch of rec visibility changes
This commit is contained in:
Sebastian Kopacz
committed by
openshift-cherrypick-robot
openshift-cherrypick-robot
parent
d0504e4f15
commit
542b386592
@@ -6,7 +6,7 @@ include::_attributes/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
etcd (pronounced et-see-dee) is a consistent, distributed key-value store that stores small amounts of data across a cluster of machines that can fit entirely in memory. As the core component of many projects, etcd is also the primary data store for Kubernetes, which is the standard system for container orchestration.
|
||||
etcd (pronounced et-see-dee) is a consistent, distributed key-value store that stores small amounts of data across a cluster of machines that can fit entirely in memory. As the core component of many projects, etcd is also the primary data store for Kubernetes, which is the standard system for container orchestration.
|
||||
|
||||
By using etcd, you can benefit in several ways:
|
||||
|
||||
@@ -22,6 +22,10 @@ The default etcd configuration optimizes container orchestration. Use it as desi
|
||||
// How etcd works
|
||||
include::modules/how-etcd-works.adoc[leveloffset=+1]
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
* xref:../etcd/etcd-practices.adoc#etcd-practices[Recommended etcd practices]
|
||||
|
||||
//Understanding etcd and the conditions affecting performance
|
||||
include::modules/understand-etcd-performance.adoc[leveloffset=+1]
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
[id="etcd-practices"]
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
= Recommended etcd practices
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: etcd-practices
|
||||
|
||||
toc::[]
|
||||
|
||||
@@ -51,7 +51,12 @@ endif::openshift-dedicated,openshift-rosa[]
|
||||
|
||||
ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
mint mode::
|
||||
Mint mode is the default and recommended best practice setting for the Cloud Credential Operator (CCO) to use on the platforms for which it is supported. In this mode, the CCO uses the provided administrator-level cloud credential to create new credentials for components in the cluster with only the specific permissions that are required.
|
||||
In mint mode, the Cloud Credential Operator (CCO) uses the provided administrator-level cloud credential to create new credentials for components in the cluster with only the specific permissions that are required.
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
Mint mode is the default and the preferred setting for the CCO to use on the platforms for which it is supported.
|
||||
====
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
|
||||
namespace::
|
||||
|
||||
@@ -8,7 +8,13 @@
|
||||
|
||||
When working in a highly regulated environment, you might need the ability to secure DNS traffic when forwarding requests to upstream resolvers so that you can ensure additional DNS traffic and data privacy.
|
||||
|
||||
Be aware that CoreDNS caches forwarded connections for 10 seconds. CoreDNS will hold a TCP connection open for those 10 seconds if no request is issued. With large clusters, ensure that your DNS server is aware that it might get many new connections to hold open because you can initiate a connection per node. Set up your DNS hierarchy accordingly to avoid performance issues.
|
||||
Be aware that CoreDNS caches forwarded connections for 10 seconds. CoreDNS will hold a TCP connection open for those 10 seconds if no request is issued.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
With large clusters, ensure that your DNS server is aware that it might get many new connections to hold open because you can initiate a connection per node. Set up your DNS hierarchy accordingly to avoid performance issues.
|
||||
====
|
||||
|
||||
ifdef::openshift-rosa,openshift-dedicated[]
|
||||
[IMPORTANT]
|
||||
====
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
[id="how-etcd-works_{context}"]
|
||||
= How etcd works
|
||||
|
||||
To ensure a reliable approach to cluster configuration and management, etcd uses the etcd Operator. The Operator simplifies the use of etcd on a Kubernetes container platform such as {product-title}.
|
||||
To ensure a reliable approach to cluster configuration and management, etcd uses the etcd Operator. The Operator simplifies the use of etcd on a Kubernetes container platform such as {product-title}.
|
||||
|
||||
Additionally, you can use the etcd Operator to deploy and manage the etcd cluster for the {product-title} control plane. The etcd Operator manages the cluster state in the following ways:
|
||||
|
||||
@@ -13,4 +13,7 @@ Additionally, you can use the etcd Operator to deploy and manage the etcd cluste
|
||||
* Analyzes differences between the current state and the required state
|
||||
* Corrects the differences through the etcd cluster management APIs, the Kubernetes API, or both
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
etcd holds the cluster state, which is constantly updated. This state is continuously persisted, which leads to a high number of small changes at high frequency. As a result, it is critical to back up the etcd cluster member with fast, low-latency I/O. For more information about best practices for etcd, see "Recommended etcd practices".
|
||||
====
|
||||
|
||||
@@ -123,7 +123,12 @@ values are ignored. `groupsQuery` must set a valid `derefAliases`.
|
||||
<2> The attribute that uniquely identifies a group on the LDAP server. It must be set to `dn`.
|
||||
<3> The attribute to use as the name of the group.
|
||||
<4> The attribute to use as the name of the user in the {product-title} group
|
||||
record. `mail` or `sAMAccountName` are preferred choices in most installations.
|
||||
record.
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
`mail` or `sAMAccountName` are preferred choices in most installations.
|
||||
====
|
||||
<5> The attribute on the user that stores the membership information. Note the use of `LDAP_MATCHING_RULE_IN_CHAIN`.
|
||||
|
||||
.Prerequisites
|
||||
|
||||
@@ -121,6 +121,7 @@ Repeat this step to create additional secrets for any other required private reg
|
||||
|
||||
. Create or update an existing `CatalogSource` object to reference one or more secrets:
|
||||
+
|
||||
--
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: operators.coreos.com/v1alpha1
|
||||
@@ -143,7 +144,13 @@ spec:
|
||||
interval: 30m
|
||||
----
|
||||
<1> Add a `spec.secrets` section and specify any required secrets.
|
||||
<2> Specify the value of `legacy` or `restricted`. If the field is not set, the default value is `legacy`. In a future {product-title} release, it is planned that the default value will be `restricted`. If your catalog cannot run with `restricted` permissions, it is recommended that you manually set this field to `legacy`.
|
||||
<2> Specify the value of `legacy` or `restricted`. If the field is not set, the default value is `legacy`. In a future {product-title} release, it is planned that the default value will be `restricted`.
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
If your catalog cannot run with `restricted` permissions, it is recommended that you manually set this field to `legacy`.
|
||||
====
|
||||
--
|
||||
|
||||
. If any Operator or Operand images that are referenced by a subscribed Operator require access to a private registry, you can either provide access to all namespaces in the cluster, or individual target tenant namespaces.
|
||||
|
||||
|
||||
@@ -67,9 +67,10 @@ ifdef::olm-restricted-networks[]
|
||||
If you used the `oc adm catalog mirror` command to mirror your catalog to a target registry, you can use the generated `catalogSource.yaml` file in your manifests directory as a starting point.
|
||||
endif::[]
|
||||
|
||||
ifdef::olm-restricted-networks[]
|
||||
.. Modify the following to your specifications and save it as a `catalogSource.yaml` file:
|
||||
+
|
||||
ifdef::olm-restricted-networks[]
|
||||
--
|
||||
[source,yaml,subs="attributes+"]
|
||||
----
|
||||
apiVersion: operators.coreos.com/v1alpha1
|
||||
@@ -90,12 +91,21 @@ spec:
|
||||
----
|
||||
<1> If you mirrored content to local files before uploading to a registry, remove any backslash (`/`) characters from the `metadata.name` field to avoid an "invalid resource name" error when you create the object.
|
||||
<2> If you want the catalog source to be available globally to users in all namespaces, specify the `{namespace}` namespace. Otherwise, you can specify a different namespace for the catalog to be scoped and available only for that namespace.
|
||||
<3> Specify the value of `legacy` or `restricted`. If the field is not set, the default value is `legacy`. In a future {product-title} release, it is planned that the default value will be `restricted`. If your catalog cannot run with `restricted` permissions, it is recommended that you manually set this field to `legacy`.
|
||||
<3> Specify the value of `legacy` or `restricted`. If the field is not set, the default value is `legacy`. In a future {product-title} release, it is planned that the default value will be `restricted`.
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
If your catalog cannot run with `restricted` permissions, it is recommended that you manually set this field to `legacy`.
|
||||
====
|
||||
<4> Specify your index image. If you specify a tag after the image name, for example `:{tag}`, the catalog source pod uses an image pull policy of `Always`, meaning the pod always pulls the image prior to starting the container. If you specify a digest, for example `@sha256:<id>`, the image pull policy is `IfNotPresent`, meaning the pod pulls the image only if it does not already exist on the node.
|
||||
<5> Specify your name or an organization name publishing the catalog.
|
||||
<6> Catalog sources can automatically check for new versions to keep up to date.
|
||||
--
|
||||
endif::[]
|
||||
ifndef::olm-restricted-networks[]
|
||||
.. Modify the following to your specifications and save it as a `catalogSource.yaml` file:
|
||||
+
|
||||
--
|
||||
[source,yaml,subs="attributes+"]
|
||||
----
|
||||
apiVersion: operators.coreos.com/v1alpha1
|
||||
@@ -119,10 +129,16 @@ spec:
|
||||
----
|
||||
<1> If you want the catalog source to be available globally to users in all namespaces, specify the `{namespace}` namespace. Otherwise, you can specify a different namespace for the catalog to be scoped and available only for that namespace.
|
||||
<2> Optional: Set the `olm.catalogImageTemplate` annotation to your index image name and use one or more of the Kubernetes cluster version variables as shown when constructing the template for the image tag.
|
||||
<3> Specify the value of `legacy` or `restricted`. If the field is not set, the default value is `legacy`. In a future {product-title} release, it is planned that the default value will be `restricted`. If your catalog cannot run with `restricted` permissions, it is recommended that you manually set this field to `legacy`.
|
||||
<3> Specify the value of `legacy` or `restricted`. If the field is not set, the default value is `legacy`. In a future {product-title} release, it is planned that the default value will be `restricted`.
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
If your catalog cannot run with `restricted` permissions, it is recommended that you manually set this field to `legacy`.
|
||||
====
|
||||
<4> Specify your index image. If you specify a tag after the image name, for example `:{tag}`, the catalog source pod uses an image pull policy of `Always`, meaning the pod always pulls the image prior to starting the container. If you specify a digest, for example `@sha256:<id>`, the image pull policy is `IfNotPresent`, meaning the pod pulls the image only if it does not already exist on the node.
|
||||
<5> Specify your name or an organization name publishing the catalog.
|
||||
<6> Catalog sources can automatically check for new versions to keep up to date.
|
||||
--
|
||||
endif::[]
|
||||
|
||||
.. Use the file to create the `CatalogSource` object:
|
||||
|
||||
@@ -29,7 +29,12 @@ spec:
|
||||
displayName: "My Operators"
|
||||
priority: 100
|
||||
----
|
||||
<1> Specify the value of `legacy` or `restricted`. If the field is not set, the default value is `legacy`. In a future {product-title} release, it is planned that the default value will be `restricted`. If your catalog cannot run with `restricted` permissions, it is recommended that you manually set this field to `legacy`.
|
||||
<1> Specify the value of `legacy` or `restricted`. If the field is not set, the default value is `legacy`. In a future {product-title} release, it is planned that the default value will be `restricted`.
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
If your catalog cannot run with `restricted` permissions, it is recommended that you manually set this field to `legacy`.
|
||||
====
|
||||
|
||||
A `CatalogSource` object has a `priority` field, which is used by the resolver to know how to prefer options for a dependency.
|
||||
|
||||
|
||||
@@ -104,4 +104,4 @@ include::snippets/technology-preview.adoc[leveloffset=+1]
|
||||
|
||||
* Online expansion is supported from vSphere version 8.0 Update 1 and later.
|
||||
--
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
@@ -6,16 +6,19 @@
|
||||
[id="telemetry-consequences-of-disabling-telemetry_{context}"]
|
||||
= Consequences of disabling remote health reporting
|
||||
|
||||
In {product-title}, customers can disable reporting usage information.
|
||||
In {product-title}, customers can disable reporting usage information.
|
||||
|
||||
Before you disable remote health reporting, read the following benefits of a connected cluster:
|
||||
|
||||
* Red{nbsp}Hat can react more quickly to problems and better support our customers.
|
||||
* Red{nbsp}Hat can better understand how product upgrades impact clusters.
|
||||
* Red{nbsp}Hat can better understand how product upgrades impact clusters.
|
||||
* Connected clusters help to simplify the subscription and entitlement process.
|
||||
* Connected clusters enable the {cluster-manager} service to offer an overview of your clusters and their subscription status.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
Consider leaving health and usage reporting enabled for pre-production, test, and production clusters. This means that Red{nbsp}Hat can participate in qualifying {product-title} in your environments and react more rapidly to product issues.
|
||||
====
|
||||
|
||||
The following lists some consequences of disabling remote health reporting on a connected cluster:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user