Chapter 2. Preparing your Red Hat OpenShift Container Platform environment for Service Telemetry Framework
Chapter 2. Preparing your Red Hat OpenShift Container Platform environment for Service Telemetry Framework To prepare your Red Hat OpenShift Container Platform environment for Service Telemetry Framework (STF), you must plan for persistent storage, adequate resources, event storage, and network considerations: Ensure that you have persistent storage available in your Red Hat OpenShift Container Platform cluster for a production-grade deployment. For more information, see Section 2.2, "Persistent volumes" . Ensure that enough resources are available to run the Operators and the application containers. For more information, see Section 2.3, "Resource allocation" . 2.1. Observability Strategy in Service Telemetry Framework Service Telemetry Framework (STF) does not include event storage backends or dashboarding tools. STF can optionally create datasource configurations for Grafana using the community operator to provide a dashboarding interface. Instead of having Service Telemetry Operator create custom resource requests, you can use your own deployments of these applications or other compatible applications, and scrape the metrics Smart Gateways for delivery to your own Prometheus-compatible system for telemetry storage. If you set the observabilityStrategy to none , then storage backends will not be deployed so persistent storage will not be required by STF. Use the observabilityStrategy property on the STF object to specify which type of observability components will be deployed. The following values are available: value meaning use_redhat Red Hat supported components are requested by STF. This includes Prometheus and Alertmanager from the Cluster Observability Operator, but no resource requests to Elastic Cloud on Kubernetes (ECK) Operator. If enabled, resources are also requested from the Grafana Operator (community component). use_hybrid In addition to the Red Hat supported components, Elasticsearch and Grafana resources are also requested (if specified in the ServiceTelemetry object) use_community The community version of Prometheus Operator is used instead of Cluster Observability Operator. Elasticsearch and Grafana resources are also requested (if specified in the ServiceTelemetry object) none No storage or alerting components are deployed Note Newly deployed STF environments as of 1.5.3 default to use_redhat . Existing STF deployments created before 1.5.3 default to use_community . To migrate an existing STF deployment to use_redhat , see the Red Hat Knowledge Base article Migrating Service Telemetry Framework to fully supported operators . 2.2. Persistent volumes Service Telemetry Framework (STF) uses persistent storage in Red Hat OpenShift Container Platform to request persistent volumes so that Prometheus can store metrics. When you enable persistent storage through the Service Telemetry Operator, the Persistent Volume Claims (PVC) requested in an STF deployment results in an access mode of RWO (ReadWriteOnce). If your environment contains pre-provisioned persistent volumes, ensure that volumes of RWO are available in the Red Hat OpenShift Container Platform default configured storageClass . Additional resources For more information about configuring persistent storage for Red Hat OpenShift Container Platform, see Understanding persistent storage. For more information about recommended configurable storage technology in Red Hat OpenShift Container Platform, see Recommended configurable storage technology . For more information about configuring persistent storage for Prometheus in STF, see the section called "Configuring persistent storage for Prometheus" . 2.3. Resource allocation To enable the scheduling of pods within the Red Hat OpenShift Container Platform infrastructure, you need resources for the components that are running. If you do not allocate enough resources, pods remain in a Pending state because they cannot be scheduled. The amount of resources that you require to run Service Telemetry Framework (STF) depends on your environment and the number of nodes and clouds that you want to monitor. Additional resources For recommendations about sizing for metrics collection, see the Red Hat Knowledge Base article Service Telemetry Framework Performance and Scaling . 2.4. Network considerations for Service Telemetry Framework You can deploy Service Telemetry Framework (STF) in fully connected network environments or in Red Hat OpenShift Container Platform-disconnected environments. You cannot deploy STF in network proxy environments. 2.5. Deploying STF on Red Hat OpenShift Container Platform-disconnected environments Since Service Telemetry Framework (STF) version 1.5.4, you can deploy STF in Red Hat OpenShift Container Platform-disconnected environments. Prerequisites Red Hat OpenShift Container Platform Extended Update Support (EUS) version 4.12 or 4.14 deployed in a restricted network. A mirror registry so that the Red Hat OpenShift Container Platform cluster can access the required images. For more information about mirror registries, see Disconnected installation mirroring in the Red Hat OpenShift Container Platform Installing guide. All the STF dependencies are available in the Red Hat OpenShift Container Platform cluster mirror registry. Adding STF dependencies to the mirror registry You can use the oc-mirror plugin to fetch the STF dependencies and add them to the Red Hat OpenShift Container Platform cluster mirror registry. For more information about installing the oc-mirror plugin, see Mirroring images for a disconnected installation using the oc-mirror plugin in the Red Hat OpenShift Container Platform Installing guide. Procedure Create an imagesetconfig.yaml file in your local working directory: imagesetconfig.yaml apiVersion: mirror.openshift.io/v1alpha2 kind: ImageSetConfiguration storageConfig: local: path: ./ mirror: operators: - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.14 packages: - name: service-telemetry-operator channels: - name: stable-1.5 - name: openshift-cert-manager-operator channels: - name: stable-v1 - name: amq7-interconnect-operator channels: - name: 1.10.x - name: smart-gateway-operator channels: - name: stable-1.5 - name: cluster-observability-operator channels: - name: stable (Optional) If your mirror registry is not reachable, you can save the manifests and images that you fetched with oc-mirror and physically transfer them to the mirror registry and Red Hat OpenShift Container Platform cluster. Otherwise you can run oc-mirror and point to the mirror registry. You can use the oc-mirror plugin differently, depending on your environment, such as: mirroring between mirrors. mirror from mirror to disk. mirror from disk to mirror. For more information about different oc-mirror scenarios, see Mirroring an image set in a fully disconnected environment in the Red Hat OpenShift Container Platform Installing guide. Push the STF operators and their dependencies from the mirror registry and generate the manifest for the Red Hat OpenShift Container Platform cluster. USD oc-mirror --config imagesetconfig.yaml <mirror_registry_location> Replace <mirror_registry_location> with the filepath to the mirror registry that you want to use. Locate the generated manifests and apply them to the target Red Hat OpenShift Container Platform cluster. For more information, see Configuring your cluster to use the resources generated by oc-mirror in the Red Hat OpenShift Container Platform Installing guide. Note The manifests that you generate with oc-mirror produce catalogs with the full index name, such as redhat-operator-index instead of redhat-operators for CatalogSource . Ensure that you use the correct index name for the STF subscriptions. For more information, see Section 3.1, "Deploying Service Telemetry Framework to the Red Hat OpenShift Container Platform environment" . For more information about customizing Operators with oc mirror, see the Red Hat Knowledgebase solution How to customize the catalog name and tags of Operators mirrored to the mirror registry using the oc mirror plugin. Verification Check that the catalog sources are applied. You can return the entries for new catalogs that reference the STF operators and their dependencies: USD oc get catalogsources You have deployed STF in a disconnected Red Hat OpenShift Container Platform cluster and therefore cannot access external networks.
apiVersion: mirror.openshift.io/v1alpha2 kind: ImageSetConfiguration storageConfig: local: path: ./ mirror: operators: - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.14 packages: - name: service-telemetry-operator channels: - name: stable-1.5 - name: openshift-cert-manager-operator channels: - name: stable-v1 - name: amq7-interconnect-operator channels: - name: 1.10.x - name: smart-gateway-operator channels: - name: stable-1.5 - name: cluster-observability-operator channels: - name: stable oc-mirror --config imagesetconfig.yaml <mirror_registry_location> oc get catalogsources