Configuring a private repository (OperatorHub)

Turbonomic gathers information from your clusters through the Kubeturbo container images that are available through a public repository in IBM Container Registry (icr.io).

The following list describes the different Kubeturbo container images.

  • Container image for Kubeturbo

    This is the primary image and is pulled from icr.io/cpopen/turbonomic/kubeturbo:<version>.

  • Container image for the CPU frequency getter job

    The cpufreqgetter image (also known as BusyBox) runs a job on every node to collect CPU speed. This image is pulled from icr.io/cpopen/turbonomic/cpufreqgetter.

    For more information about the parameters associated with this job, see this topic.

  • (Operator method only) Container image for kubeturbo-operator

    This image is pulled for icr.io/cpopen/kubeturbo-operator:<version>

By default, the operator deploys a Kubeturbo image that matches the deployed operator version, and pulls directly from IBM Container Registry. While it is important that the Kubeturbo version matches your Turbonomic version, you might be using a different version or a private repository.

If you are using a private repository, be aware that IBM Container Registry provides multi-architecture container images. Your private repository needs to support loading these images. For example, multi-architecture container images are supported in Artifactory version 7.2+, but not in Artifactory version 6. Optionally, pull only the architecture version that you need. Specify the --platform parameter with docker pull and use docker inspect to confirm the architecture.

docker pull --platform linux/arm64 icr.io/cpopen/turbonomic/kubeturbo:8.14.1
docker inspect 49a61c21c3a1 | grep architecture
                "architecture": "aarch64",

To use a private repository, you need to define additional parameters.

  1. Define the parameters in the operator instance or custom resource you have configured (default is kubeturbo-release), as shown in the following example (see a sample YAML here):

    spec:
      image:
        # Supply your private repo and specific product version here
        # With v8.7.5 and newer, kubeturbo is available via IBM Container Registry
        repository: {your_kubeturbo_repository}/icr.io/cpopen/turbonomic/kubeturbo
        tag: 8.14.1
        # Specify your cpu frequency job container image.
        cpufreqgetterRepository: {your_frequency_getter_repository}/icr.io/cpopen/turbonomic/cpufreqgetter
        # Note cpufreqgetter will use the same pull secret as set for the kubeturbo container image
        #imagePullSecret: secretName
    
      #Rest of CR will be retained
      ...

    Update the sample command with the following parameters:

    • repository: {your_kubeturbo_repository}/icr.io/cpopen/turbonomic/kubeturbo

      Specify your private Kubeturbo repository, such as myrepo.com.

    • cpufreqgetterRepository: {your_frequency_getter_repository}/icr.io/cpopen/turbonomic/cpufreqgetter

      Specify your private CPU frequency getter repository, such as mygetterrepo.com.

  2. Pull the Kubeturbo operator and specify the operator's path and digest ID in the ClusterServerVersion resource.

    For information on how to work with operators or OLMs in a disconnected or restricted network (also referred to as an air-gapped environment) and how to stage certified operators, see the Red Hat OpenShift documentation. The Kubeturbo certified operator bundle is available in this GitHub repository. Be sure to work with the bundle version that matches the Kubeturbo product version that you need.

After you apply your configuration, an instance or custom resource called kubeturbo-release is created, with a Kubeturbo deployed at either the same version as the operator, or a user-specified version.