Provision your container agent

Overview

In order to gather the data we need to perform allocation for a given cluster, you will need to deploy the IBM FinOps Agent, the next-generation data collection agent for Cloudability Containers. In order to get container optimization recommendations, you will need to deploy the Turbonomic kubeturbo agent to each cluster you want to report on.

This is achieved through a HELM deployment provisioned for each cluster. These HELM commands can be generated by following these steps:

Provision Cloudability Metrics Agent

1. Navigate to Insights > Containers .

2. Select the Provision Clusters button.

3. Fill out the form with your cluster name and either your Kubernetes version or your OpenShift version.

4. 4. Click Next -> Generate Command.

Google Kubernetes Engine (GKE)-specific instructions

You need to add a cluster label in each cluster as follows:

• key: gke-cluster
• value: The cluster name(s) you set in the form/YAML. This allows Cloudability to map GKE clusters to line items in the GCP billing file, and allocate costs to your clusters.

Cloudability will need to ingest a billing file with the cluster labels you added, which can take up to 48 hours. Once Apptio has processed the new billing file, you need to create a new tag mapping in the Cloudability application. Set a Cloudability Dimension as gke-cluster and map this to the gke-cluster tag. This is a one time need, not per cluster.

Ensure that your account has cluster-admin role before deploying the Metrics agent. By default, a user account does not have the cluster-admin role. Use the following command on the GKE cluster to grant a user the cluster-admin role:

"kubectl create clusterrolebinding username-cluster-admin-binding --
clusterrole=cluster-admin --user=username@emailaddress.com"

Deploy the agent

Prerequisites:

Networking Requirements:

In the Cloudability metrics-agent the networking requirements were documented in the README.

The unified agent has updated networking requirements in order to function properly and upload data to Cloudability’s S3.

The new Networking requirements for the agent are as follows:

The container that hosts the metrics agent should allow HTTPS requests to following endpoints:

• https://frontdoor.apptio.com port 443

  • https://frontdoor-eu.apptio.com if Cloudability is in EU

  • https://frontdoor-au.apptio.com if Cloudability is in AU

  • https://frontdoor-me.apptio.com if Cloudability is in ME

• https://api.cloudability.com port 443

  • https://api-eu.cloudability.com if Cloudability is in EU

  • https://api-au.cloudability.com if Cloudability is in AU

  • https://api-me.cloudability.com if Cloudability is in ME

The container that hosts the metrics agent should have write access to following Apptio S3 buckets:

• apptio* (bucket prefixed with apptio)

  • If you require more detailed information on whitelisting requirements, please reach out to our support team

Storage Requirements:

The IBM-Finops-Agent requires a configurable persistent volume claim (default 8Gi). This change was to reduce the chance of data loss if/when the agent gets rescheduled. The agent now stores samples on this volume and will attempt to recover any samples after a restart. This improvement vastly improves the agent’s ability to recover data in failure scenarios.

Container Registry change:

The IBM-Finops-Agent is not stored in docker like the existing metrics-agent. Instead the IBM-Finops-Agent is stored in ICR. So you may need to update your container registry whitelisting to allow the IBM-Finops-Agent deployment to pull the ICR image. The IBM-Finops-Agent container registry is:

icr.io/ibm-finops/agent:vx.x.x

If you need to pull the image locally to copy to your container registry. You can run the following docker/podman pull command:

 podman pull icr.io/ibm-finops/agent:v0.0.25 --platform=linux/amd64

Authentication:

It is important to call out that the Cloudability metrics-agent used a Containers specific API key. The IBM finops agent will no longer use/support this api key. Instead customers need to create an API key for the agent in Frontdoor and gather their Frontdoor Environment ID.

Creating User to manage container API key:

It is required that your Frontdoor environment has api keys enabled on it for the Containers Feature to work

It is recommended that customers create a containers specific service user within their own domain to manage their api key going forward. This way, the uploading api key is not associated with one specific user that may be deactivated in the future. The person creating the new user and api key needs to be an admin user in their Frontdoor environment.

1. Navigate to “Access Wizard” in “Access Administration”, select “Add User(s)”, set “Customer” and “Environment”. Finally, hit “Confirm”

   

2. Enter user information and hit “Next”

   

3. Select “Grant Role(s)”, “Do not send User an activation Email” and hit “Confirm” to create the user

   

4. Ensure user is selected for granting roles

   

5. Grant the “CloudabilityContainerUploader” Role to the user and hit “Next”/”Confirm”.

   

   Creating User to manage container API key:

6. Navigate to “Home”, search for the newly created user, and click on their “Username”

   

7. Hit “View User Profile”

   

8. Add an api key for the user

   

9. Enter a name for the API key (ex: IBM-Finops-agent), set “No Expiration” if not already set, and hit confirm.

10. Store the API Key Credentials (Public Key and Private Key) for later to be used in the helm installation of the agent.

11. Hit “Grant Access”

12. Select your environment and hit “Next”

    

13. Add the “CloudabilityContainerUploader” role to the key and hit “Next”. This role has limited access to on the containers uploading endpoint.

    

14. Check that your key has been created and has the correct Role

    

Gathering Frontdoor Environment ID

1. Navigate to Frontdoor

2. In the top right select the Profile logo and click on “User Account”

   

3. Navigate to the Environment Access tab

4. Gather the environment ID under the Environment tab in the table

   1. Ensuring the environment is the same as what you use to access Cloudability

      

   2. Example id format: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Deploying the metrics-agent With Helm

Prerequisites:

• Install Helm must be installed to use the charts. Refer to Helm’s documentation to get started.

• Update Cluster’s Networking policies to allow for new Networking Requirements (if necessary)

• Gather API Public and Private Keys

• Gather Frontdoor Environment ID

Once Helm has been set up correctly, Add the repo as follows:

helm repo add ibm-finops https://kubecost.github.io/finops-agent-chart

If you had already added this repo earlier, Update it:

helm repo update

Install Helm Repo

helm install ibm-finops-agent ibm-finops/finops-agent \   
--set agent.cloudability.enabled=true \
--set agent.cloudability.uploadRegion=<uploadRegion> \      
--set agent.cloudability.parseMetricData=false \
--set agent.cloudability.secret.create=true \
--set agent.cloudability.secret.cloudabilityAccessKey='<AccessKey>' \
--set agent.cloudability.secret.cloudabilitySecretKey='<SecretKey>' \
--set agent.cloudability.secret.cloudabilityEnvId='<EnvID>' \
--set clusterId='<ClusterName> \
--create-namespace -n ibm-finops-agent

To Uninstall Helm Repo:

helm uninstall ibm-finops-agent

If your cluster is currently running the old Cloudability metrics-agent, feel free to keep that running until you see the new ibm-finops-agent start uploading successfully for 24 hours. The ibm-finops-agent can be installed and run in parallel to the Cloudability metrics-agent but it is recommended to spin down the Cloudability metrics-agent once the new agent is stable in your cluster.

UploadRegion depends on what region the customer’s Cloudability environment exists in. The supported values are below

• US: us (or us-west-2)

• EU: eu (or eu-central-1)

• AU: au (or ap-southeast-2)

• ME: me (or me-central-1)

• Hybrid EU (customers who have EU frontdoor but upload containers data to the US region): hybrid-eu

• Hybrid AU (customers who have AU frontdoor but upload containers data to the US region): hybrid-au

• Hybrid ME (customers who have ME frontdoor but upload containers data to the US region): hybrid-me

ClusterName should be the same value as what is currently in the metrics-agent CLOUDABILITY_CLUSTER_NAME to prevent any cost ingestion issues.

helm install ibm-finops-agent ibm-finops/finops-agent \   
--set agent.cloudability.enabled=true \
--set agent.cloudability.uploadRegion=<uploadRegion> \      
--set agent.cloudability.parseMetricData=false \
--set agent.cloudability.secret.create=true \
--set agent.cloudability.secret.cloudabilityAccessKey="<PublicKey>" \
--set agent.cloudability.secret.cloudabilitySecretKey="<PrivateKey>" \
--set agent.cloudability.secret.cloudabilityEnvId="<FDEnvID>" \
--set agent.cloudability.outboundProxy="http://x.x.x.x:8080" \
--set agent.cloudability.parseMetricsData="true"
--set clusterId="<ClusterName>" \
--create-namespace -n ibm-finops-agent

1. Ensure the ibm-finops-agent pod is running

   kubectl get pods -n ibm-finops-agent
   
   ### Example Output Below ###
   NAME                                READY   STATUS    RESTARTS   AGE
   ibm-finops-agent-7bbf99d9fb-kmhh9   1/1     Running   0          1m

2. Check the pods logs in order to confirm the agent is successfully uploading data to Cloudability. It will take 10 minutes in order to see the first successful upload log.

   kubectl logs <POD_NAME> -n ibm-finops-agent
   
   ### Example Output Below ###
   INF Starting IBM Finops Agent...
   DBG HTTP server started on port 9003
   INF Initializing cldy emitter
   INF emitting sample to Cldy 0
   INF added sample to Cldy
   INF emitting sample to Cldy 1
   INF added sample to Cldy
   INF emitting sample to Cldy 2
   INF added sample to Cldy
   INF Attempt 1: performing login request to FrontDoor using KeyAccess and KeySecret
   INF Attempt 1: acquiring presigned URL from Cloudability with acquired Open-token
   INF Attempt 1: uploading sample to Cloudability S3 using presigned URL
   INF successfully uploaded metric sample xxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx_xxxx-xx-xx-xx-xx-xx.tgz to cloudability

Once again, it will take 10 minutes for the log “successfully uploaded metric sample to cloudability” to appear. This is a common point of failure in agent’s if they do not have the correct whitelisting/proxy settings enabled.

After 24 hours of the ibm-finops-agent running and uploading successfully. If you are still running a Cloudability metrics-agent deployment, you may now tear down that infrastructure and keep only the ibm-finops-agent helm chart running.

Provision Cloudability Container Optimization ( Turbonomic kubeturbo) Agent

1. Navigate to Insights > Containers .
2. Select the Provision Clusters button.
3. Fill out the form with your cluster name and either your Kubernetes version or your OpenShift version.
4. Select Generate Agent Script under the section Container optimization Agent .

Installation Steps

Once the script is downloaded, copy it to the location where you want to run it from, in an environment where you are connected to the destination cluster where you want the agent deployed.

Run the command using the example below:

chmod +x new-js-aks.sh &&./new-js-aks.sh

The summary for the installation is as below.

Parameter            Value
---------            ---------
Mode                 Create/Update
Kubeconfig           default
Host                 https://20.116.237.9
Namespace            turbo
Target Name          new-js-aks
Target Subtype       Kubernetes
Role                 turbo-cluster-admin
Version              8.14.5
Auto-Update          false
Auto-Logging         false
Proxy Server         false
Private Registry     false

Please confirm the above settings [Y/n]: Y

Your current Kubernetes context is set to the following.

NAME                     CLUSTER                  AUTHINFO                                                NAMESPACE
concise-lobster-aks      concise-lobster-aks      clusterUser_concise-lobster-rg_concise-lobster-aks           

Please confirm if the script should work in the above cluster [Y/n]: Y

Creating turbo namespace to deploy Kubeturbo operator
namespace/turbo created
secret/turbonomic-credentials created
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
100  159k  100  159k    0     0   920k      0 --:--:-- --:--:-- --:--:--  923k

customresourcedefinition.apiextensions.k8s.io/kubeturbos.charts.helm.k8s.io unchanged
serviceaccount/kubeturbo-operator created
clusterrole.rbac.authorization.k8s.io/kubeturbo-operator unchanged
Skip patching ClusterRoleBinding kubeturbo-operator as the clusterRole has bound to the operator service account already.
deployment.apps/kubeturbo-operator created
namespace/turbo configured
Waiting for deployment 'kubeturbo-operator' to start...
Resource is not ready, re-attempt after 10s ... (1/10)
pod/kubeturbo-operator-857855c6b5-d9x2c condition met
apply Kubeturbo CR ...
kubeturbo.charts.helm.k8s.io/kubeturbo-release created
Waiting for deployment 'kubeturbo-release' to start...
Resource is not ready, re-attempt after 10s ... (1/10)
pod/kubeturbo-release-7d499cf568-cg5sm condition met
Successfully apply Kubeturbo in turbo namespace!

NAME                                SECRETS   AGE
serviceaccount/kubeturbo-operator   0         32s
serviceaccount/turbo-user           0         12s

NAME                                     READY   STATUS    RESTARTS   AGE
pod/kubeturbo-release-7d499cf568-cg5sm   1/1     Running   0          12s

NAME                                 READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/kubeturbo-operator   1/1     1            1           30s
deployment.apps/kubeturbo-release    1/1     1            1           12s

NAME                                       DATA   AGE
configmap/turbo-config-kubeturbo-release   2      12s
Done!

Run the command below to verify the 2 pods are running, as shown in the example below:

kubectl get pods -n turbo

NAME                                  READY   STATUS    RESTARTS   AGE 
kubeturbo-operator-857855c6b5-d9x2c   1/1     Running   0          105s 
kubeturbo-release-7d499cf568-cg5sm    1/1     Running   0          87s

The following image illustrates the Installation.