Skip to content

Working with Private Repos

Eva Tuczai edited this page Oct 17, 2023 · 11 revisions

The Turbonomic platform gathers information from your kubernetes / OpenShift environment through the Kubeturbo container image that is deployed into the k8s/OCP cluster you want to manage. The container image is ready for you, available through a public repo in IBM Container Registry which is icr.io, starting with Turbonomic Product version 8.7.5 and higher.

Required Container Images

Note these are MULTIARCH container images, and your private repo needs to support loading multi-arch images. For example Artifactory v6 doesn't support MULTIARCH but Artifactory v7.2+ does support MULTIARCH images.

Optionally only pull the architecture version you need. Supply the --platform option with docker pull, and use docker inspect to confirm what you have.

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

There will be 2 container images required: kubeturbo which is the primary mediation probe, and cpufreqgetter which runs a brief job on every node to collect CPU speed.

  • Kubeturbo probe container image:
    • ICR or IBM Container Registry using icr.io/cpopen/turbonomic/kubeturbo:<version> for version 8.7.5 and higher
    • Archive: Images for version 8.7.4 and older are available from RedHat Container Catalog
  • CPU Frequency container image (also known as busybox):
    • ICR or IBM Container Registry using icr.io/cpopen/turbonomic/cpufreqgetter
    • For more information on parameters associated with this job, go to the article here

If applicable, there will be a 3rd container image for the kubeturbo-operator required for using the Operator deployment method.

  • Kubeturbo operator container image:
    • ICR or IBM Container Registry using icr.io/cpopen/kubeturbo-operator:<version> for version 8.7.5 and higher
    • Archive: Images for version 8.7.4 and older are available from RedHat Container Catalog

Working with a Private Repo

When using a private repo you will need to update certain resources to specify the new container image path. What you need to update depends on your deployment model.

Yaml Method

If you deployed Kubeturbo following the Yaml method, update the following:

  • Kubeturbo: Update the kubeturbo deployment resource, the image parameter
  • CPU Frequency: Update the kubeturbo deployment resource, under the args parameter, add - --cpufreqgetter-image=YOUR-REPO-IMAGE-PATH
kind: Deployment
metadata:
  name: kubeturbo
  namespace: turbo
spec:
  replicas: 1
  selector:
     matchLabels:
       app.kubernetes.io/name: kubeturbo
  template:
    spec:
      containers:
      - name: kubeturbo
        image: YOUR-REPO.COM/icr.io/cpopen/turbonomic/kubeturbo:8.9.3
        args:
          - --turboconfig=/etc/kubeturbo/turbo.config
          - --v=2
          - --kubelet-https=true
          - --kubelet-port=10250
          - --cpufreqgetter-image=YOUR-REPO.COM/icr.io/cpopen/turbonomic/cpufreqgetter
          # If using busybox parameter, uncomment to override default, and specify your own location
          #- --busybox-image=docker.io/busybox
          # or uncomment below to pull from RHCC
          #- --busybox-image=registry.access.redhat.com/ubi8/ubi-minimal
          # Uncomment to specify the secret name which holds the credentials to busybox OR cprfreqgetter image
          #- --busybox-image-pull-secret=<secret-name>

For an example see the sample deployment resource yaml here.

HELM Method

If you deployed Kubeturbo following the HELM method, update the following:

  • Kubeturbo: Update in the values.yaml resource, the repository parameter
  • CPU Frequency: Update in the values.yaml resource, add cpufreqgetterRepository:YOUR-REPO-IMAGE-PATH
image:
  repository: YOUR-REPO.COM/icr.io/cpopen/turbonomic/kubeturbo
  tag: 8.9.3
  cpufreqgetterRepository: YOUR-REPO.COM/icr.io/cpopen/turbonomic/cpufreqgetter
#  busyboxRepository: busybox
#  imagePullSecret: ""
#  cpufreqgetterRepository: icr.io/cpopen/turbonomic/cpufreqgetter

For an example see the sample values resource yaml here.

Operator Manual Method

If you deployed Kubeturbo following the manual Operator method, update the following:

  • Kubeturbo: Update in the custom resource resource, the repository parameter
  • CPU Frequency: Update in the values.yaml resource, add cpufreqgetterRepository:YOUR-REPO-IMAGE-PATH Define these parameter's in the operator instance or custom resource you have configured (default is kubeturbo-release) as shown in the example below:
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-REPO.COM/icr.io/cpopen/turbonomic/kubeturbo
    tag: 8.9.0
    # Specify your cpu frequency job container image.
    cpufreqgetterRepository: YOUR-REPO.COM/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
  ...

For an example see the sample Custom Resource resource yaml here.

NOTE you will also have to define your Kubeturbo-operator image path in the operator's deployment resource

kind: Deployment
metadata:
  name: kubeturbo-operator
  namespace: turbo
spec:
  replicas: 1
  selector:
     matchLabels:
       app.kubernetes.io/name: kubeturbo-operator
  template:
    spec:
      containers:
      - name: kubeturbo-operator
        image: YOUR-REPO.COM/icr.io/cpopen/turbonomic/kubeturbo-operator:8.9.3

For an example see the sample operator deployment resource yaml here.

OpenShift Operator Hub Method

If you deployed Kubeturbo following the OpenShift Operator Hub method, update the following:

  • Kubeturbo: Update in the custom resource resource, the repository parameter
  • CPU Frequency: Update in the values.yaml resource, add cpufreqgetterRepository:YOUR-REPO-IMAGE-PATH Define these parameter's in the operator instance or custom resource you have configured (default is kubeturbo-release) as shown in the example below:
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-REPO.COM/icr.io/cpopen/turbonomic/kubeturbo
    tag: 8.9.0
    # Specify your cpu frequency job container image.
    cpufreqgetterRepository: YOUR-REPO.COM/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
  ...

For an example see the sample Custom Resource resource yaml here.

NOTE you will also have to pull the Kubeturbo-operator and will need to specify in the ClusterServerVersion resource the operator's path and digest id. Refer to OPENSHIFT Documentation for your version on how to work with Operators (or OLM) in a Disconnected or Restricted Network (also referred to as an air-gapped environment) and how to stage CERTIFIED OPERATORS. KubeTurbo certified operator bundle is here. Work with the bundle version that matches the Kubeturbo product version you need.

Kubeturbo

Introduction
  1. What's new
  2. Supported Platforms
Kubeturbo Use Cases
  1. Overview
  2. Getting Started
  3. Full Stack Management
  4. Optimized Vertical Scaling
  5. Effective Cluster Management
  6. Intelligent SLO Scaling
  7. Proactive Rescheduling
  8. Better Cost Management
  9. GitOps Integration
  10. Observability and Reporting
Kubeturbo Deployment
  1. Deployment Options Overview
  2. Prerequisites
  3. Turbonomic Server Credentials
  4. Deployment by Helm Chart
    a. Updating Kubeturbo image
  5. Deployment by Yaml
    a. Updating Kubeturbo image
  6. Deployment by Operator
    a. Updating Kubeturbo image
  7. Deployment by Red Hat OpenShift OperatorHub
    a. Updating Kubeturbo image
Kubeturbo Config Details and Custom Configurations
  1. Turbonomic Server Credentials
  2. Working with a Private Repo
  3. Node Roles: Control Suspend and HA Placement
  4. CPU Frequency Getter Job Details
  5. Logging
  6. Actions and Special Cases
Actions and how to leverage them
  1. Overview
  2. Resizing or Vertical Scaling of Containerized Workloads
    a. DeploymentConfigs with manual triggers in OpenShift Environments
  3. Node Provision and Suspend (Cluster Scaling)
  4. SLO Horizontal Scaling
  5. Turbonomic Pod Moves (continuous rescheduling)
  6. Pod move action technical details
    a. Red Hat Openshift Environments
    b. Pods with PVs
IBM Cloud Pak for Data & Kubeturbo:Evaluation Edition
Troubleshooting
  1. Startup and Connectivity Issues
  2. KubeTurbo Health Notification
  3. Logging: kubeturbo log collection and configuration options
  4. Startup or Validation Issues
  5. Stitching Issues
  6. Data Collection Issues
  7. Collect data for investigating Kubernetes deployment issue
  8. Changes to Cluster Role Names and Cluster Role Binding Names
Kubeturbo and Server version mapping
  1. Turbonomic - Kubeturbo version mappings
Clone this wiki locally