-
Notifications
You must be signed in to change notification settings - Fork 75
Working with Private Repos
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.
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 withdocker pull
, and usedocker 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
- ICR or IBM Container Registry using
- 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
- ICR or IBM Container Registry using
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
- ICR or IBM Container Registry using
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.
If you deployed Kubeturbo following the Yaml method, update the following:
- Kubeturbo: Update the kubeturbo
deployment
resource, theimage
parameter - CPU Frequency: Update the kubeturbo
deployment
resource, under theargs
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.
If you deployed Kubeturbo following the HELM method, update the following:
- Kubeturbo: Update in the
values.yaml
resource, therepository
parameter - CPU Frequency: Update in the
values.yaml
resource, addcpufreqgetterRepository: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.
If you deployed Kubeturbo following the manual Operator method, update the following:
- Kubeturbo: Update in the
custom resource
resource, therepository
parameter - CPU Frequency: Update in the
values.yaml
resource, addcpufreqgetterRepository:YOUR-REPO-IMAGE-PATH
Define these parameter's in the operator instance or custom resource you have configured (default iskubeturbo-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.
If you deployed Kubeturbo following the OpenShift Operator Hub method, update the following:
- Kubeturbo: Update in the
custom resource
resource, therepository
parameter - CPU Frequency: Update in the
values.yaml
resource, addcpufreqgetterRepository:YOUR-REPO-IMAGE-PATH
Define these parameter's in the operator instance or custom resource you have configured (default iskubeturbo-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.
Introduction
Kubeturbo Use Cases
Kubeturbo Deployment
Kubeturbo Config Details and Custom Configurations
Actions and how to leverage them
- Overview
-
Resizing or Vertical Scaling of Containerized Workloads
a. DeploymentConfigs with manual triggers in OpenShift Environments - Node Provision and Suspend (Cluster Scaling)
- SLO Horizontal Scaling
- Turbonomic Pod Moves (continuous rescheduling)
-
Pod move action technical details
a. Red Hat Openshift Environments
b. Pods with PVs
IBM Cloud Pak for Data & Kubeturbo:Evaluation Edition
Troubleshooting
- Startup and Connectivity Issues
- KubeTurbo Health Notification
- Logging: kubeturbo log collection and configuration options
- Startup or Validation Issues
- Stitching Issues
- Data Collection Issues
- Collect data for investigating Kubernetes deployment issue
- Changes to Cluster Role Names and Cluster Role Binding Names