# Kubex Public Cloud Resources
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/API_Reference_Public_Cloud



<CardGroup>
  <Card title="Onboard AWS Accounts" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_AWS_Analyze" />

  <Card title="Analysis: AWS Delete" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_AWS_Delete" />

  <Card title="Analysis: AWS Recommendations" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_AWS_Results" />

  <Card title="Analysis: AWS Systems" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_AWS_Systems" />

  <Card title="Analysis: Azure Analyze" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Azure_Analyze" />

  <Card title="Analysis: Azure Delete" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Azure_Delete" />

  <Card title="Analysis: Azure Recommendations" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Azure_Results" />

  <Card title="Analysis: Azure Systems" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Azure_Systems" />

  <Card title="Analysis: Cloud" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Cloud" />

  <Card title="Analysis: Containers" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Container" />

  <Card title="Analysis: Entity" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Entity" />

  <Card title="Analysis: GCP Analyze" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_GCP_Analyze" />

  <Card title="Analysis: GCP Delete" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_GCP_Delete" />

  <Card title="Analysis: GCP Recommendations" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_GCP_Results" />

  <Card title="Analysis: GCP Systems" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_GCP_Systems" />

  <Card title="Analysis: Kubernetes Container Recommendations" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Kubernetes_Results" />

  <Card title="Analysis: Kubernetes Container Systems" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Kubernetes_Systems" />

  <Card title="Analysis: Status" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Status" />

  <Card title="Analysis: Webhook" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Webhook" />

  <Card title="Existing Systems" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Existing_Systems" />

  <Card title="Receive Metrics Jobs" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Receive_Metrics_Jobs" />

  <Card title="./Subscriptions" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions" />

  <Card title="Subscriptions: Results" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Results" />

  <Card title="Subscriptions: Properties" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Properties" />

  <Card title="Subscriptions: Status" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Status" />

  <Card title="Subscriptions: Suppressions" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Suppressions" />

  <Card title="Subscriptions: Tags" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Tags" />

  <Card title="./Systems" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Systems" />

  <Card title="Systems: Analysis Details" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Systems_Analysis_Details" />
</CardGroup>


# Onboard AWS Accounts
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_AWS_Analyze



The `/analysis/cloud/aws/analyze` resource is used to collect AWS CloudWatch data and initiate optimization analysis with the cloud infrastructure collected. Below are the series of processes that occur when the initial `/analysis/cloud/aws/analyze` request is triggered:

1. Set up and initiate data collection of the specified AWS account and schedule it to run automatically on a nightly basis.
2. Initiate analysis on the data collected using the default policy.

* Subsequent analysis is scheduled to run on a nightly basis after the completion of data collection.
* Optionally, you can configure the results to be sent to a webhook URI upon analysis completion. See [Add webhook to an analysis](./Analysis_Webhook#_AddWebhook) for details.

3. Once data collection succeeds and an `analysisId` is created for the account, you can check progress with `/analysis/cloud/aws/<analysisId>/status` or wait for the results to be published to an optional webhook URI. Accounts that have not produced an `analysisId` (for example, due to unsupported resources or insufficient data) cannot use the status endpoint until an analysis run begins.
4. The reporting database update is scheduled to run automatically on a nightly basis after the completion of the analysis. This process produces reports for each instance recommendation, which is useful for analysts or application owners. These reports are only created after the scheduled analysis is completed, and may therefore only be available on the following day for a new analysis. Exact timing depends on the size of your environment.

<Note>
  When onboarding an account using the `/analysis/cloud/aws/analyze` endpoint, receiving a 200 status code signals that the onboarding was successful.
</Note>

#### Analysis Update

You can make an ad-hoc request to refresh an existing analysis, outside of the scheduled nightly run using `/analysis/cloud/<aws|azure|gcp>/analyze`. This manual, ad hoc analysis request does not perform data collection or reporting database (RDB) updates. It only runs the analysis on the existing data collected with the following behavior:

* The analysis uses the policy that is configured for the analysis. Contact [support@kubex.ai](mailto:support@kubex.ai) to change the configured policy.
* If a new webhook is provided, the analysis will send results to the new webhook URI. If no webhook is provided, the analysis will send results to the existing webhook, if configured.
* If the same analysis is already running, the request does not proceed and an appropriate message is returned.
* If the specified analysis has data collection scheduled within 30 minutes, the request does not proceed and an appropriate message is returned. For example, if data collection is scheduled to run at 12:05 AM, and you initiate a manual, ad hoc analyze request at 11:45 PM, then the analysis will not proceed and an error message is returned.

### Prerequisite Configuration

Before you can collect AWS CloudWatch data, you need to create an IAM role for Kubex to have a trust relationship with your AWS account that contains data. See [AWS Data Collection Prerequisites for an IAM Role](/docs/WebHelp_Densify_Cloud/Content/Data_Collection_for_Public_Cloud_Systems/AWS_Data_Collection_Prerequisites_for_an_IAM_Role__CloudWatch_only_) for details on how to set up the IAM role for data collection.

## Resource

```
/analysis/cloud/aws/analyze
```

```
/analysis/cloud/aws
```

## Endpoints

<CardGroup>
  <Card title="Analyze AWS" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_AWS_Analyze/analyzeAws" />
</CardGroup>

<CardGroup>
  <Card title="List AWS Analyses" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_AWS_Analyze/listAwsAnalyses" />
</CardGroup>


# Onboard AWS account
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_AWS_Analyze/analyzeAws

openapi/public_cloud/Analysis_AWS_Analyze.yaml POST /analysis/cloud/aws/analyze
Initiates AWS CloudWatch data collection and runs optimization analysis. Subsequent data collection and analysis are scheduled nightly. If an analysis already exists, this endpoint re-runs analysis and can update  the webhook for result delivery.




# List AWS accounts being analyzed
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_AWS_Analyze/listAwsAnalyses

openapi/public_cloud/Analysis_AWS_Analyze.yaml GET /analysis/cloud/aws
Returns the set of analyses that have been created, with details needed to reference them elsewhere.



# Offboard AWS Accounts
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_AWS_Delete



The `/analysis/cloud/aws/<analysisId>` resource can be used to delete the audit and all associated scheduler entries of the cloud analysis specified by `<analysisId>`.

* The single-day and 60-day historical audits are removed, if they exist.
* The audit and all associated scheduler entries, are deleted, if they exist.

When executing the delete operation in an environment observe the following:

* When deleting an audit for an environment associated with a single account, the operation proceeds as outlined above.
* When deleting an audit for a payer account with multiple linked accounts, If Kubex determines that there is a many-to-one relationship for this account, then the delete request fails. This type of multi-account connection can only be created through the Cloud Connection Wizard and must be deleted through the Cloud Connection Wizard.

During a delete operation, any attempt to access other associated endpoints related to the specified `<analysisId>` (i.e. GET, PUT, POST) will trigger a "400 Bad Request" error response.

While the delete operation is in progress, you can check the status (using the `/analysis/cloud/aws/<``analysisId``>/status` resource) or wait for the results to be published to an optional webhook URI.

Collected data is saved for the defined retention period and the environment and associated analysis structure are saved in case you want to generate reports on the historical data or restart data collection. Since the environment and analyses are not deleted, a GET call for the specified `<analysisId>` will always succeed regardless of whether the associated connection has been deleted.

If you use a GET call to list available environment and analyses, for which the audits have been deleted, they are still listed. You can reestablish the audit without have to re-create the analysis. You will still see the data in the Kubex Console.

## Resource

```
/analysis/cloud/aws/
analysisId
```

## Endpoints

<CardGroup>
  <Card title="Delete Aws Analysis" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_AWS_Delete/deleteAwsAnalysis" />
</CardGroup>


# Delete AWS Cloud Connection and Analysis
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_AWS_Delete/deleteAwsAnalysis

openapi/public_cloud/Analysis_AWS_Delete.yaml DELETE /analysis/cloud/aws/{analysisId}
Deletes the Cloud Connection and Analysis for the specified AWS account. 

This API only supports deletion for AWS accounts that have a valid analysisId. If the AWS
account was not analyzed (for example, unsupported resources or insufficient data), no
analysisId exists and this API cannot be used. In those cases, delete the cloud connection
manually and contact support@kubex.ai if assistance is required.




# AWS Recommendations
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_AWS_Results



## Description

The `/analysis/cloud/aws/<analysisId>/results` resource is used to return a collection of AWS system (i.e. EC2 instance, Auto Scaling group, etc.) recommendations for an AWS account defined by a Kubex Analysis entity (see [Analysis: Entity](./Analysis_Entity)).

For each system recommendation, you can also download a PDF version of the Impact Analysis and Recommendation Report, which details system impact based on the recommendations. This report is useful to application owners and other system stakeholders who need to review recommended changes to their application resources. See the [rptHref](#_rptHref) resource element for details.

To return a collection of all systems included in an AWS optimization analysis, see [Analysis: AWS Systems](./Analysis_AWS_Systems).

To see the catalog map for a selected instance, see [Systems: Analysis Details](./Systems_Analysis_Details)

## Resource

```
/analysis/cloud/aws/
<analysisId>
/results
```

## Endpoints

<CardGroup>
  <Card title="Get Aws Recommendations" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_AWS_Results/getAwsRecommendations" />
</CardGroup>


# AWS recommendations using analysisId
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_AWS_Results/getAwsRecommendations

openapi/public_cloud/Analysis_AWS_Results.yaml GET /analysis/cloud/aws/{analysisId}/results
Returns optimization recommendations for systems (EC2, RDS, ASG) in the specified analysis. Use the `Accept` header to choose the representation: `application/json` (array of recommendation objects) or `application/terraform-map` (Terraform-style map where each key is the system's **provisioningId** or name). To include workload collection details per metric, use the `dataQuality` query. To include system attributes, set `includeAttributes=true`.




# Analysis: Azure Analyze
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Azure_Analyze



The `/analysis/azure/analyze` resource is used to collect Microsoft Azure infrastructure data and initiate optimization analysis with the collected data. The following processes occur when the first `/analysis/azure/analyze` request is triggered:

1. Set up and initiate data collection of the specified Azure subscription and schedule it to run automatically on a nightly basis.
2. Initiate analysis on the data collected using the default policy.
   * Subsequent analysis is scheduled to run on a nightly basis after the completion of data collection.
   * Optionally, you can configure the results to be sent to a webhook URI upon analysis completion. See [Add webhook to an analysis](./Analysis_Webhook#_AddWebhook) for details.
3. Once data collection succeeds and an `analysisId` is created for the subscription, you can track progress with `/analysis/cloud/azure/<analysisId>/status` or wait for the results to be published to an optional webhook URI. Subscriptions that have not produced an `analysisId` (for example, unsupported resources or insufficient data) cannot use the status endpoint until an analysis run begins.
4. The reporting database update is scheduled to run automatically on a nightly basis after the completion of the analysis. This process produces reports for each instance recommendation, which is useful for analysts or application owners. These reports are only created after the scheduled analysis is completed, and may therefore only be available on the following day for a new analysis. Exact timing depends on the size of your environment.

<Note>
  When onboarding a subscription using the `/analysis/cloud/azure/analyze` endpoint, receiving a 200 status code signals that the onboarding was successful.
</Note>

The `/analysis/cloud/azure` resource is also used to return a list of Microsoft Azure optimization analyses currently in Kubex.

#### Analysis Update

You can make an ad-hoc request to refresh an existing analysis, outside of the scheduled nightly run using `/analysis/cloud/<aws|azure|gcp>/analyze`. This manual, ad hoc analysis request does not perform data collection or reporting database updates. It only runs the analysis on the existing data collected with the following behavior:

* The analysis uses the policy that is configured for the analysis. Contact [support@kubex.ai](mailto:support@kubex.ai) to change the configured policy.
* If a new webhook is provided, the analysis will send results to the new webhook URI. If no webhook is provided, the analysis will send results to the existing webhook, if configured.
* If the same analysis is already running, the request does not proceed and an appropriate message is returned.
* If the specified analysis has data collection scheduled within 30 minutes, the request does not proceed and an appropriate message is returned. For example, if data collection is scheduled to run at 12:05 AM, and you initiate a manual, ad hoc analyze request at 11:45 PM, then the analysis will not proceed and an error message is returned.

### Prerequisite Configuration

Before you can collect Azure cloud infrastructure data in Kubex, you need to create a service principle and configure a secret key. See [Microsoft Azure Data Collection Prerequisites for a Service Principal](/docs/WebHelp_Densify_Cloud/Content/Data_Collection_for_Public_Cloud_Systems/Microsoft_Azure_Data_Collection_Prerequisites_for_a_Service_Principal) for details on creating and configuring the service principle.

<Note>
  When using the Kubex API only the Azure "Service Principal" can be used to connect to your Azure subscriptions.
</Note>

If you are using the API, data collection and analysis are created and then refreshed daily on a per subscription basis (1-to-1). You can associate many subscriptions with a service principle, but when using the API to initiate data collection, you must specify a subscription ID and the audit and analysis are created for each subscription, separately.

When using the Connection Wizard in the Kubex UI, you do not need the subscription ID, as all subscriptions that are associated with the service principle are collected and listed once the connection has been verified. You can then select one or more of the subscriptions that you want to analyze (1-to-Many). When using the Connection Wizard, data collection and analysis are created and then refreshed daily for all of the subscriptions that you selected when you created the connection.

<Note>
  When using the Kubex API only one subscription will be processed per API request. This is the case, even if more than one subscription is associated with the service principle.
</Note>

### Changing Credentials

When you need to change the credentials for the subscription or the service principle, you need to delete the data collection audit and recreate it. When you delete the audit, only the audit and all associated scheduler entries are removed, so you can recreate the audit with the new credentials and continue without any loss of data.

## Resource

```
/analysis/cloud/azure/analyze
```

```
/analysis/cloud/azure
```

## Endpoints

<CardGroup>
  <Card title="Analyze Azure" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Azure_Analyze/analyzeAzure" />
</CardGroup>

<CardGroup>
  <Card title="Get Azure Analyses Status" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Azure_Analyze/getAzureAnalysisStatus" />
</CardGroup>

<CardGroup>
  <Card title="List Azure Analyses" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Azure_Analyze/listAzureAnalyses" />
</CardGroup>


# Onboard Azure Subscription
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Azure_Analyze/analyzeAzure

openapi/public_cloud/Analysis_Azure_Analyze.yaml POST /analysis/azure/analyze
- **Initial run**: provide subscription and credentials; schedules nightly collection and analysis.  
- **Re-run analysis**: provide subscription and (optionally) a new webhook; does **not** collect data.  
- **Historical audit**: set `triggerAdhocAudit=true` and optionally `startDayOffset` / `endDayOffset` to collect up to 30 days of historical data.  
Notes: request is rejected if collection/analysis is in progress or within ~30 minutes of scheduled time.




# Get analysis status by subscription
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Azure_Analyze/getAzureAnalysisStatus

openapi/public_cloud/Analysis_Azure_Analyze.yaml GET /analysis/azure/{subscriptionId}/status
Check the status of collection/analysis for a given Azure subscription.



# List Azure subscriptions being analyzed
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Azure_Analyze/listAzureAnalyses

openapi/public_cloud/Analysis_Azure_Analyze.yaml GET /analysis/cloud/azure
Returns analyses created for Azure subscriptions; obtain `analysisId` for other operations.



# Analysis: Azure Delete
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Azure_Delete



The `/analysis/cloud/azure/<analysisId>` resource can be used to delete the audit and all associated scheduler entries of the cloud analysis specified by `<analysisId>`.

* The single-day and 60-day historical audits are removed, if they exist.
* The audit and all associated scheduler entries, are deleted, if they exist.

When executing the delete operation in an environment observe the following:

* When deleting an audit for an environment associated with a single account, the operation proceeds as outlined above.
* When deleting an audit, if Kubex determines that there is a many-to-one relationship for this connection, then the delete request fails. This type of multi-account connection can only be created through the Cloud Connection Wizard and must be deleted through the Cloud Connection Wizard.

During a delete operation, any attempt to access other associated endpoints related to the specified `<analysisId>` (i.e. GET, PUT, POST) will trigger a "400 Bad Request" error response.

While the delete operation is in progress, you can check the status (using the `/analysis/cloud/azure/<``analysisId``>/status` resource) or wait for the results to be published to an optional webhook URI.

Collected data is saved for the defined retention period and the environment and associated analysis structure are saved in case you want to generate reports on the historical data or restart data collection. Since the environment and analyses are not deleted, a GET call for the specified `<analysisId>` will always succeed regardless of whether the associated connection has been deleted.

If you use a GET call to list available environment and analyses, for which the audits have been deleted, they are still listed. You can reestablish the audit without have to re-create the analysis. You will still see the data in the Kubex Console.

## Resource

```
/analysis/cloud/azure/
analysisId
```

## endpoints

<CardGroup>
  <Card title="Delete Azure Analysis Audit" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Azure_Delete/deleteAzureAnalysisAudit" />
</CardGroup>


# Delete Azure Cloud Connection and Analysis
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Azure_Delete/deleteAzureAnalysisAudit

openapi/public_cloud/Analysis_Azure_Delete.yaml DELETE /analysis/cloud/azure/{analysisId}
Deletes the Cloud Connection and Analysis for the specified Azure subscription. 

This API only supports deletion for Azure subscriptions that have a valid analysisId. If the Azure
subscription was not analyzed (for example, unsupported resources or insufficient data), no
analysisId exists and this API cannot be used. In those cases, delete the cloud connection
manually and contact support@kubex.ai if assistance is required.




# Analysis: Azure Recommendations
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Azure_Results



The `/analysis/cloud/azure/<analysisId>/results` resource is used to return a collection of Azure Virtual Machine instance recommendations after the optimization analysis has been performed on your collected Azure infrastructure data.

For each instance recommendation, you can also download a PDF version of the Impact Analysis and Recommendation Report, which details system impact based on the recommendation. This report is useful to application owners who need to review recommended changes to their application resources. See the [rptHref](#_rptHref) resource element for details on how to download this report.

To return a collection of all instances included in an Azure optimization analysis, see [Analysis: Azure Systems](./Analysis_Azure_Systems).

To see the catalog map for a selected instance, see [Systems: Analysis Details](./Systems_Analysis_Details)

<Note>
  When using the Kubex API only one subscription is processed per analysis This is the case, even if more than one subscription is associated with the service principle. If the connection was created through the Cloud Connection wizard in the UI, all subscriptions that were selected, when the connection was created, and associated with the `<analysisId>`are returned.
</Note>

## Resource

```
/analysis/cloud/azure/
<analysisId>
/results
```

## endpoints

<CardGroup>
  <Card title="List Azure Recommendations" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Azure_Results/listAzureRecommendations" />
</CardGroup>


# List recommendations for an Azure analysis
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Azure_Results/listAzureRecommendations

openapi/public_cloud/Analysis_Azure_Results.yaml GET /analysis/cloud/azure/{analysisId}/results
Returns Azure recommendations for a completed analysis.

**Content negotiation**
- `Accept: application/json` → JSON recommendation objects
- `Accept: application/terraform-map` → Terraform-map objects

**Filtering**
- Element-based filters are supplied as ordinary query pairs named after fields
  (e.g., `recommendationType=Upsize`). Not all fields are filterable.

**Attributes/data quality**
- `includeAttributes=true` returns the `attributes` array.
- `dataQuality` accepts a quoted, comma-separated list of workload names.




# Analysis: GCP Analyze
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_GCP_Analyze



The `/analysis/gcp` resource is used to return a list of GCP optimization analyses currently in the Kubex system.

An analysis is generated for each GCP project associated with the provided GCP service account used during data collection.

The `/analysis/gcp/analyze` resource is used to collect Google Cloud Platform infrastructure data and initiate optimization analysis with the data collected. Below are the series of processes that occur when the initial `/analysis/gcp/analyze` request is triggered:

1. Set up and initiate data collection of the GCP projects based on the associated GCP service account and schedule it to run automatically on a nightly basis.
2. Initiate analysis on the data collected using the default policy.

* Subsequent analysis is scheduled to run on a nightly basis after data collection.
* You can optionally configure the results to be sent to a webhook URI upon analysis completion. See [Add webhook to an analysis](./Analysis_Webhook#_AddWebhook) for details.

3. Once data collection succeeds and an `analysisId` is created for the project, you can check progress via `/analysis/cloud/gcp/<analysisId>/status` or wait for the results to be published to an optional webhook URI. Projects that do not yet have an `analysisId` (for example, unsupported resources or insufficient data) must wait for an analysis run before the status endpoint becomes available.
4. The reporting database update is scheduled to run automatically on a nightly basis after the completion of the analysis. This process produces reports for each instance recommendation, which is useful for analysts or application owners. These reports are only created after the scheduled analysis is completed, and may therefore only be available on the following day for a new analysis. Exact timing depends on the size of your environment.

<Note>
  When onboarding a project using the `/analysis/cloud/gcp/analyze` endpoint, receiving a 200 status code signals that the onboarding was successful.
</Note>

#### Analysis Update

You can make an ad-hoc request to refresh an existing analysis, outside of the scheduled nightly run using `/analysis/cloud/<aws|azure|gcp>/analyze`. This manual, ad hoc analysis request does not perform data collection or reporting database updates. It only runs the analysis on the existing data collected with the following behavior:

* The analysis uses the policy that is configured for the analysis. Contact [support@kubex.ai](mailto:support@kubex.ai) to change the configured policy.
* If a new webhook is provided, the analysis will send results to the new webhook URI. If no webhook is provided, the analysis will send results to the existing webhook, if configured.
* If the same analysis is already running, the request does not proceed and an appropriate message is returned.
* If the specified analysis has data collection scheduled within 30 minutes, the request does not proceed and an appropriate message is returned. For example, if data collection is scheduled to run at 12:05 AM, and you initiate a manual, ad hoc analyze request at 11:45 PM, then the analysis will not proceed and an error message is returned.

### Prerequisite Configuration

Before you can collect GCP cloud infrastructure data in Kubex, you need to create a GCP service account with services enabled and permissions configured. See [Google Cloud Platform Data Collection Prerequisites](/docs/WebHelp_Densify_Cloud/Content/Data_Collection_for_Public_Cloud_Systems/Google_Cloud_Platform_Data_Collection_Prerequisites) for details.

<Note>
  When using the Kubex API only one project will be processed per API request. This is the case, even if more than one project is associated with the service account.
</Note>

## Resource

```
/analysis/gcp/analyze
```

```
/analysis/gcp
```

## endpoints

<CardGroup>
  <Card title="Analyze Gcp" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_GCP_Analyze/analyzeGcp" />
</CardGroup>

<CardGroup>
  <Card title="Historical Audit Gcp" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_GCP_Analyze/historicalAuditGcp" />
</CardGroup>

<CardGroup>
  <Card title="List Gcp Analyses" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_GCP_Analyze/listGcpAnalyses" />
</CardGroup>


# Run GCP data collection+analysis, or re-run analysis
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_GCP_Analyze/analyzeGcp

openapi/public_cloud/Analysis_GCP_Analyze.yaml POST /analysis/gcp/analyze
- **Initial run**: provide a GCP service account credential and `projectId`. Schedules
  nightly collection and analysis; can set `connectionName` and a `webHook`.
- **Re-run**: call again with the same `projectId` (+ optional new `webHook`); does **not**
  collect data.
- Request is rejected if collection/analysis is in progress or within ~30 minutes of the
  scheduled tasks.




# List all generated GCP analyses
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_GCP_Analyze/listGcpAnalyses

openapi/public_cloud/Analysis_GCP_Analyze.yaml GET /analysis/cloud/gcp
Return analyses with details and links; use this to obtain `analysisId` for other calls.



# Analysis: GCP Delete
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_GCP_Delete



The `/analysis/cloud/gcp/<analysisId>` resource can be used to delete the audit and all associated scheduler entries of the cloud analysis specified by `<analysisId>`.

* The single-day and 60-day historical audits are removed, if they exist.
* The audit and all associated scheduler entries, are deleted, if they exist.

When executing the delete operation in an environment observe the following:

* When deleting an audit for an environment associated with a single account, the operation proceeds as outlined above.
* When deleting an audit, if Kubex determines that there is a many-to-one relationship for this connection, then the delete request fails. This type of multi-account connection can only be created through the Cloud Connection Wizard and must be deleted through the Cloud Connection Wizard.

During a delete operation, any attempt to access other associated endpoints related to the specified `<analysisId>` (i.e. GET, PUT, POST) will trigger a "400 Bad Request" error response.

While the delete operation is in progress, you can check the status (using the `/analysis/cloud/gcp/<``analysisId``>/status` resource) or wait for the results to be published to an optional webhook URI.

Collected data is saved for the defined retention period and the environment and associated analysis structure are saved in case you want to generate reports on the historical data or restart data collection. Since the environment and analyses are not deleted, a GET call for the specified `<analysisId>` will always succeed regardless of whether the associated connection has been deleted.

If you use a GET call to list available environment and analyses, for which the audits have been deleted, they are still listed. You can reestablish the audit without have to re-create the analysis. You will still see the data in the Kubex Console.

## Resource

```
/analysis/cloud/gcp/
analysisId
```

## endpoints

<CardGroup>
  <Card title="Delete Gcp Analysis Audit" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_GCP_Delete/deleteGcpAnalysisAudit" />
</CardGroup>


# Delete GCP Cloud Connection and Analysis
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_GCP_Delete/deleteGcpAnalysisAudit

openapi/public_cloud/Analysis_GCP_Delete.yaml DELETE /analysis/cloud/gcp/{analysisId}
Deletes the Cloud Connection and Analysis for the specified GCP project. 

This API only supports deletion for GCP projects that have a valid analysisId. If the GCP
project was not analyzed (for example, unsupported resources or insufficient data), no
analysisId exists and this API cannot be used. In those cases, delete the cloud connection
manually and contact support@kubex.ai if assistance is required.




# Analysis: GCP Recommendations
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_GCP_Results



The `/analysis/cloud/gcp/<analysisId>/results` resource is used to return a collection of Compute Engine instance recommendations after optimization analysis has been performed on your collected GCP infrastructure data.

For each instance recommendation, you can also download a PDF version of the Impact Analysis and Recommendation Report, which details system impact based on the recommendations. This report is useful to application owners who need to review recommended changes to their application resources. See the [rptHref](#_rptHref) resource element for details on how to download this report.

To return a collection of all instances included in a GCP optimization analysis, see [Analysis: GCP Systems](./Analysis_GCP_Systems).

## Resource

```
/analysis/cloud/gcp/<analysisId>/results
```

## endpoints

<CardGroup>
  <Card title="List Gcp Recommendations" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_GCP_Results/listGcpRecommendations" />
</CardGroup>


# List recommendations for a GCP analysis
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_GCP_Results/listGcpRecommendations

openapi/public_cloud/Analysis_GCP_Results.yaml GET /analysis/cloud/gcp/{analysisId}/results
Returns a collection of recommendations.  
Content negotiation:
- `application/json` → JSON recommendation objects  
- `application/terraform-map` → terraform-map objects  
Element filters are standard query pairs (e.g., `recommendationType=Upsize`).  
`includeAttributes=true` returns the `attributes` array.  
`dataQuality` takes a quoted, comma-separated list of workload names; unsupported names yield 400.




# Analysis: Status
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Status



The `/analysis/<platformType>/<platformSubType>/<analysisId>/status` resource is used to return the current status of an analysis in Kubex.

## Resource

```
/analysis/<platformType>/<platformSubType>/<analysisId>/status
```

## endpoints

<CardGroup>
  <Card title="Get Analysis Status" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Status/getAnalysisStatus" />
</CardGroup>


# Analysis: Webhook
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Webhook



The `/webhook/analysis` resource is used to manage the webhook definition for a Kubex analysis. The webhook definition is the path and authentication to a third-party application, where recommendation results are sent when the analysis completes. The receiving application can process the resulting data for downstream consumption. For example, the receiving application can route recommendations to an orchestration engine or distribute reports to instance owners.

You can define the webhook when you initiate data collection and analysis with the `/analysis/<platformType>/<platformSubType>/analyze` request. See the example, [Run AWS data collection and analysis](./Analysis_AWS_Analyze#_runAnalysis) for details of specifying webhook input parameters. Results are posted to the webhook location when the analysis is complete. You can edit or delete a webhook at any time.

## Resource

```
/webhook/analysis
```

## endpoints

<CardGroup>
  <Card title="Add Analysis Webhook" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Webhook/addAnalysisWebhook" />
</CardGroup>

<CardGroup>
  <Card title="Delete Analysis Webhook" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Webhook/deleteAnalysisWebhook" />
</CardGroup>

<CardGroup>
  <Card title="Get Analysis Webhook" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Webhook/getAnalysisWebhook" />
</CardGroup>

<CardGroup>
  <Card title="List Analysis Webhook By Plataform" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Webhook/listAnalysisWebhooksByPlatform" />
</CardGroup>

<CardGroup>
  <Card title="Update Analysis Webhook" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Webhook/updateAnalysisWebhook" />
</CardGroup>


# Add webhook to an analysis
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Webhook/addAnalysisWebhook

openapi/public_cloud/Analysis_Webhook.yaml POST /webhook/analysis/{platformType}/{platformSubType}/{analysisId}
Only allowed if the analysis does not already have a webhook.



# Delete webhook from an analysis
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Webhook/deleteAnalysisWebhook

openapi/public_cloud/Analysis_Webhook.yaml DELETE /webhook/analysis/{platformType}/{platformSubType}/{analysisId}



# Get webhook definition for an analysis
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Webhook/getAnalysisWebhook

openapi/public_cloud/Analysis_Webhook.yaml GET /webhook/analysis/{platformType}/{platformSubType}/{analysisId}



# List webhooks by platform
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Webhook/listAnalysisWebhooksByPlatform

openapi/public_cloud/Analysis_Webhook.yaml GET /webhook/analysis/{platformType}
List all analysis webhooks for a platform (cloud or containers).



# Update webhook for an analysis
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Webhook/updateAnalysisWebhook

openapi/public_cloud/Analysis_Webhook.yaml PUT /webhook/analysis/{platformType}/{platformSubType}/{analysisId}



# Authorize
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Authorize



The `authorize` resource is used to obtain a JSON Web Token (JWT) for Kubex users to make authorized API requests. The resource will return a token for any active Kubex user when the proper credentials are provided. Only API-enabled users can make authorized API calls. See [Using the API: Authentication](./Using_the_API#_Authentication) for details on API-enabled users.

The JWT API token is only valid within the expiry time of the token, which by default is set to 60 minutes.

The key used to validate the token is also refreshed every 30 days.

<Note>
  To access the Kubex API, you need user credentials with membership in the following Kubex user group: SaaS\_User\_Admin.or SaaS\_User.
</Note>

## Security Considerations

The authorization workflow provides a progressively longer delay each time an invalid password is entered in an Authorize request.

This behaviour is applied regardless of whether or not you have enabled the Kubex password policy. The workflow does change if the password policy has been enabled. Contact [support@kubex.ai](mailto:support@kubex.ai) for details.

Contact [support@kubex.ai](mailto:support@kubex.ai) for details on configuring the Kubex password policy.

## Resource

```
/authorize
```

## Endpoints

<CardGroup>
  <Card title="Authorize User" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Authorize/authorize-user" />
</CardGroup>


# Obtain a JWT API token
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Authorize/authorize-user

openapi/authorize.yaml POST /authorize
Returns a JWT token for any **active** Kubex user when valid credentials are provided.
Only tokens for **API-enabled** users can be used to make authorized API calls.




# Compatible Instances
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/CatalogMap



Returns the list of all instance types that the given instance (input parameter=entity\_id) is compatible with.

## Resource

```
https://<kubex_instance_name>/api/v2/systems/{{entityId}}/analysis-details?target=compatible_instances/&spendTolerance=1.5&effort_tolerance=low
```

### Optional parameters:

#### Spend Tolerance

Specified in terms of a multiplier. E.g., 1.3 means all compatible instance types that are less that 1.3 times
the optimal instance type cost.

##### Resource

```
https://<kubex_instance_name>/api/v2/systems/{{entityId}}/analysis-details?target=compatible_instances/&spendTolerance=1.3
```

#### Effort Tolerance

Used to only return compatible instance types that are at the provided effort level or lower. Possible values are 'none','low','medium','high'

##### Resource

```
https://<kubex_instance_name>/api/v2/systems/{{entityId}}/analysis-details?target=compatible_instances/&spendTolerance=1.3&effort_tolerance=low
```


# Introduction
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Introduction



The Kubex API is a REST-based web service that is designed for the following:

* Kubernetes Container Recommendations
* AWS - Onboard new accounts and retrieve Kubex right-sizing recommendations
* Azure - Onboard new subscriptions and retrieve Kubex right-sizing recommendations
* GCP - Onboard new projects and retrieve Kubex right-sizing recommendations
* Catalog Map - Get a list of how all instance types scored for a given instance
* Analysis webhook
* Subscriptions (customizable analysis results API)


# Kubernetes Clusters
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Kubernetes_Clusters



This resource is used to return all clusters, as specified in the data forwarder.

No filtering is applied.

This endpoint does not require the analysis ID that is required when using the [`/systems`](./Analysis_Kubernetes_Systems) and [`/results`](./Analysis_Kubernetes_Results) endpoints.

## Resources

* `/kubernetes/clusters`
* `/kubernetes/clusters/<clusterName>`

## endpoints

<CardGroup>
  <Card title="List Kubernetes Clusters" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Kubernetes_Clusters/listKubernetesClusters" />
</CardGroup>

<CardGroup>
  <Card title="Get Kubernetes Cluster Details" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Kubernetes_Clusters/getKubernetesClusterDetails" />
</CardGroup>


# Get details for a Kubernetes cluster
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Kubernetes_Clusters/getKubernetesClusterDetails

openapi/kubernetes/kubernetes_clusters.yaml GET /kubernetes/clusters/{clusterName}
Returns namespaces, pods, and containers for the specified cluster.



# List Kubernetes clusters
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Kubernetes_Clusters/listKubernetesClusters

openapi/kubernetes/kubernetes_clusters.yaml GET /kubernetes/clusters
Returns all clusters from which data is being collected. No filtering is applied.



# Kubernetes Clusters Results
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Kubernetes_Clusters_Results



This resource is used to return container recommendations at the cluster level. This endpoint shows all analyzed containers in the specified cluster.

## Resources

* `/kubernetes/clusters/<clusterName>/containers`
* `/analysis/containers/kubernetes/clusters/<clusterName>/containers?details=true`

## endpoints

<CardGroup>
  <Card title="Get Kubernetes Cluster Containers" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Kubernetes_Clusters_Results/getKubernetesClusterContainers" />
</CardGroup>

<CardGroup>
  <Card title="Get Kubernetes Cluster Containers Details" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Kubernetes_Clusters_Results/getKubernetesClusterContainersDetailed" />
</CardGroup>


# List container recommendations for a cluster
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Kubernetes_Clusters_Results/getKubernetesClusterContainers

openapi/kubernetes/kubernetes_clusters_results.yaml GET /kubernetes/clusters/{clusterName}/containers
Returns recommendation details for container manifests in the specified cluster.
This endpoint returns the base set of fields. For additional details including uptime predictions,
OOM kill counts, and audit history, use the detailed endpoint with details=true.
Fields with no value may be omitted from the response.


## Overview

This endpoint returns container recommendation details for a specific cluster. This is the **base response format** without additional details.

For extended information including uptime predictions, OOM kill counts, node group associations, and audit history, use the detailed endpoint with `details=true`. See [getKubernetesClusterContainersDetailed](/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Kubernetes_Clusters_Results/getKubernetesClusterContainersDetailed) for more information.

## Example Request

```bash theme={null}
curl -X GET "https://api.example.com/api/v2/kubernetes/clusters/my-cluster/containers" \
  -H "Authorization: Bearer YOUR_API_TOKEN"
```

## Example Response

```json theme={null}
[
  {
    "cluster": "my-cluster",
    "namespace": "production",
    "podOwnerName": "web-app",
    "podOwnerKind": "Deployment",
    "container": "nginx",
    "entityId": "abc123",
    "containerId": "def456",
    "avgContainerCount": 3,
    "currentCpuRequestmCores": 500,
    "currentCpuLimitmCores": 1000,
    "currentMemRequestBytes": 536870912,
    "currentMemLimitBytes": 1073741824,
    "recommendedCpuRequestmCores": 300,
    "recommendedCpuLimitmCores": 600,
    "recommendedMemRequestBytes": 268435456,
    "recommendedMemLimitBytes": 536870912,
    "estimatedSavingsPerContainer": 45.50,
    "analyzedOn": "2026-06-08T10:30:00Z",
    "hpaMetricName": "cpu",
    "hpaMetricThreshold": "75%",
    "currentEphemeralStorageRequestBytes": 1073741824,
    "currentEphemeralStorageLimitBytes": 2147483648,
    "recommendedEphemeralStorageRequestBytes": 536870912,
    "recommendedEphemeralStorageLimitBytes": 1073741824
  }
]
```

<Note>
  Fields without values may be omitted from the response. All timestamps are in UTC format (`YYYY-MM-DDTHH:mm:ssZ`).
</Note>

## Need More Details?

If you need additional fields such as:

* Predicted uptime percentage
* Configuration change history
* Node group associations
* OOM kill events
* Audit timeline information

Use the [detailed endpoint](/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Kubernetes_Clusters_Results/getKubernetesClusterContainersDetailed) by adding `?details=true` to your request.


# List container recommendations with additional details
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Kubernetes_Clusters_Results/getKubernetesClusterContainersDetailed

openapi/kubernetes/kubernetes_clusters_results.yaml GET /kubernetes/clusters/{clusterName}/containers?details=true
Returns recommendation details for container manifests in the specified cluster with additional fields.
This endpoint includes all base fields plus: predictedUptime, configLastChangedOn, nodeGroup,
oomKills_last7days, dateFirstAudited, and dateLastAudited.
Fields with no value may be omitted from the response.


## Overview

This endpoint returns container recommendation details for a specific cluster with **additional fields** when `details=true` is included.

For the base response format without additional details, see [getKubernetesClusterContainers](/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Kubernetes_Clusters_Results/getKubernetesClusterContainers).

## Additional Fields with details=true

When you include `details=true` in the query parameters, the following additional fields are included in each container recommendation:

<Accordion title="Additional Fields Reference">
  | Field                 | Type               | Description                                                   |
  | --------------------- | ------------------ | ------------------------------------------------------------- |
  | `predictedUptime`     | number (float)     | Predicted uptime percentage for the container                 |
  | `configLastChangedOn` | string (date-time) | Timestamp of the most recent change to requests/limits        |
  | `nodeGroup`           | array of strings   | Names of associated node groups                               |
  | `oomKills_last7days`  | integer            | Number of OOM (Out Of Memory) events in the last 7 days       |
  | `dateFirstAudited`    | string (date-time) | When this container was first audited (from workload history) |
  | `dateLastAudited`     | string (date-time) | When this container was last audited (from workload history)  |
</Accordion>

## Example Request

```bash theme={null}
curl -X GET "https://api.example.com/api/v2/kubernetes/clusters/my-cluster/containers?details=true" \
  -H "Authorization: Bearer YOUR_API_TOKEN"
```

## Example Response

```json theme={null}
[
  {
    "cluster": "my-cluster",
    "namespace": "production",
    "podOwnerName": "web-app",
    "podOwnerKind": "Deployment",
    "container": "nginx",
    "entityId": "abc123",
    "containerId": "def456",
    "avgContainerCount": 3,
    "currentCpuRequestmCores": 500,
    "currentCpuLimitmCores": 1000,
    "currentMemRequestBytes": 536870912,
    "currentMemLimitBytes": 1073741824,
    "recommendedCpuRequestmCores": 300,
    "recommendedCpuLimitmCores": 600,
    "recommendedMemRequestBytes": 268435456,
    "recommendedMemLimitBytes": 536870912,
    "estimatedSavingsPerContainer": 45.50,
    "analyzedOn": "2026-06-08T10:30:00Z",
    "hpaMetricName": "cpu",
    "hpaMetricThreshold": "75%",
    "currentEphemeralStorageRequestBytes": 1073741824,
    "currentEphemeralStorageLimitBytes": 2147483648,
    "recommendedEphemeralStorageRequestBytes": 536870912,
    "recommendedEphemeralStorageLimitBytes": 1073741824,
    
    // Additional fields when details=true
    "predictedUptime": 99.8,
    "configLastChangedOn": "2026-05-15T14:20:00Z",
    "nodeGroup": ["node-group-1", "node-group-2"],
    "oomKills_last7days": 2,
    "dateFirstAudited": "2026-01-10T08:00:00Z",
    "dateLastAudited": "2026-06-08T10:30:00Z"
  }
]
```

## Use Cases

The detailed fields are particularly useful for:

* **Stability Monitoring**: `oomKills_last7days` helps identify containers experiencing memory pressure
* **Change Tracking**: `configLastChangedOn` shows when resource configurations were last modified
* **Historical Analysis**: `dateFirstAudited` and `dateLastAudited` provide audit timeline context
* **Infrastructure Planning**: `nodeGroup` information helps with placement and scaling decisions
* **Reliability Metrics**: `predictedUptime` aids in understanding container availability patterns

<Note>
  Fields without values may be omitted from the response. All timestamps are in UTC format (`YYYY-MM-DDTHH:mm:ssZ`).
</Note>


# AI Tools: MCP Server
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/MCP



## Model Context Protocol

The Model Context Protocol, or MCP, is a standard that allows Large Language Models (LLMs) to securely access external systems,
tools, and data sources. By connecting through MCP, an LLM can retrieve real-time information and take structured actions,
extending its usefulness beyond static chat interactions. In practice, this means that an LLM can integrate live data
from trusted systems into its reasoning process, enabling more informed and actionable responses.

## Kubex MCP

Kubex MCP extends this capability to your cloud and container environments. It gives LLMs access to detailed operational
information about containers, nodes, and cloud instances, including Kubex optimization recommendations.
You can use a chat-based LLM interface to review key optimization insights, identify risks, and plan remediation
steps interactively. You can also use an LLM-based coding tool to apply Kubex recommendations directly to your
infrastructure-as-code definitions.

## Getting Started

### LLM Clients

To get started with Kubex MCP, you must use an LLM client that supports the Model Context Protocol.
You can choose an existing LLM client application or build your own. Kubex MCP should work with any LLM
client that supports MCP.

Common chat interfaces that support MCP include Anthropic Claude and ChatGPT when Developer Mode is enabled.
Coding-oriented clients such as Cursor, Claude Code, and Gemini CLI also provide MCP support.

Alternatively, you can develop your own LLM-based agent using MCP. This approach requires significant
development expertise and should only be attempted if you are comfortable building and maintaining your own
software. Frameworks such as Microsoft Copilot Studio and Pydantic AI provide a useful starting point for
developers who want to build their own MCP-enabled systems.

### Configuring Your Client

#### General

Each company has a unique Kubex MCP server endpoint. The MCP server URL follows a consistent pattern based on your company dashboard address.

* If your Kubex dashboard is [https://corp.kubex.ai](https://corp.kubex.ai/), your MCP server URL is [https://corp-mcp.kubex.ai](https://corp-mcp.kubex.ai/).
* If your organization uses a densify.com host such as [https://corp.densify.com/kubex](https://corp.densify.com/kubex), use the corresponding MCP URL: [https://corp-mcp.densify.com](https://corp-mcp.densify.com/).

Kubex MCP supports the streamable HTTP transport, using OAuth 2.1 with dynamic client registration for authentication.

#### Claude

##### Claude for Web (Claude.ai):

Navigate to the [connectors](https://claude.ai/customize/connectors) page and connect Kubex.

##### Claude Desktop:

From Claude Settings, go to Connectors and add the Kubex connector.

##### Claude Code:

Run the following command:

```bash theme={null}
claude mcp add --transport http kubex https://corp-mcp.kubex.ai/
```

Then run `/mcp` after you open a Claude Code session to sign in with your Kubex account and connect it to Claude Code.

#### Codex

The setup steps for the MCP server apply to both the IDE extension and the CLI because the configuration is shared.

Run the following command in your terminal:

```bash theme={null}
codex mcp add kubex --url https://corp-mcp.kubex.ai/
```

You will be prompted to sign in with your Kubex account and connect it to Codex.

#### Cursor

1. Press `Ctrl/Cmd + ,` to open settings.
2. Go to the **Tools & MCPs** tab.
3. Click **Add Custom MCP Server**.
4. Add the following configuration (replace the URL with your Kubex MCP URL):

```json theme={null}
{
	"mcpServers": {
		"kubex": {
			"command": "npx",
			"args": ["-y", "mcp-remote", "https://corp-mcp.kubex.ai/"]
		}
	}
}
```

You may need to restart Cursor for the MCP tools to appear in chat.

#### Visual Studio Code

1. Press `Shift + Ctrl/Cmd + P` and search for **MCP: Add Server**.
2. Select **HTTP**.
3. Enter your Kubex MCP URL and use `kubex` as the server name.
4. Authorize access to your Kubex instance when prompted.
5. Activate the server through **MCP: List Servers**, select `kubex`, then select **Start Server**.

You may need to restart Visual Studio Code for the MCP tools to appear in chat.

#### Devin Desktop (formerly Windsurf)

1. Press `Ctrl/Cmd + ,` to open settings.
2. Scroll to **Devin Local -> MCP servers**.
3. Select **Open Devin MCP marketplace -> Add custom MCP**.
4. Add the following configuration (replace the URL with your Kubex MCP URL):

```json theme={null}
{
	"mcpServers": {
		"kubex": {
			"command": "npx",
			"args": ["-y", "mcp-remote", "https://corp-mcp.kubex.ai/"]
		}
	}
}
```

Return to the Devin MCP marketplace and click **Connect** to authorize with Kubex.

#### Zed

1. Press `Ctrl/Cmd + ,` to open Zed settings.
2. Add the following configuration (replace the URL with your Kubex MCP URL):

```json theme={null}
{
	"context_servers": {
		"kubex": {
			"source": "custom",
			"command": "npx",
			"args": ["-y", "mcp-remote", "https://corp-mcp.kubex.ai/"],
			"env": {}
		}
	}
}
```

#### Others

Many other tools now support MCP servers. You can configure Kubex MCP with the following settings (replace the URL with your Kubex MCP URL):

* Command: `npx`
* Arguments: `-y mcp-remote https://corp-mcp.kubex.ai/`
* Environment: `None`

## Authorization

Access to Kubex data through MCP is tightly controlled. Only users who have been properly authenticated and who have explicitly authorized their LLM client application are allowed to retrieve or act on data. Authorization is temporary and must be refreshed daily for security reasons.

Some client applications handle expired authorizations gracefully, automatically prompting for reauthorization when required. Others may not, which can lead to connection errors or incomplete responses. If you encounter these issues, the solution is usually to manually reconnect and reauthorize your client with the Kubex MCP server.

## Security

Because MCP allows direct integration between an LLM and your operational environment, it is essential to treat security as a first priority. You should only connect to MCP servers that you trust. A malicious MCP server could attempt to manipulate an LLM into revealing sensitive information or performing unwanted actions.

Kubex guarantees that the Kubex MCP server is secure and trustworthy. It is designed to provide authorized users with access to relevant data and recommendations without compromising system integrity or user privacy. However, Kubex cannot make any guarantees about the behavior of third-party MCP servers. If you choose to use additional MCP connections, you do so at your own risk and should apply standard best practices for verifying the legitimacy and security of external systems.


# Ping API
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Ping



The `/ping` resource is used to check the status of the Kubex API subsystem. No credentials are required for this resource to validate the API subsystem. A ping API call performs an end-to-end test from the client to the API subsystem, ensuring that the Kubex database is available and is able to respond to requests. Network elements, such as load balancers, can use this resource to verify that the web server receiving the request can be kept as an active participant in the resource pool.

## Resource

```
/CIRBA/api/ping
```

## Endpoints

<CardGroup>
  <Card title="Ping" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Ping/ping" />
</CardGroup>


# Ping Kubex API subsystem
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Ping/ping

openapi/ping.yaml GET /ping
End-to-end connectivity check to ensure the API subsystem
and database are reachable.




# Postman Collection
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Postman_Collection



## Postman Collection

Kubex provides a Postman collection of sample API requests for public cloud and containers.

<Card title="Download the Kubex Public Cloud Postman Collection (v2)" href="/docs-api/WebHelp_Densify_API_Cloud/Content/Resources/Collections/DensifyCCO_PostmanCollection.txt" icon="download" />

Follow the steps below to use the downloaded Postman collection:

1. Unzip the downloaded file and import both the **Kubex API Collection** collection and **Kubex Environment** variables into your Postman workspace.

2. Modify the variables in the **Kubex Environment** to match your Kubex settings and credentials.

   <Note>
     If you already have a **Kubex** environment in your Postman application, you can either delete the previous version or rename it. Otherwise, you will have duplicate Kubex environments after the new collection is imported.
   </Note>

3. Review the **Documentation** section of the collection for an overview of the workflow and API requests.

4. Use this sample collection to familiarize yourself with Kubex API requests.

### Troubleshooting the Postman Collection

<AccordionGroup>
  <Accordion title="Token Requests">
    When using token-based authentication you need to request a token for each session. Subsequent API requests within the session are automatically authenticated with this token. Then in a future session you need to again request and acquire a token.

    Postman is only intended to provide the tools for learning and testing Kubex APIs.

    Once you are comfortable with how the Kubex API works you can start to place the API calls within your code, used to interface with Kubex. For example you could write a call to get all analysis IDs, then loop through each ID making another API call to get the associated recommendations, thus providing the full list of recommendations for the scope of systems.
  </Accordion>

  <Accordion title="&#x22;Bad request, invalid accept header&#x22; Error">
    If you use Postman v9.x or later you may encounter a "Bad request, invalid accept header" error. This is due to the fact that the Kubex API does not currently support the **Accept** key value "\*/" for **Headers**.

    Set the **Accept** key value to "application/json".

    <Accordion title="Figure: Postman Header Configuration">
      <img alt="" />
    </Accordion>
  </Accordion>
</AccordionGroup>


# Subscriptions
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions



The `/subscriptions/<platformType>` resource is used to create and manage subscription-based notifications for Kubex cloud and container recommendations.

To learn more watch the video,

<iframe />

This resource allows you to set up and schedule the delivery of personalized Kubex recommendations to a third-party application for targeted distribution.

Personalization of the recommendation data set (returned subscription notification output) is facilitated by the following mechanisms:

* Return only the systems you are interested in by specifying system attribute conditions with the [tagReferences](#tagReferences) parameter.
* Return only specific recommendations you are interested in by specifying recommendation property conditions with the [propertyReferences](#propertyReferences) parameter.
* Suppress certain systems or recommendations in the returned output, for a period of time, with the [suppressionReferences](#suppressionReferences) parameter.
* Finally, the fields and attributes displayed in the returned output can be customized with the [returnStructure](#returnStructure) parameter. You can specify which recommendation field to display and whether to display the field name or the field alias as the element key.

Subscription notifications are delivered to a third party application, such as Microsoft Teams™ or Slack™, using the [webhook](#webhook)  definition. If you do not specify a webhook in your Subscriptions definition, the notifications are not triggered because there is no delivery location. See [Subscriptions: Status](./Subscriptions_Status) for details on Subscriptions results and webhook status.

You can dynamically retrieve the current personalized Subscriptions recommendations by providing a subscription ID in the GET subscription request. See [Subscriptions: Results](./Subscriptions_Results) for details on retrieving Subscriptions results on-demand.

You can also schedule the frequency of the notification distribution using the [schedule](#schedule) definition parameter. Subscriptions without a schedule definition will typically have notifications triggered nightly after recommendation analysis and reporting database updates.

## Resource

```
/subscriptions/cloud
```

```
/subscriptions/containers
```

```
/subscriptions
```

<Note>
  If you use this resource without the `<platformType>` specified (i.e. without `cloud` or `containers` specified), the behavior is exactly the same as specifying the `cloud`-specific resource. This behavior enables backward compatibility with scripts using the Kubex API prior to release 12.1.6, where the platform-specific indicator was not available.
</Note>

## endpoints

<CardGroup>
  <Card title="Create Subscriptions" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions/createSubscriptions" />
</CardGroup>

<CardGroup>
  <Card title="Delete Subscription" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions/deleteSubscription" />
</CardGroup>

<CardGroup>
  <Card title="Delete Subscriptions" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions/deleteSubscriptions" />
</CardGroup>

<CardGroup>
  <Card title="List Subscriptions" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions/listSubscriptions" />
</CardGroup>

<CardGroup>
  <Card title="Lsit Subscriptions Default Platform" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions/listSubscriptionsDefaultPlatform" />
</CardGroup>

<CardGroup>
  <Card title="Replace Subscriptions" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions/replaceSubscription" />
</CardGroup>


# Create subscriptions (bulk)
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions/createSubscriptions

openapi/public_cloud/Subscriptions.yaml POST /subscriptions/{platformType}
Creates a **collection** of platform-specific subscriptions in one request. The operation
is committed as a whole: any creation failure rolls back the entire batch. Non-admin users
are auto-assigned as `owner`; admins may create global (owner="") or assign any owner. 




# Delete a single subscription
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions/deleteSubscription

openapi/public_cloud/Subscriptions.yaml DELETE /subscriptions/{platformType}/{subscriptionRef}



# Delete subscriptions (bulk)
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions/deleteSubscriptions

openapi/public_cloud/Subscriptions.yaml DELETE /subscriptions/{platformType}
Deletes a **collection** of subscriptions by ID. Each delete is independent; an error on one
does not affect others. Success returns **204 No Content**; **404 Not Found** if a sub doesn't
exist or you lack privilege (non-owner, non-admin). Admins may delete any global/private subs. 




# List subscriptions for a platform
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions/listSubscriptions

openapi/public_cloud/Subscriptions.yaml GET /subscriptions/{platformType}
Returns a list of existing platform-specific subscriptions. Filters:
- `type` → all | global | owner
- `owner` (admin only) → list another user's private subs with `type=owner`
- `subscriptionRef` → return a single subscription by ID. 




# List subscriptions (alias of /subscriptions/cloud)
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions/listSubscriptionsDefaultPlatform

openapi/public_cloud/Subscriptions.yaml GET /subscriptions
Behaves the same as `GET /subscriptions/cloud`. Backward compatibility alias.



# Replace an existing subscription (full PUT)
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions/replaceSubscription

openapi/public_cloud/Subscriptions.yaml PUT /subscriptions/{platformType}/{subscriptionRef}
Replaces **all** parameters of an existing subscription. You must supply all body parameters
required by the existing subscription. Non-admin users can only modify their own private subs;
admins can also promote private→global by setting `owner: ""`. 




# Subscriptions: Properties
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Properties



The `/subscriptions/<platformType>/properties` resource is used to store a list of recommendation properties available to the [Subscriptions](./Subscriptions) resource for the purpose of filtering recommendations from the resulting subscription data set.

This resource acts as a catalog of recommendation properties to be referenced by the [propertyReferences](./Subscriptions#propertyReferences) parameter in a subscription. Properties not defined in the `/subscriptions/<platformType>/properties` resource, cannot be referenced by a subscription property filter condition. See [Subscriptions](./Subscriptions) for details on defining a subscription and using property filter conditions.

There is a catalog for each supported `<platformType>`, which can only be referenced by the corresponding `<platformType>` subscription. For example, a container subscription (i.e. `/subscriptions/containers`) can only reference properties from the Container Subscriptions Properties catalog (i.e. `/subscriptions/containers/properties`).

Kubex provides a default set of properties for each `<platformType>` catalog. You can extend these default sets by adding additional properties, or you can customize the sets by modify or deleting existing properties.

For the full set of available properties to add to the Cloud Subscriptions Properties catalog, refer to the cloud recommendation response schema:

* See [Analysis: AWS Recommendations: Response](./Analysis_AWS_Results#_ResultElements) for a list of all the recommendation elements available for the AWS instances.
* See [Analysis: Azure Recommendations: Response](./Analysis_Azure_Results#_ResultElements) for a list of all the recommendation elements available for the Azure instances.
* See [Analysis: GCP Recommendations: Response](./Analysis_GCP_Results#_ResultElements) for a list of all the recommendation elements available for the GCP instances.

See [Default Cloud Properties](#DefaultProperties) for the list of default cloud properties.

<Note>
  Some recommendation elements are not common to all technologies. It is good practice to indicate the technology for an element that is technology-specific in the [aliasName](#aliasName) (e.g. aliasName = "AWS minGroupRecommended"). This practice is helpful when you use the Cloud Subscriptions Properties catalog to form property conditions.
</Note>

For the full set of available properties to add to the Container Subscriptions Properties catalog, refer to the container recommendation response schema:

* See [Analysis: Kubernetes Container Recommendations: Response](./Analysis_Kubernetes_Results#_ResultElements) for a list of all the recommendation elements available for Kubernetes containers.

See [Default Container Properties](#containerDefaultProperties) for the list of default cloud properties.

Properties in the platform-specific Subscriptions Properties catalogs can be declared as: global or private (i.e. user-specific). Global properties can be used by any API enabled user, while private properties can only be used by their owners. An exception to this rule is that <Tooltip>administrative users</Tooltip> have access to all properties - global or private user-specific.

## Resource

```
/subscriptions/cloud/properties
```

```
/subscriptions/containers/properties
```

```
/subscriptions/properties
```

<Note>
  If you use this resource without the `<platformType>` specified (i.e. without `cloud` or `containers` specified), the behavior is exactly the same as specifying the `cloud`-specific resource. This behavior enables backward compatibility with scripts using the Kubex API prior to release 12.1.6, where the platform-specific indicator was not available.
</Note>

## endpoints

<CardGroup>
  <Card title="Add Subscriptions Properties" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Properties/addSubscriptionProperties" />
</CardGroup>

<CardGroup>
  <Card title="Delete Subscriptions Properties" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Properties/deleteSubscriptionProperties" />
</CardGroup>

<CardGroup>
  <Card title="Delete Subscriptions Property" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Properties/deleteSubscriptionProperty" />
</CardGroup>

<CardGroup>
  <Card title="Get Subscriptions Property" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Properties/getSubscriptionProperty" />
</CardGroup>

<CardGroup>
  <Card title="List Subscriptions Properties" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Properties/listSubscriptionProperties" />
</CardGroup>

<CardGroup>
  <Card title="Get Subscriptions Properties Default Plat" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Properties/listSubscriptionPropertiesDefaultPlatform" />
</CardGroup>

<CardGroup>
  <Card title="Replace Subscriptions Properties" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Properties/replaceSubscriptionProperties" />
</CardGroup>

<CardGroup>
  <Card title="Replace Subscriptions Property" href="/docs-api\WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Properties/replaceSubscriptionProperty" />
</CardGroup>


# Add properties (bulk)
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Properties/addSubscriptionProperties

openapi/public_cloud/Subscriptions_Properties.yaml POST /subscriptions/{platformType}/properties
Adds one or more properties to the platform catalog.  
Bulk add is all-or-nothing; a single error rolls back the set.  
`propertyName` must be unique within the catalog; `aliasName` uniqueness depends on scope
(global vs private). Platform-specific properties must be added to their matching catalog.




# Delete properties (bulk)
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Properties/deleteSubscriptionProperties

openapi/public_cloud/Subscriptions_Properties.yaml DELETE /subscriptions/{platformType}/properties
Deletes a collection of properties by ID.  
Each delete is independent; errors for some IDs do not affect others.  
Properties referenced by subscriptions cannot be deleted.




# Delete a property by ID
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Properties/deleteSubscriptionProperty

openapi/public_cloud/Subscriptions_Properties.yaml DELETE /subscriptions/{platformType}/properties/{propertyRef}
Returns 204 on success; 404 if not found; if referenced by a subscription, returns `propertyRef`, `message`, and `status`.



# Get a property by ID
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Properties/getSubscriptionProperty

openapi/public_cloud/Subscriptions_Properties.yaml GET /subscriptions/{platformType}/properties/{propertyRef}



# List properties in the platform catalog
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Properties/listSubscriptionProperties

openapi/public_cloud/Subscriptions_Properties.yaml GET /subscriptions/{platformType}/properties



# List properties (alias of cloud)
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Properties/listSubscriptionPropertiesDefaultPlatform

openapi/public_cloud/Subscriptions_Properties.yaml GET /subscriptions/properties



# Replace existing properties (bulk PUT)
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Properties/replaceSubscriptionProperties

openapi/public_cloud/Subscriptions_Properties.yaml PUT /subscriptions/{platformType}/properties
Replaces parameters for existing properties.  
You must supply all parameters required by each property.  
Admins may promote private→global by setting `owner: ""`. Bulk edit is all-or-nothing.




# Replace a property by ID (full PUT)
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Properties/replaceSubscriptionProperty

openapi/public_cloud/Subscriptions_Properties.yaml PUT /subscriptions/{platformType}/properties/{propertyRef}
Admins can promote private→global (`owner: ""`); non-admins can only set `owner` to themselves.



# Subscriptions: Results
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Results



The `/subscriptions/<platformType>/<subscriptionRef>` resource is used to dynamically retrieve your latest personalized Kubex subscription recommendations. This resource allows you to review your platform-specific subscription results on-demand. The same information is delivered to a third-party application for targeted distribution if the third-party application is defined in the subscription's webhook.

To see how subscriptions are defined, refer to [Subscriptions](./Subscriptions).

## Resource

```
/subscriptions/cloud/<subscriptionRef>
```

```
/subscriptions/containers/<subscriptionRef>
```

```
/subscriptions/<subscriptionRef>
```

<Note>
  If you use this resource without the `<platformType>` specified (i.e. without `cloud` or `containers` specified), the behavior is exactly the same as specifying the `cloud`-specific resource. This behavior enables backward compatibility with scripts using the Kubex API prior to release 12.1.6, where the platform-specific indicator was not available.
</Note>

## endpoints

<CardGroup>
  <Card title="Get Subscriptions Results" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Results/getSubscriptionResults" />
</CardGroup>

<CardGroup>
  <Card title="Get Subscriptions Results Default Plat" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Results/getSubscriptionResultsDefaultPlatform" />
</CardGroup>


# Get subscription results (on-demand)
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Results/getSubscriptionResults

openapi/public_cloud/Subscriptions_Results.yaml GET /subscriptions/{platformType}/{subscriptionRef}
Returns the current results for the specified subscription.  
Notes for on-demand calls: `active`, `webhook`, and `schedule` are ignored (results are always returned).  
Optional `divider` controls whether a divider string is included between properties and tags.  
`limit` controls the maximum number of returned systems (default 3000; range 1–30000). 




# Get subscription results (alias of cloud)
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Results/getSubscriptionResultsDefaultPlatform

openapi/public_cloud/Subscriptions_Results.yaml GET /subscriptions/{subscriptionRef}



# Subscriptions: Status
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Status



The `/subscriptions/<platformType>/<subscriptionId>/status` resource is used to return the status of the results posted to a webhook for a specific subscription in Kubex.

Refer to [Subscriptions](./Subscriptions) for details on subscription results and defining a webhook.

## Resource

```
/subscriptions/cloud/<subscriptionId>/status
```

```
/subscriptions/containers/<subscriptionId>/status
```

```
/subscriptions/<subscriptionId>/status
```

<Note>
  If you use this resource without the `<platformType>` specified (i.e. without `cloud` or `containers` specified), the behavior is exactly the same as specifying the `cloud`-specific resource. This behavior enables backward compatibility with scripts using the Kubex API prior to release 12.1.6, where the platform-specific indicator was not available.
</Note>

## endpoints

<CardGroup>
  <Card title="Get Subscriptions Status" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Status/getSubscriptionStatus" />
</CardGroup>

<CardGroup>
  <Card title="Get Subscriptions Status Default Plataform" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Status/getSubscriptionStatusDefaultPlatform" />
</CardGroup>


# Get subscription status (results + webhook)
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Status/getSubscriptionStatus

openapi/public_cloud/Subscriptions_Status.yaml GET /subscriptions/{platformType}/{subscriptionRef}/status
Returns `lastTriggered` (On-Demand/Scheduled Success/Failure with timestamp)
and `webHookStatus` (Success/Failure with timestamp) for the specified
subscription. 




# Get subscription status (alias of cloud)
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Status/getSubscriptionStatusDefaultPlatform

openapi/public_cloud/Subscriptions_Status.yaml GET /subscriptions/{subscriptionRef}/status



# Subscriptions: Suppressions
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Suppressions



The `/subscriptions/<platformType>/suppressions` resource is used to store a list of attribute tags and recommendation properties available to the [Subscriptions](./Subscriptions) resource for the purpose of suppressing specific sets of system recommendations from the resulting subscription data set.

This resource acts as a catalog of the suppression tags or properties to be referenced by the [suppressionReferences](./Subscriptions#suppressionReferences) parameter in the [Subscriptions](./Subscriptions) resource . Suppression entries (tags or properties) not defined in a `/subscriptions/<platformType>/suppressions` resource cannot be referenced; you must define the suppression entries before using them in a suppression condition. See [Subscriptions](./Subscriptions) for details on defining a subscription.

There is a catalog for each supported `<platformType>`, which can only be referenced by the corresponding `<platformType>` subscription. For example, a container subscription (i.e. `/subscriptions/containers`) can only reference suppressions from the Container Subscriptions Suppressions catalog (i.e. `/subscriptions/containers/suppressions`).

Suppression entries can be declared as global or private (i.e. user-specific). Global suppression entries can be used by any API enabled user, while private entries can only be used by their owners. Note that <Tooltip>administrative users</Tooltip> have access to all suppression entries - global or private user-specific.

## Resource

```
/subscriptions/cloud/suppressions
```

```
/subscriptions/containers/suppressions
```

```
/subscriptions/suppressions
```

<Note>
  If you use this resource without the `<platformType>` specified (i.e. without `cloud` or `containers` specified), the behavior is exactly the same as specifying the `cloud`-specific resource. This behavior enables backward compatibility with scripts using the Kubex API prior to release 12.1.6, where the platform-specific indicator was not available.
</Note>

## endpoints

<CardGroup>
  <Card title="Create Suppressions" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Suppressions/createSuppressions" />
</CardGroup>

<CardGroup>
  <Card title="Delete Suppression" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Suppressions/deleteSuppression" />
</CardGroup>

<CardGroup>
  <Card title="Delete Suppressions" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Suppressions/deleteSuppressions" />
</CardGroup>

<CardGroup>
  <Card title="Get Suppressions" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Suppressions/getSuppression" />
</CardGroup>

<CardGroup>
  <Card title="List Suppressions" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Suppressions/listSuppressions" />
</CardGroup>

<CardGroup>
  <Card title="List Suppressions Default Platform" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Suppressions/listSuppressionsDefaultPlatform" />
</CardGroup>

<CardGroup>
  <Card title="Replace Suppression" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Suppressions/replaceSuppression" />
</CardGroup>

<CardGroup>
  <Card title="Replace Suppressions" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Suppressions/replaceSuppressions" />
</CardGroup>


# Add suppressions (bulk; all-or-nothing)
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Suppressions/createSuppressions

openapi/public_cloud/Subscriptions_Suppressions.yaml POST /subscriptions/{platformType}/suppressions
Adds one or more entries. A suppression is either an **attribute** suppression
(`attributeName`, optionally with `key` + `technology` for Resource Tags /
Container Labels) **or** a **property** suppression (`propertyName`). Uniqueness
and owner rules apply; non-admins can only add private entries.




# Delete a suppression by ID
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Suppressions/deleteSuppression

openapi/public_cloud/Subscriptions_Suppressions.yaml DELETE /subscriptions/{platformType}/suppressions/{suppressionRef}
Returns 204 on success; 404 if not found; if referenced by subscriptions
(or other errors), returns an object with `suppressionRef`/`suppressionName`
and `message`.




# Delete suppressions (bulk; independent per entry)
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Suppressions/deleteSuppressions

openapi/public_cloud/Subscriptions_Suppressions.yaml DELETE /subscriptions/{platformType}/suppressions
Deletes a collection of entries by `suppressionRef`. If **all** succeed,
returns 204. If any fail, returns an array with per-entry status/messages
for failures; successful deletes may omit a message. Suppressions referenced
by subscriptions cannot be deleted.




# Get a suppression by ID
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Suppressions/getSuppression

openapi/public_cloud/Subscriptions_Suppressions.yaml GET /subscriptions/{platformType}/suppressions/{suppressionRef}



# List suppressions for a platform
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Suppressions/listSuppressions

openapi/public_cloud/Subscriptions_Suppressions.yaml GET /subscriptions/{platformType}/suppressions
Returns global/private suppression entries; use `type` and (admin only)
`owner` to filter.




# List suppressions (alias of cloud)
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Suppressions/listSuppressionsDefaultPlatform

openapi/public_cloud/Subscriptions_Suppressions.yaml GET /subscriptions/suppressions



# Replace a suppression by ID (full PUT)
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Suppressions/replaceSuppression

openapi/public_cloud/Subscriptions_Suppressions.yaml PUT /subscriptions/{platformType}/suppressions/{suppressionRef}
Supply **all** required parameters; previous values are replaced. Admin
can promote private→global by setting `owner: ""`.




# Replace suppressions (bulk PUT; all-or-nothing)
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Suppressions/replaceSuppressions

openapi/public_cloud/Subscriptions_Suppressions.yaml PUT /subscriptions/{platformType}/suppressions
Deletes and replaces parameters for existing entries. Supply **all**
parameters required by each entry. Admins can promote private→global by
setting `owner: ""`.




# Subscriptions: Tags
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Tags



The `/subscriptions/<platformType>/tags` resource is used to store a list of system attributes available to the [Subscriptions](./Subscriptions) resource for the purpose of filtering systems from the resulting subscription data set.

This resource acts as a catalog of system attributes to be referenced by the [tagReferences](./Subscriptions#tagReferences) parameter in a subscription. System attributes that are not defined in a `/subscriptions/<platformType>/tags` resource, cannot be referenced by a Subscriptions tag filter condition. See [Subscriptions](./Subscriptions) for details on defining a subscription and using tag filter conditions.

The SQL to filter results employs a "STRING" comparison and not a numeric comparison on tags so you may observe inconsistent results. Tags can only be lexicographically compared.

There is a catalog for each supported `<platformType>`, which can only be referenced by the corresponding `<platformType>` subscription. For example, a container subscription (i.e. `/subscriptions/containers`) can only reference tags from the Container Subscriptions Tags catalog (i.e. `/subscriptions/containers/tags`). Kubex provides an initial, default set of system attributes for each `<platformType>` catalog. You can extend these default sets by adding additional system attributes, or you can customize the sets by modifying or deleting existing attributes. Only Kubex standard attributes or technology-specific attributes (e.g. AWS, Containers) can be added to the platform-specific Subscriptions Tags catalogs. Contact [support@kubex.ai](mailto:support@kubex.ai) for a complete list of available Kubex standard attributes. See [Default Cloud Attribute Tags](#cloudDefaultTags) or [Default Container Attribute Tags](#containerDefaultTags).

Attributes in the platform-specific Subscriptions Tags catalog can be declared as global or private (i.e. user-specific). Global attribute tags can be used by any API enabled user, whereas private attributes can only be used by their owners. Note that <Tooltip>administrative users</Tooltip> have access to both global and private attributes for all users.

## Resource

```
/subscriptions/cloud/tags
```

```
/subscriptions/containers/tags
```

```
/subscriptions/tags
```

<Note>
  If you use this resource without the `<platformType>` specified (i.e. without `cloud` or `containers` specified), the behavior is exactly the same as specifying the `cloud`-specific resource. This behavior enables backward compatibility with scripts using the Kubex API prior to release 12.1.6, where the platform-specific indicator was not available.
</Note>

## endpoints

<CardGroup>
  <Card title="Add Subscription Tags" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Tags/addSubscriptionTags" />
</CardGroup>

<CardGroup>
  <Card title="Delete Subscription Tag" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Tags/deleteSubscriptionTag" />
</CardGroup>

<CardGroup>
  <Card title="Delete Subscription Tags" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Tags/deleteSubscriptionTags" />
</CardGroup>

<CardGroup>
  <Card title="Get Subscription Tag" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Tags/getSubscriptionTag" />
</CardGroup>

<CardGroup>
  <Card title="List Subscription Tags" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Tags/listSubscriptionTags" />
</CardGroup>

<CardGroup>
  <Card title="List Subscription Tags Default Platform" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Tags/listSubscriptionTagsDefaultPlatform" />
</CardGroup>

<CardGroup>
  <Card title="Replace Subscription Tag" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Tags/replaceSubscriptionTag" />
</CardGroup>

<CardGroup>
  <Card title="Replace Subscription Tags" href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Tags/replaceSubscriptionTags" />
</CardGroup>


# Add tags (bulk; all-or-nothing)
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Tags/addSubscriptionTags

openapi/public_cloud/Subscriptions_Tags.yaml POST /subscriptions/{platformType}/tags
Adds one or more tags. Admins may create **global** (owner empty) or private tags;
non-admins can only create **private** (owner auto-set to their username).
Uniqueness: `attributeName` must be unique per catalog; `tagName` and `aliasName`
must be unique per ownership scope (global vs owner).




# Delete a tag by ID
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Tags/deleteSubscriptionTag

openapi/public_cloud/Subscriptions_Tags.yaml DELETE /subscriptions/{platformType}/tags/{tagRef}
204 on success; 404 if not found. If referenced by subscriptions (or other
errors), returns an object with `tagRef`, `message`, `status`.




# Delete tags (bulk; independent per entry)
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Tags/deleteSubscriptionTags

openapi/public_cloud/Subscriptions_Tags.yaml DELETE /subscriptions/{platformType}/tags
Deletes a collection of tags by `tagRef`. If **all** succeed, returns 204.
If any fail (e.g., tag is referenced by subscriptions), returns an array of
per-entry results with status/messages; other entries may still delete.




# Get a tag by ID
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Tags/getSubscriptionTag

openapi/public_cloud/Subscriptions_Tags.yaml GET /subscriptions/{platformType}/tags/{tagRef}



# List tags in the platform catalog
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Tags/listSubscriptionTags

openapi/public_cloud/Subscriptions_Tags.yaml GET /subscriptions/{platformType}/tags
Returns global/private tags. Use `type` and (admin only) `owner` to filter. 




# List tags (alias of cloud)
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Tags/listSubscriptionTagsDefaultPlatform

openapi/public_cloud/Subscriptions_Tags.yaml GET /subscriptions/tags



# Replace a tag by ID (full PUT)
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Tags/replaceSubscriptionTag

openapi/public_cloud/Subscriptions_Tags.yaml PUT /subscriptions/{platformType}/tags/{tagRef}
**All parameters must be supplied.** Admin may promote private→global by setting `owner: ""`.




# Replace tags (bulk PUT; all-or-nothing)
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Subscriptions_Tags/replaceSubscriptionTags

openapi/public_cloud/Subscriptions_Tags.yaml PUT /subscriptions/{platformType}/tags
Replace parameters for existing tags. **Supply all parameters** for each tag;
PUT acts as delete+replace. Admins may promote private→global by setting `owner: ""`.




# Impact Analysis and Recommendation Report (PDF)
Source: https://docs.kubex.ai/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Systems/downloadAnalysisReport

openapi/systems.yaml GET /systems/{id}/analysis-report
Downloads the Impact Analysis and Recommendation Report (Application Owner report) as a PDF.
Use `Accept: application/octet-stream` to download the file.




# Analysis Details Modal
Source: https://docs.kubex.ai/docs-kubex/Content/Cloudex/AI_Analysis_Details_Modal-Cloud



A hyperlink in the Analysis Details page opens this page showing significant details of the selected instance provided in a format that is easier to view and compare the current versus the recommended instance types.

## Instance Optimization Details

This card lists the following details for the current instance type.

<div>
  <ul>
    <li>Optimization Type</li>
    <li>Policy</li>
  </ul>

  <ul>
    <li>Monthly Waste</li>
    <li>Effort</li>
  </ul>
</div>

These additional details are listed for both instance types for easy comparison.

<div>
  <ul>
    <li>Instance Type</li>
    <li>Monthly Cost</li>
  </ul>

  <ul>
    <li>CPUs</li>
    <li>CPU Benchmark</li>
    <li>Memory (GB)</li>
  </ul>
</div>

Descriptions for all of these values are provided in the [Analysis Details](/docs-kubex/Content/Cloudex/AI_Analysis_Details_Tab-Cloud) table.

### Impact Analysis and Recommendation Report

The Impact Analysis and Recommendation report provides a PDF version of the instance details. You can easily share this report with the application owner to share your proposed sizing recommendations.

<div>
  <div>
    <Frame>
      <img />
    </Frame>

    <Frame>
      <img />
    </Frame>
  </div>

  <div>
    <Note>
      Note:  This report is not available for Azure VM Scale Sets.
    </Note>

    Click the link in the upper corner to download a PDF version of the Impact Analysis and Recommendation Report.

    <br />

    <br />

    When you click the button, a popup opens with a link. You can save or download the file.

    <br />

    <br />

    The filename will be `<cloud provider>_<system name>_<system_id>.pdf`
  </div>
</div>

<Frame>
  <img />
</Frame>

## System Information

This card indicates identifying details for the selected instance.

<div>
  <Frame>
    <img />
  </Frame>

  <ul>
    <li>Cloud Provider</li>

    <li>
      <a href="/docs-kubex/Content/Cloudex/AI_Analysis_Details_Table-Cloud#service-type">
        Service Type
      </a>
    </li>

    <li>System Name</li>
    <li>Instance ID</li>
    <li>Instance OS</li>
    <li>Account Name/ID</li>
    <li>Region/Availability Zone</li>
  </ul>
</div>

## Status Overview

This card indicates the status of the current instance.

<Frame>
  <img />
</Frame>


# Analysis Details Page
Source: https://docs.kubex.ai/docs-kubex/Content/Cloudex/AI_Analysis_Details_Tab-Cloud



The Analysis Details tab shows a table of results from the AI analysis for public cloud instances in the selected scope. It provides all the information needed for you to implement optimization recommendations in your environments.

<Accordion title="Figure: Locating the Analysis Details Tab">
  <img alt="" />
</Accordion>

This page consists of:

<ul>
  <li>
    A tabular report--A configurable tabular report is shown in the top pane. Descriptions of each column are provided in <a href="/docs-kubex/Content/Cloudex/AI_Analysis_Details_Table-Cloud">
    Analysis Details Table</a> tabular data.
  </li>

  <li>
    Utilization Charts--Based on the system selected in the top pane, the corresponding utilization charts are shown in the lower pane. See <a href="/docs-kubex/Content/Kubex/AI_Analysis_Details_Charts">Analysis Details Utilization Charts</a> for details on expanding, configuring and interpreting the utilization charts
  </li>
</ul>

<Note>
  <strong>Note:</strong> Systems that do not have adequate collected data for recommendation analysis are not included on this page.
</Note>

## Searching for Systems

You can search the table for a specific system or set of systems.

<ol>
  <li>Enter your search criteria in the search bar, located in the upper right of the page.</li>
  <li>The table contents update as you enter your search parameters.</li>
  <li>Click the X in the search box to clear the search parameters.</li>
</ol>

Kubex only searches the scope of systems that are currently displayed. You may need to expand your scope of systems if your systems are not found.

## Column Filters

You can apply various filters to customize the scope of containers or cloud instance you are reviewing in the table. See [Using Filters](/docs-kubex/Content/Kubex/Using_Filters).

## Exporting Data

You can export tabular reports from this tab to Microsoft® Excel.

<ol>
  <li>Select the table view and adjust views and filters to obtain the desired set of data.</li>
  <li>Click the export icon, located beside the **Table View** drop down menu.</li>
</ol>

<Frame>
  <img alt="" />
</Frame>

When the content of the Analysis Details is exported, entity names that are provided as a hyperlink are included in the exported XLS file. When you open the exported .XLS file, the URL content initially appears as plain text, and when you click on the cell it becomes a hyperlink.

## Table Views

A number of pre-configured views enable you to see analysis results that are applicable to your specific use case. Each pre-defined view has only the applicable columns enabled and filters have been set to include only systems that meet certain criteria.
Details of all pre-configured views are provided in [Analysis Details Table](/docs-kubex/Content/Cloudex/AI_Analysis_Details_Table-Cloud).


# Analysis Details Table
Source: https://docs.kubex.ai/docs-kubex/Content/Cloudex/AI_Analysis_Details_Table-Cloud



Use the Analysis Details report to review instance-specific details. The content of report is defined by your selection in the tree viewer. You can further filter the table content using the options on the column headers and from a flyout menu. See [Using Filters](/docs-kubex/Content/Kubex/Using_Filters).

See [Using Table Column Features](/docs-kubex/Content/Kubex/Using_Table_Column_Features) for details of using the features on this page, including exporting the content, right-click-context menu, moving columns, etc.

A [summary banner](/docs-kubex/Content/Kubex/Visualizing_Your_Data#summary-banner) at the top of the page provides an overall summary of the scope of selected systems.

### Pre-Configured Views

The following pre-configured table views are provided to quickly show various resources in your environment. Specific filters have been set and selected columns are displayed to highlight the specified set of data.

<Frame>
  <img alt="" />
</Frame>

<br />

<Accordion title="Table: Pre-Configured Views">
  <table>
    <colgroup>
      <col />

      <col />

      <col />
    </colgroup>

    <thead>
      <tr>
        <th>System View</th>
        <th>View</th>
        <th>Column</th>
      </tr>
    </thead>

    <tbody>
      <tr>
        <td>N/A</td>
        <td>Default View</td>
        <td>This is the most commonly used set of columns that provide a summary view of your cloud instances. Significant risks or wasted spend are highlighted.</td>
      </tr>

      <tr>
        <td>N/A</td>
        <td>All Data</td>
        <td>All columns and all data, as defined by your tree viewer selections are displayed. All filters are cleared. Horizontal and vertical scroll bars are displayed so you can navigate the content of the table.</td>
      </tr>

      <tr>
        <td>Cloud Provider</td>
        <td>AWS</td>
        <td>This view shows all AWS EC2, RDS and ASG instances.</td>
      </tr>

      <tr>
        <td>Azure</td>
        <td>This view shows all Azure VM and VMSS instances.</td>
      </tr>

      <tr>
        <td>GCP</td>
        <td>This view shows all GCP Compute instances.</td>
      </tr>

      <tr>
        <td>Optimization Type</td>
        <td>Downscale</td>
        <td>This view displays all services of the specified optimization type within the selected scope, as defined by the tree viewer. i.e. Downsize, Upsize, etc.</td>
      </tr>

      <tr>
        <td>Downsize</td>
      </tr>

      <tr>
        <td>Modernize</td>
      </tr>

      <tr>
        <td>Terminate</td>
      </tr>

      <tr>
        <td>Upscale</td>
      </tr>

      <tr>
        <td>Upsize</td>
      </tr>

      <tr>
        <td>Service Type</td>
        <td>AWS ASG</td>
        <td>This view displays all services of the specified type within the selected scope, as defined by the tree viewer.</td>
      </tr>

      <tr>
        <td>AWS ECS</td>
      </tr>

      <tr>
        <td>AWS RDS</td>
      </tr>

      <tr>
        <td>Azure VM</td>
      </tr>

      <tr>
        <td>Azure VMSS</td>
      </tr>

      <tr>
        <td>GCP - Compute Engine</td>
      </tr>
    </tbody>
  </table>
</Accordion>

### Instance Details Table

The content of the table as well as the totals at the bottom reflect applied filter settings. Not all columns may be displayed in your view, but you can add them at any time. See [Using Table Column Features](/docs-kubex/Content/Kubex/Using_Table_Column_Features).

<Accordion title="Table: Instance Optimization Details Tabular Report Columns">
  <table>
    <colgroup>
      <col />

      <col />

      <col />
    </colgroup>

    <thead>
      <tr>
        <th>
          <p>Column Name </p>
        </th>

        <th>
          <p>Description</p>
        </th>

        <th>
          <p>Available For</p>
        </th>
      </tr>
    </thead>

    <tbody>
      <tr>
        <td>
          <p>Cloud Provider</p>
        </td>

        <td>
          <p>The name of the public cloud provider. </p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p><a name="Service_Type" />Service Type</p>
        </td>

        <td>
          <p>The type of service being analyzed. Not all service types are supported. </p>

          <ul>
            <li>AWS EC2, RDS and ASGs </li>
            <li>Azure VM and VM Scale Sets </li>
            <li>GCP Compute Instances</li>
          </ul>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>Account Name</p>
        </td>

        <td>
          <p>The instance's parent account. This corresponds to:</p>

          <ul>
            <li>AWS Linked Account</li>
            <li>Azure Subscription</li>
            <li>GCP Project</li>
          </ul>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>System Name</p>
        </td>

        <td>
          <p>The name of the selected system. The name is a hyperlink that opens <a href="./AI_Analysis_Details_Modal-Cloud">modal view</a> with a detailed summary of the instance and comparison of the current and recommended instance types.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>Region</p>
        </td>

        <td>
          <p>The region, in which this instance is located.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p><a name="Details_OverallStatus" />Overall Status</p>
        </td>

        <td>
          <p>Identifies the overall status of the optimization results based on <a href="#Details_OptimizationType"><u>Optimization Type</u></a> and potential <a href="#Details_SavingsMonth"><u>Analysis Details Table</u></a>:</p>

          <table>
            <colgroup>
              <col />

              <col />
            </colgroup>

            <tbody>
              <tr>
                <td>
                  <p>Optimal</p>
                </td>

                <td>
                  <p>This instance is currently optimal. Optimization type is just right and there are no savings or risks for this instance.</p>
                </td>
              </tr>

              <tr>
                <td>
                  <p>Identified Risk</p>
                </td>

                <td>
                  <p>This instance is currently at risk. This status typically occurs when the savings amount is less than \$0 (i.e.  you need to spend money to mitigate performance risk). </p>
                  <p>This may also occur when the  savings amount is \$0, but the optimization type is upscale, upsize, or upsize to optimal family. This situation occurs when services are inactive, but they will need to be upscaled or upsized when they resume activity to mitigate risk.</p>
                </td>
              </tr>

              <tr>
                <td>
                  <p>Savings Opportunity</p>
                </td>

                <td>
                  <p>This instance is currently over-provisioned. The possible savings amount is greater than $0.</p> <p>This may also occur when the savings amount is $0, but the optimization type is terminate, modernize, modernize to optimal family, downscale, downsize, or downsize to optimal family. This situation occurs when services are inactive, but have a recommendation of terminate, modernize, downsize or downscale, when they resume activity.</p>
                </td>
              </tr>
            </tbody>
          </table>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>Instance Type</p>
        </td>

        <td>
          <p>The current instance type, based on data collection.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>Recommended Instance Type</p>
        </td>

        <td>
          <p>This is the recommended catalog instance type is listed, based on the optimization analysis.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p><a name="Details_EstimatedCost" />Current Estimated <br />Cost (\$/month)</p>
        </td>

        <td>
          <p>This is the per instance cost per month, for the current instance type, corresponding to the listed <a href="#Details_CatalogInstance"><u>Analysis Details Table</u></a> type for on-demand usage. </p>
          <p>Calculated as: Catalog Price \* Uptime</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p><a name="Details_RecEstimatedCost" />Recommended Estimated Cost (\$/month)</p>
        </td>

        <td>
          <p>This is the per instance cost per month, for the recommended instance type, corresponding to the listed <a href="#Details_CatalogInstance"><u>Analysis Details Table</u></a> type for on-demand usage. </p>
          <p>Calculated as: Catalog Price \* Uptime</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>\$Total Waste/Month</p>
        </td>

        <td>
          <p>The current and recommended estimated instance cost is used to calculate savings per month.</p>
          <p>Calculated as: (current estimated cost - recommended estimated cost).</p>

          <ul>
            <li>The total waste of selected instances with a positive dollar amount = Estimated Waste indicated in the summary bar.</li>
            <li>The total waste of selected instances with a negative dollar amount = Upsize Cost indicated in the summary bar.</li>
          </ul>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>%Waste/Month</p>
        </td>

        <td>
          <p>The savings/month expressed as percentage of the current cost, for this instance.</p>
          <p>Calculated as: (current estimated cost - recommended estimated cost)/current estimated cost \*100.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>System ID</p>
        </td>

        <td>
          <p>A unique key assigned by the public cloud vendors to identify this instance. </p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>Account ID</p>
        </td>

        <td>
          <p>A unique key assigned by the public cloud vendors to identify the account.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p><a name="Effort" />Effort</p>
        </td>

        <td>
          <p>This column describes the effort required to investigate and implement the recommendation. Effort will be one of :</p>
          <p>Moderate  | Low  | Very Low  | None </p>
          <p>Effort for each instance is calculated using rule-driven analytics based on factors, such as instance family change, storage change, data quality checks, feature changes, etc.</p>
          <p>These factors can be configured through the policy settings that capture your best practices. </p>
          <p>Click on the <span>Effort Details</span> tab to view the factors that contribute to the effort level. See <a href="#Lower_Section">Reviewing the Workload Charts and Additional Details Tabs</a>, below.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>Availability Zone</p>
        </td>

        <td>
          <p>The cluster/availability zone that corresponds to a geographic region.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>OS</p>
        </td>

        <td>
          <p>The operating system running on this instance.</p>
          <p>The operating system running on all scale set instances.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>Instance Creation Date</p>
        </td>

        <td>
          <p>The date on which this instance, was first created in your public cloud account.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>Instance Discovery Date</p>
        </td>

        <td>
          <p>The date on which data was first collected from this instance, by <span>Kubex</span>.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>Power State</p>
        </td>

        <td>
          <p>The power state of the selected instance.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>K8s Cluster <br />(from CSP)</p>
        </td>

        <td>
          <p>This column indicates the name of the Kubernetes cluster that the scale group is hosting. When populated the analysis requires additional information to ensure the scale group can satisfy all of the container requests. </p>
          <p>If the column "K8s Node Group" is populated with a dash (-) or the column is not visible, then consider deploying the <span>Kubex</span> <a href="#">data collector</a> into this cluster to collect the required data. </p>
          <p><strong>Note: </strong>This column is displayed only if the scale group is hosting a Kubernetes cluster.</p>
        </td>

        <td>
          <ul>
            <li>ASG</li>
            <li>VM Scale Set</li>
          </ul>
        </td>
      </tr>

      <tr>
        <td>
          <p>K8s Cluster (from Kubex Agent)</p>
        </td>

        <td>
          <p>This column indicates the name of the Kubernetes cluster, as configured in the <span>Kubex</span> <span>data collector</span>.</p>
          <p><strong>Note: </strong>This column is displayed only if the scale group is hosting a Kubernetes cluster.</p>
        </td>

        <td>
          <ul>
            <li>ASG</li>
            <li>VM Scale Set</li>
          </ul>
        </td>
      </tr>

      <tr>
        <td>
          <p>K8s Node Group</p>
        </td>

        <td>
          <p>This column indicates the name of the Kubernetes node group associated with this scale group. When populated, <span>Kubex</span> has the data required for enhanced scale group analysis.  </p>
          <p><strong>Note: </strong>This column is displayed only if the scale group is hosting a Kubernetes cluster.</p>
        </td>

        <td>
          <ul>
            <li>ASG</li>
            <li>VM Scale Set</li>
          </ul>
        </td>
      </tr>

      <tr>
        <td>
          <p>ECS Cluster</p>
        </td>

        <td>
          <p>The name of the ECS cluster hosted by this <span>Auto Scaling group</span>. The additional cluster-level information is used for enhanced ASG analysis, resulting in more accurate recommendations. <a name="kanchor104" /></p>
          <p><strong>Note: </strong>This column is available only if the <span>Auto Scaling group</span> is hosting an ECS instance.</p>
          <p>For ECS services, capacity providers can be used to manage the infrastructure that the tasks in your clusters use. Capacity providers for ECS allow for multiple ASGs to support an ECS cluster. The reference in this column accounts for  created capacity providers and indicates the ECS service cluster that is associated with this ASG.</p>
          <p>There will be an impact to the effort value for ASGs, hosting a Kubernetes cluster, and not linked with a ECS/EKS reference (i.e. has no parent). </p>
        </td>

        <td>
          <ul>
            <li>ASG</li>
          </ul>
        </td>
      </tr>

      <tr>
        <td>
          <p>Policy</p>
        </td>

        <td>
          <p>The policy used to analyze the data and generate the recommendations. </p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p><a name="Details_OptimizationType" />Optimization Type</p>
        </td>

        <td>
          <p>The recommended action for this instance. See <a href="#Recommendation_Color-Coding"><u>Details - Optimization Type Descriptions and Color-Coding</u></a> for a description of each optimization type.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>Recommendation Reason/Observations</p>
        </td>

        <td>
          <p>The reason for the Optimization Type recommendation. <span>Kubex</span> also provides any relevant details related to the recommendation.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p><a name="Inst_Updated" />Instance Type <br />Updated On </p>
        </td>

        <td>
          <p>A value in this column indicates that the instance type was changed recently. </p>
          <p>The recommendation for this instance is based only on workload data collected from the specified date, onward. Any historical data gathered before this date is excluded from the analysis, as it has been collected from a different instance type and is no longer relevant.<a name="kanchor105" /></p>
          <p>A blank cell indicates the current instance type has not changed and all available workload data within the range, defined by the policy, has been used to generate the recommendation.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p><a name="currentRIcoverage" />Current RI Coverage (%)</p>
        </td>

        <td>
          <p>This is the percentage of reserved instance (RI) coverage  available for the current instance. Flexible RIs are taken into consideration when calculating the percentage of RI coverage. However, convertible RIs are included in the calculation depending on the RI coverage assessment <span>Kubex</span> settings.</p>
          <p> For individual compute or database instances, the coverage percentage is either 100% or 0%. Coverage between 0 and 100% occurs when Flexible RIs are converted into partial coverage.</p>
          <p>Contact <span>[support@kubex.ai](mailto:support@kubex.ai)</span> to review your RI candidate policies and RI coverage assessment <span>Kubex</span> settings. </p>
        </td>

        <td>
          <ul>
            <li>ASG, EC2, RDS</li>
          </ul>
        </td>
      </tr>

      <tr>
        <td>
          <p><a name="Defer_RI" />Defer Recommendation Until <br />Current RI <br />Coverage Expires </p>
        </td>

        <td>
          <p>Defer recommending an instance type change until reserved instance coverage for this instance expires. Values include:</p>

          <ul>
            <li>Yes--defer instance type recommendation due to RI coverage;</li>
            <li> No--do not defer instance type recommendation; this is also the case for "Terminate" recommendation;</li>
            <li>"-" --not applicable; this is also the case for "Just Right" recommendation.</li>
          </ul>

          <p>An icon  on this column indicates that instances that are RI-constrained should not be modified to the recommended instance type at this time, since the current instance has existing reserved instance coverage. When the applicable reserved instances expire (as indicated by the "Current RI Expiry Date"), then the instance can be modified to the recommended instance type.</p>
          <p>Contact <span>[support@kubex.ai](mailto:support@kubex.ai)</span> to review the setting for "AWS Defer Recommendations". .</p>
        </td>

        <td>
          <ul>
            <li>EC2, RDS</li>
          </ul>
        </td>
      </tr>

      <tr>
        <td>
          <p>Current RI Expiry Date</p>
        </td>

        <td>
          <p>If <a href="#Defer_RI"><u>Defer Recommendation Until Current RI Coverage Expires </u></a> = Yes, then the expiry date of the reserved instance, currently providing coverage for this instance, is displayed. </p>
          <p>This value is only applicable to AWS EC2, RDS instances.</p>
          <p><span>Note: </span>The RI expiry date is not displayed for an instance with <a href="#Details_OptimizationType"><u>Optimization Type</u></a>= "Just Right" or "Terminate" .</p>
        </td>

        <td>
          <ul>
            <li>EC2, RDS</li>
          </ul>
        </td>
      </tr>

      <tr>
        <td>
          <p>Scaling Mode</p>
        </td>

        <td>
          <p>The scaling mode applied to this <span>VM Scale Set</span>. The scaling mode can be one of manual  or autoscale. If the <span>VM Scale Set</span> is currently running in manual mode, consider changing it to autoscale mode.</p>
          <p>If, enabled, historical audits only apply to s set to "auto" and do not include s set to "manual". Data for s set to "manual" is only collected on a daily basis and the required number of days, as defined by the policy, must be collected before recommendations are displayed in the UI.The proposed recommended instance type, minimum and maximum group size are based on scaling mode being set to autoscale.</p>
          <p>If, enabled, historical audits only apply to <span>VM Scale Set</span>s set to "auto" and do not include <span>VM Scale Set</span>s set to "manual". Data for <span>VM Scale Set</span>s set to "manual" is only collected on a daily basis and the required number of days, as defined by the policy, must be collected before recommendations are displayed in the UI.</p>
          <p>This value is only applicable to Azure instances <span>VM Scale Set</span>s.</p>
        </td>

        <td>
          <ul>
            <li><span>VM Scale Set</span></li>
          </ul>
        </td>
      </tr>

      <tr>
        <td>
          <p>No. of Profiles</p>
        </td>

        <td>
          <p>The number of profiles associated with the selected <span>VM Scale Set</span>. Profiles are only applicable to scale sets with scaling mode=Autoscale. </p>
          <p> By default, scale sets with orchestration mode=Uniform are created with one  scaling profile. Multiple profiles can be used to scale in different ways at different times. If for example, your workloads are inactive on some weekends, a recurring profile to scale in resources can be applied.</p>
        </td>

        <td>
          <ul>
            <li><span>VM Scale Set</span></li>
          </ul>
        </td>
      </tr>

      <tr>
        <td>
          <p>Orchestration Mode</p>
        </td>

        <td>
          <p>The orchestration mode applied to this <span>VM Scale Set</span>. The orchestration mode can be one of Uniform or Flexible.</p>
          <p>Only Uniform scale sets, or Flexible scale sets running identical instance types are analyzed. See <a href="#Mixed"><u>Details - VM Scale Set Mixed Mode Services</u></a> for details.</p>
          <p>The proposed recommended instance type, minimum and maximum group size are based on the orchestration mode being set to uniform.</p>
        </td>

        <td>
          <ul>
            <li>
              <span>VM Scale Set</span>
            </li>
          </ul>
        </td>
      </tr>

      <tr>
        <td>
          <p><a name="Uptime%" />Uptime (%) </p>
        </td>

        <td>
          <p>When using pay-per-use pricing models, the amount of time each instance has been running, is required to accurately estimate future costs. </p>
          <p>The predicted uptime (%) for a cloud instance or container, is based on the percentage of hours CPU utilization data is present in the historical interval, as specified in the policy settings for the entity. For <span>Auto Scaling group</span>s and <span>VM Scale Set</span>s and Individual child instances are not taken into account.</p>
          <p>Uptime for new instances or containers, that started mid-way through the historical interval, is calculated from the time/date that the instance was started rather than the beginning of the interval, resulting in more accurate predictions for future usage.</p>
          <p>For example, the uptime is the number of hours that have "CPU Utilization in mcores", and the range is the lesser of when the container was discovered, or the range that is defined in the policy. Looking at a specific container that was discovered on July 5th 2025, that has workload for 42 hours since that date, then 13 days later, the uptime % is 42 hrs/(13 days x 24 hrs/day) = 13.4%. This is the value reported in this column.</p>
          <p>When determining the uptime for <span>Auto Scaling group</span>s and <span>VM Scale Set</span>s individual child instances are not taken into account.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>Total Hours</p>
        </td>

        <td>
          <p>The total hours that the instance has been in the environment. </p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>Running Hours</p>
        </td>

        <td>
          <p>The number of hours that the instance has been running. </p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>Avg Group Size</p>
        </td>

        <td>
          <p>The average instance count when the scale group is running.</p>
        </td>

        <td>
          <ul>
            <li>ASG</li>

            <li>
              <span>VM Scale Set</span>
            </li>
          </ul>
        </td>
      </tr>

      <tr>
        <td>
          <p>
            <a name="ASGMinSize" />Min Group Size
          </p>
        </td>

        <td>
          <p>The minimum number of instances/hour. </p>
          <p>For <span>VM Scale Set</span>, when configured to autoscale, this value is the minimum of all the profiles associated with the selected <span>VM Scale Set</span>.</p>
          <p>When configured to scale manually, this is the minimum number of instances found during the historical period that is used for the analysis.  The historical period is defined by the policy setting, "Workload range".</p>
        </td>

        <td>
          <ul>
            <li>ASG</li>

            <li>
              <span>VM Scale Set</span>
            </li>
          </ul>
        </td>
      </tr>

      <tr>
        <td>
          <p>
            <a name="Reviewing_ASGMaxSize" />Max Group Size
          </p>
        </td>

        <td>
          <p>This is the maximum number of instances/hour. </p>
          <p>For <span>VM Scale Set</span>, when configured to autoscale this value is the maximum of all the profiles associated with the selected <span>VM Scale Set</span>.</p>
          <p>When configured to scale manually, this is the maximum number of instances found during the historical period that is used for the analysis. The historical period is defined by the policy setting, "Workload range".</p>
        </td>

        <td>
          <ul>
            <li>ASG</li>

            <li>
              <span>VM Scale Set</span>
            </li>
          </ul>
        </td>
      </tr>

      <tr>
        <td>
          <p>
            <a name="Reviewing_ASGAvgInstCount" /> Predicted Avg Group Size
          </p>
        </td>

        <td>
          <p>The predicted, average instance count on the recommended instance type.</p>
        </td>

        <td>
          <ul>
            <li>ASG</li>

            <li>
              <span>VM Scale Set</span>
            </li>
          </ul>
        </td>
      </tr>

      <tr>
        <td>
          <p>Recom. Min Group Size</p>
        </td>

        <td>
          <p>The recommended minimum number of instances for the selected scale group.</p>
        </td>

        <td>
          <ul>
            <li>ASG</li>

            <li>
              <span>VM Scale Set</span>
            </li>
          </ul>
        </td>
      </tr>

      <tr>
        <td>
          <p>Recom. Max Group Size</p>
        </td>

        <td>
          <p>The recommended maximum number of instances for the selected scale group.</p>
        </td>

        <td>
          <ul>
            <li>ASG</li>

            <li>
              <span>VM Scale Set</span>
            </li>
          </ul>
        </td>
      </tr>

      <tr>
        <td>
          <p><a name="Scaling_Policies" />Scaling Policies</p>
        </td>

        <td>
          <p>This value indicates whether the scaling mode  needs to be reviewed.  Possible values depend on whether or not the <span>VM Scale Set</span>  is managed by AKS:</p>

          * VM Scale Set is managed by an AKS cluster:
            * No Value – If the optimization type = Terminate, then:
              * In the UI, a dash, "--" is displayed.
              * In the API, "Terminate" is returned in the /results.
            * Keep – If the current average group size is the same as the recommended average group size.\
              The optimization type = Just Right.
            * Review – If Kubex recommends changing one or more of instance type, average, minimum or maximum group size.

          * VM Scale Set is NOT managed by an AKS cluster:
            * No Value – If the optimization type = Terminate, then:
              * In the UI, a dash, "--" is displayed.
              * In the API, "Terminate" is returned in the /results.
            * Keep – If the current average group size, minimum and maximum group size are not changed.\
              The optimization type = Just Right.
            * Review – If Kubex recommends changing one or more of instance type, average, minimum or maximum group.
            * Enable Autoscale – If Kubex recommends changing one or more of instance type, average, minimum\
              or maximum group size and the VM Scale Set is not managed by AKS.
            * Adjust – If the current average group size is not the same as the predicted average group size **AND**\
              instance type and minimum and maximum group size do not change **AND** the VM Scale Set is not managed by AKS.
        </td>

        <td>
          <ul>
            <li>
              <span>VM Scale Set</span>
            </li>
          </ul>
        </td>
      </tr>

      <tr>
        <td>
          <p>Life Cycle</p>
        </td>

        <td>
          <p>This is the instance market option configured for an <span>Auto Scaling group</span>.</p>

          <ul>
            <li>Normal--The ASG is configured to run with On-Demand instances.</li>
            <li>Spot--The ASG is configured to run with Spot instances.</li>
          </ul>
        </td>

        <td>
          <ul>
            <li>ASG</li>
          </ul>
        </td>
      </tr>

      <tr>
        <td>
          <p>Current CPU </p>
        </td>

        <td>
          <p>The current CPU allocation for the selected instance.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>Recommended CPU </p>
        </td>

        <td>
          <p>The recommended CPU allocation for the selected instance.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>Current CPU Benchmark</p>
        </td>

        <td>
          <p>The CPU benchmark for the current instance type.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>Recommended CPU Benchmark</p>
        </td>

        <td>
          <p>The CPU benchmark for the recommended instance type.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>vCPU Surplus </p>
        </td>

        <td>
          <p>The change in actual vCPUs that will result if the recommendation is made.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>Recommended CPU Benchmark </p>
        </td>

        <td>
          <p>The CPU benchmark for the recommended instance type.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>Current Memory
          <br />Allocation (GB)</p>
        </td>

        <td>
          <p>The current memory allocation for the selected instance.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>
            Recommended Memory Allocation (GB)
          </p>
        </td>

        <td>
          <p>The recommended memory allocation for the selected instance.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>Network IO Throughput MB/s (current)</p>
        </td>

        <td>
          <p>The network throughput in MB/s for the curernt instance.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>Network IO Throughput pkts/s (current)</p>
        </td>

        <td>
          <p>The network throughput in pkts/s  for the current instance.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>
            % CPU Usage Current
          </p>
        </td>

        <td>
          <p>The percentage of current CPU allocation that is used by the workload, on the selected instance.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>% Memory Usage Current</p>
        </td>

        <td>
          <p>The percentage of active memory allocation that is used by the workload, on the selected instance.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>
            % CPU Usage Recommended
          </p>
        </td>

        <td>
          <p>The percentage of the recommended CPU allocation that would be used by the workload, on the selected instance.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>% Memory Usage Recommended</p>
        </td>

        <td>
          <p>The percentage of the recommended active memory allocation that would be used by the workload, on the selected instance.instance.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>IP Address</p>
        </td>

        <td>
          <p>The IP address of the selected instance.</p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>Summary Total</p>
        </td>

        <td>
          <p>In the top-right of the tabular report, the total number of <span>Instances</span> and <span>Savings/Month</span> for implementing the recommendations are displayed. </p>
          <p>The amount of savings per month is a sum of all the monthly savings for each instance listed and can be negative if the recommendation is an upsize or upsize to an optimal family. </p>
        </td>

        <td>
          <p>All supported services</p>
        </td>
      </tr>
    </tbody>
  </table>
</Accordion>

### Details - Optimization Type Descriptions and Color-Coding

The following descriptions and color coding apply to all tables with cloud instance data.

<Note>
  <strong>Note:</strong> Not all optimization types are supported for all cloud providers.
</Note>

<Accordion title="Table: Optimization Type Color-Coding Summary">
  <table>
    <colgroup>
      <col />

      <col />
    </colgroup>

    <thead>
      <tr>
        <th>Optimization Type</th>
        <th>Description</th>
      </tr>
    </thead>

    <tbody>
      <tr>
        <td>Just Right</td>
        <td>This instance is optimally sized for the workload.</td>
      </tr>

      <tr>
        <td>
          In general the following upsize recommendations incur additional costs. The cost increase is determined by comparing on-demand pricing for the current and recommended instance. The increased cost is required to alleviate application risk. If you have an RI or SP for the recommended upsize instance, there could be cost savings. This would still be an upsize recommendation.
        </td>
      </tr>

      <tr>
        <td>Upsize - Optimal Family</td>

        <td>
          This indicates the instance should be upsized to a more optimal instance family. This will improve the workload's performance and reduce risk.

          <br />

          If the workload can be moved to larger instance in a different family and still reduce cost, this then becomes a Modernize recommendation. e.g. t2.medium-Linux to m3.medium-Linux
        </td>
      </tr>

      <tr>
        <td>Upsize</td>

        <td>
          This indicates the instance should be upsized to an instance within the same instance family. The hosted workload needs an instance with more CPU and/or memory resources.

          <br />

          e.g. r3.large to r4.xlarge, both are in the "Memory Optimized" instance family.
        </td>
      </tr>

      <tr>
        <td>Upscale</td>

        <td>
          This indicates the maximum group size for the Auto Scaling group or VM Scale Set should be increased for additional compute capacity.

          <br />

          It may be more cost effective to use a larger instance instead of increasing the group size, for this Auto Scaling group or VM Scale Set.
        </td>
      </tr>

      <tr>
        <td>
          Downsize recommendations reduce the allocated resources as your workload has likely been over-provisioned. Once the recommendation has been determined from CPU and memory utilization, it is further verified against policy-defined limits, before the downsize or terminate recommendations are made.
        </td>
      </tr>

      <tr>
        <td>Terminate</td>

        <td>
          This indicates the instance should be terminated, as it is idle. An instance is determined to be idle if it has very low CPU utilization, network and disk I/O over an extended period of time. This will save you money.
        </td>
      </tr>

      <tr>
        <td>Downsize - Optimal Family</td>

        <td>
          This indicates the instance should be downsized to an instance belonging to an instance family that more closely suits your workload's utilization.

          <br />

          When you downsize, CPU and/or memory will be decreased to better suit your workloads. Utilization will improve with no impact on performance. This will save you money. e.g. d2.medium-Linux to m4.medium-Linux
        </td>
      </tr>

      <tr>
        <td>Downsize</td>

        <td>
          This indicates the instance should be downsized to an instance within the same instance family.

          <br />

          As indicated above, CPU and/or memory will be decreased to better suit your workloads. Utilization will improve with no impact on performance. This will save you money. e.g. m3.large-Linux to m3.small-Linux
        </td>
      </tr>

      <tr>
        <td>Downscale</td>

        <td>
          This indicates the instance the Auto Scaling group or VM Scale Set should be downscaled to decrease the compute capacity by adjusting the maximum and/or minimum group size.
        </td>
      </tr>

      <tr>
        <td>
          The following modernize recommendations move your workload to a more modern instance type without changing the resource allocation, cost or performance, at a minimum. Your costs could decrease and/or you may benefit from potential utilization and performance improvements.
        </td>
      </tr>

      <tr>
        <td>Modernize - Optimal Family</td>

        <td>
          This indicates the instance should be modernized to an instance belonging to a more optimal instance family. The cost of the new instance type will be less than the existing cost.

          <br />

          Allocated resources are not being removed and moving to an instance with more current hardware, you may also benefit potential utilization and performance improvements.

          <br />

          When you modernize, you will not decrease performance but will decrease cost.
        </td>
      </tr>

      <tr>
        <td>Modernize</td>

        <td>
          This indicates the instance should be modernized to an instance within the same instance family. The cost of the new instance type will be less than the existing cost and as indicated above you may also get utilization and performance improvements.

          <br />

          For example, moving to a new generation of the same instance family (e.g. m3.large to m4.large).
        </td>
      </tr>
    </tbody>
  </table>
</Accordion>

### Details - VM Scale Set Mixed Mode Services

Kubex cannot analyze VM Scale Set with a set of mixed instance types i.e. VM Scale Set configured with Orchestration Mode = Flexible. However, a scale set with Orchestration Mode = Flexible, can still be configured to run on one instance type and Kubex can analyze these services.

Kubex checks the VM Scale Set to determine if it is actually configured to run a mix of instance types or to run on a single instance type. Mixed groups are tagged by setting the attribute, "Mixed Instance Policy Set" to True and these scale sets are filtered from the analysis using the Cloud Environment filter.

Additionally, Kubex detects mixed instance configurations that result from changes to the launch configuration/scale set model. When the configuration of a VM Scale Set changes then in the event of scale out, new instances are created based on the new configuration, while the existing child instances continue to run with the previous configuration.

In the event of a scale in, VM Scale Sets are typically set to favour terminating instances created via the old launch template. This behaviour may also result in a mix of instance types.

Kubex detects these changes and excludes services where the configuration of the scale set has changed but the running child-instances have not been affected.

Where Orchestration Mode = Uniform, Kubex tags the VM Scale Set with the attribute, "Mixed Instance Policy Set"=True, when:

<ul>
  <li>Child instances are a combination of different instance types;</li>

  <li>
    Child-instances differ from what is defined in the launch template/configuration/scale set model for the ASG or

    <span>
      VM Scale Set
    </span>

    .
  </li>
</ul>

Kubex tags the ASGs or VM Scale Set with "Mixed Instance Policy Set"=False, when

<ul>
  <li>Mixed Policy is not set/Orchestration Mode = Uniform and all running instance types are the same.</li>

  <li>
    When the instance type defined for the ASG or

    <span>
      VM Scale Set
    </span>

    and child-instance types are the same and all running instance types are the same.
  </li>
</ul>

The attribute, "Mixed Instance Policy Set" (key=aws:mixedpolicy) is used for both AWS ASGs and Azure VM Scale Sets.

## Utilization Charts

The last section provides utilization charts that show hourly min/max and sustained activity for the selected node group. You can also expand any chart to the modal view and select other metrics for review. See [Using the Utilization Charts](/docs-kubex/Content/Kubex/AI_Analysis_Details_Charts#workload-charts-details) for details on using these charts to review workload data.

<div>
  <div>
    <p>All Instance Types</p>

    <ul>
      <li>CPU Utilization (%) Current</li>
      <li>CPU Utilization (%) Recommended</li>
      <li>CPU Utilization - Busiest Day (%) Current</li>
      <li>CPU Utilization - Busiest Day (%) Recommended</li>
      <li>Memory Utilization (%) Current</li>
      <li>Memory Utilization (%) Current</li>
      <li>Disk  I/O (Bytes/s)</li>
      <li>Disk I/O (Operations/s)</li>
      <li>Network I/O (Bytes/s)</li>
      <li>Network I/O (Packets/s)</li>
    </ul>
  </div>

  <div>
    <p>Scale Sets Only</p>

    <ul>
      <li>In Service Instances (Current)</li>
      <li>In Service Instances (Recommended)</li>
      <li>CPU Request (%) (Current)</li>
      <li>CPU Request (%) (Recommended)</li>
      <li>Memory Request (%) (Current)</li>
      <li>Memory Request (%) (Recommended)</li>
    </ul>
  </div>
</div>

#### Video Resources

<AccordionGroup>
  <Accordion title="Searching for a System">
    <iframe />

    <a href="https://player.vimeo.com/video/1044765242?badge=0&autopause=0&player_id=0&app_id=58479">Searching for a System</a>
  </Accordion>

  <Accordion title="Setting Filters in Columns">
    <iframe />

    <a href="https://player.vimeo.com/video/1039085173?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479">Setting Filters in Columns</a>
  </Accordion>

  <Accordion title="Using the Tree Viewer">
    <iframe />

    <a href="https://player.vimeo.com/video/1038945637?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479">Using the Tree Viewer</a>
  </Accordion>

  <Accordion title="Using the Utilization Charts">
    <iframe />

    <a href="https://player.vimeo.com/video/1042992591?badge=0&autopause=0&player_id=0&app_id=58479">Using the Utilization Charts</a>
  </Accordion>
</AccordionGroup>


# Catalog Map
Source: https://docs.kubex.ai/docs-kubex/Content/Cloudex/Catalog_Map_Tab



## Overview

The Kubex catalog map allows you to view a range of recommended instance type options for public cloud instances. The map view shows the AWS or Azure catalog scores for the selected instance.

<Note>
  **Note:** The catalog map is **not** currently available for ASGs, VM Scale Sets, GCP CE Instances or OCI Instances.
</Note>

Filters allow you to limit the catalog based on items such as processor type, processor features and instance cost.

### Page Navigation

The catalog map is displayed only when a single AWS and Azure cloud instance is selected in the tree viewer.

<Frame>
  <img alt="" />
</Frame>

<br />

<Frame>
  <img alt="" />
</Frame>

### Catalog Map Controls

The catalog map is populated with the analysis results for the single instance, selected in the tree viewer. Select any single AWS or Azure instance to see its map. The cloud provider's catalog options and the available instance sizes and their scores for the selected workload comprise the catalog map.

Use the following options to configure this report:

<Accordion title="Table: Catalog Map Controls">
  <table>
    <thead>
      <tr>
        <th>Setting</th>
        <th>Default</th>
        <th>Description</th>
      </tr>
    </thead>

    <tbody>
      <tr>
        <td>Show Instance Types that are:</td>
        <td>Commonly used options, that are available in the selected region are shown as a comma-separated list</td>

        <td>
          Select one or more of the following options to filter the list of instance types to be displayed in the catalog map.

          <ul>
            <li>Commonly used--Instances that are used by less than 0.5% of Kubex customers are considered to be NOT commonly used. These "exotic" instances are not included in the chart, unless the "Commonly Used" option is deselected.</li>
            <li>Available in the current region--Instance types available in the same region as the selected service.</li>
            <li>Meeting all policies--Instance types that comply with all policy settings that have been defined for the selected service.</li>
          </ul>
        </td>
      </tr>

      <tr>
        <td>Processor Supplier</td>
        <td>All</td>

        <td>
          Select one or more of the following options to filter the list of instance types to be displayed in the catalog map.

          <ul>
            <li>Intel</li>
            <li>AMD</li>
            <li>ARM</li>
          </ul>
        </td>
      </tr>

      <tr>
        <td>Spend Tolerance</td>
        <td>5X more than optimal</td>

        <td>
          Specify a spend tolerance value that determines cost compatibility. For example, selecting a value of 20% means that instance types that cost up to 20% more than the optimal instance type are considered compatible. You can choose a spend tolerance ranging from the exact cost of the optimal instance (No more than optimal) to no cost limit (Unlimited).
          Spend tolerance impacts the compatibility status of instance types that are technically compatible based on resource requirements. If an instance exceeds the specified spend tolerance, it will be shown in yellow to indicate it is technically compatible but not cost-efficient. As you increase the spend tolerance, more instance types will be within the acceptable range and change from yellow to green, indicating both technical and cost compatibility.
        </td>
      </tr>

      <tr>
        <td>Highlight Instance Features</td>

        <td />

        <td>
          Select one or more instance features that may improve the performance of your workload. Values displayed in this dropdown are based on the selected region and cloud provider.
          Selections are shown in the dropdown window as comma-separated values.
          Instance types with the selected features are not highlighted for services with a terminate recommendation.
        </td>
      </tr>
    </tbody>
  </table>
</Accordion>

The chart is refreshed immediately when you change any of the control options. Your settings are saved for the current user session and are returned to the default values if you log out or if another user opens the viewer.

### Catalog Map Legend

The score shown in each cell in the catalog map is based on the current utilization and the analysis results. These calculations account for both compatibility of the workload with an instance type's features and its monthly cost.

All instances that have been evaluated are displayed with their score displayed in colour-coded squares:

<Accordion title="Table: Catalog Map Legend">
  <table>
    <colgroup>
      <col />

      <col />

      <col />
    </colgroup>

    <thead>
      <tr>
        <th>Value</th>
        <th>Score Range</th>
        <th>Description</th>
      </tr>
    </thead>

    <tbody>
      <tr>
        <td>Current Instance</td>
        <td>N/A</td>
        <td>This is the current instance. If "Commonly used" instances are selected, you may not see the current instance.</td>
      </tr>

      <tr>
        <td>Meets All Policies</td>
        <td>Score ≥ 50 and Cost ≤ the selected Spend Tolerance.</td>

        <td>
          The best option, with the highest score is shown in green and other good options are shown in lighter shades of green.<br />
          Cost is the on-demand price \*
        </td>
      </tr>

      <tr>
        <td>Best Instance Type</td>
      </tr>

      <tr>
        <td>Outside Spend Tolerance</td>
        <td>Score ≥ 50 and Cost > the selected Spend Tolerance.</td>

        <td>
          These instances meet the technology and resource requirements of your workload, but their Cost exceeds the defined spend tolerance.<br />
          Cost is the on-demand price \*
        </td>
      </tr>

      <tr>
        <td>Technically Incompatible</td>
        <td>Score > 0 and \< 50</td>
        <td>These instances do not meet the technology requirements of the selected workload.</td>
      </tr>

      <tr>
        <td>Insufficient Resources</td>
        <td>Score = 0</td>
        <td>These instances do not meet the resource requirements of the selected workload.</td>
      </tr>

      <tr>
        <td>Not Available in \<region></td>
        <td>N/A</td>
        <td>These instance types do not exist in the selected region. The score is not displayed for these instance types.</td>
      </tr>

      <tr>
        <td>Instance Does Not Exist.</td>
        <td>N/A</td>
        <td>These instance types do not exist in the catalog. The score is not displayed for these instance types.</td>
      </tr>

      <tr>
        <td>Highlighted Instance Features</td>
        <td>N/A</td>
        <td>These instance types possess the specific feature selected from the "Highlight Instance Features" dropdown control.</td>
      </tr>

      <tr>
        <th>Value</th>
        <th>Image</th>
        <th>Description</th>
      </tr>

      <tr>
        <td>Show | Hide All Score Results</td>

        <td>
          <img alt="Toggle Scores" />
        </td>

        <td>Use this control to show/hide the score values.</td>
      </tr>
    </tbody>
  </table>
</Accordion>

You can hover over any square in the chart to see the following information:

<div>
  <ul>
    <li>Instance Type</li>
    <li>Score</li>

    <li>
      On-Demand Cost \*

      <a href="/docs-kubex/Content/Cloudex/AI_Analysis_Details_Table-Cloud#uptime25">
        Uptime (%)
      </a>
    </li>

    <li>Instance Availability</li>
  </ul>

  <Columns>
    <Frame>
      <img alt="Toggle Scores" />
    </Frame>

    <Frame>
      <img alt="Toggle Scores" />
    </Frame>
  </Columns>
</div>

### Summary Table

A summary table showing details of the current and recommended (optimal) instance type is displayed below the catalog map.

<Frame>
  <img alt="" />
</Frame>

You can select a third instance in the map to view its details and compare it to the current and recommended instance types:

Press Esc on your keyboard, or click the same tile again to cancel the selection.

Click on another tile to compare another instance type.

<Frame>
  <img alt="" />
</Frame>

### More Details

Click the chevrons (>) to see additional details for both instances.

The following details are provided for current and recommended instances. The indented columns are only displayed with you expand the table by clicking on the chevron to see additional details.

<Accordion title="Table: Catalog Map Summary Table Descriptions">
  <table>
    <colgroup>
      <col />

      <col />
    </colgroup>

    <thead>
      <tr>
        <th>Section</th>
        <th>Description</th>
      </tr>
    </thead>

    <tbody>
      <tr>
        <td>Instance Type</td>
        <td>The instance type name of current and optimal, recommendation.</td>
      </tr>

      <tr>
        <td>Overall Result</td>
        <td>A high-level summary of how Kubex determined the score.</td>
      </tr>

      <tr>
        <td>Within Spend Tolerance</td>

        <td>
          Indicates whether or not the estimated cost for the instance type is within the specified spend tolerance.<br />
          The monthly on-demand instance cost is based on the catalog per instance cost and the predicted uptime. Potential savings are also based on per instance cost and the predicted uptime.<br />
          The monthly cost is calculated as On-Demand Cost \* Uptime %<br />
          A warning message is displayed if the current instance type exceeds the spend tolerance.
        </td>
      </tr>

      <tr>
        <td>Analysis Details</td>

        <td>
          Specific details from the analysis results.<br />
          For non-terminate recommendations, possible descriptions include:

          <ul>
            <li>Save \<\$xx.xx> when using the recommended instance type;</li>
            <li>Cost of the selected instance type is greater than the specified Spend Tolerance. A warning indicator for the current and/or selected instance is displayed.</li>
            <li>A dash (-) is displayed if there are no significant details.</li>
          </ul>
        </td>
      </tr>

      <tr>
        <td>Technically Compatible</td>
        <td>Indicates whether or not the instance type meets the technical requirements of the workloads.</td>
      </tr>

      <tr>
        <td>Instance Features</td>
        <td>Lists specific features that contributed to the score and match your workload's characteristics.</td>
      </tr>

      <tr>
        <td>Sufficient Resources</td>
        <td>Indicates whether or not the instance has sufficient resources to run the workloads.</td>
      </tr>

      <tr>
        <td>Analysis Details</td>
        <td>Specific details from the analysis results.</td>
      </tr>

      <tr>
        <td>Processor</td>
        <td>Specific details of the processor on which the instance type is based are listed.</td>
      </tr>

      <tr>
        <td>CPU</td>
        <td>The number of available vCPU/CPUs.</td>
      </tr>

      <tr>
        <td>Memory</td>
        <td>The amount of available memory in GB.</td>
      </tr>
    </tbody>
  </table>
</Accordion>

## Reviewing Instance Type Options

See the following video for an overview of how the score is determined and how to use the catalog map and the API to automate optimization of your AWS and Azure environments.

<Accordion title="Video: Selecting the Right Infrastructure">
  <iframe />
</Accordion>


# Optimizing Public Cloud
Source: https://docs.kubex.ai/docs-kubex/Content/Cloudex/Cloud_Analysis



<InlineImageWithText>
  Kubex provides a simple, yet powerful interface to optimize your public cloud environment. The <a href="/docs-kubex/Content/Cloudex/Using_the_Cloud_Tree_Viewer">tree viewer</a> offers an intuitive and efficient way to navigate and explore your public cloud environment. See <a href="/docs-kubex/Content/Kubex/Visualizing_Your_Data">Visualizing Your Data</a> for details of navigation and other UI features.
</InlineImageWithText>

<InlineImageWithText>
  Use the <a href="/docs-kubex/Content/Cloudex/Cloud_Connections">Connections</a> button to monitor the status of data collection for each of your clusters. The Connections icon is the last option in the Cloud bar.
</InlineImageWithText>

<Frame>
  <img alt="" />
</Frame>

Various reporting tabs provide all the required features:

<ul>
  <li>
    <a href="/docs-kubex/Content/Cloudex/Summary_Tab-Cloud"> Summary </a>
    \--Shows a graphical summary of the selected scope of systems. Use the tree viewer to select the scope of systems to incude.
  </li>

  <li>
    <a href="/docs-kubex/Content/Cloudex/AI_Analysis_Details_Table-Cloud"> Analysis Details </a>
    \--Shows analysis details of the selected scope of your environment in various tabular views with utilization charts for a selected system.
  </li>

  <li>
    <a href="/docs-kubex/Content/Kubex/Overview_Tab"> Overview </a> and <a href="/docs-kubex/Content/Cloudex/Catalog_Map_Tab"> Catalog Map </a>
    \--These tabs are only available when a single instance is selected.
  </li>
</ul>

#### Video Resources

<AccordionGroup>
  <Accordion title="Using the Tree Viewer">
    <iframe />

    <a href="https://player.vimeo.com/video/1038945637?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479">Using the Tree Viewer</a>
  </Accordion>
</AccordionGroup>


# Data Collection Status
Source: https://docs.kubex.ai/docs-kubex/Content/Cloudex/Cloud_Connections



## Data Collection Status Details

<InlineImageWithText>
  <p>Access this page from the side panel. The Connections icon is the last option in the Cloud bar.</p>
  <p>You can monitor the status of data collection for each of your clusters, from this page.</p>
</InlineImageWithText>

<Frame>
  <img alt="" />
</Frame>

See [Using Table Column Features](/docs-kubex/Content/Kubex/Using_Table_Column_Features) for details on setting filters and customizing views of the table's content.

## Standard Data Collection

Kubex collects configuration and utilization data from your public cloud environments and then analyzes the data to provide resizing recommendations to run your cloud-based applications on the correct infrastructure.<br />

Before creating a connection you need to grant access to Kubex so that it can connect to your accounts and collect data. Granting access is slightly different for each of the supported cloud providers:

<ul>
  <li>
    <a href="/docs/WebHelp_Densify_Cloud/Content/Data_Collection_for_Public_Cloud_Systems/AWS_Data_Collection_Using_a_CloudFormation_Template">
      AWS Data Collection Using a CloudFormation Template
    </a>
  </li>

  <li>
    <a href="/docs/WebHelp_Densify_Cloud/Content/Data_Collection_for_Public_Cloud_Systems/AWS_Data_Collection_Prerequisites_for_an_IAM_Role__CloudWatch_only_">
      AWS Data Collection Using IAM Roles Prerequisites
    </a>
  </li>

  <li>
    <a href="/docs/WebHelp_Densify_Cloud/Content/Data_Collection_for_Public_Cloud_Systems/Microsoft_Azure_Data_Collection_Prerequisites_for_a_Service_Principal">
      Microsoft Azure Data Collection Prerequisites
    </a>
  </li>

  <li>
    <a href="/docs/WebHelp_Densify_Cloud/Content/Data_Collection_for_Public_Cloud_Systems/Google_Cloud_Platform_Data_Collection_Prerequisites">
      Google Cloud Platform Data Collection Prerequisites
    </a>
  </li>

  <li>
    <a href="/docs/WebHelp_Densify_Cloud/Content/Data_Collection_for_Public_Cloud_Systems/Oracle_Cloud_Infrastructure_Data_Collection_Prerequisites">
      Oracle Cloud Infrastructure Data Collection Prerequisites
    </a>
  </li>
</ul>

Once you have completed the prerequisites you can create the connections using the Add button. See the following for details.

<ul>
  <li>
    <a href="/docs-kubex/Content/Cloudex/Data_Collection_AWS_Connections">
      Creating AWS Cloud Connections
    </a>
  </li>

  <li>
    <a href="/docs-kubex/Content/Cloudex/Data_Collection_Azure_Connections">
      Creating Azure Cloud Connections
    </a>
  </li>

  <li>
    <a href="/docs-kubex/Content/Cloudex/Data_Collection_GCP_Connections">
      Creating GCP Cloud Connections
    </a>
  </li>

  <li>
    <a href="/docs-kubex/Content/Cloudex/Data_Collection_OCI_Connections">
      Creating OCI Cloud Connections
    </a>
  </li>
</ul>

## Reviewing Data Collection Status

Once the connections are created, data will be collected and stored for detailed analysis. As data is collected the Connections table is populated/updated with the status of each connection.<br />

Data collection details will appear in this table within a few minutes, but your instance-specific data will not appear in the tree viewer until it has been analyzed, usually within 24-hrs. This is also the case for all reports/tabs that show the analyzed data and resulting recommendations.

<Accordion title="Table: Connections Table">
  <table>
    <colgroup>
      <col />

      <col />
    </colgroup>

    <thead>
      <tr>
        <th>Column</th>
        <th>Description</th>
      </tr>
    </thead>

    <tbody>
      <tr>
        <td>Connection Name</td>

        <td>
          The name of connection, as specified when you create the connection.

          <br />

          If the name is longer than the column width, hover over the name to see the full string in a popup.
        </td>
      </tr>

      <tr>
        <td>Cloud Provider</td>

        <td>
          The name of the public cloud provider.
        </td>
      </tr>

      <tr>
        <td>No. of Accounts | Subscriptions | Projects</td>

        <td>
          The specific subscription or project name or account number.
        </td>
      </tr>

      <tr>
        <td>First Collection</td>

        <td>
          The date and time on which data was first collected.
        </td>
      </tr>

      <tr>
        <td>Last Collection</td>

        <td>
          The date and time on which data was last collected.
        </td>
      </tr>

      <tr>
        <td>Latest Service Count</td>

        <td>
          The number of services that were discovered during the last collection. This value is populated only after data collection has been run once, and immediately after a connection has been created.
        </td>
      </tr>
    </tbody>
  </table>
</Accordion>

The last collection data and service count are updated each time data is collected. This is done daily, on a schedule that usually runs overnight.


# Connecting AWS to Kubex
Source: https://docs.kubex.ai/docs-kubex/Content/Cloudex/Data_Collection_AWS_Connections



You can connect to your AWS account with the following method:

<ul>
  <li>
    CloudFormation Template--You need your account credentials and an external ID, which corresponds to a password.  See <a href="/docs/WebHelp_Densify_Cloud/Content/Data_Collection_for_Public_Cloud_Systems/AWS_Data_Collection_Using_a_CloudFormation_Template">AWS Data Collection Using a CloudFormation Template</a> for details on creating the connection. Once the connections are created, you will see them in the <a href="/docs-kubex/Content/Cloudex/Cloud_Connections">Cloud Connections</a>
    page.
  </li>

  <li>
    IAM Role--An IAM role establishes a trust relationship between AWS accounts and <span>Kubex</span>. You need to complete the prerequisite setup in your AWS account, including the external ID and Role ARN. See <a href="/docs/WebHelp_Densify_Cloud/Content/Data_Collection_for_Public_Cloud_Systems/AWS_Data_Collection_Prerequisites_for_an_IAM_Role__CloudWatch_only_">AWS Data Collection Using IAM Roles Prerequisites</a>.
  </li>
</ul>

## Configuring a Connection to AWS

<ol>
  <li>
    Click the <strong>Add</strong> button and select AWS.

    <Frame>
      <img />
    </Frame>
  </li>

  <li>
    The Kubex Account ID is predefined. This value must match the value you entered when you created the role in AWS.

    <Frame>
      <img />
    </Frame>
  </li>

  <li>
    Enter the AWS-specific connection parameters, listed in the table below.
  </li>

  <div>
    <Accordion title="Table: AWS Connection Parameters">
      <table>
        <colgroup>
          <col />

          <col />
        </colgroup>

        <thead>
          <tr>
            <th>Field</th>
            <th>Description</th>
          </tr>
        </thead>

        <tbody>
          <tr>
            <td>External ID</td>

            <td>
              The external ID specified for Kubex, when you created the IAM role in AWS.

              <br />

              If you need to edit or review a saved connection, for security reasons, you will need to re-enter the external ID.
            </td>
          </tr>

          <tr>
            <td>Role ARN</td>

            <td>
              The Amazon Resource Name (ARN) for the IAM role that you created in AWS.
            </td>
          </tr>
        </tbody>
      </table>
    </Accordion>
  </div>

  <Note>
    <strong>Note:</strong> The External ID and the Role ARN are encrypted and are not displayed as plain text in log files.
  </Note>

  <li>
    Verify your connection by clicking <strong>Verify Connection</strong>.

    <ul>
      <li>
        If the credentials are valid, you will be connected and authenticated.
      </li>

      <li>
        If the credentials cannot be validated, then review the displayed error message and correct your credentials. It is possible that the user account does not have the required permissions or that the IAM role has not been setup properly. See <a href="/docs/WebHelp_Densify_Cloud/Content/Data_Collection_Troubleshooting/AWS_Cloud_Connections">Troubleshooting AWS Cloud Connections</a> for details.
      </li>
    </ul>
  </li>

  <li>
    Once the account is verified, discovers the AWS account ID and displays the ID number in a second dialog box.

    <Note>
      <strong>Note:</strong> The number of instances returned is an estimate obtained when Kubex verifies the connectivity. It may not match the number of instances discovered during the more detailed, scheduled data collection.
    </Note>
  </li>

  <li>
    Optionally, specify a connection name to clearly identify the AWS account in Kubex. This name will appear in the <strong>Cloud Connections</strong> list so you can easily identify this connection.

    <Frame>
      <img />
    </Frame>

    <p>The connection name must be unique within the AWS connection type section, so if the name is already in use, you are prompted to enter a new connection name.</p>
    <p>The Connection Name is limited to 32-characters.</p>
  </li>

  <li>
    Click the <strong>Save Connection</strong> button, that appears when the connection is successfully verified.
    <p>The connection table is updated with your new connection listed. Actual data collection will begin at the scheduled time, usually overnight.</p>
  </li>

  <li>If you want to add another connection, click <strong>Add</strong> and repeat these steps to configure the connection.</li>
</ol>


# Connecting Azure to Kubex
Source: https://docs.kubex.ai/docs-kubex/Content/Cloudex/Data_Collection_Azure_Connections



Kubex uses a Service Principal to access one or more of your Azure subscriptions. See [Microsoft Azure Data Collection Prerequisites](/docs/WebHelp_Densify_Cloud/Content/Data_Collection_for_Public_Cloud_Systems/Microsoft_Azure_Data_Collection_Prerequisites_for_a_Service_Principal) for details on configuring the Service Principal and obtaining the required credentials.

## Configuring Microsoft Azure Connections

<ol>
  <li>Click the **Add** button and select Azure.</li>

  <Frame>
    <img />
  </Frame>

  <Frame>
    <img />
  </Frame>

  <li>
    Enter the Azure-specific connection parameters. A link in the header takes you to the online help.
    <p>Table: Azure Connection Parameters</p>

    <table>
      <colgroup>
        <col />

        <col />
      </colgroup>

      <thead>
        <tr>
          <th>Field</th>
          <th>Description</th>
        </tr>
      </thead>

      <tbody>
        <tr>
          <td>Application ID</td>

          <td>
            Specify the Application ID/Service Principal. Both the ID and the corresponding key are provided when you create the application through your Azure portal.
          </td>
        </tr>

        <tr>
          <td>Secret Key</td>

          <td>
            Enter the key corresponding to your application/service principal. This is called the Client Secret in the Azure portal interface.
          </td>
        </tr>

        <tr>
          <td>Tenant ID</td>

          <td>
            The Directory (tenant) ID is a unique identifier that represents your Azure Active Directory tenant.
          </td>
        </tr>
      </tbody>
    </table>
  </li>

  <li>
    Click **Verify Connection** to validate your settings.

    <ul>
      <li>
        If the credentials are valid, you will be connected and authenticated.
      </li>

      <li>
        If the credentials cannot be validated, then review the displayed error message and correct your credentials. See <a href="/docs/WebHelp_Densify_Cloud/Content/Data_Collection_Troubleshooting/Azure_Cloud_Connections">Troubleshooting Azure Cloud Connections</a> for details.
      </li>
    </ul>
  </li>

  <li>Once the account is verified, all subscriptions that are associated with the account or Application ID are listed. Select the subscriptions that you want to include in this connection.</li>

  <Note>
    <strong>Note:</strong> The number of instances returned is an estimate obtained when Kubex verifies the connectivity. It may not match the number of instances discovered during the more detailed, scheduled data collection.
  </Note>

  <Frame>
    <img />
  </Frame>

  <li>
    Specify a connection name to clearly identify the Azure subscription in Kubex. This name will appear in the <strong>Cloud Connections</strong> list so you can easily identify this connection.

    <Frame>
      <img />
    </Frame>

    <p>The connection table is updated with your new connection listed. Actual data collection will begin at the scheduled time, usually overnight.</p>
  </li>

  <li>If you want to add another connection, click **Add** and repeat these steps to configure the connection.</li>

  <Note>
    <strong>Note:</strong> If you create another connection, you must ensure subscriptions are not included in more than one cloud connection, and each connection name must be unique.
  </Note>
</ol>


# Connecting GCP to Kubex
Source: https://docs.kubex.ai/docs-kubex/Content/Cloudex/Data_Collection_GCP_Connections



Kubex uses an API-Key user to access your Google Cloud Platform (GCP) project. See [Google Cloud Platform Data Collection Prerequisites](/docs/WebHelp_Densify_Cloud/Content/Data_Collection_for_Public_Cloud_Systems/Google_Cloud_Platform_Data_Collection_Prerequisites) for details on configuring the API-Key user and obtaining the required credentials.

## Configuring GCP Connections

<ol>
  <li>
    Click the **Add** button and select GCP.

    <Frame>
      <img />
    </Frame>
  </li>

  <li>
    Enter the GCP-specific connection parameters.

    <Frame>
      <img />
    </Frame>

    <Accordion title="Table: GCP Connection Parameters">
      <table>
        <colgroup>
          <col />

          <col />
        </colgroup>

        <thead>
          <tr>
            <th>Field</th>
            <th>Description</th>
          </tr>
        </thead>

        <tbody>
          <tr>
            <td>Service Account Key File</td>

            <td>
              The JSON key file for the service account you created in GCP for Kubex data collection.
            </td>
          </tr>

          <tr>
            <td>Client ID</td>

            <td>
              The client ID for the service account you created in GCP for Kubex data collection. This is auto filled when you upload the service account key file.
            </td>
          </tr>

          <tr>
            <td>Client Email</td>

            <td>
              The client email for the service account you created in GCP for Kubex data collection. This is auto filled when you upload the service account key file.
            </td>
          </tr>
        </tbody>
      </table>
    </Accordion>
  </li>

  <li>
    Verify your connection by clicking the **Verify Connection** button.

    <ul>
      <li>
        If the credentials are valid, you will be connected and authenticated.
      </li>

      <li>
        If the credentials cannot be validated, then review the displayed error message and correct your credentials. See <a href="/docs/WebHelp_Densify_Cloud/Content/Data_Collection_Troubleshooting/GCP_Cloud_Connections">Troubleshooting GCP Cloud Connections</a> for details.
      </li>
    </ul>
  </li>

  <li>
    Once the account is verified, the available projects that are associated with the service account are listed. Select the projects that you want to include in this connection and click **Next**.
  </li>

  <Frame>
    <img />
  </Frame>

  <li>
    Review the connection details and add a name for your connection. Click **Save** to save the connection.
  </li>

  <Frame>
    <img />
  </Frame>

  <li>
    If you want to connect another tenancy, click **Add** and repeat these steps to configure the connection.
  </li>
</ol>


# Connecting OCI to Kubex
Source: https://docs.kubex.ai/docs-kubex/Content/Cloudex/Data_Collection_OCI_Connections



Kubex uses an API-Key user to access your Oracle Cloud Infrastructure (OCI) tenancy. See [Oracle Cloud Infrastructure Data Collection Prerequisites](/docs/WebHelp_Densify_Cloud/Content/Data_Collection_for_Public_Cloud_Systems/Oracle_Cloud_Infrastructure_Data_Collection_Prerequisites) for details on configuring the API-Key user and obtaining the required credentials.

## Configuring OCI Connections

<ol>
  <li>
    Click the **Add** button and select OCI.

    <Frame>
      <img />
    </Frame>
  </li>

  <li>
    Enter the OCI-specific connection parameters.

    <Frame>
      <img />
    </Frame>

    <Accordion title="Table: OCI Connection Parameters">
      <table>
        <colgroup>
          <col />

          <col />
        </colgroup>

        <thead>
          <tr>
            <th>Field</th>
            <th>Description</th>
          </tr>
        </thead>

        <tbody>
          <tr>
            <td>Tenancy OCID</td>

            <td>
              The Oracle Cloud Identifier (OCID) for your tenancy.
            </td>
          </tr>

          <tr>
            <td>User OCID</td>

            <td>
              The OCID for the API-Key user you created in the OCI Console for Kubex data collection.
            </td>
          </tr>

          <tr>
            <td>Region Identifier</td>

            <td>
              The identifier for the home region assigned to your tenancy.
            </td>
          </tr>

          <tr>
            <td>API Key Fingerprint</td>

            <td>
              The fingerprint for the API key you created in OCI for the Kubex data collection user.
            </td>
          </tr>

          <tr>
            <td>Private Key File</td>

            <td>
              The private key file you created in OCI for the Kubex data collection user. This file must be in PEM format.
            </td>
          </tr>
        </tbody>
      </table>
    </Accordion>
  </li>

  <li>
    Verify your connection by clicking the **Verify Connection** button.

    <ul>
      <li>
        If the credentials are valid, you will be connected and authenticated.
      </li>

      <li>
        If the credentials cannot be validated, then review the displayed error message and correct your credentials. See <a href="/docs/WebHelp_Densify_Cloud/Content/Data_Collection_Troubleshooting/OCI_Cloud_Connections">Troubleshooting OCI Cloud Connections</a> for details.
      </li>
    </ul>
  </li>

  <li>
    Once the connection to the tenancy is verified, you can edit the connection name or use the prefilled tenancy name. This name will appear in the **Cloud Connections** list so you can easily identify this connection. When ready, click the **Save** button to save your connection.
  </li>

  <Frame>
    <img />
  </Frame>

  <li>
    If you want to connect another tenancy, click **Add** and repeat these steps to configure the connection.
  </li>
</ol>


# Overview
Source: https://docs.kubex.ai/docs-kubex/Content/Cloudex/Data_Collection_Overview-Cloud



Use the <strong>Cloud Connections</strong> > <strong>Add</strong> button to create your cloud connections. Collected configuration and workload data from your public cloud accounts is analyzed and used to generate sizing and instance type recommendations.

## Supported Public Cloud Providers

The following cloud platforms are currently supported in Kubex:

See [Supported Platforms and Integrations - Public Cloud Platforms](/docs-kubex/Content/General/supported_platforms#public-cloud-platforms) for the complete list.

<Frame>
  <img alt="" />
</Frame>

## Required User Roles

When working with cloud connections, all users can access and view the cloud connections page.

Only a user assigned to the "SaaS\_Audit\_Admin" group can create public cloud connections. See [Managing Kubex User Accounts](/docs/WebHelp_Densify_Cloud/Content/Densify_Com/Managing_Densify_User_Accounts) for details on adding the role to your user account.

<Frame>
  <img />
</Frame>

<ul>
  <li>
    <a href="/docs-kubex/Content/Cloudex/Data_Collection_AWS_Connections">
      Amazon Web Services
    </a>
  </li>

  <li>
    <a href="/docs-kubex/Content/Cloudex/Data_Collection_Azure_Connections">
      Azure Cloud
    </a>
  </li>

  <li>
    <a href="/docs-kubex/Content/Cloudex/Data_Collection_GCP_Connections">
      Google Cloud Platform
    </a>
  </li>

  <li>
    <a href="/docs-kubex/Content/Cloudex/Data_Collection_OCI_Connections">
      Oracle Cloud Infrastructure
    </a>
  </li>
</ul>

## API Access

You can collect and analyze cloud data through the Kubex API. Refer to the following use cases for examples:

<ul>
  <li>
    <a href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Optimizing_AWS_EC2_Instances">
      Optimizing AWS EC2 Instances
    </a>
  </li>

  <li>
    <a href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Optimizing_Microsoft_Azure_Virtual_Machine_Instances">
      Optimizing Microsoft Azure Virtual Machine Instances
    </a>
  </li>

  <li>
    <a href="/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Optimizing_GCP_Compute_Engine_Instances">
      Optimizing GCP Compute Engine Instances
    </a>
  </li>
</ul>

## Considerations when Working with Large Environments

In large environments, Kubex highly recommends batching your accounts into smaller groups for improved performance when creating the cloud connections. i.e. 10 accounts at a time. You can use a resource tag, such as organization or business unit to split the total number of accounts so that is collected in manageable batches


# Cloud Instance Overview
Source: https://docs.kubex.ai/docs-kubex/Content/Cloudex/Overview_Tab-Cloud



The cards on this tab provide a visual overview of a single instance. When navigating the [tree viewer](/docs-kubex/Content/Kubex/Using_the_Tree_Viewer), you will see this tab when a single scale set or instance is selected.

<Frame>
  <img alt="" />
</Frame>

You will also see a popup of this page when you click the "System Name" hyperlink in the [Analysis Details](/docs-kubex/Content/Kubex/AI_Analysis_Details_Table#hyperlink) tab.

### Impact Analysis and Recommendation Report

The Impact Analysis and Recommendation report provides a PDF version of the instance details. You can easily share this report with the application owner to share your proposed sizing recommendations.

You can also share the link.

<div>
  <div>
    <Frame>
      <img />
    </Frame>

    <Frame>
      <img />
    </Frame>
  </div>

  <div>
    <Note>
      Note:  This report is not available for Azure VM Scale Sets.
    </Note>

    Click the link in the upper corner to download a PDF version of the Impact Analysis and Recommendation Report.

    <br />

    <br />

    When you click the button, a popup opens with a link. You can save or download the file.

    <br />

    <br />

    The filename will be `<cloud provider>_<system name>_<system_id>.pdf`
  </div>
</div>

You also have access to the [metrics viewer](/docs-kubex/Content/Kubex/Metrics_Viewer_Tab) when a single container is selected.

### Optimization Summary

Hover over any of the listed items to see a brief description. Complete descriptions of each setting are provided in the [Analysis Details Table](/docs-kubex/Content/Cloudex/AI_Analysis_Details_Table-Cloud).

### Optimization Summary - Single VM Instances

Instance details and key metrics are displayed for the current and recommended instance types.

<div>
  <Frame>
    <img />
  </Frame>

  <ul>
    <li>
      <Tooltip>Instance Type</Tooltip>
    </li>

    <li>
      <Tooltip>
        Monthly Cost
      </Tooltip>
    </li>

    <li>
      <Tooltip>CPU</Tooltip>
    </li>

    <li>
      <Tooltip>CPU Benchmark</Tooltip>
    </li>

    <li>
      <Tooltip>Memory</Tooltip>
    </li>
  </ul>
</div>

### Optimization Summary Block - Single Scale Set

Instance details and key metrics are displayed for the current and recommended instance types for a scale set.

<div>
  <Frame>
    <img />
  </Frame>

  <ul>
    <li>
      <Tooltip>
        Optimization Summary
      </Tooltip>
    </li>

    <li>
      <Tooltip>
        Policy
      </Tooltip>
    </li>

    <li>
      <Tooltip>
        Monthly Waste
      </Tooltip>
    </li>

    <li>
      <Tooltip>
        Effort
      </Tooltip>
    </li>

    <li>
      <Tooltip>
        Instance Type
      </Tooltip>
    </li>

    <li>
      <Tooltip>
        Group Size
      </Tooltip>
    </li>

    <li>
      <Tooltip>
        Avg No. of Instances
      </Tooltip>
    </li>

    <li>
      <Tooltip>
        Monthly Cost
      </Tooltip>
    </li>

    <li>
      <Tooltip>
        CPU
      </Tooltip>
    </li>

    <li>
      <Tooltip>
        CPU Benchmark
      </Tooltip>
    </li>

    <li>
      <Tooltip>
        Memory
      </Tooltip>
    </li>
  </ul>
</div>

## System Details

This card summarizes the identification details for the selected instance. The same details are provided for a single VM or scale set.

<div>
  <Frame>
    <img />
  </Frame>

  <ul>
    <li>
      <Tooltip>
        Cloud Provider
      </Tooltip>
    </li>

    <li>
      <Tooltip>
        Service Type
      </Tooltip>
    </li>

    <li>
      <Tooltip>
        System Name
      </Tooltip>
    </li>

    <li>
      <Tooltip>
        System ID
      </Tooltip>
    </li>

    <li>
      <Tooltip>
        Instance OS
      </Tooltip>
    </li>

    <li>
      <Tooltip>
        Service Type
      </Tooltip>
    </li>

    <li>
      <Tooltip>
        System Name
      </Tooltip>
    </li>

    <li>
      <Tooltip>
        System ID
      </Tooltip>
    </li>

    <li>
      <Tooltip>
        Instance OS
      </Tooltip>
    </li>

    <li>
      <Tooltip>
        Account Name/ID
      </Tooltip>
    </li>

    <li>
      <Tooltip>
        Region/Availability Zone
      </Tooltip>
    </li>
  </ul>
</div>

## Status Overview

This card summarizes the status of this instance within Kubex.

<div>
  <Frame>
    <img />
  </Frame>

  <ul>
    <li>
      <Tooltip>
        Creation Date
      </Tooltip>
    </li>

    <li>
      <Tooltip>
        State
      </Tooltip>
    </li>

    <li>
      <Tooltip>
        Discovery Date
      </Tooltip>
    </li>

    <li>
      <Tooltip>
        Predicted Uptime %
      </Tooltip>
    </li>

    <li>
      <Tooltip>
        Instance Type Updated On
      </Tooltip>
    </li>
  </ul>
</div>

## Utilization Charts

The bottom section shows the utilization charts for the selected instance. These charts show hourly min/max and sustained activity for the selected system. The charts show the current and the recommended settings for selected workloads. If the selected instance is "Just Right" then there are no charts for the recommended instance type.

See [Analysis Details Utilization Charts](/docs-kubex/Content/Kubex/AI_Analysis_Details_Charts) for details on using these charts to review workload data.

<Frame>
  <img alt="" />
</Frame>

<div>
  <ul>
    <li>
      CPU Utilization (

      <Tooltip>
        Predicted Day
      </Tooltip>

      )
    </li>

    <li>CPU Utilization - Busiest Day</li>
    <li>Memory Utilization</li>
  </ul>

  <ul>
    <li>In Service Instances (for ASG and VMSS only)</li>
    <li>Network I/O Bytes</li>
    <li>Network I/O Packets</li>
  </ul>
</div>

### Expanded Modal View

You can also expand any chart to the modal view and select from the following options for review.

<InlineImageWithText>
  Clicking the zoom button opens the chart in a modal view with additional options to view the collected and analyzed data.
</InlineImageWithText>

<Frame>
  <img alt="" />
</Frame>

The following options allow you to view all details of your data:

<div>
  <ul>
    <li>
      <Tooltip>
        ML Model
      </Tooltip>
    </li>

    <li>
      <Tooltip>
        Historical Daily
      </Tooltip>
    </li>
  </ul>

  <ul>
    <li>
      <Tooltip>
        Historical Hourly
      </Tooltip>
    </li>

    <li>
      <Tooltip>
        Historical (5 Min)
      </Tooltip>
    </li>
  </ul>
</div>


# Cloud Optimization Summary
Source: https://docs.kubex.ai/docs-kubex/Content/Cloudex/Summary_Tab-Cloud



This tab is the landing page for your cloud environments. The charts on this tab allow you to quickly understand the optimization potential in your public cloud environments. Your environment's efficiency and wasted spend are shown in the status bar at the top.

<Frame>
  <img alt="" />
</Frame>

The charts provide a concise summary of the environment and a breakdown of how optimization recommendations can provide immediate savings. You can clearly see the impact of taking the recommendations to reduce risk in your environment. You can also see the wasted resources that can be safely removed after you have eliminated risks.

The content on this tab is based on your selection in the tree viewer.

When a single instance is selected in the tree viewer, you will see the [Overview](/docs-kubex/Content/Cloudex/Overview_Tab-Cloud) and the [Catalog Map](/docs-kubex/Content/Cloudex/Catalog_Map_Tab) tabs.

## Overall Monthly Spend

This first chart summarizes your current spend and compares this to what you should be spending, based on utilization.

<Frame>
  <img alt="" />
</Frame>

These cards provide:

<ul>
  <li>
    A link to the <a href="/docs-kubex/Content/Cloudex/AI_Analysis_Details_Table-Cloud">
    Analysis Details</a> page, filtered to the selected scope of systems.
  </li>

  <li>A link to open a modal view showing a breakdown of spending on each service type and possible savings.</li>
  <li>The overall efficiency rating.</li>
</ul>

### Efficiency Rating

The Efficiency Rating provides an indication of the health of your aggregated environment.

<ul>
  <li>A value of 1 indicates that, at an aggregate level, the environment is efficient according to the defined policy settings.</li>
  <li>A value less than 1 indicates potential savings opportunities due to over-allocated resources.</li>
  <li>A value greater than 1 indicates potential risks due to under-allocated resources. The value is indicated in red, when it is greater than 1.</li>
</ul>

### Wasted/Shortfall Spend Estimates

The current and recommended estimated instance costs are used to calculate potential savings or additional spend.

Calculated as: (current estimated cost - recommended estimated cost).

<ul>
  <li>The total estimated **Monthly Waste** is the sum of the selected instances with positive savings values.</li>
  <li>The shortfall cost (also in the summary bar) is the sum of all selected instances with negative savings values.</li>
</ul>

## Modal Views

The modal views show an inventory of the selected items, broken down by instance type, for the selected provider.
Links at each level take you to the [Analysis Details](/docs-kubex/Content/Cloudex/AI_Analysis_Details_Table-Cloud) page, filtered to the specific scope of systems.

<Frame>
  <img alt="" />
</Frame>

## Optimization Breakdown

This bar chart shows the breakdown of your cloud spending:

<Frame>
  <img alt="" />
</Frame>

<Accordion title="Table: Optimization Breakdown Table">
  <table>
    <colgroup>
      <col />

      <col />
    </colgroup>

    <thead>
      <tr>
        <th>Column</th>
        <th>Description</th>
      </tr>
    </thead>

    <tbody>
      <tr>
        <td>Current Spend</td>

        <td>
          The bar shows what you are currently spending on the instances, selected in the tree viewer.
        </td>
      </tr>

      <tr>
        <td>Immediate Savings</td>

        <td>
          Immediate savings can be achieved by optimizing specific instances.

          <br />

          A container qualifies for immediate savings if the "% of Nodes with CPU Saturation" is below a predefined threshold. For example, if the threshold is set at 50%, only containers where "% of Nodes with CPU Saturation" is less than 50% should be considered.

          <br />

          Immediate savings can be achieved by adjusting the Memory Request settings only for containers within Node Groups where Memory Request is the primary constraint.

          <br />

          Calculated as: Sum of immediate CPU savings + Sum of immediate memory savings
        </td>
      </tr>

      <tr>
        <td>Risk Removal</td>

        <td>
          Surplus CPU and memory are aggregated for all containers in the selected scope and used to determine this value.

          <br />

          Calculated as: Sum(Surplus CPU > 0 (in mcores)) / 1000 mcores/core \* CPU unit cost/core + Sum(Surplus mem > 0 (in MB)) / 1024 MB/GB \* Memory unit cost/GB
        </td>
      </tr>

      <tr>
        <td>Optimal Cost</td>

        <td>
          This is what the infrastructure should cost to run the selected workloads.

          <br />

          Calculated as ($Total Cost - $Total Estimated Waste).
        </td>
      </tr>

      <tr>
        <td>Additional Waste</td>

        <td>
          This is possible, additional savings that can be achieved.

          <br />

          Calculated as (\$Total Cost + Risk Removal - Immediate Savings - Optimal Cost).
        </td>
      </tr>
    </tbody>
  </table>
</Accordion>

## Optimization Breakdown - Details

These cards list the aggregated recommendations for the selected scope of systems, broken down by the same optimization opportunities listed above. These cards provide the details of the recommendations that comprise the total in the corresponding bar chart.
The values are colour-coded to easily identify wasted resources and systems at risk.
Links to the Analysis Details page, with the appropriate view applied, are provided so you can investigate the recommendation.

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>

Each card provides a hyperlink that takes you to the Analysis Details page, with the [relevant view](/docs-kubex/Content/Kubex/AI_Analysis_Details_Table#pre-cfg-views) selected.

#### Video Resources

<AccordionGroup>
  <Accordion title="Using the Tree Viewer">
    <iframe />

    <a href="https://player.vimeo.com/video/1038945637?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479">Using the Tree Viewer</a>
  </Accordion>
</AccordionGroup>


# Using the Cloud Tree Viewer
Source: https://docs.kubex.ai/docs-kubex/Content/Cloudex/Using_the_Cloud_Tree_Viewer



The tree viewer offers an intuitive and efficient way to navigate and explore your cloud environments.

<Frame>
  <img alt="" />
</Frame>

Use the tree viewer to select the scope of systems on which to report. As you navigate through the tree, the reports on the right update automatically to show your selected scope.
If you are using Kubex for container optimization, then see the following:

<div>
  <Frame>
    <img />
  </Frame>

  <div>
    <div>
      <Frame>
        <img />
      </Frame>

      <p>Use the <a href="/docs-kubex/Content/Kubex/Using_the_Tree_Viewer">container tree viewer</a> to navigate your container environment.</p>
    </div>

    <div>
      <Frame>
        <img />
      </Frame>

      <p>Use the <a href="/docs-kubex/Content/Kubex/Using_the_Node_Tree_Viewer">node tree viewer</a> to navigate node groups supporting your container environments.</p>
    </div>
  </div>
</div>

## Hiding the Tree Viewer

Once you have selected the scope of systems to review you can hide the tree viewer. If you are working on a smaller screen or laptop it will be easier to view tables and charts with the increased screen space.

<div>
  <div>
    <Frame>
      <img />
    </Frame>
  </div>

  <div>
    <p>By default, the tree view is pinned to the left side of the screen.</p>
    <p>When the viewer is pinned, click the chevrons to open/close the tree viewer.</p>
  </div>
</div>

<div>
  <div>
    <Frame>
      <img />
    </Frame>
  </div>

  <div>
    <p>Click the pin to hide the tree viewer.</p>\
    Use the <InlineImageWithText />icon on the main page, to open the tree viewer as required and the X to close it, when not required.
  </div>
</div>

## Views and Filters

The default view is your container hierarchy i.e. Cloud Provider > Cluster> Region> Service > Instance. This view can be customized to better manage your data. See [Creating Custom Views](/docs-kubex/Content/Kubex/Creating_Custom_Views).
You can also create customized filters to manage large sets of data. See [Creating Custom Filters](/docs-kubex/Content/Kubex/Creating_Custom_Filters).

## Navigating the Tree Viewer

The following icons are available, by default. You can create custom views based on other attributes that may not include any of the following items.

<Accordion title="Table: Tree Viewer Icons">
  <table>
    <colgroup>
      <col />

      <col />

      <col />
    </colgroup>

    <thead>
      <tr>
        <th>Icon</th>
        <th>Entity</th>
        <th>Description</th>
      </tr>
    </thead>

    <tbody>
      <tr>
        <td>
          <img />
        </td>

        <td>Cloud Environment</td>

        <td>
          The top level entity that contains your cloud infrastructure.
        </td>
      </tr>

      <tr>
        <td>
          <img />
        </td>

        <td>Region</td>

        <td>
          This represents a region. The region is the geographic location where your public cloud resources are located.
        </td>
      </tr>

      <tr>
        <td>
          <img />

          <img />

          <img />
        </td>

        <td>Service Type</td>

        <td>
          This represents the type of service. Currently the following types are supported:

          <ul>
            <li>AWS EC2, RDS and ASG</li>
            <li>Azure VM and VM Scale Sets</li>
            <li>GCP Compute Instance</li>
          </ul>
        </td>
      </tr>

      <tr>
        <td>
          <img />

          <img />

          <img />
        </td>

        <td>Provider</td>

        <td>
          This represents your public cloud provider. Currently AWS, Azure and GCP are supported.
        </td>
      </tr>

      <tr>
        <td>
          <img />
        </td>

        <td>Instance</td>

        <td>
          This represents an individual instance.
        </td>
      </tr>

      <tr>
        <td>
          <img />
        </td>

        <td>Other Grouping</td>

        <td>
          Represents other attributes or labels that have been used to group the data.
        </td>
      </tr>
    </tbody>
  </table>
</Accordion>

## Instance Counts

You can see a count of the number of instances at each branch of the tree viewer. When counts are very large, consider creating a [view](/docs-kubex/Content/Kubex/Creating_Custom_Views) or a [filter](/docs-kubex/Content/Kubex/Creating_Custom_Filters) to more efficiently view your systems.

<Frame>
  <img alt="" />
</Frame>

## Using the Tabs

Based on your selection in the tree viewer various tabs are displayed to view the selected data. When multiple systems are selected you see:

<ul>
  <li>
    <a href="/docs-kubex/Content/Cloudex/Summary_Tab-Cloud">
      Summary
    </a>

    \--Shows you a summary of how effectively your resources are being utilized.
  </li>

  <li>
    <a href="/docs-kubex/Content/Cloudex/AI_Analysis_Details_Table-Cloud">
      Analysis Details
    </a>

    \--Shows analysis details of the selected scope of your environment in various tabular views with utilization charts for a selected system.
  </li>
</ul>

When a single instance is selected you see:

<ul>
  <li>
    <a href="/docs-kubex/Content/Cloudex/Overview_Tab-Cloud">
      Overview
    </a>

    \--Shows you the utilization and recommendation details for the selected instance.
  </li>

  <li>
    <a href="/docs-kubex/Content/Cloudex/Catalog_Map_Tab">
      Catalog Map
    </a>

    \--Shows you collected and analyzed data for the selected instance.
  </li>
</ul>

#### Video Resources

<AccordionGroup>
  <Accordion title="Searching for a System">
    <iframe />

    <a href="https://player.vimeo.com/video/1044765242?badge=0&autopause=0&player_id=0&app_id=58479">Searching for a System</a>
  </Accordion>

  <Accordion title="Using the Tree Viewer">
    <iframe />

    <a href="https://player.vimeo.com/video/1038945637?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479">Using the Tree Viewer</a>
  </Accordion>
</AccordionGroup>


# Kubex Overview
Source: https://docs.kubex.ai/docs-kubex/Content/General/Kubex_Overview

Kubex is an autonomous resource optimization platform for Kubernetes and AI infrastructure

Kubex helps teams improve performance while reducing infrastructure waste by combining analytics, recommendations, and controlled automation.

Kubex is designed for organizations that need optimization at scale with governance. It supports platform operations where reliability, compliance, and cost control all matter.

<Frame>
  <img alt="" />
</Frame>

## Who Kubex Is For

Kubex is built for cross-functional teams that share responsibility for infrastructure outcomes:

* SRE and Platform Engineering teams that need to improve cluster efficiency without increasing operational risk
* FinOps and Cloud Operations teams that need measurable cost savings with technical context
* Engineering leaders who need consistent optimization practices across environments

## Core Capabilities

Kubex focuses on:

* Rightsizing Kubernetes containers
* Kubernetes Node optimization
* GPU optimization, including coordinated CPU, memory, storage, and GPU recommendations
* Guardrail-based automation to execute approved optimization actions safely
* Historical usage analytics to support proactive resource decisions
* Multi-environment support across major cloud and Kubernetes platforms

<Frame>
  <img alt="" />
</Frame>

## Common Use Cases

### 1. Reduce Kubernetes Waste

Identify overprovisioned workloads and right-size requests and limits to recover unused capacity while preserving application performance.

### 2. Improve Cluster and Workload Reliability

Use data-driven recommendations to reduce saturation risk, improve headroom planning, and prevent avoidable performance incidents.

### 3. Optimize AI and GPU Infrastructure

Improve utilization of expensive AI resources by tuning GPU allocations and scheduling decisions alongside compute and storage resources.

### 4. Scale Optimization with Governance

Apply optimization through policy-driven workflows with approvals, maintenance windows, and operational guardrails.

### 5. Align Engineering and FinOps Outcomes

Provide teams with a shared view of optimization opportunities so technical actions map directly to business outcomes.

## How Kubex Delivers Value

Kubex helps teams move from reactive tuning to continuous optimization. In practice, this means:

* Faster identification of high-impact optimization opportunities
* More confident execution through governed automation
* Better balance between performance objectives and cost efficiency
* Repeatable optimization workflows across Kubernetes and AI environments

## Related Topics

* [Getting Started with Kubex](/docs-kubex/Content/Kubex/Getting_Started_with_Kubex)
* [Data Collection Overview](/docs-kubex/Content/Kubex/Data_Collection_Overview)
* [Automation Overview](/docs-kubex/Content/Kubex/Automation_Overview)
* [Kubex AI Agent](/docs-kubex/Content/General/KubexAIAgent)


# Supported Platforms and Integrations
Source: https://docs.kubex.ai/docs-kubex/Content/General/supported_platforms



Kubex integrates with your platforms, observability tools, and open source frameworks to complement and enhance your existing infrastructure and workflows.

## Kubernetes Platforms

Kubex provides container and node optimization across all major Kubernetes distributions:

<div>
  <div>
    <img alt="AWS EKS" />

    <span>AWS EKS: Amazon Elastic Kubernetes Service</span>
  </div>

  <div>
    <img alt="Azure AKS" />

    <span>Azure AKS: Azure Kubernetes Service</span>
  </div>

  <div>
    <img alt="Google GKE" />

    <span>Google GKE: Google Kubernetes Engine</span>
  </div>

  <div>
    <img alt="Red Hat OpenShift" />

    <span>Red Hat OpenShift: Enterprise Kubernetes</span>
  </div>

  <div>
    <img alt="Rancher" />

    <span>Rancher: Multi-cloud Kubernetes management</span>
  </div>

  <div>
    <img alt="Nutanix NKP" />

    <span>Nutanix NKP: Nutanix Kubernetes Platform</span>
  </div>
</div>

## Public Cloud Platforms

Kubex optimizes infrastructure across all major cloud providers:

<div>
  <div>
    <img alt="AWS" />

    <span>AWS: EC2, RDS, Auto Scaling Groups</span>
  </div>

  <div>
    <img alt="Azure" />

    <span>Azure: Virtual Machines, Scale Sets</span>
  </div>

  <div>
    <img alt="Google Cloud" />

    <span>Google Cloud: Compute Engine instances</span>
  </div>

  <div>
    <img alt="Oracle Cloud" />

    <span>Oracle Cloud: OCI Compute instances</span>
  </div>

  <div>
    <img alt="Amazon ECS" />

    <span>Amazon ECS: Elastic Container Service</span>
  </div>
</div>

## Observability & Monitoring Integrations

Kubex augments optimization analysis by integrating with leading observability platforms:

<div>
  <div>
    <img alt="Prometheus" />

    <span>Prometheus: Ingest Kubernetes metrics for optimization analysis</span>
  </div>

  <div>
    <img alt="Datadog" />

    <span>Datadog: Collect monitoring and observability data</span>
  </div>

  <div>
    <img alt="New Relic" />

    <span>New Relic: Collect monitoring and observability data</span>
  </div>

  <div>
    <img alt="Grafana" />

    <span>Grafana: Visualize and explore metrics used by Kubex</span>
  </div>

  <div>
    <img alt="OpenTelemetry" />

    <span>OpenTelemetry: Collect distributed traces, metrics, and logs</span>
  </div>

  <div>
    <img alt="DCGM Exporter" />

    <span>DCGM Exporter: NVIDIA GPU performance and utilization metrics</span>
  </div>
</div>

## Process Automation Integrations

Kubex integrates with ticketing and infrastructure-as-code platforms:

<div>
  <div>
    <img alt="JIRA" />

    <span>JIRA: Automate optimization ticket creation and management</span>
  </div>

  <div>
    <img alt="ServiceNow" />

    <span>ServiceNow: Automate optimization ticket creation and management</span>
  </div>

  <div>
    <img alt="Terraform" />

    <span>Terraform: Align infrastructure as code with optimization outputs</span>
  </div>
</div>

## Deployment and Orchestration

<div>
  <div>
    <img alt="Helm" />

    <span>Helm: Deploy and manage Kubex components via Helm charts</span>
  </div>

  <div>
    <img alt="Karpenter" />

    <span>Karpenter: Optimize Kubernetes node provisioning and scaling</span>
  </div>
</div>

## AI and Advanced Capabilities

<div>
  <div>
    <img alt="MCP Server" />

    <span>MCP Server: Provide secure and structured access to optimization data for AI agents</span>
  </div>
</div>

## Marketplace Availability

Kubex is available on major cloud marketplaces:

* AWS Marketplace
* Azure Marketplace

## Industry Memberships

Kubex is a proud member of:

* **FinOps Foundation** – Committed to optimizing cloud costs
* **Linux Foundation** – Supporting open source development
* **Cloud Native Computing Foundation (CNCF)** – Advancing cloud native computing

## Getting Started

Ready to integrate Kubex with your infrastructure?

* [Get Started for Free](https://kubex.ai/product/trial/)
* [Book a Demo](https://kubex.ai/product/demo/)
* [View Full Integrations](https://kubex.ai/integrations/)

## Additional Resources

For platform-specific guidance and solutions:

* [OpenShift Optimization](https://kubex.ai/solutions/openshift/)
* [Amazon EKS Optimization](https://kubex.ai/solutions/amazon-eks/)
* [Azure AKS Optimization](https://kubex.ai/solutions/azure-aks/)
* [Google GKE Optimization](https://kubex.ai/solutions/google-gke/)
* [AWS Optimization](https://kubex.ai/amazon-web-services-aws-optimization/)
* [Azure Optimization](https://kubex.ai/azure-optimization/)
* [GCP Optimization](https://kubex.ai/google-cloud-optimization/)


# Automation Engine Configuration Reference
Source: https://docs.kubex.ai/docs-kubex/Content/Kubex/Automation_Engine_Configuration_Reference



This page highlights the most important configuration keys for Kubex Automation Engine.

## Required Values

| Key                          | Purpose                                      |
| ---------------------------- | -------------------------------------------- |
| `kubex.url.host`             | Kubex host (for example: `example.kubex.ai`) |
| `kubex.url.scheme`           | URL scheme used to build Kubex API base URL  |
| `kubex.clusterName`          | Cluster identifier sent to Kubex             |
| `kubexCredentials.username`  | Required when `createSecrets=true`           |
| `kubexCredentials.epassword` | Required when `createSecrets=true`           |
| `gateway.configSecretName`   | Required when `createSecrets=false`          |

## Core Operational Values

Commonly tuned fields:

* `replicaCount`
* `image.repository`
* `image.tag`
* `gateway.image.repository`
* `webhook.enabled`
* `webhook.certManager.enabled`
* `metrics.enabled`

## Global Configuration Values

These values render into the `GlobalConfiguration` custom resource:

* `globalConfiguration.recommendationReloadInterval`
* `globalConfiguration.rescanInterval`
* `globalConfiguration.mutationLogInterval`
* `globalConfiguration.snapshotInterval`
* `globalConfiguration.heartbeatInterval`
* `globalConfiguration.kubexAPIRequestTimeout`
* `globalConfiguration.automationEnabled`
* `globalConfiguration.respectKubexAutomation`
* `globalConfiguration.protectedNamespacePatterns`
* `globalConfiguration.webhookHealth.*`

## Helm-Managed Policy Values

If you use Helm to generate policies, key inputs are:

* `policy.defaultPolicy`
* `policy.policies`
* `scope[]`

These are mapped by the chart into cluster-scoped policy and strategy CRs.

## Full Reference

* Configuration Reference:
  [https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Configuration-Reference.md](https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Configuration-Reference.md)
* Global Configuration details:
  [https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Global-Configuration.md](https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Global-Configuration.md)
* Policy Configuration:
  [https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Policy-Configuration.md](https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Policy-Configuration.md)
* Policy Evaluation reference:
  [https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Policy-Evaluation.md](https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Policy-Evaluation.md)
* Rollback Backoff:
  [https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Rollback-Backoff.md](https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Rollback-Backoff.md)
* GPU Sharing with KAI:
  [https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/GPU-Sharing-with-KAI.md](https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/GPU-Sharing-with-KAI.md)
* Apply updates workflow:
  [https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Getting-Started.md#apply-configuration-updates](https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Getting-Started.md#apply-configuration-updates)


# Getting Started with Automation Engine
Source: https://docs.kubex.ai/docs-kubex/Content/Kubex/Automation_Engine_Getting_Started



This page summarizes the installation flow for Kubex Automation Engine.

For the full workflow, use the upstream guide:

[https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Getting-Started.md](https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Getting-Started.md)

## Prerequisites

Before installing:

* You have access to your Kubex instance details
* You have Helm access to your cluster
* You can install CRDs in the target cluster
* You can create required cluster-scoped RBAC and admission webhook resources

## Step 1: Prepare Required Values

Start from the chart template:

[https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/kubex-automation-values.yaml](https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/kubex-automation-values.yaml)

At minimum, set:

```yaml theme={null}
kubex:
  url:
    host: your-instance.kubex.ai
  clusterName: my-cluster

kubexCredentials:
  username: your-username
  epassword: your-encrypted-password
```

If credentials are managed externally:

```yaml theme={null}
createSecrets: false

gateway:
  configSecretName: kubex-gateway-config

kubex:
  url:
    host: your-instance.kubex.ai
  clusterName: my-cluster
```

## Step 2: Add Helm Repo

```bash theme={null}
helm repo add kubex https://densify-dev.github.io/helm-charts
helm repo update
```

## Step 3: Install CRDs

```bash theme={null}
helm install kubex-crds kubex/kubex-crds \
  --namespace kubex \
  --create-namespace
```

## Step 4: Install Automation Engine

```bash theme={null}
helm install kubex-automation-engine kubex/kubex-automation-engine \
  --namespace kubex \
  --create-namespace \
  -f kubex-automation-values.yaml
```

OpenShift note:

* Installation still requires cluster-scoped permissions for RBAC and admission webhook resources
* Set `openshift.enabled=true` for the chart's restricted-friendly OpenShift path
* Set `openshift.fsGroup` only if your cluster policy requires it

## Step 5: Verify Health

```bash theme={null}
kubectl get deployment kubex-automation-engine -n kubex
kubectl get pods -n kubex -l control-plane=controller-manager
kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations | grep kubex
```

## Step 6: Create First Strategy and Policy

You can either:

* Use Helm-managed values (`scope` and `policy.policies`) for generated cluster-scoped resources
* Manage CR manifests directly with `kubectl` or GitOps

Also validate:

* Policy resolution in controller logs
* Recommendation ingestion and rightsizing application for targeted workloads

## Step 7: Apply Configuration Updates

After changing values or policy configuration, re-run:

```bash theme={null}
helm upgrade kubex-automation-engine kubex/kubex-automation-engine \
  --namespace kubex \
  -f kubex-automation-values.yaml
```

## Uninstall Notes

When uninstalling, remove chart resources and clean up any remaining finalizers for externally managed CRs.

For full guided steps, see:

[https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Getting-Started.md](https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Getting-Started.md)


# Kubex Automation Engine Overview
Source: https://docs.kubex.ai/docs-kubex/Content/Kubex/Automation_Engine_Overview



Kubex Automation Engine is the Kubernetes rightsizing automation component that applies Kubex recommendations safely and continuously.

It uses policy-driven controls to decide:

* What workloads are eligible for automation
* Which resource dimensions can change
* How and when changes are applied
* Which safety checks must pass before any mutation

## Why This Matters

Automation Engine is designed to reduce manual tuning while preserving workload stability and platform controls.

Key outcomes include:

* Continuous rightsizing for CPU and memory
* Lower infrastructure waste
* Better scheduler packing efficiency
* Safer automation with Kubernetes-aware guardrails

## Core Components

A standard deployment includes:

* A single `kubex-automation-engine` deployment that evaluates policy, performs safety checks, and applies in-place or eviction-based resize
* Mutating admission webhook configuration for admission-time pod mutation
* Gateway sidecar that retrieves recommendations from Kubex
* Custom resources for global behavior, strategy, policy, and runtime evaluation state

## Key Features

* Declarative automation model using CRDs or Helm-generated resources
* Recommendation-driven and static policy support
* Zero-downtime optimization with in-place resize on Kubernetes 1.33+ and eviction fallback when required
* Namespaced and cluster-scoped control patterns
* Admission-time and proactive enforcement paths
* Fail-closed safety model with health gating and prechecks
* Smart pause control with per-pod annotations
* GitOps-friendly adoption path with backward compatibility for values-based settings

## Supported Workload Owners

Recommendation-driven automation can target:

* Deployment
* StatefulSet
* CronJob
* Rollout
* Job
* AnalysisRun
* StrimziPodSet
* DaemonSet

## Engine Model in One View

The Automation Engine separates behavior from scope:

* `AutomationStrategy` and `ClusterAutomationStrategy`: Define how rightsizing is allowed to happen
* `ProactivePolicy` and `ClusterProactivePolicy`: Define where recommendation-driven automation applies
* `StaticPolicy` and `ClusterStaticPolicy`: Define fixed resource behavior when recommendations are not used
* `GlobalConfiguration`: Defines cluster-wide runtime behavior

This makes automation easier to standardize across teams while still allowing namespace-level exceptions.

Important:

* Helm-managed `scope` and `policy.policies` preserve the existing values-driven flow by generating cluster-scoped strategy and proactive policy resources
* Namespaced `AutomationStrategy`, `ProactivePolicy`, `StaticPolicy`, and cluster static policies are supported by the controller and can be managed independently through CR manifests

## Deprecation Note

The older Kubex Automation Controller chart has been deprecated and replaced by Kubex Automation Engine.

## Official Source Documentation

* Helm chart root: [https://github.com/densify-dev/helm-charts/tree/master/charts/kubex-automation-engine](https://github.com/densify-dev/helm-charts/tree/master/charts/kubex-automation-engine)
* Chart README: [https://github.com/densify-dev/helm-charts/tree/master/charts/kubex-automation-engine/README.md](https://github.com/densify-dev/helm-charts/tree/master/charts/kubex-automation-engine/README.md)


# Automation Strategy and Policy Model
Source: https://docs.kubex.ai/docs-kubex/Content/Kubex/Automation_Engine_Policy_Model



Kubex Automation Engine separates automation into strategy and policy.

## Strategy vs Policy

* Strategy: Defines how resource changes are allowed
* Policy: Defines where those rules apply and how recommendations are selected

## Main CRD Types

### Strategy CRs

* `AutomationStrategy` (namespaced)
* `ClusterAutomationStrategy` (cluster scoped)

These define:

* Resource enablement for CPU and memory requests and limits
* In-place resize behavior
* Pod eviction fallback behavior
* Safety-check behavior

### Policy CRs

* `ProactivePolicy` and `ClusterProactivePolicy` (recommendation-driven)
* `StaticPolicy` and `ClusterStaticPolicy` (fixed resource values)

These define:

* Namespace and workload selection scope
* Strategy reference
* Resource targets (for static policies)
* Weight and precedence behavior

## Mapping from Helm Values

When using Helm-managed policy generation:

* `policy.policies.<name>` creates a `ClusterAutomationStrategy`
* `scope[].name` becomes `ClusterProactivePolicy.metadata.name`
* `scope[].policy` (or `policy.defaultPolicy`) references strategy name

Helm-managed `scope` and `policy.policies` preserve the values-driven flow from `values-edit.yaml`, while those generated CRs can still be managed independently when needed.

Namespaced `AutomationStrategy`, `ProactivePolicy`, `StaticPolicy`, and cluster static policies are supported by the controller and are commonly managed through dedicated CR manifests.

## Scope Design Guidance

Recommended practices:

* Keep policy ownership clear between platform and app teams
* Use separate strategies for conservative and aggressive automation profiles
* Use scope selectors to avoid broad accidental inclusion
* Validate precedence when scopes overlap

## Deep References

* Policy Configuration Guide:
  [https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Policy-Configuration.md](https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Policy-Configuration.md)
* Policy Evaluation Reference:
  [https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Policy-Evaluation.md](https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Policy-Evaluation.md)
* Cluster Automation Strategies:
  [https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Cluster-Automation-Strategies.md](https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Cluster-Automation-Strategies.md)
* Cluster Proactive Policies:
  [https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Cluster-Proactive-Policies.md](https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Cluster-Proactive-Policies.md)
* Static Policies:
  [https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Static-Policies.md](https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Static-Policies.md)


# Automation Safety and Operations
Source: https://docs.kubex.ai/docs-kubex/Content/Kubex/Automation_Engine_Safety_and_Operations



Kubex Automation Engine uses a fail-closed safety model so recommendations are only applied when runtime checks pass.

## Safety Controls

The engine combines multiple protections:

* Webhook health gating
* HPA and VPA compatibility filters
* LimitRange and ResourceQuota checks
* Node headroom checks
* Readiness and rollout safety checks
* Protected namespace patterns
* Policy- and scope-based workload inclusion checks

When checks fail, mutations are blocked and reasons are surfaced through events and logs.

## Global Runtime Controls

`GlobalConfiguration` is used for cluster-wide behavior:

* Recommendation refresh cadence
* Pod rescan cadence
* Mutation and snapshot upload intervals
* Automation on/off switch
* Webhook health thresholds
* Protected namespace patterns

## Pause and Control Patterns

Operational pause options include:

* Global disable through `globalConfiguration.automationEnabled`
* Targeted exclusions via scope and selectors
* Annotation-based per-pod pause behaviors
* Temporary learning-window pauses after workload changes

## Execution Paths

The engine can apply rightsizing via:

* In-place resize when supported by cluster version and policy
* Eviction/restart fallback path when in-place resize cannot be applied

## Diagnostics for Runtime Safety

Useful commands:

```bash theme={null}
kubectl get globalconfiguration global-config -o yaml
kubectl get events -A --field-selector reason=PrecheckFailed
kubectl logs -n kubex -l control-plane=controller-manager -c manager --since=10m | grep 'rightsizing summary'
```

## Source References

* Advanced Configuration:
  [https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Advanced-Configuration.md](https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Advanced-Configuration.md)
* Safety Controls Reference:
  [https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Safety-Controls.md](https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Safety-Controls.md)
* Global Configuration:
  [https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Global-Configuration.md](https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Global-Configuration.md)
* RBAC Permissions:
  [https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/RBAC-Guide.md](https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/RBAC-Guide.md)


# Automation Troubleshooting and FAQ
Source: https://docs.kubex.ai/docs-kubex/Content/Kubex/Automation_Engine_Troubleshooting_and_FAQ



This page consolidates common operational checks and FAQ topics for Kubex Automation Engine.

## Quick Verification Checklist

1. Confirm deployment exists and is ready
2. Confirm controller pods are running
3. Confirm CRDs and policy objects exist
4. Confirm no repeated `PrecheckFailed` events for intended targets
5. Confirm recent `rightsizing summary` logs are present

## Diagnostic Commands

```bash theme={null}
kubectl get deployment kubex-automation-engine -n kubex
kubectl get pods -n kubex -l control-plane=controller-manager
kubectl get globalconfiguration global-config -o yaml
kubectl get clusterproactivepolicy,proactivepolicy,clusterstaticpolicy,staticpolicy,clusterautomationstrategy,automationstrategy -A
kubectl get events -A --field-selector reason=PrecheckFailed
kubectl logs -n kubex -l control-plane=controller-manager -c manager --since=10m | grep 'rightsizing summary'
```

## Common Questions

### What is the difference between strategy and policy?

* Strategy defines how changes are allowed.
* Policy defines where those changes apply.

### Can Helm-managed and manual CRs coexist?

Yes. A common pattern is Helm-managed baseline with manually managed exception policies.

### What FAQ topics should I review first?

Start with FAQ coverage for:

* Getting started and prerequisites
* Helm-managed versus manual CR management
* Safety controls and emergency stop options
* Troubleshooting and verification steps

### How do I stop automation quickly?

Set `globalConfiguration.automationEnabled: false` and run `helm upgrade`, or scale down the controller as an emergency action.

## Support Routing

* Documentation issues: begin with Troubleshooting and runtime diagnostics
* Configuration questions: compare chart values and generated CR behavior against Configuration Reference
* Upgrade and migration concerns: review backward compatibility notes in Advanced Configuration

## Detailed References

* Troubleshooting Guide:
  [https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Troubleshooting.md](https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Troubleshooting.md)
* Known Issues:
  [https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Known-Issues.md](https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Known-Issues.md)
* FAQ:
  [https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/FAQ.md](https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/FAQ.md)
* Advanced Configuration:
  [https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Advanced-Configuration.md#backward-compatibility-and-migration](https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-engine/docs/Advanced-Configuration.md#backward-compatibility-and-migration)


# Resource Breakdown Summary
Source: https://docs.kubex.ai/docs-kubex/Content/Kubex/Breakdown_Tab



This page summarizes the content as a breakdown of the items, selected in the tree view. For example, if you have the entire environment selected, the breakdown for clusters, namespaces, pods and containers is listed.<br /> If you have namespace selected, then you will see the breakdown by pods.<br />
A [summary banner](/docs-kubex/Content/Kubex/Visualizing_Your_Data#summary-banner) is displayed at the top of page to highlight the status and scope of systems that are included in the breakdown chart.

<Frame>
  <img alt="" />
</Frame>

The following values are displayed for each item in the list:

<ul>
  <li>Container Count--The number of containers in the selected scope.</li>

  <Note>
    <b>Note </b><br />
    The value here is the number of containers and will not match the tree viewer that shows the number of manifests.
  </Note>

  <li>Containers at Risk--The number of containers in the selected scope, that are at risk due to resources being under-allocated. The colour of bar indicates the severity of the issue.</li>
  <li>Estimated waste--The wasted resources, in the selected scope, converted to dollars. A negative value indicates  more resources are required to avoid performance issues.</li>
</ul>

Environments can have both over- and under-allocated systems. The [Histogram](/docs-kubex/Content/Kubex/Histograms_Tab) tab helps you identify these situations and you can then use the [Analysis Details](/docs-kubex/Content/Kubex/AI_Analysis_Details_Tab) tab to identify and correct individual containers.

## Drill-Down Hyperlinks

You can click the hyperlinks in the first column to drill down to its contained elements. As you drill down, the tree viewer, column header and breadcrumbs update to show your relative location.
When you reach a single container, the detailed [Overview](/docs-kubex/Content/Kubex/Overview_Tab) and the [Metrics Viewer](/docs-kubex/Content/Kubex/Metrics_Viewer_Tab) tabs are displayed, providing the tools for more detailed investigation.

## Reading the Bar Chart

Each bar in this table is sized based on the highest value within its own column-- rather than the total of all selected items (i.e. clusters, or container, etc.). As an example, in the figure above:

<ul>
  <li>In the first column ("Containers"), the cluster k8seng has the most containers (719). So, it is shown as 100%, and all other clusters are displayed as a percentage of that number.</li>
  <li>In the second column ("Containers at Risk"), k8sengexp has the highest count (9), making it 100% for this column. The other clusters are scaled accordingly.</li>
  <li>In the third column ("Cost"), again, k8sengexp has the highest cost (\$336.20), so it is shown as 100%, and the rest are shown as a percentage of that value.</li>
</ul>

This way, each column uses its own highest value as the baseline for comparison.

#### Video Resources

<AccordionGroup>
  <Accordion title="Using the Breakdown Tab">
    <iframe />

    <a href="https://player.vimeo.com/video/1065616008?badge=0&autopause=0&player_id=0&app_id=58479">Using the Breakdown Tab</a>
  </Accordion>

  <Accordion title="Using the Tree Viewer">
    <iframe />

    <a href="https://player.vimeo.com/video/1038945637?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479">Using the Tree Viewer</a>
  </Accordion>
</AccordionGroup>


# Advanced K8s Configurations
Source: https://docs.kubex.ai/docs-kubex/Content/Kubex/Data_Collection_Alternate_Methods



Kubex recommends using the [Kubex Collection Stack Helm Chart](https://github.com/densify-dev/helm-charts/tree/master/charts/kubex-automation-stack). This Helm chart bundles all of the components required for Kubex and is the preferred method of data collection.
The following configuration options support multi-cluster configurations and observability platforms. See [Container Data Collection Prerequisites](/docs-kubex/Content/Kubex/Data_Collection_Prerequisites) for required prerequisite software.

<Accordion title="Amazon Managed Prometheus">
  In this example the data forwarder is setup in an EKS cluster to connect to Amazon Managed Prometheus (AMP) and send container data to <span>Kubex</span> on an hourly basis. Using an EKS cluster allows you to use EKS's ability to associate an IAM role with a Kubernetes service account and configure your pods to use the service account. This is the preferred way to connect to AMP.
  Figure: Container Data Collection Using EKS-AMP

  <frame />

  <img alt="" />

  * Supports EKS as well as other Amazon Kubernetes deployments

  * See [https://github.com/densify-dev/container-data-collection/tree/main/multi-cluster/examples/amp](https://github.com/densify-dev/container-data-collection/tree/main/multi-cluster/examples/amp) for details on deploying the data forwarder with AMP.
</Accordion>

<Accordion title="Azure Managed Prometheus">
  Azure Monitor managed service for Prometheus can be used when deploying AKS clusters.
  Figure: Container Data Collection Using Azure Monitor with Managed Prometheus

  <frame />

  <img alt="" />

  * Supports Azure Managed Service for Prometheus (AzMP) for container data collection.
  * See [https://github.com/densify-dev/container-data-collection/tree/main/multi-cluster/examples/azmp](https://github.com/densify-dev/container-data-collection/tree/main/multi-cluster/examples/azmp) for details on deploying the data forwarder with AzMP.
</Accordion>

<Accordion title="Other Observability platforms that support the Prometheus API with basic authentication">
  The data forwarder can be setup to connect to Prometheus or an observability platform that supports the Prometheus API with HTTP basic authentication and sends container data from multiple clusters to Kubex on an hourly basis.
  Figure: Container Data Collection from an Observability Platform

  <frame />

  <img alt="" />

  * Supports Prometheus with basic authentication (e.g., Grafana Cloud)
  * See [https://github.com/densify-dev/container-data-collection/tree/main/multi-cluster/examples/basic](https://github.com/densify-dev/container-data-collection/tree/main/multi-cluster/examples/basic) for details on deploying the data forwarder using an observability platform.
</Accordion>


# Connect Your Kubernetes Clusters
Source: https://docs.kubex.ai/docs-kubex/Content/Kubex/Data_Collection_Overview



## Getting Started

When you first log into Kubex, you'll be presented with a getting started page that walks you through the process of connecting your Kubernetes clusters to Kubex.

<Frame>
  <img alt="" />
</Frame>

<br />

## Helm Commands to deploy the Kubex data collector

Note: Refer to GitHub for <a href="https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-stack/README.md">OpenShift</a> and <a href="https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-collection-gke-autopilot/README.md">GKE Autopilot</a>

<Frame>
  <img alt="" />
</Frame>

<br />

## Data Collection Status & Adding More Clusters

After deploying Kubex data collection, data will begin flowing within an hour. You can monitor the status of each cluster connection through the data collection status page, which is also accessible from the side panel. Kubex performs data analysis overnight, so data flowing in today will show analyzed results the following morning.

<Frame>
  <img alt="" />
</Frame>

<br />

Other configuration options including multi-cluster and observability platforms are also supported. See <a href="/docs-kubex/Content/Kubex/Data_Collection_Alternate_Methods">Advanced Data Collection for Containers</a> or <a href="https://github.com/densify-dev/container-data-collection">Github</a> for other configuration options.


# Container GPU Summary
Source: https://docs.kubex.ai/docs-kubex/Content/Kubex/GPU_Tab



The cards on this tab provide a visual overview of a single container's GPU allocation and utilization details. When navigating the [tree viewer](/docs-kubex/Content/Kubex/Using_the_Tree_Viewer), you will see this tab when a single item, with allocated GPU resources, is selected.

You will see the [Summary Tab](/docs-kubex/Content/Kubex/Summary_Tab) when more than one container is selected.

<Frame>
  <img alt="" />
</Frame>

## GPU Summary

This card summarizes the GPU allocation and for the selected container. This card is only displayed if the GPU resources have been allocated to this container. A hyperlink at the bottom of the card takes you to the GPU page.

<Frame>
  <img alt="" />
</Frame>

<table>
  <tbody>
    <tr>
      <td>
        <ul>
          <li>
            <Tooltip>GPU Model</Tooltip>
          </li>

          <li>
            <Tooltip>Sharing Strategy</Tooltip>
          </li>

          <li>
            <Tooltip>Total GPU Request</Tooltip>
          </li>

          <li>
            <Tooltip>GPU Request</Tooltip>
          </li>
        </ul>
      </td>

      <td>
        <ul>
          <li>
            <Tooltip>Total GPU Memory Request</Tooltip>
          </li>

          <li>
            <Tooltip>GPU Memory Request</Tooltip>
          </li>
        </ul>
      </td>
    </tr>
  </tbody>
</table>

## Utilization Charts

The last section provides utilization charts that show hourly min/max and sustained activity for the selected container. See [Analysis Details Utilization Charts](/docs-kubex/Content/Kubex/AI_Analysis_Details_Charts) for details on using these charts to review workload data.

<Frame>
  <img alt="" />
</Frame>

<table>
  <tbody>
    <tr>
      <td>
        <ul>
          <li>GPU Utilization (GPUs) - Average Container</li>
          <li>Number of Containers</li>
        </ul>
      </td>

      <td>
        <ul>
          <li>GPU Memory Utilization (MB) - Average Container</li>
          <li>GPU Memory Utilization (%) - Average Container</li>
        </ul>
      </td>
    </tr>
  </tbody>
</table>

All other metrics are available on the [Metrics Viewer Tab](/docs-kubex/Content/Kubex/Metrics_Viewer_Tab) tab. You can also expand any chart to the modal view and adjust the timeline and the type of data to view ML model for the last day or historical data.

A link at the bottom of the modal page takes you to the [Overview Tab](/docs-kubex/Content/Kubex/Overview_Tab) tab for the selected instance.


# Histograms
Source: https://docs.kubex.ai/docs-kubex/Content/Kubex/Histograms_Tab



This tab displays the selected scope of data in an easy-to-understand visualization. It shows how well your CPU and memory limits have been set for your selected scope. It gives a high level overview of the current state of your environment.

The <Tooltip>histogram</Tooltip> charts provide links to the Analysis Details tab to review the recommendation details.

Use the [tree viewer](/docs-kubex/Content/Kubex/Using_the_Node_Tree_Viewer) to define the scope of systems to include.

By default, 4 charts are displayed. Use the options at the top of the page to select the charts to display:

<Accordion title="Table: Histogram Chart Selection Controls">
  <table>
    <thead>
      <tr>
        <td>
          Control
        </td>

        <td>
          Description
        </td>
      </tr>
    </thead>

    <tr>
      <td>
        <Frame>
          <img />
        </Frame>
      </td>

      <td>
        Select whether you want to review CPU, memory or both CPU and memory.
      </td>
    </tr>

    <tr>
      <td>
        <Frame>
          <img />
        </Frame>
      </td>

      <td>
        Select whether you want to review request values, limit values or both requests and limits.
      </td>
    </tr>

    <tr>
      <td>
        <Frame>
          <img />
        </Frame>
      </td>

      <td>
        Unspecified--You can indicate whether or not to include containers with unspecified values.

        When enabled, the grey bar indicates the number of containers with unspecified values. If, for example,  both the CPU Request and Limit values are unspecified for a container manifest, this will contribute to the unspecified count in both the CPU Request and CPU Limit charts. If only the CPU Limit value is unspecified then only the unspecified count on the CPU Limit chart is incremented.
      </td>
    </tr>
  </table>
</Accordion>

<Frame>
  <img alt="" />
</Frame>

Badges on a histogram indicate a situation that needs attention. Click the title link to move to the Analysis Details tab.

## Histogram Charts

These histogram charts show your select data grouped as a distribution. The scope of data, is defined by the tree viewer.

Based on Kubex analysis of your container environments, sizing recommendations are generated and the container is determined to be at risk, just right or oversized. Each container manifest is then placed into a "bucket", based on how close its allocation is from the optimal configuration. The histogram shows you how many containers/pods (Y-axis) are in each of these buckets that are displayed along the X-axis. The current resource allocation, as a percentage of what is actually required, make up these buckets on the X-axis.

The data is shown on the chart as follows:

<ol>
  <li>Containers identified with less than optimal resource allocation (shortfall) are identified as having between 0 and 99% of their optimal allocation (Current Resources as a percentage of required \< 100%). These containers are shown on the left side of the chart.</li>
  <li>Containers with all of the resources they need are indicated as 100%, or no sizing error.</li>
  <li>Containers with surplus resources are identified as having over 100% of their optimal allocation (Current Resources as a percentage of required >100%). These containers are shown on the right side of the chart and highlight stranded resources that are committed to pods that are not using them.</li>
  <li>If you have enabled Show > Unspecified, then the number of containers with an unspecified resource request and/or limit value are also shown at the far left of the chart.</li>
</ol>

<Frame>
  <img />
</Frame>

## Additional Features

Use the following additional features on these charts to see the recommendation details:

<ul>
  <li>
    Drill down hyperlinks--The zone names are hyperlinks that take you to the <a href="/docs-kubex/Content/Kubex/AI_Analysis_Details_Tab"> Analysis Details </a> tab, with the corresponding Table View selected, showing the relevant systems. For example, if you click "Throttled CPU Risk", Kubex switches to the Analysis Details tab with the "CPU Request Shortfall" view selected.

    <a name="kanchor63" />
  </li>

  <div>
    <div>
      <div>
        <Carousel />

        Analysis Details Tab - Memory Request Shortfall View
      </div>
    </div>
  </div>

  <li>Hover-over details--When reviewing the charts, you can hover over any of the bars to see how many containers are in the selected bucket.</li>

  <Frame>
    <img />
  </Frame>

  <li>Warning Indicators--A warning indicator is displayed on the chart if memory events have occurred in the selected scope of systems. Click the message to see the corresponding detailed view on the Analysis Details tab.</li>

  <Frame>
    <img />
  </Frame>

  <li>
    Savings Indicators--Another indicator is displayed on the chart if resource allocations can be adjusted to save money. Again, you can click the message to see the corresponding detailed view on the Analysis Details tab.

    <a name="kanchor64" />
  </li>

  <Frame>
    <img />
  </Frame>
</ul>

## CPU Request

<InlineImageWithText>
  The CPU Request is the number of CPU millicores (mCores) that are guaranteed for the container. If a container CPU request is specified then Kubernetes will only schedule it on a node that can provide the requested CPU resources.
</InlineImageWithText>

Applications in containers on the left side of the histogram may experience CPU throttling and the resulting performance issues.
Containers on the right side of the chart indicate containers with over-allocated CPU resources, resulting in stranded capacity. Since the request guarantees these resource to the container, they cannot be re-allocated until the pod shuts down.

Click the zone name to review the specific details of the recommended resource allocations to improve container and/or application performance. Clicking "CPU Request Shortfall", switches to the [Analysis Details](/docs-kubex/Content/Kubex/AI_Analysis_Details_Tab) tab and displays the "CPU Request Shortfall" view in ascending order (with the negative values shown at top of the list). From here you can review the details of the recommended allocation changes for each manifest.

Clicking the "CPU Request Surplus", switches to the [Analysis Details](/docs-kubex/Content/Kubex/AI_Analysis_Details_Tab) tab sorted on the "CPU Request Shortfall" view in descending order with the largest positive values shown at top of the list. Systems with unspecified values are indicated with a dash (-) and are shown first so you may need to scroll down to see the manifests with stranded CPU resources.

## CPU Limit

<InlineImageWithText>
  The CPU limit is the maximum allocation that a pod or container can access. When you specify a resource limit, Kubernetes enforces the limit so that the running container cannot use more CPUs than the defined limit.
</InlineImageWithText>

If the limit has not been set, it is possible for a container to use more resources than it requests, if the node has available CPUs. However, a container is not allowed to use more than its resource limit. In this case, applications in containers on the left side of the histogram will likely experience performance issues due to CPU throttling.

Click the zone name to switch to the [Analysis Details](/docs-kubex/Content/Kubex/AI_Analysis_Details_Tab) tab to see the details of the specific recommended resource allocations to improve container and/or application performance. The table will be sorted on the "CPU Request Surplus" column in ascending order (with the negative values shown at top of the list). From here you review the details of the recommended allocation changes.

Containers on the right side of the chart indicate containers with over-allocated CPU resources, resulting in stranded capacity. If the limit is set too high and runaway processes exceed their request and hit the limit for sustained periods, the CPUs cannot be re-allocated until the runaway processes are terminated or the pod shuts down. This will again, result in stranded CPU capacity.

## Memory Request

<InlineImageWithText>
  Like the CPU Request, a memory request is the amount of memory that is guaranteed for the container. If a container memory request is specified then Kubernetes will only schedule it on a node that can provide the allocated resources.
</InlineImageWithText>

Applications in containers on the left side of the histogram may run out of memory resulting in performance issues or the pod may be terminated due to insufficient available memory.
Containers on the right side of the chart indicate containers with over-allocated memory resources, resulting in stranded capacity. Since the request guarantees these resource, they cannot be re-allocated until the pod or task shuts down.

Click the zone name to switch to the [Analysis Details](/docs-kubex/Content/Kubex/AI_Analysis_Details_Tab) tab to see the corresponding table view with details of the specific recommended resource allocations to improve container and/or application performance.

## Memory Limit

<InlineImageWithText>
  The memory limit is the maximum allocation that a pod or container can access. When you specify a resource limit, Kubernetes enforces the limit so that the running container cannot use more memory than the defined limit.
</InlineImageWithText>

If the limit has not been set, it is possible for a container to use more resources than its request if the node has available memory. However, a container is not allowed to use more than its resource limit. When a process in the container tries to consume more than the allowed amount of memory, the system terminates the process that attempted the allocation, with an out of memory (OOM) error.

Containers on the right side of the chart indicate containers with over-allocated memory resources, resulting in stranded capacity. If the limit is set too high and runaway processes exceed their request value for sustained periods, the memory cannot be re-allocated until the runaway processes are terminated or the pod shuts down, thereby stranding memory resources.

Click the zone name to open the [Analysis Details](/docs-kubex/Content/Kubex/AI_Analysis_Details_Tab) tab to see the corresponding table view with details of the specific recommended resource allocations to improve container and/or application performance.

#### Video Resources

<AccordionGroup>
  <Accordion title="Searching for a System">
    <iframe />

    <a href="https://player.vimeo.com/video/1044765242?badge=0&autopause=0&player_id=0&app_id=58479">Searching for a System</a>
  </Accordion>

  <Accordion title="Using Histograms">
    <iframe />

    <a href="https://player.vimeo.com/video/1039069463?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479">Using Histograms</a>
  </Accordion>

  <Accordion title="Using the Tree Viewer">
    <iframe />

    <a href="https://player.vimeo.com/video/1038945637?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479">Using the Tree Viewer</a>
  </Accordion>
</AccordionGroup>


# Improving Node Health
Source: https://docs.kubex.ai/docs-kubex/Content/Kubex/Improving_Node_Health

Understand key node health risks and how Kubex recommendations and automation reduce operational instability.

## Improving Node Health

Two of the most important node health risks are sustained saturation and resource imbalance across nodes.

## 1. CPU and Memory Saturation

CPU and memory saturation occur when utilization remains very high for prolonged periods.

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>

Typical causes include:

* Mismatch between configured requests and actual workload usage
* Missing CPU or memory requests and limits

When saturation is not addressed:

* CPU saturation can cause throttling and degrade application performance
* Memory saturation can cause OOM kills and workload instability

### Recommended Action

Apply Kubex recommendations for containers to better align requests with actual usage and reduce saturation risk.

For the most efficient and hands-off execution path, use Kubex automation to apply approved recommendations at scale. See [Automation Overview](/docs-kubex/Content/Kubex/Automation_Engine_Overview)

## 2. High CPU and Memory Balance Ratios

High CPU and memory balance ratios indicate uneven usage across nodes. Some nodes are heavily loaded while others remain underutilized.

This is commonly caused when container requests and actual usage are not aligned.

A high imbalance can destabilize the environment by increasing contention on busy nodes while wasting capacity on underused nodes.

<Frame>
  <img alt="" />
</Frame>

### Recommended Action

Use Kubex container recommendations to rebalance resource demand, then apply them through Kubex automation to continuously maintain healthier node distribution.

## Related Topics

* [Container Optimization](/docs-kubex/Content/Kubex/container_optimization)
* [Automation Overview](/docs-kubex/Content/Kubex/Automation_Overview)
* [Optimizing Node Cost](/docs-kubex/Content/Kubex/Optimizing_Node_Cost)


# Kubex Dashboard
Source: https://docs.kubex.ai/docs-kubex/Content/Kubex/Kubex_Dashboard



<Frame>
  <img alt="" />
</Frame>

The Kubex dashboard provides a high-level summary of cluster resources, workload usage, costs, and potential risks. It helps users understand how Kubernetes resources are allocated, requested, and utilized across clusters, and highlights areas of inefficiency or operational risk.

### Cluster Filter

The Cluster Filter on the left side panel allows users to select which clusters are included in the dashboard. By default all clusters are included.

<Frame>
  <img alt="" />
</Frame>

**Capabilities**

* Search for clusters
* Select one or multiple clusters
* Select all or deselect all clusters
* Apply or reset filters

The dashboard metrics and visualizations update automatically based on the selected clusters.

### Dashboard Views

Users can switch between multiple system views that are available out of the box:

<Frame>
  <img alt="" />
</Frame>

* Overview – High-level usage, cost and risk insights
* Waste – Focus on resource inefficiency and cost waste
* Risk – Focus on Node and Cluster performance and resource risks

Users can create new views and designate them as public or as private.

### Key widgets

**CPU Allocatable vs Requested vs Utilized**

This chart compares the allocatable CPU/Memory with what is being requested and the actual usage over time.

<Frame>
  <img alt="" />
</Frame>

Metrics displayed

Allocatable – Total CPU/Memory capacity available on nodes
Requested – CPU/Memory resources requested by workloads
Utilized – Actual CPU/WorkingSetMemory usage by running workloads

How to interpret

* If Utilized is much lower than Requested, workloads may be over-provisioned.
* Large gaps between Allocatable and Requested may indicate unused capacity due to other factors (like max pods/node or ephemeral storage constraints) that makes the node autoscaler spin up more nodes.

This helps identify opportunities to optimize CPU & Memory resource allocation.

**Cluster Cost / Waste**

This section shows monthly infrastructure cost and estimated waste per cluster and node groups.

<Frame>
  <img alt="" />
</Frame>

Metrics

* Monthly Cost – Total estimated monthly cost of the cluster
* Waste – Estimated cost of unused or over-provisioned resources
* Waste % – Percentage of cluster cost that is inefficiently used

This helps teams identify clusters where resource optimization could significantly reduce costs.

**Node Risks**

The Node Risks widget highlights nodes experiencing potential resource issues.

<Frame>
  <img alt="" />
</Frame>

* Memory Saturated Nodes:	# of Nodes experiencing very high memory usage in the last 7 days
* CPU Saturated Nodes: # of Nodes experiencing very high CPU usage in the last 7 days
* Nodes at Max Pods: # of Nodes that have reached the maximum allowed number of pods in the last 7 days

These indicators help identify infrastructure pressure points that may impact workload performance.

**Container Risks**

This section highlights potential risks at the container level.

<Frame>
  <img alt="" />
</Frame>

* Containers with Memory Limit Events: # of Containers where the working set utilization is at or very close to the Memory limit in the last 7 days
* Containers with Kill Events:	Containers terminated due to a kill event (SIGKILL)
* Containers with CPU Throttling:	Containers experiencing CPU throttling

High values may indicate workloads that need resource tuning.

**Automation**

The Automation widget shows workloads that have been automatically optimized by Kubex. This helps track automated efficiency improvements.

<Frame>
  <img alt="" />
</Frame>


# Metrics Viewer
Source: https://docs.kubex.ai/docs-kubex/Content/Kubex/Metrics_Viewer_Tab



The Kubex metrics viewer allows you to view your collected and analyzed time series data to review specific container details. You can use the metrics viewer to investigate specific utilization details when deciding whether to action specific recommendations.

<ol>
  <li>Select one container to review. The metrics viewer tab is not displayed until only one container is selected.</li>
  <li>Use the tree viewer's search feature to find a specific container. Enter the name of the container, as you type, matching items are displayed in the list.</li>
  <li>Ensure the view and filter settings are set accordingly, to locate your specific container.</li>
</ol>

<Frame>
  <img alt="" />
</Frame>

## Metrics Viewer Controls

When you open the metrics viewer, the instance that was selected in the Instance Optimization Details page is displayed. You can from the tree viewer, or from the Analysis Details tab.
You can configure the data you want to view for this container using the options in the dropdown menus.

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>

There are 3 options to configure this report:

<Accordion title="Table: Metrics Viewer Controls">
  <table>
    <thead>
      <tr>
        <th>
          Setting
        </th>

        <th>
          Description
        </th>
      </tr>
    </thead>

    <tbody>
      <tr>
        <td>
          Select Charts
        </td>

        <td>
          Select the number of charts to display from the drop down list. You can view all 9 different metrics for the selected container. Scroll bars are provided as required to navigate the displayed charts.
        </td>
      </tr>

      <tr>
        <td>
          Period
        </td>

        <td>
          Figure: Metrics Viewer Controls <madcap:conditionaltext />
          <a href="/images/docs-kubex/Content/Kubex/03000075.png">          <img /></a> Using the slider along the bottom of the page, select the period on which you want to report. The available time range depends on the type of report selected for display. Historical daily and hourly reports can provide up to 90 days of historical data.
          The slider is not required for the ML Model view that only shows the last 24 hours of data.

          <Note>
            <b>Note: </b><br />
            Kubex retains up to 3 months of historical data for the metrics viewer. When creating a customized period, you cannot view data older than 90 days.
          </Note>
        </td>
      </tr>

      <tr>
        <td>
          View By
        </td>

        <td>
          Figure: Metrics Viewer Chart Options <madcap:conditionaltext />
          <a href="/images/docs-kubex/Content/Kubex/03000118.png">          <img /></a> Select the one type of report to display the data. You can select one option. Clicking on one option disables the others.

          <ul>
            <li>ML Mode--The 24 hours from yesterday are displayed.</li>
            <li>Historical  daily--Data has been aggregated for daily display. Move the sliders along the bottom of the chart to define the time range.</li>
            <li>Historical hourly --Data has been aggregated for hourly display. Move the sliders along the bottom of the chart to define the time range.</li>
            <li>Historical (5 min)--Provides 5-minute utilization metric samples. Use the sliders to define the time range.</li>
          </ul>
        </td>
      </tr>
    </tbody>
  </table>
</Accordion>

All of the charts are refreshed immediately when you change any of the control options. Your settings are saved for the current user session and are returned to the default values if you log out.

**Chart Features:**

* The line chart shows the selected metric plotted by the hour or date.
* The X-axis scales based on the amount of data up to the maximum of 90-days. The X-axis will show both date and hour when the date range includes less than 7-days. Only the date is shown when there are more than 7-days of data on the chart.
* If you hover over any data point in the graph a popup indicates the values on the selected date. You can slide the mouse along the plotted lines to see data values at the specific date or time.
* If metric data is not available, the message "NA" is shown in the legend of the impacted chart.

### Available Container Metrics

The following table lists the complete set of metrics that you can review in the metrics viewer.

<Accordion title="Table: Container Metrics">
  <table>
    <thead>
      <tr>
        <th>
          Metrics
        </th>

        <th>
          Units
        </th>
      </tr>
    </thead>

    <tbody>
      <tr>
        <td>
          CPU Limit - Current
        </td>

        <td>
          mCores
        </td>
      </tr>

      <tr>
        <td>
          CPU Limit - Recommended
        </td>

        <td>
          mCores
        </td>
      </tr>

      <tr>
        <td>
          CPU Request - Current
        </td>

        <td>
          mCores
        </td>
      </tr>

      <tr>
        <td>
          CPU Request - Recommended
        </td>

        <td>
          mCores
        </td>
      </tr>

      <tr>
        <td>
          CPU Utilization - Busiest Container
        </td>

        <td>
          mCores
        </td>
      </tr>

      <tr>
        <td>
          CPU Utilization - Container Average
        </td>

        <td>
          mCores
        </td>
      </tr>

      <tr>
        <td>
          Disk I/O - Busiest Container \*
        </td>

        <td>
          Kbytes/s
        </td>
      </tr>

      <tr>
        <td>
          Memory (RSS) Utilization - Busiest Container
        </td>

        <td>
          MB
        </td>
      </tr>

      <tr>
        <td>
          Memory (RSS) Utilization - Container Average
        </td>

        <td>
          MB
        </td>
      </tr>

      <tr>
        <td>
          Memory (Total) Utilization - Busiest Container
        </td>

        <td>
          MB
        </td>
      </tr>

      <tr>
        <td>
          Memory (Total) Utilization - Container Average
        </td>

        <td>
          MB
        </td>
      </tr>

      <tr>
        <td>
          Memory (Working Set) Utilization - Busiest Container
        </td>

        <td>
          MB
        </td>
      </tr>

      <tr>
        <td>
          Memory (Working Set) Utilization - Container Average
        </td>

        <td>
          MB
        </td>
      </tr>

      <tr>
        <td>
          Memory Limit  - Current
        </td>

        <td>
          MB
        </td>
      </tr>

      <tr>
        <td>
          Memory Limit - Recommended
        </td>

        <td>
          MB
        </td>
      </tr>

      <tr>
        <td>
          Memory Request - Current
        </td>

        <td>
          MB
        </td>
      </tr>

      <tr>
        <td>
          Memory Request - Recommended
        </td>

        <td>
          MB
        </td>
      </tr>

      <tr>
        <td>
          No. of Containers
        </td>

        <td>
          Number
        </td>
      </tr>

      <tr>
        <td>
          No. of Restarts
        </td>

        <td>
          Number
        </td>
      </tr>
    </tbody>
  </table>
</Accordion>

#### Disk I/O

\* Collecting the metric, container\_fs\_usage\_bytes is an issue if the Kubernetes cluster container uses containerd as its runtime. Since most Kubernetes clusters now use containerd as their runtime and cadvisor does not return the required metrics, you will not see Disk I/O data. If you select this metric you will see "No Data Available".
See the following issues:

<ul>
  <li>
    <a href="https://github.com/google/cadvisor/issues/2785"> [https://github.com/google/cadvisor/issues/2785](https://github.com/google/cadvisor/issues/2785) </a>
  </li>

  <li>
    <a href="https://github.com/google/cadvisor/issues/3315"> [https://github.com/google/cadvisor/issues/3315](https://github.com/google/cadvisor/issues/3315) </a>
  </li>
</ul>

Collection of this metric is supported by both Docker and CRI-O container runtimes.

#### Recommended CPU and Memory Request and Limit Values

When selected, recommended CPU and memory request and limit values are shown as a straight line regardless of which statistics (Peak/Sustained/Average/Min) have been selected.


# Optimizing Node Cost
Source: https://docs.kubex.ai/docs-kubex/Content/Kubex/Optimizing_Node_Cost



## Overview

Node cost optimization is a critical aspect of managing Kubernetes infrastructure efficiently. By identifying and prioritizing the node groups with the highest savings potential, you can implement targeted optimization strategies that deliver maximum ROI on your infrastructure spending.

## Identifying Node Groups with the Most Waste

The first step in optimizing node costs is to analyze your node groups and identify which ones have the most significant savings potential. This involves examining resource utilization patterns and waste metrics across your infrastructure.

<Frame>
  <img alt="" />
</Frame>

### Key Metrics to Consider

When evaluating node groups for optimization opportunities, focus on:

* **Resource Utilization Gaps** – Difference between requested resources and actual usage
* **Idle Capacity** – Nodes running with minimal workloads
* **Oversized Instances** – Nodes larger than necessary for current workloads

<Frame>
  <img alt="" />
</Frame>

## Three Optimization Strategies

Once you've identified high-waste node groups, apply these proven optimization approaches:

### 1. Optimize Pod Density (Low Hanging Fruit)

Check the **max pods per node** setting for your node groups. This configuration often limits the number of pods that can run on a single node, even when resources remain available.

**Impact:** This is frequently the quickest win—increasing max pod density allows the autoscaler to provision more workloads on existing nodes, reducing the need for additional nodes.

**Action:** Review your Kubernetes configuration and adjust pod density limits to match your actual resource constraints, not default limits.

<Frame>
  <img alt="" />
</Frame>

<Frame>
  <img alt="" />
</Frame>

### 2. Right-Size Resource Requests and Limits

Verify that container **CPU**, **Memory**, and **Ephemeral storage** requests are aligned with actual usage patterns.

**The Problem:** Misaligned resource requests lead to waste in two ways:

* **Over-requested resources** – Nodes remain underutilized because pods reserve more capacity than they need
* **Under-requested resources** – Workloads may fail or perform poorly, requiring larger nodes than necessary

**Best Practice:** Set requests and limits based on real usage patterns with an appropriate headroom buffer for variability. This ensures efficient bin-packing of workloads while maintaining reliability.

<Frame>
  <img alt="" />
</Frame>

For guidance on applying these recommendations through Kubex's [Automation Engine](/docs-kubex/Content/Kubex/Automation_Overview).

### 3. Match Instance Types to Usage Patterns

When using Scale Groups (such as AWS Auto Scaling Groups or Azure Scale Sets), the instance types must align with your workload characteristics.

**Key Considerations:**

* **Memory-heavy workloads** – Use memory-optimized instance types
* **CPU-intensive workloads** – Use compute-optimized instances
* **General workloads** – Use balanced general-purpose instances

<Frame>
  <img alt="" />
</Frame>

**Kubex ScaleGroup Analysis:** Kubex links K8s Clusters & NodeGroups to the underlying Azure Scaleset / AWS ASG to provide actionable recommendation on how to size and spec the scale group. This includes utilization as well as the current CPU/Memory Requests.

<Frame>
  <img alt="" />
</Frame>

Refer to [Scale Group Analysis](/docs/WebHelp_Densify_Cloud/Content/Cloud_Optimization).

***

## Next Steps

Once you've identified your highest-priority node groups:

1. **Apply the three optimization strategies** – start with pod density (quick win), then resource requests, then instance type matching
2. **Monitor and validate** improvements in utilization and cost metrics
3. **Plan migration strategies** to minimize disruption when changing instance types
4. **Track ROI** on optimization efforts

By systematically addressing node groups with the most waste using these targeted strategies, you can significantly reduce infrastructure costs while maintaining performance and reliability.


# Single Container Summary
Source: https://docs.kubex.ai/docs-kubex/Content/Kubex/Overview_Tab



The cards on this tab provide a visual overview of a single container.

When navigating the [tree viewer](/docs-kubex/Content/Kubex/Using_the_Tree_Viewer), you will see this tab when a single item is selected.
You will see the [Summary tab](#) when more than one container is selected.

<Frame>
  <img alt="" />
</Frame>

You will also see a modal view of this page when you click the hyperlink in the [Analysis Details](/docs-kubex/Content/Kubex/AI_Analysis_Details_Table#hyperlink) tab. This tab provides the container details in a format that is easier to view and to compare the current versus the recommended settings.

<Frame>
  <img alt="" />
</Frame>

You also have access to the [metrics viewer](/docs-kubex/Content/Kubex/Metrics_Viewer_Tab) when a single container is selected.

## Optimization Summary

This card highlights your current & recommended settings based on utilization.

<Frame>
  <img alt="" />
</Frame>

<table>
  <tbody>
    <tr>
      <td>
        <ul>
          <li>
            <Tooltip>Total Surplus CPU Request (mCores)</Tooltip>
          </li>

          <li>
            <Tooltip>Total Surplus Memory Request (MB)</Tooltip>
          </li>

          <li>
            <Tooltip>Estimated Waste</Tooltip>
          </li>
        </ul>
      </td>

      <td>
        <ul>
          <li>
            <Tooltip>CPU Request (mCores)</Tooltip>
          </li>

          <li>
            <Tooltip>CPU Limit (mCores)</Tooltip>
          </li>

          <li>
            <Tooltip>Total Memory Request (MB)</Tooltip>
          </li>

          <li>
            <Tooltip>Total Memory Limit (MB)</Tooltip>
          </li>
        </ul>
      </td>
    </tr>
  </tbody>
</table>

### Containers with Unspecified Settings

If the selected manifest does not have CPU or memory request values set, additional cards with details of the impact of unspecified values are shown. See [Containers with Unspecified Settings](/docs-kubex/Content/Kubex/AI_Analysis_Details_Table#unspecified) for more details.

<Frame>
  <img alt="" />
</Frame>

<table>
  <tbody>
    <tr>
      <td>
        <ul>
          <li>
            <Tooltip>Total Surplus CPU Request (mCores)</Tooltip>
          </li>

          <li>
            <Tooltip>Total Surplus Memory Request (MB)</Tooltip>
          </li>

          <li>
            <Tooltip>Estimated Waste/month</Tooltip>
          </li>
        </ul>
      </td>
    </tr>
  </tbody>
</table>

## Container Information

Click any of the listed settings to see a brief description. Complete descriptions of each setting are provided in the [Analysis Details Table](/docs-kubex/Content/Kubex/AI_Analysis_Details_Table).
Identifying details are displayed on this card.

<InlineImageWithText>
  <ul>
    <li>Container Name</li>
    <li>Cluster</li>
    <li>Namespace</li>

    <li>
      <Tooltip>Pod Owner Name</Tooltip>
    </li>

    <li>
      <Tooltip>Pod Owner Kind</Tooltip>
    </li>

    <li>
      <Tooltip>Predicted Uptime</Tooltip>
    </li>

    <li>
      <Tooltip>Avg No. of Containers</Tooltip>
    </li>
  </ul>
</InlineImageWithText>

The cost per core and per GB of memory is configurable. Contact [support@kubex.ai](mailto:support@kubex.ai) for details.

## Risk Summary

These 2 cards summarize potential resource risks for the container and node group, on which the containers are running.

<Frame>
  <img alt="" />
</Frame>

<table>
  <tbody>
    <tr>
      <td>
        <ul>
          <li>
            <Tooltip>Restarts</Tooltip>
          </li>

          <li>
            <Tooltip>OOM Kills</Tooltip>
          </li>

          <li>
            <Tooltip>CPU Throttling %</Tooltip>
          </li>
        </ul>
      </td>

      <td>
        <ul>
          <li>
            <Tooltip>Node Group</Tooltip>
          </li>

          <li>
            <Tooltip>Memory Saturation</Tooltip>
          </li>

          <li>
            <Tooltip>CPU Saturation</Tooltip>
          </li>

          <li>
            <Tooltip>Primary Constraint</Tooltip>
          </li>
        </ul>
      </td>
    </tr>
  </tbody>
</table>

## GPU Summary

This card summarizes the GPU allocation and for the selected container. This card is only displayed if the GPU resources have been allocated to this container. A hyperlink at the bottom of the card takes you to the GPU page.

<Frame>
  <img alt="" />
</Frame>

<table>
  <tbody>
    <tr>
      <td>
        <ul>
          <li>
            <Tooltip>GPU Model</Tooltip>
          </li>

          <li>
            <Tooltip>Total GPU Request</Tooltip>
          </li>

          <li>
            <Tooltip>GPU Request</Tooltip>
          </li>
        </ul>
      </td>

      <td>
        <ul>
          <li>
            <Tooltip>Total GPU Memory Request</Tooltip>
          </li>

          <li>
            <Tooltip>GPU Memory Request</Tooltip>
          </li>
        </ul>
      </td>
    </tr>
  </tbody>
</table>

## Utilization Charts

Utilization charts show hourly min/max and sustained activity for the selected system. The charts show the current and the recommended request and limit values for selected metrics. A chart is only displayed if the required data is available.
Details of working with there charts is provided in [Analysis Details Utilization Charts](/docs-kubex/Content/Kubex/AI_Analysis_Details_Charts).

<InlineImageWithText>
  <ul>
    <li>
      <Tooltip>No. of Containers</Tooltip>
    </li>

    <li>
      <Tooltip>No. of Restarts</Tooltip>
    </li>

    <li>
      <Tooltip>Other Charts</Tooltip>
    </li>
  </ul>
</InlineImageWithText>

#### Video Resources

<AccordionGroup>
  <Accordion title="Using the Tree Viewer">
    <iframe />

    <a href="https://player.vimeo.com/video/1038945637?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479">Using the Tree Viewer</a>
  </Accordion>

  <Accordion title="Using the Utilization Charts">
    <iframe />

    <a href="https://player.vimeo.com/video/1042992591?badge=0&autopause=0&player_id=0&app_id=58479">Using the Utilization Charts</a>
  </Accordion>
</AccordionGroup>


# Container Summary
Source: https://docs.kubex.ai/docs-kubex/Content/Kubex/Summary_Tab



This tab provides a simplified landing page that allows you to quickly understand the optimization potential in your Kubernetes environments.

The charts provide a clear breakdown of how optimization recommendations can provide immediate savings, the impact of taking those recommendations to reduce risk in your environment, and what additional waste can be safely removed once you have eliminated the identified risks.

The content on this tab is based on your selection in the tree viewer.

<Frame>
  <img alt="" />
</Frame>

When a single container is selected you will see the [Overview](/docs-kubex/Content/Kubex/Overview_Tab) and [Metrics Viewer](/docs-kubex/Content/Kubex/Metrics_Viewer_Tab) tabs.

## Current Monthly Spend

This first chart summarizes your current spend and breaks down CPU, Memory & GPU spend. A hyperlinked value of "manifests"takes you to the [Analysis Details](/docs-kubex/Content/Kubex/AI_Analysis_Details_Table) tab with same scope of systems selected.

<Frame>
  <img alt="" />
</Frame>

### Unit Costs

The default unit monthly cost of a vCPU, a GB of Memory, and GPUs are shown here. These values are used for all cost calculations. The values are configurable.

## Monthly Waste

This block shows you wasted resources as a dollar amount broken down by CPU and memory requests. These histogram charts show your data grouped as a distribution. The scope of data, is defined by the tree viewer. The link on the right side of each chart takes you to the [histogram](/docs-kubex/Content/Kubex/Histograms_Tab) page, with same scope of systems selected.

<Frame>
  <img alt="" />
</Frame>

## GPU Summary

Your GPU spend and allocation are summarized on this card.

<Frame>
  <img alt="" />
</Frame>

Click the "view details" hyperlink in the note shown at the bottom of the image to view GPU pricing details. This table provides visibility into how the cost is calculated. The cost per GPU might change greatly depending on the model, so this table provides the model details.

<Frame>
  <img alt="" />
</Frame>

If the GPU model and/or GPU unit cost are unknown, a default GPU unit cost of \$1.4K/month is used for the calculations. This value is configurable. Contact [support@kubex.ai](mailto:support@kubex.ai) for details.

## Optimization Breakdown

This bar chart shows the breakdown of your container spending: 

<Frame>
  <img alt="" />
</Frame>

Hover over any of the bars to see a description of the recommended optimization.

<Accordion title="Table: Optimization Breakdown Table">
  <table>
    <thead>
      <tr>
        <th>
          Column
        </th>

        <th>
          Description
        </th>
      </tr>
    </thead>

    <tbody>
      <tr>
        <td>
          Current Spend
        </td>

        <td>
          The bar shows you what you are currently spending on the infrastructure that has been selected in the tree viewer.<br />
          This value includes containers with unspecified CPU and/or memory request. See <a href="#unspecified">Containers with Unspecified Settings</a> for details.
        </td>
      </tr>

      <tr>
        <td>
          Immediate Savings
        </td>

        <td>
          Immediate savings can be achieved by adjusting the requested settings for containers within Node Groups where CPU or memory requests are the primary constraint. Adjusting these settings does not impact workload performance.
          A container qualifies for immediate savings if the "% of Nodes with CPU Saturation" is below a predefined threshold. For example, if the threshold is set at 50%, only containers where "% of Nodes with CPU Saturation" is less than 50% should be considered.<br />
          Immediate savings can be achieved by adjusting the Memory Request settings only for containers within Node Groups where Memory Request" is the primary constraint.
          Calculated as: Sum of immediate CPU savings + Sum of immediate memory savings
        </td>
      </tr>

      <tr>
        <td>
          Risk Removal
        </td>

        <td>
          The incurred cost to reduce or eliminate resourcing shortfalls that may be causing application restarts, CPU throttling or memory events, including OOM kills.
          CPU and memory shortfalls are aggregated for all containers in the selected scope and used to determine this value.<br />
          Calculated as: Sum(Shortfall CPU\<0 (in mcores))/1000 mcores/core \*CPU unit cost/core +  Sum(Shortfall memory \<0 (in MB))/1024 MB/GB \*Memory unit cost/GB
        </td>
      </tr>

      <tr>
        <td>
          Additional Waste
        </td>

        <td>
          These are possible, additional savings that can be achieved, after implementing the Risk Removal recommendations.<br />
          Calculated as (\$Total Cost + Risk Removal - Immediate Savings - Optimal Cost).
        </td>
      </tr>

      <tr>
        <td>
          Optimal Spend
        </td>

        <td>
          This is the projected monthly spend if all of the recommendations are made.<br />
          Calculated as ($Total Cost - $Total Estimated Waste).
        </td>
      </tr>
    </tbody>
  </table>
</Accordion>

#### Video Resources

<AccordionGroup>
  <Accordion title="Kubex UI Overview">
    <iframe />

    <a href="https://player.vimeo.com/video/1052046936?badge=0&autopause=0&player_id=0&app_id=58479">Kubex UI Overview</a>
  </Accordion>

  <Accordion title="Using the Tree Viewer">
    <iframe />

    <a href="https://player.vimeo.com/video/1038945637?title=0&byline=0&portrait=0&badge=0&autopause=0&player_id=0&app_id=58479">Using the Tree Viewer</a>
  </Accordion>
</AccordionGroup>


# How Kubex Analyzes Kubernetes Containers
Source: https://docs.kubex.ai/docs-kubex/Content/Kubex/container_optimization



Container rightsizing is critical for both cost efficiency and runtime stability.

| Undersized Risk                                                                                     | Oversized Risk                                             |
| --------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- |
| Workloads do not receive enough resources to run safely, creating performance and reliability risk. | Idle capacity waste and reduced cluster utilization.       |
| Undersized memory limits can cause OOM kills.                                                       | Increased probability of pending pods.                     |
| CPU Throttling and degraded application performance.                                                | Failed deployments caused by resource fragmentation.       |
| Node overcommitment, leading to unstable scheduling behavior and capacity contention.               | Autoscaler thrashing from inefficient scheduling pressure. |

Kubex analyzes Kubernetes containers by combining machine learning, workload behavior analysis, and policy-driven optimization to determine the scientifically optimal CPU and memory settings for each workload. The platform continuously evaluates real container behavior over time and generates safe, explainable recommendations that reduce waste while maintaining application stability.

<Frame>
  <img alt="" />
</Frame>

## Container Optimization Workflow

### 1. Container Telemetry Collection

Kubex continuously collects raw operational data from Kubernetes containers, including:

* CPU utilization
* Memory utilization
* Resource requests
* Resource limits
* Replica behavior
* Scaling activity
* OOM kill events
* Runtime utilization trends

The platform analyzes this data across all replicas of a workload to understand actual application behavior rather than relying on static configuration values.

### 2. Usage Pattern Analysis

Kubex applies machine learning models to identify workload behavior patterns over time.

The analysis includes:

#### Historical Resource Consumption

Evaluates:

* Average utilization
* Peak utilization
* Sustained demand
* Burst patterns
* Idle periods

#### Temporal Workload Behavior

Analyzes:

* Time-of-day usage
* Daily and weekly cycles

<Frame>
  <img alt="" />
</Frame>

### 3. Policy-Based Optimization

Kubex combines machine learning analysis with configurable operational policies.

[Policies](k8s_container_policy) allow teams to control:

* Optimization aggressiveness
* Minimum headroom requirements
* Downsizing behavior
* Upsizing sensitivity
* Environment-specific standards
* Assignment of policies to clusters, namespace or label-based

This ensures recommendations align with business and operational objectives rather than applying generic optimization logic.

### 4. Scientific Rightsizing Recommendations

Based on workload analysis and policy evaluation, Kubex generates optimized recommendations for:

* **CPU** Limit & Request
* **Memory** Limit & Request
* **Ephemeral Storage** Limit & Request
* **GPU** fractional recommendations and optimal MIG profile. See [GPU Optimization](gpu_optimization)

The recommendations are designed to:

* Eliminate wasted capacity
* Maintain workload stability
* Improve scheduler efficiency
* Reduce infrastructure cost

Kubex focuses on determining the correct resource configuration scientifically rather than relying on static thresholds or simplistic heuristics.

For the most efficient and hands-off execution path, use [Kubex automation](Automation_Engine_Overview) to apply approved recommendations consistently at scale.

## Key Benefits of Kubex Container Analysis

| Capability                     | Benefit                                          |
| ------------------------------ | ------------------------------------------------ |
| ML-Based Workload Analysis     | Accurate resource sizing based on real behavior  |
| Policy-Driven Optimization     | Aligns recommendations with operational goals    |
| Replica-Aware Analysis         | Detects workload-wide inefficiencies             |
| Continuous Reassessment        | Adapts to changing workload demands              |
| Kubernetes-Aware Safety Checks | Reduces operational risk                         |
| Automated Rightsizing          | Eliminates manual tuning effort                  |
| Explainable Recommendations    | Builds trust with platform and application teams |


# GPU Optimization in Kubex
Source: https://docs.kubex.ai/docs-kubex/Content/Kubex/gpu_optimization



Kubex provides advanced GPU optimization capabilities for Kubernetes environments running AI and machine learning workloads. The platform continuously analyzes GPU utilization, GPU memory consumption, workload density, and infrastructure efficiency to help organizations reduce GPU cost, improve utilization, and maximize AI infrastructure yield.

## Overview

GPU infrastructure is significantly more expensive than traditional CPU and memory resources, yet many AI workloads consume only a fraction of the GPU resources allocated to them.

<Frame>
  <img alt="" />
</Frame>

Kubex addresses this challenge by:

* Continuously monitoring GPU workloads
* Analyzing utilization patterns
* Identifying underutilized GPUs
* Detecting inefficient workload placement
* Recommending workload consolidation strategies
* Optimizing GPU density and infrastructure selection

Kubex focuses on increasing GPU yield while maintaining application performance and response time objectives.

## GPU Workload Visibility

Kubex automatically identifies containers consuming GPU resources and separates GPU spend from standard CPU and memory infrastructure costs.

The platform provides:

* GPU-specific workload views
* GPU spend analysis
* Per-container GPU allocation visibility
* GPU model identification
* Historical GPU utilization analysis

<Frame>
  <img alt="" />
</Frame>

This allows teams to quickly identify:

* Expensive AI workloads
* Inefficient GPU usage
* Oversized GPU allocations
* Unused GPU infrastructure

## GPU Utilization Analysis

Kubex continuously analyzes multiple dimensions of GPU consumption.

### GPU Compute Utilization

Kubex tracks:

* Average GPU usage
* Peak GPU consumption
* Sustained utilization
* Real-time GPU demand
* Historical usage trends

This helps determine whether workloads are:

* Fully utilizing allocated GPUs
* Underutilizing GPU capacity
* Suitable for consolidation or partitioning

Example findings:

* Workloads averaging 30–50% GPU usage
* Workloads consuming only 10% of a GPU
* Workloads peaking near full GPU capacity

### GPU Memory Utilization

Kubex additionally analyzes:

* GPU memory allocation
* Memory consumption trends
* Peak GPU memory usage
* Sustained memory utilization

This is critical because many AI workloads:

* Consume low GPU compute
* But require large GPU memory footprints

Kubex evaluates both dimensions together to determine safe consolidation opportunities.

### GPU Power Consumption Analysis

Kubex also provides visibility into power usage:

* GPU power utilization
* Consumption patterns
* Operational cycles

This helps organizations better understand:

* GPU efficiency
* Workload intensity
* Resource yield
* Runtime operating behavior

### Historical & Pattern-Based Analysis

Kubex performs continuous historical analysis of GPU workloads.

The platform evaluates:

* Daily operational cycles
* Weekday vs weekend behavior
* Peak activity windows
* Sustained demand periods
* Long-term workload trends

This enables Kubex to distinguish:

* Temporary spikes
* Stable sustained utilization
* Idle periods
* Predictable usage cycles

The result is more accurate optimization decisions compared to static threshold-based approaches.

## GPU Density Optimization

One of Kubex's core optimization goals is improving GPU density.

<Frame>
  <img alt="" />
</Frame>

Kubex identifies workloads that:

* Use only a fraction of a GPU
* Can safely share GPU resources
* Are candidates for workload consolidation

Examples include:

* Two workloads each consuming \~50% GPU
* Multiple workloads consuming only 10–20% GPU

Kubex helps organizations consolidate these workloads to:

* Reduce the number of deployed GPUs
* Improve GPU utilization
* Lower infrastructure cost

## GPU Partitioning & Sharing Strategies

Kubex evaluates whether workloads can benefit from GPU sharing technologies.

Supported optimization strategies include:

### Multi-Instance GPU (MIG)

For partitionable GPU models, Kubex can identify opportunities to:

* Split GPUs into multiple isolated partitions
* Run multiple workloads on a single GPU
* Increase infrastructure efficiency

### Fractional GPU Allocation

Kubex can evaluate workloads suitable for:

* Shared GPU execution
* Workload multiplexing

The platform analyzes:

* GPU model capabilities
* Workload demand
* Compute requirements
* GPU memory requirements
* Infrastructure cost tradeoffs

to determine the most efficient deployment model.

## GPU Infrastructure Optimization

Kubex evaluates the relationship between workloads and GPU hardware models.

The platform can compare:

* GPU utilization efficiency
* GPU cost efficiency
* Partitioning capabilities
* Infrastructure suitability

Example optimization decisions:

* Stay on lower-cost GPUs
* Migrate to partitionable GPUs
* Consolidate onto newer GPU architectures
* Reduce total deployed GPU count

Kubex determines the optimal balance between:

* Cost
* Performance
* Density
* Response time
* Resource availability

## Detection of Unused GPUs

Kubex identifies deployed GPU nodes that are not actively running GPU workloads.

These "deadwood" GPUs represent:

* Wasted infrastructure cost
* Idle GPU capacity
* Overprovisioned environments

## Detection of Non-GPU Workloads on GPU Nodes

Kubex also analyzes workload placement efficiency.

The platform detects:

* Containers running on GPU nodes
* But not consuming GPU resources

These workloads may unnecessarily consume:

* Node memory
* CPU capacity
* Storage resources

Removing non-GPU workloads from GPU node groups allows:

* Higher GPU workload density
* Better cluster efficiency
* Reduced infrastructure waste

## Optimization Objectives

Kubex GPU optimization focuses on several key objectives:

| Objective                    | Description                                   |
| ---------------------------- | --------------------------------------------- |
| Increase GPU Utilization     | Improve overall GPU yield                     |
| Reduce GPU Waste             | Eliminate idle or underutilized GPUs          |
| Improve Workload Density     | Consolidate compatible workloads              |
| Optimize Infrastructure Cost | Lower GPU infrastructure spend                |
| Improve Placement Efficiency | Ensure GPU nodes host GPU workloads           |
| Maintain Performance         | Preserve response times and workload behavior |

## Business Impact

GPU infrastructure often represents a disproportionate share of Kubernetes infrastructure cost.

Kubex commonly identifies opportunities to:

* Reduce GPU cost by up to 50%
* Consolidate workloads
* Eliminate idle GPU resources
* Improve utilization efficiency
* Increase AI infrastructure scalability

This enables organizations to operate AI and machine learning platforms more efficiently while controlling rapidly growing GPU spend.


# Kubernetes Container Optimization Policy Settings
Source: https://docs.kubex.ai/docs-kubex/Content/Kubex/k8s_container_policy



Kubernetes container optimization policies in Kubex define how the platform analyzes container workloads and generates resource recommendations. This page describes the key policy settings available in the container optimization policy dialog.

<Frame>
  <img alt="" />
</Frame>

## Operational Windowing

Operational Windowing settings control the time period and data samples used for analyzing container workloads.

### Workload Range

The number of days of historical data used for workload analysis.

* **Default**: 95 days
* **Purpose**: Determines the lookback window for analyzing container behavior patterns
* **Considerations**:
  * Longer ranges provide more comprehensive trend analysis
  * Shorter ranges focus on recent behavior
  * Should be sufficient to capture workload seasonality and growth trends

### Include Weekends

Whether to include weekend operations in workload analysis.

* **Options**: Yes / No
* **Default**: Yes
* **Purpose**: Determines if workload behavior differs significantly between weekday and weekend
* **Use Cases**:
  * Enable if workloads operate 24/7
  * Disable if significant operational differences exist between weekdays and weekends

### Include Samples Between

The percentile range of samples to include in analysis.

* **Default**: 0 - 100 %ile
* **Purpose**: Filters outlier data points from analysis
* **Options**:
  * 0 - 100 %ile: Include all data
  * Custom ranges: Exclude extreme outliers (e.g., 5 - 95 %ile)

### Exclude Hours

Hours of the day to exclude from workload analysis.

* **Purpose**: Removes maintenance windows, batch processing, or non-production hours
* **Example**: Exclude 2:00 AM - 4:00 AM for scheduled maintenance windows

## Minimum Data for Analysis

These settings define the minimum historical data required before generating recommendations.

### Days

Minimum number of days of data required before analysis begins.

* **Default**: 1 day
* **Purpose**: Ensures sufficient data coverage before providing recommendations
* **Considerations**:
  * Higher values ensure more reliable analysis
  * Lower values enable faster recommendations for newly deployed workloads

### Hours

Minimum number of hours per day of data collection required.

* **Default**: 2 hours
* **Purpose**: Ensures sufficient operational coverage within each day
* **Use Cases**:
  * Set higher for business-critical workloads
  * Set lower for dev/test environments

## CPU Settings

CPU policy settings control how Kubex sizes CPU requests and limits.

### Size CPU Request

Defines the basis for CPU request recommendations.

#### Metric

* **Default**: CPU Utilization in mCores - Container Average
* **Options**:
  * Container Average: Uses average CPU consumption across all replicas
  * Busiest Container: Uses the highest consuming replica
* **Impact**: Average-based sizing is more aggressive; busiest-based is more conservative

#### Statistic

The utilization trend used for sizing.

* **Default**: Sustained
* **Options**:
  * Sustained: Uses consistent, prolonged utilization patterns
  * Peak: Uses maximum observed consumption
  * Average: Uses arithmetic mean
* **Impact**: Sustained reduces overprovisioning; peak ensures stability

#### Maintain Usage Between

The target utilization range when the system is properly sized.

* **Default**: 100% - 100%
* **Purpose**: Defines acceptable resource consumption relative to the request
* **Example**:
  * 80% - 100%: Allows up to 20% headroom
  * 100% - 100%: Tight fit, no headroom

### Size CPU Limit

Defines the basis for CPU limit recommendations.

#### Metric

* **Default**: CPU Utilization in mCores - Busiest Container
* **Purpose**: Limits should account for peak demands across all replicas
* **Typical Setting**: Uses busiest container to prevent throttling

#### Statistic

* **Default**: Sustained
* **Purpose**: Ensures limits accommodate sustained peak demands

#### Maintain Usage Between

* **Default**: 99999% - 99999%
* **Purpose**: High percentages indicate limits should be generous to prevent throttling
* **Interpretation**: Very high values mean "set limit above any observed demand"

### CPU Allocation Range

Defines valid CPU resource allocation boundaries.

* **Range**: 1 - 100000 mCores
* **Increment**: 1 mCore
* **Purpose**: Prevents unrealistic recommendations outside operational constraints
* **Customization**: Adjust based on node sizes and cluster capabilities

## Memory Settings

Memory policy settings control how Kubex sizes memory requests and limits.

### Size Memory Request

Defines the basis for memory request recommendations.

#### Metric

* **Default**: Memory (Total) Utilization - Container Average
* **Options**:
  * Container Average: Uses average memory consumption
  * Busiest Container: Uses highest consuming replica
* **Purpose**: Average-based sizing fits normal operation; busiest accommodates peak demands

#### Statistic

* **Default**: Sustained
* **Purpose**: Identifies consistent memory demands to prevent OOM conditions

#### Maintain Usage Between

* **Default**: 100% - 100%
* **Purpose**: Defines acceptable memory utilization
* **Considerations**:
  * Memory should typically run higher than CPU (less headroom needed)
  * Too low utilization indicates overprovisioning
  * Too high risks out-of-memory errors

### Size Memory Limit

Defines the basis for memory limit recommendations.

#### Metric

* **Default**: Memory (Total) Utilization - Busiest Container
* **Purpose**: Limits must accommodate peak memory demands across all replicas

#### Statistic

* **Default**: Sustained
* **Purpose**: Ensures limits support sustained peak consumption

#### Maintain Usage Between

* **Default**: 99999% - 99999%
* **Purpose**: Very high values prevent memory limit enforcement
* **Interpretation**: Limits should be generous to avoid OOM kills

### Memory Allocation Range

Defines valid memory resource allocation boundaries.

* **Range**: 1 - 200000 MB
* **Increment**: 1 MB
* **Purpose**: Defines minimum and maximum memory sizes for recommendations
* **Customization**: Adjust based on node memory and application requirements

## Ephemeral Storage Settings

Ephemeral storage policy settings control how Kubex sizes container emptyDir and local storage.

### Size Ephemeral Storage Request

Defines the basis for ephemeral storage request recommendations.

#### Metric

* **Default**: Ephemeral Storage Usage (MB) - Average
* **Options**:
  * Average: Uses typical storage consumption
  * Busiest Container: Uses peak consumption
* **Purpose**: Request sizing should accommodate normal operations

#### Statistic

* **Default**: Sustained
* **Purpose**: Identifies baseline storage needs

#### Maintain Usage Between

* **Default**: 80% - 100%
* **Purpose**: Allows some headroom for growth without excessive allocation
* **Rationale**: Storage is less critical than CPU/memory, allows tighter packing

### Size Ephemeral Storage Limit

Defines the basis for ephemeral storage limit recommendations.

#### Metric

* **Default**: Ephemeral Storage Usage (MB) - Busiest Container
* **Purpose**: Limits must prevent storage-related pod evictions

#### Statistic

* **Default**: Sustained
* **Purpose**: Accommodates peak storage demands

#### Maintain Usage Between

* **Default**: 100% - 100%
* **Purpose**: Very tight fit prevents wasteful allocation
* **Impact**: Limits set close to observed peak usage

### Ephemeral Storage Allocation Range

Defines valid ephemeral storage allocation boundaries.

* **Range**: 10 - 500000 MB
* **Increment**: 10 MB
* **Purpose**: Defines practical bounds for storage recommendations
* **Customization**: Adjust based on node ephemeral storage capacity

## Policy Best Practices

### Conservative Deployment

For production environments with strict reliability requirements:

* Use "Busiest Container" metrics for requests and limits
* Set "Maintain Usage Between" to 70% - 90% for CPU/Memory
* Increase Workload Range to 95+ days
* Set higher Minimum Data requirements

### Aggressive Optimization

For cost-sensitive environments with workload flexibility:

* Use "Container Average" metrics for requests
* Set "Maintain Usage Between" to 95% - 100%
* Use shorter Workload Range (30-45 days)
* Lower Minimum Data requirements

### Balanced Approach

For typical enterprise environments:

* Use "Container Average" for requests, "Busiest" for limits
* Set "Maintain Usage Between" to 80% - 95% for CPU, 90% - 100% for Memory
* Use standard 60-day Workload Range
* Set reasonable (7+ day) minimum data requirements

## Modifying Policies

Policies can be customized at the environment level to match your specific requirements. When modifying policies:

1. Start with a default policy that matches your environment type
2. Adjust one setting at a time and review results
3. Validate recommendations with your infrastructure and application teams
4. Document policy rationale for future reference
5. Consider workload-specific policies for very different workload types

Work with your Kubex account manager to customize policies effectively based on your unique operational requirements and business objectives.


# Overview
Source: https://docs.kubex.ai/docs/WebHelp_Densify_Cloud/Content/Administration/Configuring_External_User_Authentication



Kubex provides the capability to authenticate users through external identity providers, that support the OpenID Connect specification. OpenID provides a framework for communicating between an identity provider and the OpenID acceptor, such as Okta and Microsoft Entra ID.

When authenticating users externally, authentication of Kubex users is first delegated to an external identity provider.

A user can be authenticated in one of two ways:

* Local user--The account is created and validated within Kubex. For on-premise deployments, you can configure a local account linked to a Windows® Active Directory™ account to access Kubex. Windows® Active Directory™ is not supported for SaaS deployments.
* External authentication--These users are authenticated through an external identity provider, that support the OpenID Connect specification. Only the following external identity providers are supported:

<table>
  <col />

  <col />

  <tbody>
    <tr>
      <td>
        <ul>
          <li><a href="./External_User_Authentication_Example_Configuration_for_Google_OpenID">Google OpenID</a></li>
          <li><a href="./External_User_Authentication_Example_Configuration_for_Azure_Active_Directory">Microsoft Entra ID</a></li>
        </ul>
      </td>

      <td>
        <ul>
          <li><a href="./External_User_Authentication_Example_Configuration_for_Okta">Okta</a></li>
          <li>Ping</li>
        </ul>
      </td>
    </tr>
  </tbody>
</table>

<Note>
  Once Open ID is enabled, users must exist in their OpenID provider before they can access Kubex. Users that are created in the Kubex user management console must use the same email address as their user ID in Microsoft Entra ID, Okta or Google.
</Note>

Once configured you can access either the Kubex Console or the Analysis Console using the configured connection.

<Note>
  The one exception is Google OpenID. When using Google Open ID, only the Kubex Console is supported. If you try to access the Analysis Console, the connection request will fail. If you need to access the Analysis Console, use Microsoft Entra ID, Okta or Ping.
</Note>

## Prerequisites

### Identity Provider Requirements

Before you can configure the feature in Kubex, you must register Kubex with your identity provider. You need to provide information about the application type, login/logout URLs etc. This is a standard procedure across all applications using OpenID for authentication.

Kubex supports: [Google OpenID](./External_User_Authentication_Example_Configuration_for_Google_OpenID), [Microsoft Entra ID](./External_User_Authentication_Example_Configuration_for_Azure_Active_Directory), [Okta](./External_User_Authentication_Example_Configuration_for_Okta) and Ping as external identity providers.

<Accordion title="Table: Configuring Kubex with the Identity Provider">
  <table>
    <col />

    <col />

    <thead>
      <tr>
        <td>
          <p>Setting</p>
        </td>

        <td>
          <p>Description</p>
        </td>
      </tr>
    </thead>

    <tr>
      <td>
        <p>Application Type</p>
      </td>

      <td>
        <p>Select Single Page Application (SPA) with Implicit grant type enabled. You must also allow ID Token and Access Token. </p>
        <p>If the ID Token or Access Token options are not available, please consult your Identity Provider’s administrator to determine where these are specified, or if they are implicitly set as a part of registering an SPA application with Implicit grant type. </p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Login redirect URIs:</p>
      </td>

      <td>
        <p>This is the callback URL to your <span>Kubex</span> instance where the identity provider redirects the user after they have been authenticated. </p>
        <p>https\://\<instancename>.kubex.ai:443</p>
        <p>The HTTP redirect URIs must be protected with TLS security, so the service will only redirect to URIs beginning with "https". This prevents tokens from being intercepted during the authorization process.</p>
      </td>
    </tr>

    <tr>
      <td>
        <p>Logout redirect URIs:</p>
      </td>

      <td>
        <p>A logout URL is a URL in  your <span>Kubex</span> instance that the identity provider can return to after the user has been logged out of the authorization server. </p>

        <ul>
          <li>https\://\<instancename>.kubex.ai (for the <span>Kubex Console</span>)</li>
          <li>https\://\<instancename>.kubex.ai:443/admin (for the <span>Analysis Console</span>)</li>
          <li>https\://\<instancename>.kubex.ai:443/openIdError</li>
        </ul>

        <p>When using Google OpenID Connect only the following is required:</p>

        <ul>
          <li>https\://\<instancename>.kubex.ai:443/openIdError</li>
        </ul>
      </td>
    </tr>

    <tr>
      <td>
        <p>Required Scopes</p>
      </td>

      <td>
        <ul>
          <li>openid</li>
          <li>Profile</li>
          <li>Email – If not available, <span>Kubex</span> will use the preferred user name (preferred\_username) value of the claim to verify that the user is registered with <span>Kubex</span>. <span>Kubex</span> assumes this is an email address.</li>
        </ul>
      </td>
    </tr>
  </table>
</Accordion>

### Kubex User Configuration

The user's login ID returned from the identity provider must be in the form of an email address, and this email address must correspond to the email address in the Kubex user ’s profile.

## Authentication Code Workflow

When this option is enabled, rather than transmit the user details, the identity provider sends a special, one-time-use authentication code that can be exchanged for an access token. This exchange includes the client\_id and client\_secret in addition to the authentication code.

The Kubex user, attempting to access Kubex is still redirected to their identity provider's login screen where they enter their credentials.
The user must be registered with the identity provider and must have valid credentials to access Kubex.

Upon successful login, Kubex validates the user using the ID token returned by the identity provider, as defined by the OpenID Connect specification. Additionally, the identity provider returns an authorization code to the browser.

The Kubex web server now uses the supplied authorization code to request an access token. The identity provider validates the authorization code and sends the access token.

Validation is completed by Kubex when a user profile with an email address that matches the user's email address is located in the Kubex database.

<Accordion title="Figure: Authentication Code Workflow">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

### Configuring Authentication Code

1. You must first register Kubex with your identity provider. This is a standard procedure across all applications using OpenID for authentication. See [Configuring External User Authentication](#Table_Configuring_ID_Provider), above
2. You now need to provide the following information to Kubex. These settings are all configured for you by Kubex. Contact [support@kubex.ai](mailto:support@kubex.ai) for details.

<table>
  <col />

  <col />

  <tbody>
    <tr>
      <td>
        <ul>
          <li>Enable OpenID Connect Authentication</li>
          <li>OpenID Connect Identity Provider </li>
          <li>OpenID Connect Authentication Mode </li>
          <li>OpenID Connect Login URL</li>
        </ul>
      </td>

      <td>
        <ul>
          <li>OpenID Connect ID Token Issuer </li>
          <li>OpenID Connect Client ID</li>
          <li>OpenID Connect Client Secret</li>
          <li>Use static page for OpenID Connect logout </li>
        </ul>
      </td>
    </tr>
  </tbody>
</table>

Once the configuration has been completed, both Kubex and the user are verified by your authentication provider and then permitted access to Kubex, upon user login.

### Validation Failure

If user validation fails at any point the user is re-directed to a login failure page. This page is configured and managed by the identity provider.
Similarly all session timeouts result in a session timeout call to the external identity provider and users are re-directed to the session time out page, that is configured and managed by the identity provider.

This feature only applies to the Kubex application and is not applicable to Kubex's REST API.

Validation is only performed on the mandatory fields defined in the OpenID Connect specification.

The next section contains the following topics:

* [External User Authentication Example Configuration for Microsoft Entra ID](/docs/WebHelp_Densify_Cloud/Content/Administration/External_User_Authentication_Example_Configuration_for_Azure_Active_Directory)
* [External User Authentication Example Configuration for Google OpenID](/docs/WebHelp_Densify_Cloud/Content/Administration/External_User_Authentication_Example_Configuration_for_Google_OpenID)
* [External User Authentication Example Configuration for Okta](/docs/WebHelp_Densify_Cloud/Content/Administration/External_User_Authentication_Example_Configuration_for_Okta)


# External User Authentication for Microsoft Entra ID
Source: https://docs.kubex.ai/docs/WebHelp_Densify_Cloud/Content/Administration/External_User_Authentication_Example_Configuration_for_Azure_Active_Directory



You can use the following process to setup Microsoft Entra ID (formerly known as Azure AD). You need to register Kubex as a web application in your Microsoft Entra ID and then provide the following information to Kubex:

* Application (client) ID
* Directory (tenant) ID
* Client secret (password)

An auto-provisioning feature allows users to access the Kubex Console without needing to manually create user accounts in Kubex. Additional configuration is required as outlined in, [Creating User Groups for Users](#Create_groups). Contact [support@kubex.ai](mailto:support@kubex.ai) to enable the auto-provisioning feature.

### Register an Application

You must have permission to manage applications in Microsoft Entra ID. i.e. Application administrator or Application developer, etc.

1. Log into the Microsoft Entra ID portal. If you have access to multiple tenants, use the Directories + subscriptions filter in the top menu to switch to the tenant in which you want to register the application.
2. Navigate to Microsoft Entra ID > App Registrations > New registration.

<Accordion title="Figure: Creating a New Registration">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

3. In the Register an application pane, enter the following information:

* The Name of the application (i.e. Kubex\_Connection)
* Specify who can use the application. You can leave the default setting, Accounts in this organizational directory only (Default Directory only – Single tenant).
* You do not need to add anything under the Redirect URI. You can configure the URIs in the next section.

4. Once you have entered the required information the Register button becomes available. Click Register to complete the process.

<Accordion title="Figure: Creating a New Registration">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

5. Once you have completed the registration, you will be directed to the overview page for your new application registration.

New app registrations are hidden to other users by default. Refer to Microsoft.com for details on enabling your app registration for other users, if required.

#### Obtaining the Application and Directory IDs

1. In the Microsoft Entra ID portal, navigate to Microsoft Entra ID > App Registrations.
2. Select your new App Registration and copy the following values:

* Application (client) ID
* Directory (tenant) ID

You need to provide these values to Kubex to complete the authentication process.

<Accordion title="Figure: Obtaining the Required IDs">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

### Configuring the URIs

A redirect URI is the location where the Microsoft identity platform redirects a user's client and sends back the security tokens after authentication.

1. In the Microsoft Entra ID portal, in App registrations, select your application registration.
2. Select Authentication from the side menu.
3. Under Platform configurations, click Add a platform and then choose Web applications > Web.
4. Under Redirect URIs, add the following URIs:

<Note>
  These are examples only. Contact Kubex for the actual URIs.
</Note>

* https\://\<instancename>.kubex.ai:443
* https\://\<instancename>.kubex.ai:443/redirect
* https\://\<instancename>.kubex.ai:443/kubex
* https\://\<instancename>.kubex.ai:443/openIdError

5. Click Add URI to add each entry. You should have a total of 4 URIs.

<Accordion title="Figure: Adding Redirect URIs">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

6. Click Save to commit all your information.

### Obtaining the Credentials

The credentials generated here allow Kubex to authenticate as itself, requiring no interaction from the user at runtime.

A client secret is sometimes called an application password. It is a string value that Kubex can use in place of a certificate to identity itself.

1. In the Microsoft Entra ID portal, in App registrations, select your application registration.
2. Navigate to Certificates & secrets > Client secrets > New client secret.
3. Add a description for your client secret. i.e.Kubex-Client-Secret
4. Select an expiration for the client secret or specify a custom lifetime. Please note the following:

* Client secret lifetime is limited to 24 months, or less.
* Microsoft recommends that you set an expiration value of less than 12 months.
* You will need to renew the secret prior to the expiry date and provide the new value to Kubex each time the value expires.

5. Click Add to save your settings and to generate the client secret.

<Accordion title="Figure: Copying Client Secret Value">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

Record the displayed value, as this value will not be displayed again once you leave this page and you need to provide this value to Kubex.

### Configuring the API Permissions for the Connection

In this section, you provide Kubex, now registered with the Microsoft identity platform with access to your own web API. You also provide the client app access to Microsoft Graph.

1. In the Microsoft Entra ID portal, select App registrations and then select your application registration.
2. Navigate to Manage > API permissions > Add a Permission > Microsoft Graph.

<Accordion title="Figure: Configuring the API Permissions">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

3. Choose ‘Delegated Permissions’. Microsoft Graph exposes many permissions, with the most commonly used permissions shown at the top of the list.
4. Under OpenId permissions, select:

* email--Allow Kubex to view the users’ email address;
* profile--Allow Kubex to view the users’ basic profile;

<Accordion title="Figure: Configuring the API Permissions">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

* Under GroupMember select:

* GroupMember.Read.All--Allow Kubex to read all user groups.

<Note>
  If the auto-provisioning feature is enabled, you need to add this permission. If the auto-provisioning is not enabled you do not need this permission.
</Note>

<Accordion title="Figure: Configuring the API Permissions">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

5. Under User select:

* User Read--should already be delegated. Allows Kubex to sign in and read user profile.

6. Click Add Permissions and choose Grant admin consent confirmation. Then click ‘Yes’ when prompted.
7. Click Yes when prompted.

<Accordion title="Figure: Configuring the API Permissions - 2">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

### Creating User Groups for Kubex Users

<Note>
  If the auto-provisioning feature is enabled, you need to create these groups, otherwise you can skip these steps.
</Note>

The auto-provisioning feature allows users to access the Kubex Console without needing to manually create user accounts in Kubex. Once the feature is enabled, you must create groups in your Microsoft Entra ID that correspond to Kubex's user groups and add users to grant the required permissions.

Contact [support@kubex.ai](mailto:support@kubex.ai) to enable the auto-provisioning feature.

You need to create user groups that correspond to the commonly used Kubex user groups: KUBEX\_USER, KUBEX\_USER\_ADMIN, KUBEX\_AUDIT\_ADMIN, and KUBEX\_POLICY\_ADMIN.

1. Navigate to Manage > Groups. You will see the list of existing groups.
2. Click New group at the top of the list and configure the group settings:

* Group Type--Select "Security"
* Group name--Specify the name, KUBEX\_USER. Use this exact name (uppercase, underscore and no spaces) for your new group.
* Group description--Optional: Provide a description for this group.
* Membership type--Specify how users will be added to the group i.e. "Assigned".

3. Click Create to create the group.
4. Repeat the process to create a group for KUBEX\_USER\_ADMIN, KUBEX\_AUDIT\_ADMIN, and KUBEX\_POLICY\_ADMIN.

<Note>
  These new user groups cannot be hidden groups.
</Note>

### Adding Kubex Users to Groups

Add the users to one or more groups. You can add users to all groups or add them to a specifc group , based on their requirements.

* KUBEX\_USER -- Users with this role can access all features in the Kubex Console.
* KUBEX\_USER\_ADMIN -- Users with this role can add, edit and remove Kubex user accounts through the user management dialog box.

<Note>
  User management is not required within Kubex when Open ID is configured and the auto-provisioning feature is enabled.
</Note>

* KUBEX\_AUDIT\_ADMIN -- Users with this role can create, edit or delete cloud audits, but cannot manage user accounts.
* KUBEX\_POLICY\_ADMIN -- Users with this role can edit policies applied to cloud accounts or Kubernetes clusters.

1. You should now see these new groups appear in the list of all groups. Navigate to one of the groups created above (i.e.: KUBEX\_USER)
2. Click Add members at the top of the list and select the users to be added:
3. Click Add.
4. Repeat the process to add users to the other groups.
5. After any changes, existing users must log out and clear their browser before logging in again. This is required regardless of the type or version of browser you are using.

### Completing the Setup

You now need to provide the following information to Kubex to complete the setup:

* Application (client) ID;
* Directory (tenant) ID;
* client secret value

These settings are all configured for you by Kubex. Contact [support@kubex.ai](mailto:support@kubex.ai) for details.


# External User Authentication for Google OpenID
Source: https://docs.kubex.ai/docs/WebHelp_Densify_Cloud/Content/Administration/External_User_Authentication_Example_Configuration_for_Google_OpenID



You can use the following process to setup Google OpenID for Authentication Code Flow. Before Kubex can use Google's OAuth 2.0 authentication system for user login, you must set up a project in the Google API Console to obtain OAuth 2.0 credentials and set redirect URIs. You need to register Kubex as a web application in your Google API Console and then provide specific details to Kubex to so that your Kubex instance can use Google OpenID for authentication

When using Google Open ID, only the Kubex Console is supported. If you try to access the Analysis Console, the connection request will fail. If you need to access the Analysis Console, you must use Azure AD, Okta or Ping.

### Register an Application

You must have permission to manage applications in your Google Console.

1. If you have access to multiple projects, select the project in the top menu in which you want to register the application.
2. Navigate to API & Services > Credentials.

<Accordion title="Figure: Locating the Credentials Page">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

3. Click CREATE CREDENTIALS and select OAuth client ID from the dropdown menu:

<Accordion title="Figure: Creating a New Credential">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

4. Select "Web application" from the Application type dropdown menu. You can accept the default Name for the OAuth 2.0 client.
5. Add the following redirect URIs:

* https\://\<instancename>.kubex.ai:443/redirect--This is the login redirect for Kubex.
* https\://\<instancename>.kubex.ai:443/openIdError--This is an error message page. The session management filter will redirect the user to the specified OpenID page. For example, when the Google user does not exist in Kubex.
* https\://\<instancename>.kubex.ai:443/openIdLoggedOut--This is logout URI. Specify this page if the configuration property, "login.openId.useStaticLogout" is set in the Kubex configuration settings.

<Note>
  These are examples only. Contact Kubex for the actual URIs.
</Note>

<Accordion title="Figure: Creating a OAuth Client ID">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

6. Click CREATE to create the client.

<Accordion title="Figure: Client Creation Confirmation">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

7. Copy the credentials and download the .JSON file.

New app registrations are hidden to other users by default. Refer to [Google Identity](https://developers.google.com/identity/openid-connect/openid-connect) for details on enabling your app registration for other users, if required.

### Logout Redirect Process

Google does not follow the same logout process as the other supported openID providers.

* Revokes the authentication token that was provided to user. If successful, then redirect to the specified Kubex page.
* This will not logout user from their Google account, but will only disable the selected connection made between the user and GCP account.
* Redirection to Kubex will now show the Google login screen, but will not request a password, as the user is not logged-out of their Google account


# External User Authentication for Okta
Source: https://docs.kubex.ai/docs/WebHelp_Densify_Cloud/Content/Administration/External_User_Authentication_Example_Configuration_for_Okta



You can use the following process to setup Okta for Authorization Code Flow:

### Authorization Server

You need to register Kubex as a web application in your Okta Authorization Server. and then provide the following information to the Kubex support team:

* Client ID
* Client secret (password)
* Issuer URI

### Create an Application

1. In Okta's *Admin Console*, select *Applications > Applications > Create App Integration*.

2. On the *Create a new app integration* page, select *OIDC - OpenID Connect* as the Sign-in method and *Web Application* as the Application type.

3. Click *Next*.

4. On the *New Web App Integration* page, select the following settings are click *Save*:

   * App integration name--a name for the application (example Kubex)

   * Sign-in redirect URIs--https\://\<instancename>.kubex.ai:443/redirect

   * Sign-out redirect URIs:

     * https\://\<instancename>.kubex.ai:443
     * https\://\<instancename>.kubex.ai:443/openIdError
     * https\://\<instancenanme>.kubex.ai:443/kubex

   * Controlled access - Allow everyone in your organization to access

5. Optional – If Proof Key for Code Exchange (PKCE) is required, include these additional steps:
   * Client Credentials – click ‘Edit’
   * Enable ‘Require PKCE as additional verification’
   * Click Save

6. From the application page copy Client ID and Client Secret. Provide these to Kubex.

### Testing the Token

1. From the *Admin Console* select *Security > API*
2. On the *API* page copy the *Issuer URI* and provide it to Kubex.
3. Click *default* (or the name of the Authorization Server you are using) to bring up Authorization Server Settings.
4. Select *Token Preview* tab and enter the following settings then click *Preview Token*:
   * OAuth/OIDC client – Kubex (or the App integration name you used above)
   * Grant type – Authorization Code
   * User – A user that will access Kubex
   * Scopes – openid email profile
5. If the token is generated the setup is complete. If you see an error "Policy evaluation failed for this request, please check the policy configurations." You will need to follow the next section to create an access policy.

### Create Access Policy (only required if you see the error in #5 above)

1. From the Admin Console select *Security > API*
2. Click *default* (or the name of the Authorization Server you are using) to bring up Authorization Server Settings.
3. Select *Access Policies* tab and click *Add New Access Policy*
4. On the Add Policy page enter the following settings and click *Create Policy*:
   * Name - Kubex (or any name you want to use)...
   * Description – Kubex (or any description you want to use)
   * Assign to > The following clients – Kubex (or the App integration name you used above)
5. Select the newly created Access policy and click *Add Rule*
6. On the Add Rule page give the rule a name and click *Create Rule*

### Provide Information to Kubex

You now need to provide the Client ID, Client Secret and Issuer URI, to complete the setup on the Kubex server side. These settings are all configured for you by the Kubex support team. Contact [support@kubex.ai](mailto:support@kubex.ai) for details.


# User Access Control (RBAC)
Source: https://docs.kubex.ai/docs/WebHelp_Densify_Cloud/Content/Administration/Kubex_User_Mgmt_RBAC



## Overview

Role-Based Access Control (RBAC) allows administrators to manage user permissions by assigning predefined roles. Each role grants access to specific features and capabilities within the platform, ensuring secure and efficient access management.

Users can be assigned one or more roles depending on their responsibilities.

| Role               | Description                                                                            | Key Capabilities                                                                              |
| ------------------ | -------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- |
| Analyst            | Provides access to explore and analyze data within the platform.                       | Access dashboards and analytics; explore datasets and insights; view reports and metrics      |
| Access Manager     | Responsible for managing users, groups, and access permissions.                        | Create and manage users; assign roles and group memberships; control access permissions       |
| Connection Manager | Manages integrations with external systems including cloud and container environments. | Add new connections; configure cloud and container integrations; maintain connection settings |
| Policy Manager     | Handles creation and management of analysis policies.                                  | Create and edit policies; manage analysis rules; govern policy enforcement                    |

***

## Assigning Roles

### If using SSO

If you are using Single-Sign-On (refer: [SSO Overview](/docs/WebHelp_Densify_Cloud/Content/Administration/Configuring_External_User_Authentication)), you can map your user groups to specific roles in Kubex.

By default, the following user groups are mapped to roles as described above:

* KUBEX\_USER -> Analyst
* KUBEX\_USER\_ADMIN -> Access Manager
* KUBEX\_AUDIT\_ADMIN -> Connection Manager
* KUBEX\_POLICY\_ADMIN -> Policy Manager

You can create these user groups in your identity provider and assign users to them. Once SSO is configured, Kubex will automatically provision users with the appropriate roles.

If you need to map existing user groups to Kubex roles, contact [support@kubex.ai](mailto:support@kubex.ai) to request an update to the mapping.

### If not using SSO

To assign roles to a user:

1. Navigate to the **User Management** section.
2. Edit or create a user and assign the desired role(s) using the checkboxes.
3. Save the changes to apply permissions.

Users can have multiple roles assigned simultaneously, combining permissions across roles.

<Frame>
  <img alt="" />
</Frame>

***

## Best Practices

* **Principle of Least Privilege:** Assign only the roles necessary for a user’s responsibilities.
* **Separation of Duties:** Avoid assigning conflicting roles to the same user.
* **Regular Audits:** Periodically review role assignments to ensure compliance.

***

## Summary

RBAC simplifies access control by grouping permissions into roles. By assigning appropriate roles, organizations can ensure users have the right level of access while maintaining security and governance.


# Instance & ScaleGroup Optimization
Source: https://docs.kubex.ai/docs/WebHelp_Densify_Cloud/Content/Cloud_Optimization

Optimize cloud infrastructure costs and performance across AWS, Azure, Google and Oracle Cloud

Kubex Cloud Resource Optimizer continuously analyzes cloud workloads, identifies waste, and recommends right-sizing actions across AWS, Azure, and Google Cloud and OCI environments. The platform helps SREs, Platform Engineering teams, Cloud Architects, and FinOps practitioners maximize utilization while maintaining operational reliability.

<Frame>
  <img alt="" />
</Frame>

***

## Kubex Collects and Analyzes

| Cloud Provider | Service Type     |
| -------------- | ---------------- |
| AWS            | EC2, RDS, ASG    |
| Azure          | VM, ScaleSet     |
| GCP            | Compute Instance |
| OCI            | VM               |

***

## Why Cloud Optimization Matters

Cloud environments often suffer from:

* Overprovisioned compute resources
* Underutilized instances
* Excessive cloud spend
* Performance bottlenecks caused by poor sizing decisions
* Manual optimization processes that don't scale

<Frame>
  <img alt="" />
</Frame>

Kubex helps organizations continuously align resource allocation with real workload demand, reducing waste while maintaining application performance.

***

## Key Benefits

### Lower Cloud Costs

Identify and eliminate unnecessary infrastructure spend through intelligent rightsizing recommendations and automated optimization workflows.

### Improve Resource Efficiency

Analyze actual workload behavior and allocate resources based on observed demand patterns rather than estimates.

### Reduce Operational Risk

Optimization recommendations are prioritized based on confidence, impact, and safety to minimize disruption.

### Accelerate FinOps Outcomes

Enable engineering, operations, and finance teams to collaborate around a shared view of optimization opportunities and realized savings.

***

## How It Works

### 1. Connect Cloud Accounts

Connect your cloud environment securely and begin collecting infrastructure and utilization data. See [Setup Cloud Data Collection](/docs-kubex/Content/Cloudex/Data_Collection_Overview-Cloud)

### 2. Assign Policies

A default policy is automatically assigned to instances in each account connected to Kubex. You can reassign policies at any time. For more details, refer to the [Cloud Policy](cloud_policy) page.

### 3. Analyze Workload Behavior

Kubex continuously evaluates:

* CPU utilization
* Memory consumption
* Resource allocation patterns
* Growth trends
* Performance characteristics

using machine learning and historical workload analysis.

<Frame>
  <img alt="" />
</Frame>

### 4. Identify Optimization Opportunities

The platform surfaces:

* Overprovisioned resources
* Underutilized instances
* Inefficient instance families
* Rightsizing opportunities
* Cost reduction recommendations
* For **Scale Groups (ASG, ScaleSet)**, Kubex additionally provides recommendations for min and max group sizes

prioritized by business impact and risk.

## FinOps Enablement

Kubex helps organizations mature their FinOps practices by providing:

| Capability              | Benefit                             |
| ----------------------- | ----------------------------------- |
| Cost Visibility         | Understand where cloud spend occurs |
| Resource Rightsizing    | Eliminate overprovisioning          |
| Savings Tracking        | Measure optimization impact         |
| Continuous Optimization | Maintain long-term efficiency       |

By embedding optimization into operational workflows, teams can make cloud cost management an ongoing process instead of a periodic exercise.

***

Organizations use Kubex to improve cloud efficiency, reduce operational complexity, and ensure infrastructure resources align with actual business demand.

***


# Troubleshooting AWS Data Collection
Source: https://docs.kubex.ai/docs/WebHelp_Densify_Cloud/Content/Data_Collection_Troubleshooting/AWS_Cloud_Connections



### Event: Account does not exist or incorrect permissions

The following are common issues when working with AWS cloud connections:

<Accordion title="Cause: AWS Account no longer exists">
  Solution: If the account no longer exists, the connection can be deleted using the Public Cloud Connection Wizard. See [Deleting a Connection](../Densify_Com/Using_the_Public_Cloud_Connection_Wizard.htm#Deleting).
</Accordion>

<Accordion title="Cause: Account exists, but has incorrect permissions">
  Solution: Ensure the [Minimum Permissions for CloudWatch Data Collection](../Data_Collection_for_Public_Cloud_Systems/AWS_Data_Collection_Prerequisites_for_an_IAM_Role__CloudWatch_only_.htm#Limited_Access_IAM_Policy) are set correctly.

  Once the permissions have been corrected, you can verify the connection using the Public Cloud Connection Wizard. See [Reviewing a Connection](../Densify_Com/Using_the_Public_Cloud_Connection_Wizard.htm#Review_Conn).
</Accordion>

<Accordion title="Cause: Account exists, but is configured incorrectly">
  Solution:Ensure the [AWS Data Collection Prerequisites for an IAM Role](../Data_Collection_for_Public_Cloud_Systems/AWS_Data_Collection_Prerequisites_for_an_IAM_Role__CloudWatch_only_) are setup correctly, Including that the External ID you have entered corresponds to the correct IAM Role.

  Once the prerequisites and credentials have been corrected, you can verify the connection on the Public Cloud Connection page.
</Accordion>

<Accordion title="Cause: Systems within the AWS account are not supported">
  Solution: If your account only contains services that Kubex does not analyze, then the audit will fail. i.e. DynamoDB, Redshift, Lambda, ElasticCache, etc.

  Within Kubex you need to manually delete the Cloud Environments associated with these accounts.
</Accordion>

If none of the above issues apply to your environment, contact [Support@Kubex.ai](mailto:Support@Kubex.ai) to review your connectivity details and receive further guidance.


# Troubleshooting Azure Data Collection
Source: https://docs.kubex.ai/docs/WebHelp_Densify_Cloud/Content/Data_Collection_Troubleshooting/Azure_Cloud_Connections



### Event: Subscription does not exist or incorrect permissions

The following are common issues when working with Azure cloud connections:

<Accordion title="Cause: Subscription no longer exists">
  Solution: If the subscription no longer exists, the connection can be deleted using the Public Cloud Connection Wizard.
</Accordion>

<Accordion title="Cause: Subscription no longer exists, but connection is valid">
  Solution: If the Subscription no longer exists, but the connection is still valid, you can re-discover and update subscriptions for the existing connection.

  1. In the Cloud Connection Wizard, click the Click to Refresh Account Connection and Discover Subscriptions button.

  * If the credentials are valid, you will be connected and authenticated. Once the account is verified, all subscriptions that are associated with the account or Application ID are listed. Select the subscriptions that you want to include in the audit.
  * If the credentials cannot be validated, then review the displayed error message and correct your credentials. It is possible that the user account does not have the required permissions.

  The user account/Service Principal to be used for data collection only requires the "Reader" role privileges to collect utilization data. See [Microsoft Azure Data Collection Prerequisites](../Data_Collection_for_Public_Cloud_Systems/Microsoft_Azure_Data_Collection_Prerequisites_for_a_Service_Principal.mdx) for details.

  2. In the Subscriptions In Scope section, the subscription may be removed automatically or may show a “No permission in Azure” message.
  3. From the Subscriptions In Scope section, if you want to remove existing audited subscriptions, de-select the desired subscriptions and click Save Connection.
  4. If you want to select additional subscriptions to be audited, select the desired subscriptions and click Save Connection.
  5. The Subscriptions In Scope list will not be up-to-date if subscriptions in the service account are modified after the last Click to Refresh Account Connection and Discover Subscriptions action.
  6. If you de-select all subscriptions associated with the Azure connection and try to save the connection, Kubex displays a message indicating the connection will be deleted if you save an empty subscription connection.
  7. Close the Public Cloud Connections wizard.
</Accordion>

<Accordion title="Cause: Subscription exists, but has incorrect permissions">
  Solution: Ensure Minimum Permissions are set correctly.
</Accordion>

<Accordion title="Cause: Subscription exists, but is configured incorrectly">
  Solution: If the minimum permissions are set correctly, or Microsoft Azure Data Collection Prerequisites to verify the prerequisites are setup correctly.

  Once the account and credentials have been corrected, verify the connection using the Public Cloud Connection Wizard.
</Accordion>

If none of the above issues apply to your environment, contact [support@kubex.ai](mailto:support@kubex.ai) to review your connectivity details and receive further guidance.


# Troubleshooting GCP Data Collection
Source: https://docs.kubex.ai/docs/WebHelp_Densify_Cloud/Content/Data_Collection_Troubleshooting/GCP_Cloud_Connections



### Event: Project does not exist or incorrect permissions

The following are common issues when working with GCP cloud connections:

<Accordion title="Cause: Project no longer exists">
  Solution: If the Project no longer exists, the connection can be deleted using the Public Cloud Connection Wizard.
</Accordion>

<Accordion title="Cause: Project exists, but has incorrect permissions">
  Solution: Ensure [Minimum Permissions for Data Collection](../Data_Collection_for_Public_Cloud_Systems/Google_Cloud_Platform_Data_Collection_Prerequisites#Min_Policy) are set correctly.
</Accordion>

<Accordion title="Cause: Project exists, but is configured incorrectly">
  Solution: If the minimum permissions are set correctly, see [Google Cloud Platform Data Collection Prerequisites](../Data_Collection_for_Public_Cloud_Systems/Google_Cloud_Platform_Data_Collection_Prerequisites) to verify the prerequisites are setup correctly.

  Once the account and credentials have been corrected, you can then verify the connection using the Public Cloud Connection Wizard.
</Accordion>

<Accordion title="Cause: PERMISSION_DENIED: This API method requires billing to be enabled.">
  The billing method for the audited project(s) has expired or has not been configured correctly. For example, the credit card used to setup the project has expired.

  Solution: Refer to the GCP documentation for details of configuring a billing method for your projects: [https://support.google.com/googleapi/answer/6158867](https://support.google.com/googleapi/answer/6158867)
</Accordion>

If none of the above issues apply to your environment, contact [support@kubex.ai](mailto:support@kubex.ai) to review your connectivity details and receive further guidance.


# Troubleshooting OCI Data Collection
Source: https://docs.kubex.ai/docs/WebHelp_Densify_Cloud/Content/Data_Collection_Troubleshooting/OCI_Cloud_Connections



### OCI Data Collection Issues

The following are common issues when working with OCI cloud connections:

<Accordion title="Incorrect private key file format">
  Solution: Create a new private key file in the PEM format or convert the existing key to PEM format.
</Accordion>

If none of the above issues apply to your environment, contact [support@kubex.ai](mailto:support@kubex.ai) to review your connectivity details and receive further guidance.


# AWS Data Collection Prerequisites for an IAM Role (CloudWatch only)
Source: https://docs.kubex.ai/docs/WebHelp_Densify_Cloud/Content/Data_Collection_for_Public_Cloud_Systems/AWS_Data_Collection_Prerequisites_for_an_IAM_Role__CloudWatch_only_



[View this page as a PDF](/images/docs/WebHelp_Densify_Cloud/Content/Resources/PDFs/AWS-Data-Collection-Prerequisites.pdf)

## Overview

Kubex collects resource utilization metrics (CloudWatch data) for your AWS services (e.g. EC2, RDS, ECS, etc.), analyzes the AWS data and then makes recommendations to save costs and reduce risks in your AWS environments.

Collecting data via a cross-account IAM Role simplifies the process of connecting to multiple AWS accounts from Kubex since the same role and external ID can be used across your multiple AWS accounts. As accounts are added or removed, you do not need to update the Kubex cloud connection.

<Accordion title="Video: Prerequisites for Collection AWS CloudWatch Data Using an IAM Role">
  <iframe />
</Accordion>

Kubex also supports connecting to AWS using;

* An IAM Role and CloudFormation template--See [AWS Data Collection Using a CloudFormation Template](./AWS_Data_Collection_Using_a_CloudFormation_Template).

<Note>
  Though the cloud connection wizard provides the option to use an IAM user and an access key, Kubex recommends using the IAM Role.
</Note>

## Using an IAM Role

When you create a role for cross-account access, you establish trust from the customer's account that owns the role and the resources (trusting account) to the Kubex account containing the user that will collect data (trusted account). You specify the trusted account number as the Principal in the role's trust policy when you create the role. This allows the Kubex user in the trusted account to assume the role and collect utilization data.

In addition to creating connections from your linked accounts, you also need to create a connection for your payer accounts. The payer account connection provides the name of each linked accounts.

Follow the process below to create and configure the IAM role for CloudWatch data collection.

### Creating the IAM Role and Attaching a Permission Policy to Collect CloudWatch Data

This role allows you to collect resource utilization data for the selected account. You need to attach a policy that allows the role to collect the required CloudWatch resource utilization metrics.

1. Log into the AWS Management Console and navigate to Identity and Access Management (IAM). In the navigation tree on the left, click Roles.
2. Click Create Role in the Roles dashboard.
3. Select AWS account as the of trusted entity type .
4. Enter an Account ID. This is the Kubex account that will assume the role. Enter the following Kubex account ID: 036437403198.
5. Select Require external ID and enter your external ID. This value is similar to a password and should be unique and difficult to guess. Kubex recommends using a password generator to create a random, alphanumeric string (e.g. ae73mcf4ldjpet96) for the external ID.

You will need this external ID later, when creating the cloud connection in Kubex.

6. Click Next.

<Accordion title="Figure: Creating a Role ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

7. Attach the appropriate permission policy to the role. Select AWS's predefined ReadOnlyAccess policy. Use the filter to find the ReadOnlyAccess policy. Even with the filter set you will need to go to the last page to find the "ReadOnlyAccess" policy.

<Note>
  The ReadOnlyAccess policy is provided here as an easy option for non-sensitive accounts. In most cases, you need to create a custom permission policy to grant Kubex, the permissions to collect only the required CloudWatch data. Refer to [Creating an IAM Policy with Minimum Permissions for the CloudWatch Data Collection](#Limited_Access_IAM_Policy) for details.
</Note>

<Accordion title="Figure: Selecting the ReadOnlyAccess Policy ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

8. After selecting the permission policy for the role, click Next.
9. In the Review page, specify the Role name and Role description. The role name can be any string used to identify and describe the role within the AWS account (e.g. KubexCrossAccountRole).
10. Click Create role. The new role is created.
11. From the Roles page, click on the role name that you have just created, to view the role summary.

<Accordion title="Figure: Role Summary ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

12. Copy and save the Role ARN as you will need to paste this string into the Kubex Cloud Connection wizard to create the connection.
13. You can now create an AWS connection through the Kubex Public Cloud Connection wizard. See [Using the Public Cloud Connections Wizard](../Densify_Com/Using_the_Public_Cloud_Connection_Wizard).

## Optional Configuration

The following sections contain detailed instructions for optional configuration. Some of this configuration is referenced in the procedures above.

* [Creating an IAM Policy with Minimum Permissions for the CloudWatch Data Collection](#creating-an-iam-policy-with-minimum-permissions-for-the-cloudwatch-data-collection)
* [Enabling Collection of AWS Memory Usage Metrics](#Enabling_Memory_Metrics)
* [Enabling the Collection of GPU Metrics](#GPU)

### Creating an IAM Policy with Minimum Permissions for the CloudWatch Data Collection

To simplify setup and maintenance of either an IAM user account or an IAM role for performing the CloudWatch audit, Kubex recommends attaching the AWS-managed “ReadOnlyAccess” policy to the user or role. This policy provides read-only access to your AWS services and resources and supports the requirements of the Kubex CloudWatch audit.
As the Kubex CloudWatch audit continues to evolve and expand, you do not need to update permission policy to include newly added services and features.

Alternatively, if you must restrict the IAM user or role with the minimum permissions to perform the CloudWatch audit, you can create a custom policy with only the required permissions, as shown below.

<Note>
  This custom policy must be updated periodically as Kubex standard audit requirements are updated to support additional AWS services and features.
</Note>

Example: AWS Minimum User Permission Policy

```json theme={null}
	        "Version": "2012-10-17",    
            "Statement": [
	                    {
	                    "Sid": "Stmt1499171905000",
                        "Effect": "Allow",    
                        "Action": [
	                        "autoscaling:DescribeAutoScalingGroups",
                            "autoscaling:DescribeLaunchConfigurations",
                            "autoscaling:DescribeScalingActivities",
                            "ce:GetCostAndUsage",
                            "cloudformation:DescribeStackResource",
                            "cloudformation:DescribeStackResources",
                            "cloudformation:ListStackInstances",
                            "cloudformation:ListStackResources",
                            "cloudwatch:GetMetricData",
                            "cloudwatch:GetMetricStatistics",    
                            "cloudwatch:ListMetrics",
                            "ec2:DescribeAvailabilityZones",
                            "ec2:DescribeHosts",
                            "ec2:DescribeImages",
                            "ec2:DescribeInstances",
                            "ec2:DescribeLaunchTemplateVersions",
                            "ec2:DescribeRegions",
                            "ec2:DescribeSnapshots",
                            "ec2:DescribeVolumes",
                            "ec2:DescribeSubnets",
                            "ec2:DescribeSecurityGroupRules",
                            "ec2:DescribeSecurityGroups",                    
                            "ec2:DescribeVpcs",
                            "ecs:DescribeCapacityProviders",
                            "ecs:DescribeClusters",    
                            "ecs:DescribeContainerInstances",    
                            "ecs:DescribeServices",    
                            "ecs:DescribeTaskDefinition",    
                            "ecs:ListClusters",    
                            "ecs:ListContainerInstances",    
                            "ecs:ListServices",
                            "ecs:ListTagsForResource",    
                            "ecs:ListTaskDefinitions",    
                            "eks:DescribeCluster",
                            "eks:ListClusters",
                            "elasticache:DescribeCacheClusters",
                            "elasticache:DescribeReplicationGroups",
                            "elasticache:ListTagsForResource",    
                            "iam:ListAccountAliases",
                            "organizations:DescribeOrganization",
                            "organizations:ListAccounts",
                            "rds:DescribeDBInstances",    
                            "rds:DescribeReservedDBInstances",    
                            "rds:DescribeDBClusters",    
                            "rds:ListTagsForResource"                            
                        ],
                        
                        "Resource": "*"
                     }
            ]

```

<Note>
  The permissions related to CloudFormation are used for linking ASGs with ECS clusters. If these permissions are not included and the data is not available, linking the ASGs to ECS clusters may be done based on existing container instances. If the permissions are missing, Kubex may not link some ASGs to their ECS clusters,
</Note>

1. Log into the AWS management console and navigate to Services > IAM.
2. Select Policies and click Create policy.
3. Click the JSON tab and enter the policy from the example above.
4. Review the policy and enter a policy name (e.g. KubexMinimumReadAccess) and a description (e.g. Minimum permissions required for Kubex standard audit).

### Enabling Collection of AWS Memory Usage Metrics

Memory metrics are not collected by default and they are not required to complete the Kubex analyses; however, you can manually enable collection of specific memory metrics to improve the quality of your recommendations.

<Note>
  Additional metrics collected by the CloudWatch agent incur charges. See [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/) for details.
</Note>

<Accordion title="Table: Required Cloudwatch Metrics">
  <table>
    <col />

    <col />

    <col />

    <thead>
      <tr>
        <th>
          <p>Scenario</p>
        </th>

        <th>
          <p>AWS Memory Metric</p>
        </th>

        <th>
          <p>Collected by the CloudWatch Agent, by Default</p>
        </th>
      </tr>
    </thead>

    <tbody>
      <tr>
        <td>
          <p>CloudWatch agent for
          Linux</p>
        </td>

        <td>
          <p>mem\_used\_percent</p>
        </td>

        <td>
          <p>Yes</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>mem\_active</p>
        </td>

        <td>
          <p>No</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>mem\_used</p>
        </td>

        <td>
          <p>No</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>CloudWatch agent for Windows</p>
        </td>

        <td>
          <p>Available MBytes</p>
        </td>

        <td>
          <p>No</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>% Committed Bytes In Use</p>
        </td>

        <td>
          <p>Yes</p>
        </td>
      </tr>
    </tbody>
  </table>
</Accordion>

<Note>
  The CloudWatch agent must be installed and configured on each instance for which you want to obtain memory. Refer to the AWS user documentation for details. See ([https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html))
</Note>

Once the CloudWatch agent is installed and configured, Kubex requires that you use the default "CWAgent" namespace for the collected metrics collected.

#### Memory Metrics for ASGs

Additionally, when working with ASGs, the ASG's EC2 members provide memory utilization data using the basic memory settings, but you need to specify "aggregation\_dimensions" to collect memory, aggregated at the ASG level.

#### Linux Configuration

For Linux instances, the memory metric, “mem\_used\_percent” is collected by default, as specified in the config.json file. However, the metrics “mem\_active” and “mem\_used” need to be added for Kubex analysis.

Use the following example to customize the default CloudWatch agent's configuration, to collect the required parameters and metrics that Kubex requires for memory analyses. The CloudWatch agent configuration file is located in the CWAgent namespace,

Example:  CloudWatch Agent Configuration For Linux Instances

```json theme={null}
{
	    "agent": { 
	        "metrics_collection_interval": 60,
        "run_as_user": "root"
    },
    "metrics": {
	        "append_dimensions": {
	            "AutoScalingGroupName": "${aws:AutoScalingGroupName}",
            "ImageId": "${aws:ImageId}",
            "InstanceId": "${aws:InstanceId}",
            "InstanceType": "${aws:InstanceType}"
        },
        "aggregation_dimensions":[
	            ["AutoScalingGroupName"]
        ],
        "metrics_collected": {
	            "mem": {
	                "measurement": [
	                    "mem_used",
                    "mem_active",
                    "mem_used_percent"
                ],
                "metrics_collection_interval": 60
            }
        }
    }
}    

```

#### Windows Configuration

For Windows instances, the default CloudWatch agent config.json file are the same as listed above.

The memory metric, "% Committed Bytes in Use" is collected by default, as specified in the config.json file. However, the metric “Available MBytes” needs be added to the CloudWatch agent's settings, for Kubex analysis.

Use the following example to customize the default CloudWatch agent's configuration, to collect the required parameters and metrics that Kubex requires for memory analyses. The CloudWatch agent configuration file is located in the CWAgent namespace,

Use the following example to customize the default CloudWatch agent configuration to collect the required parameters and metrics that Kubex requires for memory analyses.

Example:  CloudWatch Agent Configuration For Windows Instances

```json theme={null}
{
	    "agent": { 
	        "metrics_collection_interval": 60,
        "logfile": "c:\\ProgramData\\Amazon\\AmazonCloudWatchAgent\\Logs\\amazon-cloudwatch-agent.log"
    },
    "metrics": {
	        "append_dimensions": {
	            "AutoScalingGroupName": "${aws:AutoScalingGroupName}",
            "ImageId": "${aws:ImageId}",
            "InstanceId": "${aws:InstanceId}",
            "InstanceType": "${aws:InstanceType}"
        },
        "aggregation_dimensions":[
	            ["AutoScalingGroupName"]
        ],
        "metrics_collected": {
	            "Memory": {
	                "measurement": [
	                    "Available MBytes",
                    "% Committed Bytes In Use"
                ],
                "metrics_collection_interval": 60
            }
        }
    }
}    

```

If you are using a third-party application to collect memory metrics, the collected data can be loaded using the Receive Metrics API endpoint. See [Importing Metrics for Existing Services](https://densify.com/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Receive_Metrics_Jobs) in the API documentation.

Refer to the AWS user documentation for details on using the CloudWatch Agent to collect memory metrics.

### Enabling the Collection of GPU Metrics

To support collection of the NVIDIA® GPU data, the required metrics must be enabled through the CloudWatch agent.

Install the NVIDIA driver and CloudWatch agent on your instances. See [Collecting NVIDIA GPU Metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-NVIDIA-GPUl).

* Linux Servers--You need to add the section, `nvidia_gpu` inside the metrics\_collected section of the CloudWatch agent configuration file. For more information, see: [https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-NVIDIA-GPUl](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-NVIDIA-GPUl)
* Window Servers--Configure and use Amazon Custom CloudWatch Metrics. See [https://repost.aws/questions/QUcyzZfm3UR96Qj8JiadlCAA/how-to-monitor-and-collect-gpu-metrics-for-windows-ec2-instances-using-amazon-cloudwatch](https://repost.aws/questions/QUcyzZfm3UR96Qj8JiadlCAA/how-to-monitor-and-collect-gpu-metrics-for-windows-ec2-instances-using-amazon-cloudwatch)

Alternatively, you can use a third party tool such as [Telegraf](https://www.influxdata.com/time-series-platform/telegraf/) for metrics collection from Window Servers.

Kubex requires the following GPU metrics:

<Accordion title="Table: Required GPU Metrics">
  <table>
    <col />

    <col />

    <col />

    <col />

    <thead>
      <tr>
        <th>
          <p>NVDIA Metric</p>
        </th>

        <th>
          <p>CloudWatch Metric Name</p>
        </th>

        <th>
          <p>Unit</p>
        </th>

        <th>
          <p>Description</p>
        </th>
      </tr>
    </thead>

    <tbody>
      <tr>
        <td>
          <p>utilization\_gpu</p>
        </td>

        <td>
          <p>nvidia\_smi\_utilization\_gpu</p>
        </td>

        <td>
          <p>%</p>
        </td>

        <td>
          <p>The percentage of time over the past sample period during which one or more kernals on the GPU was running.</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>utilization\_memory</p>
        </td>

        <td>
          <p>nvidia\_smi\_utilization\_memory</p>
        </td>

        <td>
          <p>%</p>
        </td>

        <td>
          <p>The percentage of time over the past sample period during which global (device) memory was being read or written.</p>
        </td>
      </tr>

      <tr>
        <td>
          <p>memory\_used</p>
        </td>

        <td>
          <p>nvidia\_smi\_memory\_used</p>
        </td>

        <td>
          <p>MB</p>
        </td>

        <td>
          <p>Memory used.</p>
        </td>
      </tr>
    </tbody>
  </table>
</Accordion>

The following new workloads, based on the above metrics are available in the [metrics viewer](../Densify_Com/Using_the_Metrics_Viewer):

* GPU\_Utilization--GPU utilization in percent
* GPU\_Mem\_Utilization\_As\_Pct--GPU memory utilization as a percent of the total memory
* GPU\_Mem\_Used--GPU memory used, in MB

#### Prerequisites

1. NVIDIA Driver--Ensure you have the correct NVIDIA driver installed on your instances. Refer to the [NVIDIA website](https://www.nvidia.com/Download/index.aspx?lang=en-us) for the driver installation guide for your specific operating system.
2. NVIDIA Toolkit--Install the NVIDIA Toolkit to gather GPU metrics. Refer to the [NVIDIA website](https://www.nvidia.com/Download/index.aspx?lang=en-us) for details.
3. CloudWatch Agent--Refer to the AWS documentation for the latest agent installation instructions on your specific operating system. Configure the CloudWatch Agent as outlined below.
4. Ensure that the IAM role attached to your EC2 instances has the necessary permissions to publish metrics to CloudWatch.

#### Install the NVIDIA Toolkit

The driver and toolkit may be pre-installed on your instance. Verify the elements contained on your instance before installing the toolkit or driver.

On Ubuntu:

```
sudo apt-get update
sudo apt-get install -y nvidia-cuda-toolkit
```

On Amazon Linux 2:

```
sudo yum install -y nvidia cuda
```

#### Create the CloudWatch Agent Configuration File

1. Modify the CloudWatch Agent configuration file (`amazon-cloudwatch-agent.json`) to add GPU metrics.

<Accordion title="Figure:Sample Configuration File ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

2. Upload the CloudWatch Agent configuration file to your instance. For example, if using Amazon Linux 2:

```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \

-a fetch-config -m ec2 -c file:/path/to/your/amazon-cloudwatch-agent.json -s
```

3. Start the CloudWatch Agent:

```
sudo /opt/aws/amazon-cloudwatch-agent/bin/start-amazon-cloudwatch-agent
```

4. You can also modify the `metrics_collection_interval` to change how often metrics are collected and sent to CloudWatch.

#### Verifying the Configuration

1. Verify that the CloudWatch Agent is running:

```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a status
```

2. Open the CloudWatch console to review the metrics.
3. Navigate to Metrics and selec tthe `CWAgent` namespace.
4. You should see GPU metrics under this namespace.


# AWS Data Collection Using a CloudFormation Template (CFT)
Source: https://docs.kubex.ai/docs/WebHelp_Densify_Cloud/Content/Data_Collection_for_Public_Cloud_Systems/AWS_Data_Collection_Using_a_CloudFormation_Template



###### AWS Data Collection Using a CloudFormation Template

## Overview

Kubex's CloudFormation template creates a <Tooltip>stack</Tooltip> comprised of the AWS resources required by Kubex to collect the Resource Utilization Metrics (via CloudWatch) that are then used for cloud optimization analysis.

If your accounts are setup using an AWS organization/management account structure, in which many accounts are linked to one management account, you can use the CloudFormation template to create, update and delete StackSets across multiple accounts and also create the cloud connection within Kubex for each of the linked accounts.

If you are not using an organizational account structure you can provide a list of accounts to be updated when you are configuring the stack.

<Accordion title="Figure: Onboarding AWS Accounts Using CloudFormation ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

This template creates the IAM role and access policy and assigns the policy to the role using native CloudFormation capabilities. The template then uses a Lambda function to make an API call to Kubex to create the cloud connections required to collect resource utilization data.

If you need to update the IAM role or policy after they have been created, see [Editing the Stackset](#editing-the-stackset) . This may be necessary if the IAM access policy needs additional permissions.

## Supported Regions

You can run the Kubex CloudFormation template in any of the following regions;

<table>
  <col />

  <col />

  <col />

  <col />

  <tbody>
    <tr>
      <td>
        <ul>
          <li>ap-northeast-1</li>
          <li>ap-northeast-2</li>
          <li>ap-south-1</li>
          <li>ap-southeast-1</li>
          <li>ap-southeast-2</li>
        </ul>
      </td>

      <td>
        <ul>
          <li>eu-central-1</li>
          <li>eu-north-1</li>
          <li>eu-west-1</li>
          <li>eu-west-2</li>
          <li>eu-west-3</li>
        </ul>
      </td>

      <td>
        <ul>
          <li>ca-central-1</li>
          <li>us-east-1</li>
          <li>us-east-2</li>
          <li>us-west-1</li>
          <li>us-west-2</li>
          <li>sa-east-1</li>
        </ul>
      </td>
    </tr>
  </tbody>
</table>

Kubex CloudFormation template can must be run in a single region even if the target accounts span multiple regions. The template creates an IAM role and permission policy which are both global and are not region-specific.

Please contact [Support@Kubex.ai](mailto:Support@Kubex.ai) if you need to run the template in regions, not listed above.

### Additional Considerations Regarding Regions

When you create the StackSet, you need to specify a region from where the stack is deployed to each account and from where the Lambda function runs. Ensure you specify a single region as the IAM role and permission policy are globally accessible and as such will work from any region.

If you try to re-run the template in a different region it will fail as the IAM role and the permission policy already exist.

The Lambda function is region-specific but it only runs once to create the cloud connections within Kubex. The StackSet and the CloudWatch logs that result from running the template are also region-specific and are defined within a specific region. You need to log into the specified region to manage your Stack and view its related log files. These log files will be required by the Kubex support team, if troubleshooting any data collection issues.

## Using the CloudFormation Template

If your AWS accounts are setup using an organizational structure, in which many accounts are linked to one master account, you can use the CloudFormation template to create, update and delete stacks across multiple accounts and also create the cloud connection within Kubex for each of the linked accounts. If you are using the organizational account structure, you need an IAM user that has sufficient execute permissions to create the required roles and IAM policies in each linked account.

If you are not using an organizational account, you can provide a list of accounts in which the CloudFormation template will run and create the required prerequisites for data collection.

In addition to creating connections from your linked accounts, you also need to create a connection for your payer accounts. The payer account connection provides the name of each linked accounts.

### Prerequisites

Obtain the following required inputs for the template before starting:

* External ID for IAM Role--This value is similar to a password and should be unique and difficult to guess. Kubex recommends using a password generator to create a random, alphanumeric string (e.g. ae73mcf4ldjpet96) for the external ID.
* Both the URL and user credentials for your Kubex instance--Contact your Kubex Account Manager for details if you do not have this information.
* IAM User with Execute Permissions--If you are using an AWS Organization/management account structure with many linked accounts, you need an IAM user that has sufficient execute permissions to create the required roles and IAM policies in each linked account.

### Considerations when Working with Large Environments

In large environments, Kubex highly recommends batching your accounts into smaller groups for improved performance when using the CloudFormation templates. i.e. no more than 10 accounts at a time. You can use a resource tag, such as application or business unit to separate the CloudFormation stack so that data is collected in manageable batches.

### Configuring and Running the Template

#### Step 1: Choose a Template

1. Log into the AWS Management Console and navigate to CloudFormation and select StackSets. You may need to expand the options in the upper left corner of the page:

<Accordion title="Figure: Accessing Stack Options ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

2. At the top of the StackSets page, select a supported region. See the list of [Supported Regions](#supported-regions).
3. Click Create StackSet to begin.

<Accordion title="Figure: Create StackSet Options ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

4. In the Permissions section at the top of the page select the applicable option.

Your selection, here depends on the nature of your organizational structure and your specific requirements for managing permissions across accounts.

* Service-managed permissions--Use this option when you want the AWS Organization to automatically manage permissions. This is useful if you have a large number of accounts under an organization and you want to simplify the management of permissions across these accounts.
* Self-service permissions--Use this option when you need more granular control over permissions or when you are working in an environment where accounts are not part of the same AWS organizational structure.

5. If you selected "Self-service permissions", then specify an IAM role that has execute privileges in your target linked accounts.

<Accordion title="Figure: Specify CloudFormation Permissions ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

6. In the next section, Prerequisite - Prepare template, select Template is ready

7. In the next section, Specify template copy and then paste the following URL into the Amazon S3 URL field: [https://densify-cf-template.s3.us-east-2.amazonaws.com/Densify\_CloudFormation.yml](https://densify-cf-template.s3.us-east-2.amazonaws.com/Densify_CloudFormation.yml)

8. Click Next to proceed with creating the stack.

<Accordion title="Figure: Specify CloudFormation Template ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

#### Step 2: Specify StackSet Details

1. Enter the following Stackset details:

* Stack name--Kubex-Data-Collection, as an example.
* Stack description--Optionally enter a description for this StackSet

<Accordion title="Figure: Specify CloudFormation Template ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

2. Enter the following Kubex instance details:

* Kubex Instance URL--This is your Kubex SaaS instance.
* Kubex User ID--This is your Kubex user name.
* Kubex Password--This is the password for the listed user name.

<Accordion title="Figure: Specify Kubex Instance Details ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

3. The values for IAM Role Name and the Permission Policy Name fields are provided. You do not need to enter any values here.
4. Click Next to proceed with creating the stack.

#### Step 3: Configure StackSet Options

1. In the Configure StackSet options page, accept the default values and then click Next.

* Tags--No tags need to be specified for the StackSet.
* Inactive--Leave this value to simplify StackSet execution.

#### Step 4: Set Deployment Options

Set the following deployment options

1. In the first section, Add stacks to stack set select Deploy new stacks.

<Accordion title="Figure: Specify Account Details ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

2. Under Accounts > Deployment locations , define the accounts to which you want to deploy the StackSet:

* Deploy Stacks in accounts--Enter the 12-digit account numbers in the field.

Alternatively, you can specify a .CSV file with the account information. The .CSV files must contain the 12-digit account numbers separated by commas.

* Deploy stacks in organizational units--Specify the organization units to use. The StackSet will be deployed to all account in the specified organizational units.

3. In the next section, select one region from which the StackSet will be managed. This is typically the same region from which the StackSet is deployed. See the list of [Supported Regions](#Supported_Reg).
4. Set the following Deployment Options:

* Maximum Concurrent Accounts--Choose Number from the dropdown list and enter a value of 10.

Do not set this value greater than 10. Kubex highly recommends batching your accounts into smaller groups for improved performance.

Setting a higher number is faster for AWS operations, but creating the cloud environments and initiating data collection within Kubex is negatively impacted if more than 10 accounts are run concurrently.

* Failure Tolerance (Optional)--Set this to an absolute number or a percentage of the total number of accounts being updated. If this value is exceeded, all resource changes will be rolled back.

<Note>
  When setting this value you must set Failure Tolerance to a value that is ≥ (Maximum Concurrent Accounts – 1). So, if Maximum Concurrent Accounts = 10, then Failure Tolerance should be set to 9 or higher.
</Note>

* Region Concurrency--Select the desired option. As long as Maximum Concurrent Accounts is specified, parallel is preferred.
* Concurrency Mode--Leave the default value, of "Strict failure tolerance".

<Accordion title="Figure: Deployment Options ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

5. Click Next to proceed with creating the stack.

#### Step 5: Review

1. Scroll through each section and verify the data you have entered.
2. At the bottom of the page, in the Capabilities section, click the checkbox to acknowledge that the StackSet will create IAM resources with custom names, as required.

<Accordion title="Figure: Permission to Create Resources ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

#### Step 6: Run the Template

1. Click Submit to begin the process. The CloudFormation dashboard displays the stack creation progress.
2. Click on the Events tab to see both the progress and status of the stack creation process. Click the Refresh button to show the latest events.
3. Once the StackSet has been created successfully, you can review the results.

* Click the Resources tab to see the list of created resources (e.g. IAM role, policies).
* Click the Outputs tab to see the version of both the CloudFormation template and Lambda function that were run. You will need this version information if you need to upgrade the stackset or the template.

4. You can also log into your Kubex instance and verify that the cloud connections are listed in the Cloud Connection wizard.

<Accordion title="Figure: Outputs Tab ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

The initial audit will pick up historical data, if configured and available and each daily audit will collect the last 24-hours of data.

If this is a new or trial deployment, you will be contacted, once your data has been analyzed and is ready to review. Otherwise, analysis will be run overnight and you can review the optimization results the morning after creating the cloud connections. See [Viewing the Optimization Overview Report](../Densify_Com/Viewing_the_Optimization_Overview_Report) for analysis results.

## Other StackSet Operations

<Note>
  When pushing changes to an existing StackSet, you must use the same version of the CloudFormation template that was used to create the stack, and then choose “Actions > Edit StackSet details” to update the existing stack.
</Note>

If your accounts are setup using an organizational structure you can use the CloudFormation template to update stacks across the multiple linked accounts and also create the cloud connection within Kubex for each of the linked accounts.

After the initial StackSet deployment you can do the following:

* Push changes to the existing stack in your accounts.
* Add the stack to additional accounts.
* Delete the stack from the accounts.

### Editing the Stackset

In most cases you will only need to edit the set of minimum required permissions. The list of [minimum required permissions](./AWS_Data_Collection_Prerequisites_for_an_IAM_Role__CloudWatch_only_#creating-an-iam-policy-with-minimum-permissions-for-the-cloudwatch-data-collection) changes as Kubex adds new features and functionality,

1. Log into the AWS Management Console and navigate to CloudFormation and select StackSets.
2. Select the StackSet you want to edit and then choose Actions > Edit StackSet details from the dropdown menu at the top of the page.

<Note>
  When pushing changes to an existing StackSet, you must use the same version of the CloudFormation template that was used to create the stack, and then choose “Actions > Edit StackSet details” to update the existing stack.
</Note>

<Accordion title="Figure: Edit StackSet Details ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

Refer to the AWS documentation for additional details on modifying a StackSet after it has been deployed.

### Adding the Stackset to New Accounts

1. Log into the AWS Management Console and navigate to CloudFormation and select StackSets.
2. Select the StackSet you want to add and then choose Actions > Add new stacks to StackSet then specify the new accounts as outlined in [Step 4](#Step4).

<Note>
  When deploying the StackSet, to new accounts use the same version of the CloudFormation template that was used to create the stack initially. The same version of the StackSet must be deployed in all accounts.
</Note>

### Deleting a Stackset from Accounts

1. Log into the AWS Management Console and navigate to CloudFormation and select StackSets.
2. Select the StackSet you want to delete and then choose Actions > Delete stacks from StackSet
   then specify the accounts as outlined in [Step 4](#Step4).
3. Navigate to Set Deployment Options and edit the list of accounts.

<Accordion title="Figure: Specify Account Details ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

4. You need to remove any deleted accounts from Kubex.

Refer to the AWS documentation for additional details on deleting a StackSet after it has been deployed.


# Google Cloud Platform Data Collection Prerequisites
Source: https://docs.kubex.ai/docs/WebHelp_Densify_Cloud/Content/Data_Collection_for_Public_Cloud_Systems/Google_Cloud_Platform_Data_Collection_Prerequisites



[View this page as a PDF](/images/docs/WebHelp_Densify_Cloud/Content/Resources/PDFs/GCP-Data-Collection-Prerequisites.pdf)

The following prerequisites are required for each Google Cloud Platform (GCP) project in order to connect to and collect compute engine (GCE) instance data from GCP:

1. Data collection APIs

* Enable Cloud Resource Manager API;
* Verify Cloud Monitoring API is enabled.

2. Google Cloud Platform Service Account

* Create a service account with Project role set to "Viewer". Alternatively, you can create a [role with the minimum permissions](#Min_Policy) required for data collection.
* Create the JSON key credentials;
* Optionally, link this service account to other GCP projects from which you want to collect data.

3. Optionally, you can install the Ops agent on each GCE instance to collect memory data.
   See [Ops Agent](https://cloud.google.com/stackdriver/docs/solutions/agents/ops-agent) for details.

## Verify GCP Data Collection APIs are Enabled

You need to verify that the following APIs are enabled for your project:

* Cloud Resource Manager API--Needs to be enabled, if not listed.
* Cloud Monitoring API--is enabled by default when the project is created.

Verify these APIs are enabled before creating the service account. When you create the keys for the service account the permissions for the required APIs will be included in the key file and are required by Kubex.

1. Login to the GCP console and select your project.
2. From the GCP console main menu, navigate to APIs & services > Dashboard.
3. From the APIs & services Dashboard, ensure that the following APIs are enabled and listed in the Enabled APIs and services list:

* Cloud Resource Manager API
* Cloud Monitoring API (previously named, Stackdriver Monitoring API)

<Accordion title="Figure: APIs & Services Dashboard ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

4. If the Cloud Resource Manager API is not listed, click on ENABLE APIS AND SERVICES at the top of the dashboard. Search for the Cloud Resource Manager API and click Enable:

<Accordion title="Figure: Enabling Cloud Resource Manager API ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

## Creating a GCP Service Account

To connect Kubex to your GCP project, you will need a GCP service account and corresponding credentials in JSON format. You need to repeat this process for each of your GCP projects and save the credential JSON files in an encrypted .ZIP file. You will then import this file to create a connection to collect data from your GCP projects.

Use the following instructions to create and configure the GCP service account:

1. Login to the GCP console and select your project.
2. From the main menu, select IAM & Admin > Service accounts.

<Accordion title="Figure: Creating Service Account ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

3. From the Service Accounts page, click Create Service Account.

4. In the Create service account pane:

5. Specify Service account name. As a best practice, use the display name to keep track of what the account will be used for and what permissions are assigned. (e.g. Kubex\_Connection\_Viewer)

6. Provide a description of the service. This step is optional, but may help you link this account to other projects later on.

7. Click Create and Continue to create the service account.

<Accordion title="Figure: Creating Service Account ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

5. In the Role field scroll down the list and select "Project" and then set the role for the whole project to "Viewer".

<Accordion title="Figure: Assigning a Role to the Service Account ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

6. You do not need to add users to the this account so click DONE.

## Creating Credentials for the Service Account

You now need to create the key for the service account. Kubex uses this key to verify its identity

1. In the GCP console, from the main menu, select IAM & Admin > Service accounts.
2. You should see the account that you just created. In the Key ID column you can see that no keys have been created.
3. Click the options in the Actions column. Select Manage keys from the dropdown menu.
4. Select Add Key and then Create new key.
5. The key is generated and downloaded to your computer. Retain the generated keys for creating the Kubex cloud connection.

<Note>
  Do not check these service account keys into your source code or leave them in the download directory.
</Note>

### Creating a Role with Minimum Permissions for Data Collection

Kubex recommends using the viewer role, as indicated above, to simplify setup and maintenance of data collection. The viewer role provides read-only access to your GCP services and resources and supports the requirements of Kubex data collection and analysis.
As the Kubex data collection continues to evolve and expand, you do not need to update this permission policy to include newly added services and features.

Alternatively, you create a custom role and grant the minimum required permissions to the service account to be used Kubex for data collection.

You must have the `iam.roles.create permission`, to create the custom role. The custom role must be created at the Organization level.

<Note>
  This custom role must be updated periodically as Kubex standard data collection requirements are updated to support additional services and features.
</Note>

The custom role must have the following permissions to perform the GCP data collection:

<table>
  <col />

  <col />

  <tbody>
    <tr>
      <td>
        <ul>
          <li>compute.disks.get</li>
          <li>compute.disks.list</li>
          <li>compute.firewalls.list</li>
          <li>compute.images.list</li>
          <li>compute.instances.get</li>
          <li>compute.instances.list</li>
          <li>compute.licenses.get</li>
          <li>compute.machineTypes.get</li>
        </ul>
      </td>

      <td>
        <ul>
          <li>compute.zones.list</li>
          <li>monitoring.metricDescriptors.list</li>
          <li>monitoring.timeSeries.list</li>
          <li>resourcemanager.projects.get</li>
          <li>resourcemanager.projects.list</li>
          <li>compute.machineTypes.list</li>
          <li>compute.projects.get</li>
          <li>compute.regions.list</li>
        </ul>
      </td>
    </tr>
  </tbody>
</table>

Use the following instructions to create the custom role:

1. Login to the GCP console and navigate to Roles in the main menu.
2. Select your organization from the Organization drop-down.
3. From the Roles page, click Create Role.
4. Enter a Title, Description for the role.

Roles have both an ID and a title. The role ID is a unique identifier for the role and can be auto-generated. The role title appears in the list of roles in the GCP Console.

The Role Launch Stage property is optional for this use case.

5. Click Add Permissions.
   See the above list and select all 15 permission for your custom role.
6. Click Add to grant the selected permissions to your custom role.
7. Click CREATE to create the role. You will now see your new role in the list on the Roles page.

<Accordion title="Figure: Creating Custom Role ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

8. When you create the service account, select this custom role as follows:

<Accordion title="Figure: Selecting Custom Role ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

Refer to [Creating a GCP Service Account](#Creating), above for details.

## Using a Single GCP Service Account to Access Multiple Projects

In order to simplify data collection you can grant a single GCP service account access to other projects. This can be done by adding the service account ID from one project to another, through the account's IAM & admin dashboard.

You would then use this master service account to create your Kubex cloud connection.

1. Login to the GCP console and select the project that contains the service account that will become the master account.
2. From the GCP console main menu, select IAM & admin > Service accounts.
3. Select the Service account ID to be used as the master account, from the list of service accounts. Copy the Service account ID onto the clipboard, as you cannot search from the Add Members function (in the steps below).
4. Select the project to which you want to add the service account.
5. From the IAM & admin menu, select IAM.
6. Click the ADD in the toolbar.

<Accordion title="Figure: IAM & admin Dialog Box">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

7. The Add Members dialog box opens. Paste the Service Account ID into the New Members field,
8. Select the account’s role in the project. Select the Project > Viewer role for the newly added member.

<Accordion title="Figure: Add Member Dialog Box">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

9. Click Add to complete and save the change. You can now use the private key previously generated from the service account to access the selected project.
10. You can repeat these steps for your other projects.

## Collecting GCP Memory Metrics

The Ops Agent is the primary agent for collecting memory and other metrics from your Compute Engine instances. The Ops Agent replaces the stackdriver agent and cloud monitoring agent.

Refer to [https://cloud.google.com/stackdriver/docs/solutions/agents/ops-agent](https://cloud.google.com/stackdriver/docs/solutions/agents/ops-agent) for details of installing and configuring the agent.


# Microsoft Azure Data Collection Prerequisites for a Service Principal
Source: https://docs.kubex.ai/docs/WebHelp_Densify_Cloud/Content/Data_Collection_for_Public_Cloud_Systems/Microsoft_Azure_Data_Collection_Prerequisites_for_a_Service_Principal



[View this page as a PDF](/images/docs/WebHelp_Densify_Cloud/Content/Resources/PDFs/Azure-Data-Collection-Prerequisites.pdf)

## Overview

A Service Principal is an identity created within your on-premises Active Directory (AD) and that is allowed to access one or more resources within your AD. You can delegate the minimum required permissions to the service principal so that it can be used to create a connection to Kubex to collect data.

<Accordion title="Video: Data Collection Prerequisites for Azure Using a Service Principal">
  <iframe />
</Accordion>

<Note>
  Azure Stack is not supported. This data collection method currently only supports Azure Cloud.
</Note>

If you are using a standalone Azure Active Directory account (i.e. an Azure AD), then see Microsoft Azure Data Collection Prerequisites on page 1.

The Service Principal possesses the following characteristics:

* An application that is created within your <Tooltip>Microsoft Entra ID</Tooltip>. This application will be associated with the user that creates it.
* A service principal is then created for that application;
* The service principal is granted access to your Azure subscription.

The following procedure allows you to use a federated Microsoft Entra ID account to create a cloud connection to Kubex. In this case a Service Principal is required to connect Kubex to your Azure subscriptions.

<Note>
  In this case "federated" indicates that your on-premise Active Directory is linked with your Azure Cloud's Entra ID so you can use your existing on-premise AD credentials to access your Azure portal.
</Note>

## Requirements to Create a Cloud Connection

To connect Kubex to your Azure subscriptions, you need the following items to setup data collection:

* [Tenant ID/Directory ID](#Tentant_ID)
* [Service Principal/Application ID](#Secret_Key)
* [Secret Key](#Secret_Key)
* [Subscription ID](#SubscriptionID)--Only required when using the Kubex API.

Additionally, the application must be assigned the role of "Reader" for each of the subscriptions from which data will be collected. The Reader role is sufficient for resource utilization data.

### Required Account Permissions

You must have admin/owner privileges for your Azure portal to create the account required for Kubex. Typically, your on-premise Active Directory is federated with the Azure AD. In this case, the admin access is likely provided from an on-premise Active Directory account (via federation) and will possess the required Azure admin privileges.

The user account/Service Principal to be used for data collection only requires the "Reader" role privileges to collect resource utilization data.

If necessary you can configure a custom role that is more restrictive than the "Reader" role privileges. See [Configuring a Role with Minimum Permissions for Data Collection](#configuring-a-role-with-minimum-permissions-for-data-collection) for details.

### Obtaining the Tenant ID/Directory ID

The tenant ID corresponds to the Microsoft Entra ID.

1. Login into your Azure account and click on Microsoft Entra ID> Overview .
2. In the Overview  pane, copy the Tenant ID.

<Accordion title="Figure: Entra ID Overview ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

### Obtaining the Application ID and Client Secret

You now need to create a new application registration. This will be the service principal for Densi. You will need the Application ID and corresponding client secret (key), to complete the Kubex connection.

1. Click App Registration.
2. In the App Registration pane, click New registration.

<Accordion title="Figure: Create New Registration ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

3. In the Create pane enter the following information:

* The Name of the application (e.g. Kubex\_Connection).
* Select who can access the application. Leave the default of "Accounts in this organizational directory only (Default Directory only - Single tenant)".
* Select the Redirect URI (optional) as “Web” and specify a Sign-on URI (e.g. [https://Kubex.ai](https://Kubex.ai)).

The Register button becomes available once you enter valid data.

4. Click Register to create and register the application. This is the service principal that Kubex will use to collect data.

<Accordion title="Figure: Configure the Registration ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

5. Copy the Application ID (e.g. 7d16fbf8-1fc3-4e08-b48a-626).
   You need to copy this ID and save it to a location from which you can easily retrieve it. You will need the Application ID to create the Kubex connection.

<Accordion title="Figure: Obtain the Application ID ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

6. Click Client credentials to see create the credential.
7. Click on New client secret to create a new key.
8. In the Add a new client secret pane, enter a Description (e.g. KubexKey) and an expiration period (e.g. 1 year, 2 years or never expires).
9. Click Add to create the key.
10. Copy the secret key Value to a location from which you can easily retrieve it. You will need this key to create the Kubex connection.

<Accordion title="Figure: Generate the Secret Key ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

### Obtaining the Subscription ID

If you are using the API, data collection and analysis are created and then refreshed daily on a per subscription basis (1-to-1). You can associate many subscriptions with a service principle, but when using the API to initiate data collection, you must specify a subscription ID and the audit and analysis are created for each subscription, separately.

When using the Connection Wizard in the Kubex UI, you do not need the subscription ID, as all subscriptions that are associated with the service principle are collected and listed once the connection has been verified. You can then select one or more of the subscriptions that you want to analyze (1-to-Many). When using the Connection Wizard, data collection and analysis are created and then refreshed daily for all of the subscriptions that you selected when you created the connection.

Use the following instructions to get the Subscription ID.

1. Navigate to Subscriptions in the main menu. You may need to click on More services to see Subscriptions.
2. Click on a subscription to open the configuration page.
3. Copy the Subscription ID. You need to copy this ID and save it to a location from which you can easily retrieve it. You will need the Subscription ID to initiate data collection, when using the Kubex API.

### Assigning Access to Subscriptions

The application registered above, now needs access to each of your subscriptions. You need to assign the "Reader" role to the Application for each subscription being audited. Use the following process:

1. Navigate to Subscriptions in the main menu. You may need to click on All services to see Subscriptions.
2. Click on a subscription to select and open the configuration pane.

<Accordion title="Figure: Access Subscriptions ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

3. Click Access Control (IAM).
4. Click Add > Add role assignment.

<Accordion title="Figure: Access Role Assigment ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

5. In the Add role assignment pane select the Role of "Reader".
6. Click Next .

<Accordion title="Figure: Access Add Role Assigment ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

7. On the Add role assignment pane, ensure Assign Access to is set to "User, group or service principal".
8. Click Select members.
9. Search for or scroll to locate the service principle (Kubex\_Connection), created above.
10. Click Select.

<Accordion title="Figure: Add Role Assigment ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

11. The selected application will appear in the Members section.
12. Click Review + Assign to save these changes.

<Accordion title="Figure: Complete Role Assigment ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

13. Repeat this process for each subscription to be included in Kubex data collection.

<Accordion title="Figure: Allow Application to access a Subscription ">
  <Frame>
    <img alt="" />
  </Frame>
</Accordion>

Once the account has been configured you can use the tenant ID, application ID and secret key to create the cloud connection as outlined in [Using the Public Cloud Connections Wizard](../Densify_Com/Using_the_Public_Cloud_Connection_Wizard).

## Advanced Topics

The following sections contain detailed instructions for more advanced configuration. Some sections are referenced in the procedures above. Other advanced topics cover optional configuration.

* [Configuring a Role with Minimum Permissions for Data Collection](#Min_Permission)
* [Create the Service Principal Through the Azure CLI](#Azure_CLI)

### Configuring a Role with Minimum Permissions for Data Collection

To simplify setup and maintenance of the role used for performing data collection, Kubex recommends using the "Reader" role. This role provides read-only access to your Azure services and resources and supports the requirements for resource utilization data collection.
As the Kubex continues to evolve and expand, you do not need to update permission policy to include newly added services and features, when using the "Reader" role.

Alternatively, if you must restrict the role with the minimum permissions you can create a custom role with only the required permissions. These custom roles provide an alternative method for granting permissions that are more restrictive than the built-in “Reader” role. These custom roles (JSON) define the minimum permissions required by Kubex to collect resource utilization metrics data, respectively.

The "Kubex Resource Utilization Metrics Reader” custom role grants read-only permissions for collecting data related to VMs, SQL servers and reservations in the subscriptions specified in the assigned scope.

Custom Role: Kubex Resource Utilization Metrics Reader

```json theme={null}
{
    "properties": {
        "roleName": "KubexResourceUtilizationMetricsReaderCustomRole",
        "description": "This custom role defines the minimum read-only permissions required by Kubex for collecting data related to VMs, SQL servers and reservations associated in the subscriptions specified in the assigned scope",
        "assignableScopes": [],
        "permissions": [
            {
                "actions": [
                    "Microsoft.Capacity/appliedreservations/read",
                    "Microsoft.ClassicCompute/virtualMachines/read",
                    "Microsoft.Compute/virtualMachines/read",
                    "Microsoft.Compute/virtualMachines/instanceView/read",
                    "Microsoft.Compute/virtualMachineScaleSets/read",
                    "Microsoft.Compute/virtualMachineScaleSets/virtualMachines/read",
                    "Microsoft.Compute/virtualMachineScaleSets/virtualMachines/instanceView/read",
                    "Microsoft.Insights/AutoscaleSettings/read",
                    "Microsoft.Insights/eventtypes/values/read",
                    "Microsoft.Insights/Metrics/read",
                    "Microsoft.Insights/MetricDefinitions/read",
                    "Microsoft.Network/networkInterfaces/read",
                    "Microsoft.Network/networkSecurityGroups/read",
                    "Microsoft.Network/virtualNetworks/read",
                    "Microsoft.Resources/subscriptions/read",
                    "Microsoft.Resources/subscriptions/resourceGroups/read",
                    "Microsoft.Sql/servers/databases/read",
                    "Microsoft.Sql/servers/elasticPools/read",
                    "Microsoft.Sql/servers/read"
                ],
                "notActions": [],
                "dataActions": [],
                "notDataActions": []
            }
        ]
    }
}
```

Use the following instructions to create the custom roles:

1. Copy the above sample and save it as JSON files.
2. Login into your Azure account. You must have admin or owner privileges for your Azure portal. See [Microsoft Azure Data Collection Prerequisites for a Service Principal](#Acct_Perm).
3. Navigate to Subscriptions in the main menu. You may need to click on All services to see Subscriptions. Select a subscription.
4. Click Access Control (IAM).
5. Click Add > Add custom role.
6. In Create a custom role, select Start from JSON and then select one of the custom role JSON files, that you saved above. The role name and description fields are populated with details from the JSON file. The file will also be validated.
7. Click Next and review the list of permissions.
8. Click the Assignable scope tab and select subscription as the Type. Select the subscriptions to which the custom role will be assigned.
9. Click the JSON tab to review your settings and then create the custom role and click Save.
10. Assign the custom role to the Kubex service principal. See [Assigning Access to Subscriptions](#Access_to_Subscriptions).

### Create the Service Principal Through the Azure CLI

If you are comfortable working with the command line, you can create the service principle through the Azure CLI. You can then use the resulting .JSON file when working with the Kubex API. Refer to the Azure website for details: [Create an Azure service principal with the Azure CLI](https://learn.microsoft.com/en-us/cli/azure/create-an-azure-service-principal-azure-cli).

## Creating the Cloud Connection in Kubex

Once all of the prerequisites are complete, you can create the cloud connection through the Cloud Connection wizard. See [Using the Public Cloud Connections Wizard](../Densify_Com/Using_the_Public_Cloud_Connection_Wizard).

### Modifying Your Azure Cloud Connection

When you create the Azure cloud connection for the first time, Kubex discovers all of the subscriptions, associated with the user or service principal. Upon saving the connection it will schedule data collection from each of the discovered and selected subscriptions.

If subsequently, subscriptions are added, they will not be included in data collection. Additionally, subscriptions that are removed will continue to be included, resulting in wasted time and resources. To add new subscriptions or remove old ones, edit the cloud connection. See [Editing a Connection](../Densify_Com/Using_the_Public_Cloud_Connection_Wizard#Edit_Conn).


# Oracle Cloud Infrastructure Data Collection Prerequisites for API Key User
Source: https://docs.kubex.ai/docs/WebHelp_Densify_Cloud/Content/Data_Collection_for_Public_Cloud_Systems/Oracle_Cloud_Infrastructure_Data_Collection_Prerequisites



## Overview

Kubex currently supports data collection from an OCI tenancy using API Key user authentication. This method requires creating a dedicated user in OCI, generating an API signing key pair, and configuring appropriate policies to allow Kubex to collect Instance data.

## Requirements to Create a Cloud Connection

To connect Kubex to your OCI tenancy using API Key user authentication, you will need the following information for each tenancy you wish to connect:

* Tenancy OCID
* User OCID
* Region Identifier
* API Key Fingerprint
* Private Key File

Before configuring OCI data collection, ensure you have:

* **Administrative Access**: You must have administrative privileges in your OCI tenancy or sufficient permissions to create users, groups, and policies
* **Console Access**: Access to the [Oracle Cloud Infrastructure Console](https://cloud.oracle.com)

## Creating a User, Group and Policy for Kubex Data Collection

<Steps>
  <Step title="Select the Identity Domain">
    Sign in to the OCI Console and navigate to Identity & Security > Identity > Domains. Select the appropriate identity domain for the Kubex data collection user.

    <Note>
      Ensure the selected domain exists in the root compartment of your tenancy to allow Kubex access to resources across all compartments. If your tenancy has resources deployed in multiple regions, verify that the selected domain is replicated to all regions Kubex should collect data from.
    </Note>
  </Step>

  <Step title="Create a Dedicated User for Kubex Data Collection">
    In your selected Identity Domain:

    1. Navigate to **User management** tab
    2. Click **Create** button in the **Users** section
    3. Fill in the required fields:
       * Last name: `Kubex Data Collector`
       * User name: `kubex-data-collector`
       * (Optional) Email: `support@kubex.ai`
    4. Click **Create** to create the user
  </Step>

  <Step title="Create a Group for the Kubex Data Collection User">
    In your selected Identity Domain:

    1. Navigate to **User management** tab
    2. Click **Create group** button in the **Groups** section
    3. Fill in the required fields:
       * Name: `Kubex`
       * Description: `Group for Kubex data collection`
    4. Select the user you created in the previous step to add to this group
    5. Click **Create** to create the group
  </Step>

  <Step title="Create Policies to Allow Kubex Data Collection">
    1. Navigate to Identity & Security > Identity > Policies
    2. Select the Policies tab and click **Create Policy**
    3. Fill in the required fields:
       * Name: `Kubex Data Collection Policy`
       * Description: `Policy to allow Kubex data collection`
    4. Switch to the manual editor and add the following policy statements:
       ```
       Allow group Kubex to inspect compartments in tenancy
       Allow group Kubex to inspect tenancies in tenancy
       Allow group Kubex to read instances in tenancy
       Allow group Kubex to inspect instance-images in tenancy
       Allow group Kubex to inspect vnic-attachments in tenancy
       Allow group Kubex to inspect vnics in tenancy
       Allow group Kubex to read public-ips in tenancy
       Allow group Kubex to inspect instance-pools in tenancy
       Allow group Kubex to inspect instance-configurations in tenancy
       Allow group Kubex to read metrics in tenancy
       ```
    5. Click **Create** to create the policy and apply it to the group and user

    <Note>
      Ensure the policy is created in the root compartment of your tenancy.
    </Note>
  </Step>
</Steps>

## Obtaining the Required Credentials for Connection

<Steps>
  <Step title="Navigate to the User Details Page">
    In your selected Identity Domain, navigate to the **User management** tab and click on the user you created for Kubex data collection
  </Step>

  <Step title="Create an API Key for the User">
    1. Click on the **API Keys** tab in the user details page
    2. Click **Add API Key** button
    3. Select **Generate API key pair**
    4. Download private and public key files and save securely. The private key file will be required when configuring the cloud connection in Kubex
    5. Click **Add** button to create the API key and associate it with the user
  </Step>

  <Step title="Copy the Configuration file preview">
    After adding the API key, a configuration file preview will be displayed. Copy the following values from the preview:

    * user (User OCID)
    * tenancy (Tenancy OCID)
    * region (Region Identifier)
    * fingerprint (API Key Fingerprint)
  </Step>
</Steps>

Once you have the required credentials, you can add the connection in Kubex. See [Connecting OCI to Kubex](/docs-kubex/Content/Cloudex/Data_Collection_OCI_Connections) for more details.


# Kubex Features
Source: https://docs.kubex.ai/docs/WebHelp_Densify_Cloud/Content/Release_Notes/New_Features_Cloud



This topic summarizes both new and updated features introduced in Kubex

<Accordion title="5.1 September 02, 2026">
  The following changes have been made to Kubex in this release:

  * **Updates to Public Cloud Metadata**
    * Updates to AWS, Azure and OCI for new instance types and costs.

  * **K8s Analysis Policy Updates**
    * Ability for users to change the default policy. Any new clusters added to Kubex will use this default policy.
    * Updates to the thresholds on the policies shipped with Kubex. This is to reflect feedback from how users are setting these in the field.

  * **K8s Analysis using Custom Metrics**
    * Kubex uses CPU and Memory metrics for optimizing Containers. It can now also use custom cpu and/or memory metrics for optimization.
    * These could be different metrics that are more accurate for optimization. E.g., Queue Depth, Kafka driven metrics.
    * To help set this up, please contact your Kubex team.
</Accordion>

<Accordion title="5.0 August 12, 2026">
  The following changes have been made to Kubex in this release:

  * **New Container Analysis Framework**
    * Kubex v5.0 introduces a new container analysis framework, delivering near real-time analysis with hourly updates and designed to handle very large Kubernetes environments.

  * **Updated Analysis Policy Framework**
    * Enhanced policy engine with flexible policy assignment at the cluster or namespace level, or dynamically based on Kubernetes labels.

  * **Enhanced Container Cost Estimates**
    * Container cost and waste is calculated based on the cost of the node it runs on.
</Accordion>

<Accordion title="4.5.0 May 27, 2026">
  The following changes have been made to Kubex in this release:

  * **Fractional GPU Recommendations**

    * Fractional GPU recommendations on the current GPU model

    <Frame>
      <img />
    </Frame>

  * **GKE Autopilot Recommendations are Compute Class Aware**
    * Recognizes "balanced" and "general-purpose" compute classes and maintains the allowed CPU:Memory ranges

  * **Guaranteed QoS Support**
    * Kubex recommendations support Guaranteed QoS
    * This policy can be enforced (even if not currently setup) or auto-detected and maintained

  * **Container Automation Policy**

    * Visibility to the automation policy set up in the K8s cluster

    <Frame>
      <img />
    </Frame>

  * **RBAC for AI Agent**
</Accordion>

<Accordion title="4.4.0 April 29, 2026">
  The following changes have been made to Kubex in this release:

  * **Oracle Cloud Infrastructure (OCI) Support**

    * Added support for OCI connections from the Cloud Connections page
    * Enabled data collection and optimization for OCI Virtual Machines (VMs)
    * Added support for App Owner report

    <Frame>
      <img />
    </Frame>

    <Frame>
      <img />
    </Frame>

  * **Container Ephemeral Storage Optimization**

    * Introduced ephemeral storage recommendations in the UI and REST API
    * Added support for ephemeral storage policies
    * Note: Ephemeral storage data collection is opt-in and disabled by default

    <Frame>
      <img />
    </Frame>

  * **Widget Enhancements**
    * Added GPU Trend widget to visualize GPU usage over time
    * Added Prioritizer Insights widget to summarize recommended actions to focus on based on environment and preferences

  * **Policy Enhancements**

    * Improved Policy Viewer layout for readability and navigation
    * Added support for configuring samples percentile in Container and Cloud policies

    <Frame>
      <img />
    </Frame>

  * **API Enhancements**
    * Added Automation Engine heartbeat endpoint:
      `POST /automation/clusters/{clusterName}/heartbeat`

  * **UI Improvements**
    * Added container cost visibility to the Container Overview page
    * Enabled Edit and Delete functionality on the Cloud Connections page

  * **Access Control & Security**
    * Added support for Okta Groups for permission management. Enabled assignment of user permissions based on group membership
    * Added support for Microsoft Graph scopes (for example, `User.Read`) in Azure OpenID integrations
</Accordion>

<Accordion title="4.2.0 March 11, 2026">
  The following changes have been made to Kubex in this release:

  * **Kubernetes Dashboard**

    * Kubex introduces a new customizable dashboard that serves as the default landing page, enabling users to compose their own workspace using widgets for faster operational insights.
    * The dashboard includes preconfigured views that organize key metrics and charts into ready-to-use layouts. Users can customize these views by arranging widgets and visualizations to match their operational workflow.
    * Users can choose whether the classic interface or the new dashboard is used as their default landing page.

    <Frame>
      <img />
    </Frame>

  * **Improved Node and Container Visibility**
    * Container Details now displays node names instead of only a count.
    * Horizontal Pod Autoscaler (HPA) settings are now visible in the Container Details table.
    * Node group and node metrics now include 5-minute metric samples.

  * **API Enhancements**
    * GPU recommendation details added to the Containers API endpoint `GET /kubernetes/clusters/<clusterName>/containers?details=true`

  * **Google Cloud (GCP) Connection Support**

    * Kubex now supports Google Cloud Platform (GCP) connections directly from the Kubex UI.

    <Frame>
      <img />
    </Frame>

  * **AWS RDS Connection Data Support**
    * Kubex now collects and analyzes AWS RDS connection data, enabling deeper visibility into database activity and incorporating this data into platform analysis.

  * **User Management**

    * Users in the Access Manager group can now access User Management
    * Added sign-out functionality in the Kubex UI

    <Frame>
      <img />
    </Frame>

  * **Multi AI-Agent Support**

    * Kubex now supports multiple AI agents, enabling users to switch between specialized agents for tasks such as predictive pod scaling, node pre-warming, container sizing, and automation impact analysis.

    <Frame>
      <img />
    </Frame>
</Accordion>

<Accordion title="4.1.0 January 21, 2026">
  The following changes have been made to Kubex in this release:

  * **AWS ECS Support**

    * Kubex now shows optimization recommendations for Amazon ECS workloads, helping you right-size your containerized applications running on ECS for optimal performance and cost efficiency.
    * The ECS button the left-hand menu only shows up if there is ECS data.

    <Frame>
      <img />
    </Frame>

  * **PKCE Support for SSO using OpenID**
    * PKCE (Proof Key for Code Exchange) is a security extension that enhances OAuth 2.0 authorization flows.

  * **Cloud Summary Separates Waste and Risk**

    * Netting out Waste and Risk hides the true savings potential.
    * By displaying 'waste' and 'cost of risk removal' as separate metrics, users can better understand each savings opportunity.

    <Frame>
      <img />
    </Frame>

  * **Node Group Cost on the Details table**
    * Node Group costs are displayed in the details table.
    * Costs are calculated based on the sum of the costs of all nodes running in the node group. It takes into account the # of hours each node was running.

  * **License Compliance Report**

    * The license compliance report has been migrated to the Kubex UI.
    * The report shows how many Kubex licenses are being consumed against what is contractually allowed.

    <Frame>
      <img />
    </Frame>
</Accordion>

<Accordion title="4.0.0 December 03, 2025">
  The following changes have been made to Kubex in this release:

  * **New Kubex AI Agent Experience**

    * Natural-Language Interaction: Users can now simply ask questions in plain English and get accurate, contextual answers directly from the AI agent.
    * Guided Navigation: The agent can take users to the right features or pages in the product-no need to search menus or remember where things live.
    * Action Assistance: Beyond answering questions, the agent can help surface relevant insights, and streamline everyday tasks.
    * Enterprise-Grade Data Privacy: No customer data is used for model training. The underlying LLM does not learn from or use customer data to train or improve itself.

    <Frame>
      <img />
    </Frame>

    **Enhanced GPU Analysis**

    * The Kubex GPU analysis recommends the optimal GPU model and configuration for maximum potential savings. This includes alternative GPU models, provided they are compatible with the workload.
    * The newly introduced *GPU Catalog Map* provides a visual comparison of how the current workload scores against all GPU models and configurations.

    <Frame>
      <img />
    </Frame>
</Accordion>

<Accordion title="3.8.0 November 26, 2025">
  The following changes have been made to Kubex in this release:

  * **Policy Editing**

    * Version 3.8 includes a new and often requested capability to edit analysis policies via the UI.
    * The "policy\_admin" role enables specific users with the ability to edit both cloud and container analysis policy settings directly from the Kubex UI.
    * Additionally, the last update date - and who made the update - are now exposed in the UI.
    * The policy descriptions have been updated to make them easier to understand, and tooltips now include detailed information about each setting along with their default value.

    <Frame>
      <img />
    </Frame>

    **Cloud Optimization Trends Improvements**

    * The performance in loading and rendering the optimization trends charts located on the cloud Summary and Optimization Trends tabs has been significantly improved in this release.

    **Kubex Data Collection for GKE Autopilot Clusters**

    * Kubex now supports data collection and analysis of containers running in GKE Autopilot Clusters providing visibility to container level risk and waste along with remediation recommendations for optimizing container resource allocations.
</Accordion>

<Accordion title="3.7.0 November 6, 2025">
  <Accordion title="Updates to Container Optimization">
    The following changes have been made to Kubex in this release:

    * **CPU Throttling Risks**
      * The CPU Throttling risks due to undersized CPU Limits are highlighted in the Histogram.
      * Clicking on the risk item (as shown below) will take you to the Analysis Details page showing all the containers with CPU Throttling risks, and the Kubex recommendation to address it.
      <Frame>
        <img />
      </Frame>
  </Accordion>

  <Accordion title="Updates to Cloud Optimization">
    * **Optimization Trends**

      * The Optimization Trends reports visualize historical trends across key operational metrics, including instance counts, costs, savings, and CPU/Memory utilization. This helps users better understand performance patterns and optimization impact over time.
      * Dashboards can be personalized - users can select which reports to display and organize them in their preferred layout. Each report can be resized to small, medium, or large for optimal viewing.
      * Users can save dashboards as public (where others in your organization can view but not edit) and private (where only they can view/edit them).

      <Frame>
        <img />
      </Frame>

      <Frame>
        <img />
      </Frame>
  </Accordion>
</Accordion>

<Accordion title="3.6.0 October 1, 2025">
  <Accordion title="Updates to Container Optimization">
    The following changes have been made to Kubex in this release:

    * **GPU MIG Recommendation**--Supports NVIDIA MIG (Multi-Instance GPU) technology, recommending whether workloads should use a full GPU or a fraction (MIG slice).
      * The Analysis Details table will highlight the suggested MIG profile (and the GPU fraction it represents).
      <Frame>
        <img />
      </Frame>
      * MIG recommendation info is also available in the GPU tab for an individual container manifest
      <Frame>
        <img />
      </Frame>
    * **Updated Container Summary Tab**
      * "Waste" links now take you directly to the Analysis Details tab with the appropriate filter preselected
      * "Info" tooltip has been added to the Spend Breakdown modal. This highlights the total unspecified CPU/Memory request. With this info, the numbers here and in the Analysis Details table will match up.
    * **Memory Limit Events (Last Day) added to Analysis Details table**--This is a hidden column by default.
    * **Node/Node Group Analysis**--Improved quality of recommendations by switching to "Working Set Memory" when available. Working set memory is a better metric to analyze the memory requirements for Nodes.
    * **Other Improvements & Updates**
      * GPU and GPU Memory metrics viewer chart: added "Current Request" line
      * Added a new view on the Analysis Details table: "GPU Request Surplus". This highlights the container manifests that have surplus GPU and can be optimized to reduce waste.
      * Container API now include a "analyzedOn" date which allows the automation to only consider fresh recommendations.
      * Removed the word "AI" from "AI Analysis Details"
  </Accordion>

  <Accordion title="Updates to Cloud Optimization">
    * **Policies**--View policies for Cloud environments in a new modal, accessible from the Policies tab and Analysis Details table.
      <Frame>
        <img />
      </Frame>
      * Policies Tab
      <Frame>
        <img />
      </Frame>
      * Analysis Details Table
      <Frame>
        <img />
      </Frame>
    * **Updated Azure Catalog Map**--Azure Catalog Map has been updated to show all supported VM types and sizes. These are displayed on the map when "Commonly Used" is unselected.
      <Frame>
        <img />
      </Frame>
    * **Added columns to Analysis Details table**
      * Comment
      * Recommendation Reason
      * RDS Cluster ID
      * Resource Tags
  </Accordion>

  <Accordion title="Administration">
    * **SSO with Okta**--Removed requirement for Okta's CAS (Central Authentication Service).
    * **Password Reset**--Password reset emails now link to Kubex instead of Kubex Console.
  </Accordion>
</Accordion>

<Accordion title="3.5.0 August 13, 2025">
  <Accordion title="Updates to Container Optimization">
    The following changes have been made to Kubex in this release:

    * **Updated Container Summary Tab**--The container summary page has been updated with a new look and feel to better highlight current spend, waste, and risk.

    <Frame>
      <img />
    </Frame>

    * **Container Out of Memory Kills**--Container out of memory kill data is now visible in OOM Kills (Last Day) column on the Analysis Details page:
      * Badges will display on summary and histogram page to indicate if there are
        OOM Kills in the environment
      * ML Model and historical data available in the Utilization Charts carousel and Metrics Viewer
    * **CPU Throttling (%)**--CPU Throttling data is now visible in CPU Throttling (%) column on the Analysis Details page:
      * ML Model and historical data available in Utilization Charts carousel and
        Metrics Viewer
    * **Automation Tab**--Automation tab has been added to highlight request and limit changes made by the Kubex Automation Engine. An overview of optimized manifests
      is also available on the summary page
    * **Business & Operational Attributes**--Various business and operations related
      attributes (e.g., Application, Business Unit, Cost Center, Operational Environment) have been added to the tree view/filter options and Analysis Details
      columns
    * **GPU Optimization for Container Resource Requests**--- Containers with GPUs
      allocated now receive recommendations for downsize opportunities. The GPU Overview page has been updated to highlight this information:
      * Added system views to Analysis Details (Immediate GPU Savings & Addtional GPU Waste)
  </Accordion>

  <Accordion title="Updates to Cloud Optimization">
    The following changes have been made to Public Cloud optimization in this release:

    * **Effort Popup**--The Effort column on the Analysis Details page is now clickable, showing a popup with additional details on the effort required to change to the recommended instance type.
      * Overall effort is the highest effort of the individual rule items. Possible values are None, Low, Medium, and High
    * **Business & Operational Attributes**--Various business and operations related attributes (e.g., Application, Business Unit, Cost Center, Operational Environment) have been added to the tree view/filter options and the Analysis Details page.
      columns
  </Accordion>
</Accordion>

<Accordion title="3.4.0 July 9, 2025">
  <Accordion title="Updates to Container Optimization">
    The following changes have been made to Kubex in this release:

    * **Updated Container Summary Tab**--The container summary page has been updated to better highlight both your current spend and the details of possible savings.
    * **Updated Node Metrics**--The Node Metrics Viewer has been updated to show the following GPU metrics:
      * GPU Utilization %
      * GPU Memory Utilization (%)
      * GPU Power Usage (Watts)
    * **Updated Utilization Chart**--The node chart showing the number of pods running on a node has been updated to show the limit for the selected node.
    * **Customizable Data Aggregation**--You now have the ability to edit how grouped data in a table is aggregated (i.e. sum, average, max, etc.) and save your customization in a table view. This feature is available for containers, node groups, nodes and cloud instances.

    Refer to the [Kubex documentation](/docs-kubex/Content/Kubex/Getting_Started_with_Kubex) for details.
  </Accordion>

  <Accordion title="Updates to Cloud Optimization">
    The following changes have been made to the Public Cloud optimization in this release:

    * **Cloud Connections**--In this release you can now can create and edit the connections to AWS and Azure. You can also view data collection status for each of the connections. Kubex uses these connections to collect data from each account, daily.
    * **Accessing the Catalog Map**--You can now access the catalog map directly from the Analysis Details tab. The catalog map with a modal view has been added to the utilization charts. You now do not need to leave the Analysis Details tab to use the catalog map.
    * **Summary Tab**--The Cloud Summary tab has been updated to improve useability.

    Refer to the [Kubex documentation](/docs-kubex/Content/Kubex/Getting_Started_with_Kubex) for details.
  </Accordion>

  <Accordion title="Enhanced Cost Modeling">
    The following changes have been made to improve how Kubex determines the cost of public cloud instances, using customer-specific discounts:

    * **Azure Hybrid Benefit Status**--As part of enhancing the cost data model, Kubex needs to distinguish between systems that are BYOL (also called Azure Hybrid Benefit or AHB) to accurately represent the cost of the system. The license model is available in the existing data collection configuration so no changes are required to the minimum permissions for BYOL VMs.
    * **Azure Instance OS Name**--Kubex now determines the type of Linux OS. In this release RHEL and SUSE are supported. The OS name is used to accurately determine instance costs.
    * **Updated Cost Model**--The cloud cost data model has been updated to apply discounts based on the following details:
      * OS Type--The type of Linux OS installed on a cloud instance. This is not an attribute and is stored in a table but cannot be edited or cleared like an attribute.
      * License Model (Attr\_key is aws:licensemodel)--The licensing model that has been configured for a cloud instance )
      * Life Cycle (Attr\_key is aws:lifecycle)--This attribute is not currently used but is collected for future development. It is used to store whether or not the instance is a spot instance. Possible values are "spot" or "normal"

    Refer to the [Kubex documentation](/docs-kubex/Content/Kubex/Getting_Started_with_Kubex) for details.
  </Accordion>
</Accordion>

<Accordion title="3.3.0 June 25, 2025">
  <Accordion title="Updates to Container Optimization">
    The following changes have been made to Kubex in this release:

    * **Node Modal**--A new modal opens when you click a node name on the Node Details page.
    * **Performance Improvements**-- The Kubex UI no longer retrieves data from the Kubex Reporting Database (RDB). All UI component queries are directed exclusively to Kubex-specific tables in MS SQL.

    Refer to the [Kubex documentation](/docs-kubex/Content/Kubex/Getting_Started_with_Kubex) for details.
  </Accordion>
</Accordion>

<Accordion title="3.2.0 June 11, 2025">
  <Accordion title="Updates to Container Optimization">
    The following changes have been made to Kubex in this release:

    * **GPU Metrics for Containers**--In this release Kubex introduces reporting of GPU configuration and utilization data for containers, node groups and nodes. This data enables you to identify GPU-enabled containers and nodes in your environment and see how effectively you are utilizing your GPU resources.

      You must have [data forwarder v4.2.1](#Forwarder) deployed to collect the GPU data from your environments.

      There are updates on many pages to highlight GPU resource configuration and utilization:

      * **Updated Analysis Details**--A number of data points allow you to identify containers with GPU requests and to determine where the GPU and GPU memory request values are higher than peak utilization over a given period.
        The analysis populates these attribute values based on the date range and data selection options that are defined in your container optimization policy. The Analysis Details page has been updated to display the following GPU data.

        <table>
          <col />

          <col />

          <tbody>
            <tr>
              <td>
                <ul>
                  <li>
                    GPU Model
                  </li>

                  <li>
                    GPU Request
                  </li>

                  <li>
                    Total GPU Request
                  </li>

                  <li>
                    GPU Average
                  </li>

                  <li>
                    %GPU Average
                  </li>

                  <li>
                    GPU Sustained
                  </li>

                  <li>
                    GPU Min
                  </li>

                  <li>
                    GPU Memory Request
                  </li>

                  <li>
                    Total GPU Memory Request
                  </li>
                </ul>
              </td>

              <td>
                <ul>
                  <li>
                    GPU Memory Average
                  </li>

                  <li>
                    % GPU Memory Average
                  </li>

                  <li>
                    GPU Memory Sustained
                  </li>

                  <li>
                    GPU Memory Min
                  </li>

                  <li>
                    GPU Power Usage Peak
                  </li>

                  <li>
                    GPU Power Usage Average
                  </li>
                </ul>
              </td>
            </tr>
          </tbody>
        </table>
      * **New Views**--Four new views have been added to the Analysis Details page. These views allow you to focus on your GPU data:

        <table>
          <col />

          <col />

          <tbody>
            <tr>
              <td>
                <ul>
                  <li>
                    GPU Inventory
                  </li>

                  <li>
                    GPU Cost
                  </li>
                </ul>
              </td>

              <td>
                <ul>
                  <li>
                    GPU Low Utilization
                  </li>

                  <li>
                    GPU Memory Low Utilization
                  </li>
                </ul>
              </td>
            </tr>
          </tbody>
        </table>

        The default view has been updated to include GPU data.
      * **Updated Summary**--New GPU-specific cards have been added to the containers Summary page. A note includes a link that opens a modal containing GPU pricing details.

        The top two cards on the Summary page have also been updated to better highlight both your current spend and the details of possible savings.
      * **New GPU Tab**--A new GPU tab has been added when reviewing a single container. This new page provides details of the GPU utilization on the selected container.
      * **Updated Metrics Viewer**--The following GPU metrics are available in the metrics viewer:
        * GPU Utilization in GPUs - Average Container
        * GPU Memory Utilization (MB) - Average Container
        * GPU Memory Utilization (%) - Average Container
        * GPU Power Usage (Watts) - Average Container
    * **GPU Metrics for Node Groups**--GPU metrics have also been added for Node Groups and individual nodes.

      <table>
        <tbody>
          <tr>
            <td>
              <ul>
                <li>
                  Allocatable GPU Memory (GB)
                </li>

                <li>
                  Allocatable GPUs
                </li>

                <li>
                  Allocatable Memory (GB)
                </li>

                <li>
                  Average CPU Utilization (%)
                </li>

                <li>
                  Average GPU Memory Utilization (%)
                </li>

                <li>
                  Average GPU Utilization (%)
                </li>

                <li>
                  Average Memory Utilization (%)
                </li>

                <li>
                  GPU - Node Balance Ratio
                </li>

                <li>
                  GPU Capacity
                </li>

                <li>
                  GPU Memory - Node Balance Ratio
                </li>

                <li>
                  GPU Memory Capacity (GB)
                </li>
              </ul>
            </td>

            <td>
              <ul>
                <li>
                  GPU Request (% of Allocatable)
                </li>

                <li>
                  No. of Nodes with Underused GPU
                </li>

                <li>
                  No. of Nodes with Underused GPU Memory
                </li>

                <li>
                  Nodes with Underused GPU Memory(%)
                </li>

                <li>
                  Nodes with Underused GPU(%)
                </li>

                <li>
                  Peak GPU Memory Utilization (%)
                </li>

                <li>
                  Peak GPU Utilization (%)
                </li>

                <li>
                  Primary Node GPU Model
                </li>

                <li>
                  Primary Node Type GPU (GPUs)
                </li>

                <li>
                  Primary Node Type GPU Memory (GB)
                </li>

                <li>
                  Unallocated GPUs
                </li>
              </ul>
            </td>
          </tr>
        </tbody>
      </table>
    * **Updated Node Overview Tab**--This tab has been updated add GPU details and to improve usability.
    * **New Data in Analysis Details**--Six new data points allow you to find containers where the CPU and memory request values are higher than peak utilization over a given period.

      The analysis populates these values based on the date range and data selection options that are defined in your container optimization policy.

      * CPU Peak--Highest peak value in mCores, on the busiest container.
      * CPU Sustained--Highest sustained value in mCores, on the average container.
      * CPU Min--Lowest value in mCores, on the average container.
      * Memory Peak--Highest peak value in MB, on the busiest container.
      * Memory Sustained--Highest sustained value in MB, on the average container.
      * Memory Min--Lowest value in mCores, on the average container.
    * **Timezone**--The utilization charts for containers, node groups and nodes have been updated to standardize the timeline on UTC. The X-axis label has been updated to indicate the timezone designation for all charts to 'UTC '.
    * **Updated Node Overview**--The node overview page has been updated to improve useability and add details of GPU utilization.

    Refer to the [Kubex documentation](/docs-kubex/Content/Kubex/Getting_Started_with_Kubex) for details.
  </Accordion>

  <Accordion title="Updates to Cloud Optimization">
    The following changes have been made to Public Cloud optimization in this release:

    * **Timezone**--The X-axis label has been updated to indicate the timezone designation for all historical utilization charts to 'UTC ' This change to does not currently apply to the ML charts. The ML charts on the Analysis Details page use Kubex server's time. So this will be either "Eastern Time" or "Central Europe Time".

    Refer to the [Kubex documentation](/docs-kubex/Content/Kubex/Getting_Started_with_Kubex) for details.
  </Accordion>
</Accordion>

<Accordion title="3.1.0 May 14, 2025">
  The following changes have been made in this release:

  * Users no longer need to clear their browser cache after an upgrade.

    When using the Kubex Console users must clear their browser cache after an upgrade,
  * **Analysis Details Export** --When the content of the Analysis Details is exported, the Container Name is provided as a hyperlink that takes you to the Overview page for the selected container.

    When you open the exported .XLS file, the content initially appears as plain text, and when you click on the cell it becomes a hyperlink.
  * **Node Group Overview**--The cards on the Node Group Overview page have been updated to better report on the status of a single node group. Additionally, utilization charts have been added to this page so you can review detailed metrics for a selected node group.
  * **New Filter**--A new public filter, "With automation enabled", has been added to the container tree viewer. When selected this filter displays all containers with automation enabled. i.e. Automation Enabled = true.
  * **Improved Performance>**--By focusing on nodes that were running in the last day rather than the past 7 days you will notice improved performance when working with nodes and node groups.
  * **Access to the Online Help**--A new help icon provides direct access to the online help.
  * **Renamed Value**--The value, "No. of Containers" has been renamed to, "Avg No. of Containers". The new name more appropriately describes the value. The following pages have been updated: Summary, Overview, Histogram and Analysis Details.

  Refer to the [Kubex documentation](/docs-kubex/Content/Kubex/Getting_Started_with_Kubex) for details.
</Accordion>

<Accordion title="3.0.0 April 23, 2025">
  <Accordion title="New Public Cloud Management Console">
    <div>
      <div>
        <img alt="" />
      </div>

      <div>
        <p>
          In this release Kubex introduces Public Cloud optimization features. In this new console, Kubex's patented analytics determine optimal resource settings for your public cloud environments and display the results in a new user interface.
        </p>

        <p>
          Use the new console to review resource utilization across your AWS, Azure and Google Cloud environments.
        </p>
      </div>
    </div>

    You can access the new console from your existing instance using:

    ```
    https://<customer name>.kubex.ai
    ```

    See the new [Kubex](https://www.kubex.ai) website to start a free trial.

    Use your existing Kubex credentials to access the console. You can either close the browser window or navigate back to the Kubex Console to log out.

    The new console uses the latest MSSQL and Postgres databases.
  </Accordion>

  <Accordion title="Kubex Updates">
    The following changes have been made to Kubex in this release:

    * **Automation Tab**--A new automation tab has been added to report on the status of the Kubex Container Automation solution.
    * **Updated Connections Table** --The following changes have been made to this table:
      * Three new columns have been added: Cluster Version, Kubex Collection Stack Version and Prometheus Version
      * A link that provides secure Kubex credentials has been added. The credentials are provided in a code snippet than can be copied directly into your `values.edit.yaml` file.

        This new method makes it easier for you to set up container data collection, reducing the previous manual dependency of requesting these credentials from Kubex.
    * **Updated Optimization Breakdown**--Hovering over any bar in this chart, displays a description of the recommended optimization. Badges have also been added to indicate significant information, such a s memory events or unspecified resource settings.
    * **Summary Page**--The Summary page has been updated for improved readability.
    * **Cost Modeling**--Kubex now has improved algorithms that use existing utilization data to estimate the cost for containers with unspecified CPU/memory request values. The Summary, Analysis Details, and Overview pages have all been updated to show the cost estimates for these containers. The following updates have been made to show these values:
      * Two columns have been added to the Analysis Details tab:
        * "Total Surplus CPU Request from Unspecified (mCores)";
        * "Total Surplus Memory Request from Unspecified (MB)"
      * Two system views have been added to the Analysis Details tab:
        * "CPU Request Shortfall (from Unspecified)"
        * "Memory Request Shortfall (from Unspecified)"
      * The Overview tab and single instance modal page have been updated to add details of unspecified CPU and memory request settings. These additional cards are only displayed if the selected container does not have specified CPU and/or memory request settings.

    Refer to the [Kubex documentation](/docs-kubex/Content/Kubex/Getting_Started_with_Kubex) for details.
  </Accordion>

  <Accordion title="Kubex Automation">
    This release provides enhancements to the Kubernetes automation framework that sends configuration and modification event status information to your Kubex instance

    A new Automation status page has been added to Kubex that reports on the status of containers that have been enabled for automation, You can enable/disable containers for automation using a right-click context menu from the Kubex container tree viewer. Refer to the [Kubex documentation](/docs-kubex/Content/Kubex/Getting_Started_with_Kubex) for details.

    Refer to [Kubex Automation Engine](https://github.com/densify-dev/helm-charts/tree/master/charts/kubex-automation-engine) for details on deploying and using the Kubex Container Automation solution.
  </Accordion>

  <Accordion title="New Kubernetes API Endpoints">
    The following endpoints have been added to the Kubex API:

    * `GET /kubernetes/clusters`
    * `GET /kubernetes/clusters/<clusterName>`
    * `GET /kubernetes/clusters/<clusterName>/containers`
    * `GET /kubernetes/clusters/<clusterName>/containers?details=true`
    * `GET /kubernetes/clusters/<clusterName>/automation`

    Two new attributes have been added to support the automation features.

    * Kubex Automation--Indicates whether the container is eligible for automation within Kubex.The attribute is set one-time, is static, and is not inherited from cluster, node group, or any higher level.
    * Kubex Policy--Indicates what policy to use when automation is enabled.

    See [Kubex API New Features](/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/API_New_Features)
  </Accordion>

  <Accordion title="Updated API Token Expiry Duration">
    The token expiry has been increased from 5 to 60 minutes. Re-authorize will no longer be required for longer-running pipeline operations that previously exceed the 5-minute limit. The JSON Web Token (JWT) secures the Kubex API so users can only make authorized API requests.

    See [Authorize](/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Authorize)
  </Accordion>

  <Accordion title="Changes to Scale Groups with Max Size =1">
    In this release, singleton scale groups, both ASGs and VM Scale Sets, will now be analyzed as scale groups rather than as EC2 or VM instances. You will observe the following changes:

    * Kubex Console:
      * Singleton ASGs/VM Scale Sets will now only appear in the corresponding ASG or VM Scale Set tabs.
      * If you have large number of these singleton scale groups, you may notice a decrease in the number of EC2 and Azure VMs reported, while the ASG and VM Scale Set counts will increase accordingly.
      * The Catalog Map will no longer report on ASGs and VM Scale Sets with Max Size =1.
      * No change to the Impact Analysis and Recommendation Report for ASGs, as this report recognized singleton ASG instances and reported on them accordingly.
    * Scaling Recommendations:
      * Singleton scale groups will now have scaling recommendations, as required. Previously, there were no scaling recommendations, only instance type change recommendations.
      * If you need to control the group size and prevent scaling, use the "Group Max Size Override" and "Group Min Size Override" attributes. See [Overriding Cloud Recommendations](../Densify_Com/Overriding_Cloud_Recommendations#Scale_Group_Overrides). Contact <a href="mailto:support@kubex.ai">
        [support@kubex.ai](mailto:support@kubex.ai)</a>

        for detail of configuring these attributes.
    * API Results:
      * There are no changes to how scale groups are managed through the Kubex API. Scale groups have service type "ASG" or "VMSS".
      * Scaling recommendation are already included in the results. See [Analysis: AWS Recommendations](/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_AWS_Results). or [Analysis: Azure Recommendations](/docs-api/WebHelp_Densify_API_Cloud/Content/API_Guide/Analysis_Azure_Results)..
    * Licensing:
      * Currently, singleton scale groups are licensed as individual EC2/VMs.
      * With this update, ASG licensing can be based on 1 ASG = 4 licenses OR 1 license per instance, based on the average number of instances in the scale group.

        VM Scale Sets are licensed using 1 license per instance, based on the average number of instances in the group.

        See
        [License Compliance Report](../Densify_Com/License_Compliance_Report).
      * The current container licensing model is based on the last known number of containers, on which the scale groups are running. With this change, container licensing will be calculated based on the average number of containers used, over the data range, as defined in the policy.
  </Accordion>

  <Accordion title="Updated Public Cloud Catalog">
    The public cloud metadata catalogs have been updated to ensure Kubex recommendations are based on the latest vendor pricing:

    * AWS Metadata Updates:
      * The pricing has been updated and is correct as of April 7, 2025.
      * The following new instance type has been added:

        <table>
          <col />

          <col />

          <col />

          <tbody>
            <tr>
              <td>
                <ul>
                  <li>
                    i8g.48xlarge
                  </li>
                </ul>
              </td>

              <td>
                <p />
              </td>

              <td />
            </tr>
          </tbody>
        </table>
    * Azure Metadata Updates:
      * The pricing has been updated and is correct as of April 7, 2025.
      * The following new instance families have been added:

        <table>
          <col />

          <col />

          <col />

          <tbody>
            <tr>
              <td>
                <ul>
                  <li>
                    Dsv6
                  </li>

                  <li>
                    Ddsv6
                  </li>

                  <li>
                    Dasv6
                  </li>

                  <li>
                    Dadsv6
                  </li>

                  <li>
                    Dlsv6
                  </li>

                  <li>
                    Dldsv6
                  </li>

                  <li>
                    Dalsv6
                  </li>

                  <li>
                    Daldsv6
                  </li>
                </ul>
              </td>

              <td>
                <ul>
                  <li>
                    Esv6
                  </li>

                  <li>
                    Edsv6
                  </li>

                  <li>
                    Easv6
                  </li>

                  <li>
                    Eadsv6
                  </li>
                </ul>
              </td>

              <td>
                <ul>
                  <li>
                    Fasv6
                  </li>

                  <li>
                    Falsv6
                  </li>

                  <li>
                    Famsv6
                  </li>
                </ul>
              </td>
            </tr>
          </tbody>
        </table>
      * Retired the following instances:

        <table>
          <col />

          <col />

          <col />

          <tbody>
            <tr>
              <td>
                <ul>
                  <li>
                    NC
                  </li>

                  <li>
                    NC-Promo instances
                  </li>
                </ul>
              </td>

              <td>
                <ul>
                  <li>
                    NCv2 instances
                  </li>
                </ul>
              </td>

              <td />
            </tr>
          </tbody>
        </table>
    * GCP Metadata Updates:
      * The pricing has been updated and is correct as of April 14, 2025.
      * The following new instance families have been added:

        <table>
          <col />

          <col />

          <col />

          <tbody>
            <tr>
              <td>
                <ul>
                  <li>
                    c4a-standard-lssd
                  </li>
                </ul>
              </td>

              <td>
                <ul>
                  <li>
                    c4a-highmem-lssd
                  </li>
                </ul>
              </td>

              <td />
            </tr>
          </tbody>
        </table>
  </Accordion>
</Accordion>


# Kubex Automation Engine
Source: https://docs.kubex.ai/docs/WebHelp_Densify_Cloud/Content/Release_Notes/release_notes_k8s_automation_engine



<Accordion title="1.13.1 - September 15, 2026">
  **Fixed:**

  * Reduced memory usage from ClusterCompactionPolicy controllers.
</Accordion>

<Accordion title="1.13.0 - September 14, 2026">
  **Added:**

  * Controller can now target Karpenter `NodePool` resources.
  * `ObjectPatch` and `ClusterObjectPatch` automatically repair drift with configurable retry limits, exponential backoff between repairs, and a stabilization window.

  **Changed:**

  * The target observation interval for `ObjectPatch` and `ClusterObjectPatch` is now configurable.
</Accordion>

<Accordion title="1.12.0 - September 10, 2026">
  **Added:**

  * Managed custom resources (automation strategies, policies, and proposals) now report readiness and reconciliation outcomes directly on the resource.

  **Changed:**

  * Proposal sync to the Kubex SaaS is now enabled by default.
  * Automation state reporting to the Kubex SaaS is now always enabled, instead of requiring a manual opt-in setting.

  **Fixed:**

  * Reported resource values after a resize no longer fall back to a stale or missing pod snapshot; they now reflect the last known-good state.
  * Bundled gateway image updated to 1.7, resolving all CVEs reported against 1.4/1.6 (including a critical `golang.org/x/crypto` authentication bypass and an `echo` vulnerability not addressed by the earlier 1.6 update).
</Accordion>

<Accordion title="1.11.2 - August 27, 2026">
  **Changed:**

  * Proposal synchronization now handles every supported `rightsizing.kubex.ai/v1alpha1` custom resource, including `ObjectPatch` and `ClusterObjectPatch` resources and both namespaced and cluster-scoped objects.
  * Compaction scheduler and descheduler support objects are enabled by default, so `ClusterCompactionPolicy` setup no longer needs extra Helm values.
</Accordion>

<Accordion title="1.11.1 - August 26, 2026">
  **Fixed:**

  * KAI vLLM GPU memory tuning now accounts for HAMi's visible GPU memory instead of the raw device total, avoiding an incorrect double application of the GPU fraction on HAMi-backed clusters.
  * vLLM GPU memory tuning is now applied correctly in mixed resize plans and when the selected GPU recommendation is already applied (no-op resizes).
</Accordion>

<Accordion title="1.11.0 - August 19, 2026">
  **Added:**

  * `ContainerArgsPolicy` for managing named container arguments during admission and pod replacement, with support for add, update, and remove operations to support GPU vLLM tuning.
  * Policy snapshots now include all supported `rightsizing.kubex.ai` custom resources, including GPU, compaction, object patch, and container argument policies.
  * Cluster names can be sourced from a ConfigMap or Secret instead of being specified directly in chart values, supporting installations from `kubex-automation-stack`.

  **Changed:**

  * Policy evaluation now includes `PodAffinityPolicy` resources.
  * Compaction scheduler and descheduler components are enabled by default for compaction policy support.
  * Pre-delete cleanup now removes finalizers from every supported `rightsizing.kubex.ai` custom resource.
</Accordion>

<Accordion title="1.10.0 - August 11, 2026">
  **Added:**

  * ObjectPatch and ClusterObjectPatch resources for applying controlled JSON merge patches to Kubernetes objects.
  * Cluster compaction policies for bin-packing workloads with Kubex-managed or external schedulers, per-policy descheduler settings, and eviction-loop suppression.

  **Changed:**

  * Resource and workload handling now preserves more Kubernetes state across resize, rollback, and controller-managed reconciliation paths.
  * Updated the KAI GPU-sharing guide for KAI v0.17.0 and optional HAMi-core 1.1.0 integration.

  **Fixed:**

  * In-place resize rollback monitoring now records the refreshed post-resize Pod state.
  * Compaction eviction convergence now reacts when replacement Pods are assigned to nodes.
</Accordion>

<Accordion title="1.9.1 - August 06, 2026">
  **Fixed:**

  * Rollback no longer gets stuck indefinitely when there's nothing to roll back to; it now stops with a clear error instead of looping forever.
  * Rollback now correctly restores the last known-good configuration, instead of reapplying the broken one that triggered it.
  * Fixed a safety check that could permanently block recovery for single-replica workloads.
  * A resize that triggered a rollback can no longer be immediately reapplied by another policy while the workload is recovering.
  * Improved reliability of rollback handling for workloads with deleted or missing owners.
</Accordion>

<Accordion title="1.9.0 - July 28, 2026">
  ### Breaking

  * **[GPU policies renamed](./BREAKING.md#2026-07-21-gpu-reactive-policy-rename)**: `GpuRebalancingPolicy` and `ClusterGpuRebalancingPolicy` are renamed to `GpuReactivePolicy` and `ClusterGpuReactivePolicy`. Kubernetes doesn't support renaming a CRD in place, so existing GPU policies need to be recreated under the new names after upgrading - see the linked migration steps before upgrading.

  **Added:**

  * The pod rightsizing webhook can now optionally run at the beginning and end of admission, so it works correctly alongside the KAI GPU-sharing scheduler's own webhook. This is off by default and only needed if you're running other resource-mutating webhooks alongside Kubex.
  * Pods now get a `rightsizing.kubex.ai/automation-constraints` annotation explaining why a recommendation couldn't be fully applied (for example, a resource being managed by an HPA, or automation being disabled), including which containers and resources were affected.

  **Changed:**

  * The default timeout for requests to the Kubex API increased from 30 seconds to 60 seconds.
</Accordion>

<Accordion title="1.8.0 - July 22, 2026">
  ### Breaking

  * **[GPU enablement defaults and experimental contract](./BREAKING.md#2026-07-20---gpu-enablement-defaults-and-experimental-contract)**: GPU request actions now default to disabled. `spec.enablement.gpu.requests.downsize`, `.upsize`, and `.setFromUnspecified` changed from `true` to `false`. The GPU/KAI experimental contract changed to `v1alpha1-2026-07`; the previous contract is no longer accepted. Affects `AutomationStrategy`, `ClusterAutomationStrategy`, `GpuRebalancingPolicy`, `ClusterGpuRebalancingPolicy`, and `GpuConsolidationPolicy`.
  * After upgrading the CRDs, update `spec.experimental.gpuKaiContract` from `v1alpha1-2026-04` to `v1alpha1-2026-07` in every affected resource.
  * For `AutomationStrategy`/`ClusterAutomationStrategy`, explicitly set each desired GPU action under `spec.enablement.gpu.requests` to `true` if you rely on GPU request resizing. GPU policy kinds only need the contract update.
  * Reapply affected resources after making these changes.

  **Added:**

  * Rollback monitoring now reopens automatically when a newer replacement pod appears carrying the same recommendation and matching resources, so a pod recreated by eviction, in-place resize, or a manual restart resumes being tracked instead of starting a brand-new monitoring turn.
  * `RollbackPolicy`/`ClusterRollbackPolicy` gain `spec.enableMonitoringReopen` (default `true`) to opt out of this reopen behavior for a given policy.
  * Manifest-level resource sizing is now reported to the Kubex backend, giving visibility into a workload's declared (manifest) resources alongside its live/adopted values.
</Accordion>

<Accordion title="1.7.0 - July 14, 2026">
  **Added:**

  * Secondary/DR cluster mode for recommendation consumption from a primary cluster.
</Accordion>

<Accordion title="1.6.0 - July 06, 2026">
  **Added:**

  * KubeAI `Model` workload support for automated rightsizing and rollback tracking.
  * GPU-sharing tuning controls for KAI-based automation strategies.
  * Container-level skip controls for rightsizing, so specific containers can be excluded without blocking resize actions for the rest of the pod.

  **Changed:**

  * Default policy evaluation now includes KubeAI `Model` workloads when `workloadTypes` is not set.
  * VPA-aware resize handling is more consistent across live workloads.

  **Fixed:**

  * Helm uninstall reliability for charts using rightsizing resources.
  * GPU rightsizing and validation stability.
  * In-place resized pods now retain the pod-rightsizing-info annotation so live pod state stays observable.
</Accordion>

<Accordion title="1.5.0 - June 23, 2026">
  **Added:**

  * KubeAI `Model` workload support, including owner-scoped recommendation and rollback state handling.
  * KAI/vLLM tuning controls for GPU-sharing automation strategies.

  **Changed:**

  * Default policy workload scope now includes KubeAI `Model` objects when `workloadTypes` is omitted.
  * Rollback monitoring now enforces adoption-threshold behavior more consistently.
  * Agentic Proposal sync remains opt-in through `GlobalConfiguration` and is disabled by default.

  **Fixed:**

  * Helm uninstall reliability by aligning the pre-delete cleanup hook permissions with the rightsizing resources it patches.
</Accordion>

<Accordion title="1.4.0 - June 11, 2026">
  **Added:**

  * Initial formal release of the integration with the KAI scheduler for rightsizing fractional GPUs

  **Changed:**

  * KAI documentation, examples, and release notes were updated for the `v1.4.0` release
</Accordion>

<Accordion title="1.3.1 - June 09, 2026">
  **Changed:**

  * Default policy evaluation now gives `RollbackPolicy` and `ClusterRollbackPolicy` the highest precedence.
</Accordion>

<Accordion title="1.3.0 - June 04, 2026">
  **Added:**

  * Introduced Rollback automation so clusters can now use the rollback state machine in live environments.

  **Changed:**

  * Rollback owner/runtime handling and e2e fixtures were updated to support the new rollback flow.

  **Fixed:**

  * Live rollback e2e instability caused by synthetic state seeding.
</Accordion>

<Accordion title="1.2.0 - June 02, 2026">
  **Added:**

  * Webhook/client behavior improvements that make policy admission and reconciliation more resilient.

  **Changed:**

  * Webhook reconciliation now uses informers/client behavior tuned for more reliable event handling.
  * GPU-related e2e and policy behavior was refined for stability and consistency.
  * Chart/docs content was updated to reflect the current release flow and user-facing guidance.

  **Fixed:**

  * Webhook error handling paths that could surface avoidable failures.
  * Miscellaneous release-blocking regressions from the beta cycle.
</Accordion>

<Accordion title="1.1.0 - May 26, 2026">
  **Added:**

  * PodAffinityPolicy automation for supported workload types, including preferred node placement rules
  * StrimziPodSet workload support for automating Strimzi-managed Kafka pods
  * Prometheus scraping support for controller metrics with a chart-managed metrics service and optional ServiceMonitor
  * Added experimental support for GPU sharing using the KAI scheduler

  **Changed:**

  * GPU proactive policies can use `gpuOverallOptimal` recommendations from KAI for overall GPU optimization
  * Resize summaries now show when recommendations were clamped to configured resource bounds
</Accordion>

<Accordion title="1.0.0 - May 07, 2026">
  **Changed:**

  * No customer-facing changes in this release.
</Accordion>

<Accordion title="0.4.0 - May 05, 2026">
  **Added:**

  * Namespace-level pause controls using the `rightsizing.kubex.ai/pause-until` annotation so automation can be paused across an entire namespace without annotating each pod individually
</Accordion>

<Accordion title="0.3.0 - May 01, 2026">
  **Added:**

  * Time-based automation scheduling with configurable windows including all-day support, overnight windows, and 24:00 explicit end time
  * Policy snapshot uploads to Kubex gateway via automation-gateway with configurable intervals

  **Changed:**

  * VPA resizing now requires active VPA recommendation conditions before allowing resize plans to prevent premature operations

  **Fixed:**

  * Stale owner recommendation cleanup flow for missing automation strategies
  * Overlapping exclusion window handling by jumping to the latest end time
  * Startup policy rescan now triggers automatically after readiness opens
</Accordion>

<Accordion title="0.2.1 - April 01, 2026">
  **Added:**

  * Configurable webhook probe pod settings via GlobalConfiguration including image selection
  * ImagePullSecrets and securityContext support for enhanced security configuration
  * GlobalConfiguration singleton enforcement via validating webhook to prevent multiple instances

  **Fixed:**

  * Case-insensitive HPA kind detection to match HPA targets regardless of casing
  * Guaranteed QoS resize plan calculation to correctly normalize requests and limits
</Accordion>

<Accordion title="0.2.0 - March 01, 2026">
  **Added:**

  * Guaranteed QoS support with `retainGuaranteedQOS` flag to enforce requests==limits constraint

  **Fixed:**

  * Webhook retry handling to properly manage too-many-requests scenarios
  * Resize method preservation in retry scenarios to maintain consistency across retries
  * Workload-to-policy namespace matching to ensure correct policy application
</Accordion>

<Accordion title="0.1.3 - February 01, 2026">
  **Added:**

  * Per-container enablement bounds to set different resource floor and ceiling limits for individual containers within a pod

  **Fixed:**

  * Webhook validation for inherited automation strategy bounds to ensure proper constraint enforcement
</Accordion>

<Accordion title="0.1.2 - January 15, 2026">
  **Added:**

  * Webhook validation for policy automation strategy references to ensure referential integrity
  * Protection against deleting automation strategies that are actively referenced by policies

  **Fixed:**

  * ENABLE\_WEBHOOKS flag parsing to correctly interpret as boolean value
</Accordion>

<Accordion title="0.1.1 - January 01, 2026">
  **Changed:**

  * Rebranded from previous name to Kubex

  **Fixed:**

  * Workload-to-policy namespace matching to ensure policies are applied to correct workloads
</Accordion>

### Legacy Kubex Automation Controller Release Notes

<Note>
  The Kubex Automation Controller has been deprecated and replaced by the Kubex Automation Engine.
</Note>

The Kubex Automation Controller automatically implemented Kubex's optimization recommendations for Kubernetes workloads.

<Accordion title="1.0.13 - February 6, 2026 (Patch)">
  **Valkey Helm & OpenShift Compatibility Fixes:**

  * Provided complete security contexts to resolve Helm `coalesce.go:298` warnings for `valkey.podSecurityContext` and `valkey.securityContext`.
  * Added initContainer resource requests/limits to satisfy OpenShift admission requirements.
  * Removed fixed UIDs/GIDs from valkey for OpenShift SCC compatibility.

  **VPA Exclusion to Prevent Autoscaler Conflicts:**

  * Automatic VerticalPodAutoscaler (VPA) detection and exclusion to prevent Kubex Automation from competing with VPA for resource management.
  * Prevents conflicts between VPA and Kubex automation.
</Accordion>

<Accordion title="1.0.12 - January 28, 2026 (Patch)">
  **OpenShift anyuid Requirement Removed:**

  * Removed OpenShift SCC rolebinding configuration-no longer requires `anyuid` for Kubex Automation Controller.
</Accordion>

<Accordion title="1.0.11 - January 27, 2026 (Patch)">
  **OpenShift Support & Valkey Storage Update:**

  * Added OpenShift support for Kubex Automation Controller.
  * Removed default valkey storage settings-now ephemeral by default.
</Accordion>

<Accordion title="1.0.10 - January 22, 2026 (Patch)">
  **Service Account Metadata & Logging Improvements:**

  The following improvements have been made in this release:

  * **Human-readable timestamps for automation logs**--All automation logs now use clear, human-readable timestamps, improving readability, troubleshooting, and auditability.
  * **Support for user-defined metadata on service accounts**--Users can now attach additional, custom metadata to service accounts.
</Accordion>

<Accordion title="1.0.9 - December 19, 2025 (Minor)">
  **Simplified Certificate Management:**

  Streamlined deployment by changing the default certificate method, making cert-manager optional rather than required.

  * **Easier Installation**--Reduced deployment complexity and external dependencies by no longer requiring cert-manager by default.
  * **Flexible Options**--Continue to choose from self-signed certificates, cert-manager integration, or bring-your-own-certificate based on your environment requirements.

  **Performance Enhancements:**

  Optimized default settings for Kubernetes 1.33+ clusters to take advantage of in-place resizing capabilities, significantly reducing time-to-optimization.

  **Enhanced Visibility:**

  In-place resizing operations are now visible in the Kubex UI, providing better insight into automation activities and outcomes.
</Accordion>

<Accordion title="1.0.8 - December 12, 2025 (Patch)">
  **Configurable Wait-for-Valkey Image:**

  Added support for overriding the wait-for-Valkey init container image to accommodate environments with restricted access to public container registries.

  * **Private Registry Support**--Organizations that cannot pull images from public repositories can now configure the automation controller to use images hosted in their private registries.
  * **Image Location Override**--The `waitForValkeyImage` configuration option allows specifying a custom image location (default: `busybox:latest`), enabling deployment in air-gapped or restricted network environments.
  * **Flexible Deployment**--This enhancement ensures the automation controller can be deployed in security-hardened environments where all container images must be sourced from approved internal registries.
</Accordion>

<Accordion title="1.0.7 - December 11, 2025 (Major)">
  **In-Place Pod Resizing Support:**

  The Kubex Automation Controller now supports Kubernetes In-Place Pod Resizing for eligible workloads running on Kubernetes 1.33 or higher. This capability enables resource adjustments without pod restarts, eliminating downtime during optimization.

  * **Zero-Downtime Resizing**--Containers are resized in-place without eviction when supported by the cluster, ensuring continuous availability for critical workloads.
  * **Automatic Fallback**--For clusters that don't support in-place resizing or workloads that require pod recreation, the controller automatically falls back to the traditional pod eviction method.
  * **Kubernetes 1.33+ Required**--In-place resizing requires Kubernetes 1.33 or later with the InPlacePodVerticalScaling feature gate enabled.

  **Enhanced Logging and Action Visibility:**

  Pod scan logs have been significantly improved to provide clear summaries of the actions taken by the automation controller. Each log entry now clearly indicates the action taken and the reason:

  * **RESIZED**--Pod was successfully resized using in-place resizing (zero downtime).
  * **EVICTED**--Pod was evicted and recreated with new resource specifications (traditional method).
  * **BLOCKED**--Pod could not be resized, with detailed blocking reasons explaining why (e.g., `hpa_conflict_cpu`, `limit_range_violation`, `resource_quota_exceeded`, `node_size_insufficient`, `manual_pause_infinite`).
  * **SKIPPED**--Pod is already sized at the recommended specification, no action needed.

  These enhanced logs make it easier to monitor automation activity, troubleshoot issues, and understand why specific pods were not optimized.

  **Annotation-Based Automation Control:**

  Administrators can now use Kubernetes annotations to control automation behavior at the pod or workload level using the `rightsizing.kubex.ai/pause-until: "<RFC3339 timestamp | infinite>"` annotation:

  * **Learning Periods**--Pause automation temporarily after application changes or deployments to allow the system to gather sufficient metrics before optimizing. Specify an RFC3339 timestamp to pause until a specific date.
  * **Permanent Exclusions**--Permanently exclude specific workloads from automation by setting the annotation value to `infinite`, providing granular control over which resources are managed by Kubex.

  Additionally, the controller now respects the `cluster-autoscaler.kubernetes.io/safe-to-evict=false` annotation, ensuring that pods marked as unsafe to evict are never evicted by the automation controller, even when optimization recommendations are available.

  This annotation-based approach integrates seamlessly with GitOps workflows and provides declarative control over automation scope. See [Pausing Automation for Specific Pods](https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-controller/docs/Advanced-Configuration.md#pausing-automation-for-specific-pods) for detailed usage examples.

  **Simplified Scope Configuration:**

  The `podLabels` field in the Helm values scope configuration is now optional, simplifying deployment for users who want to enable automation across entire namespaces without label-based filtering.

  * Previously, `podLabels` was mandatory and required explicit configuration even when not needed.
  * Now, you can define scope using only `namespace` for namespace-wide automation, or combine `namespace` with optional `podLabels` for more granular control.

  **Optimized Startup and Scan Intervals:**

  The controller's pod scanning behavior has been enhanced to balance responsiveness with efficiency:

  * **Quick Initial Scan**--The first scan now executes 2 minutes after controller startup (default), allowing rapid initialization and faster time-to-value.
  * **Configurable Regular Interval**--Subsequent scans run at the configured interval, providing predictable automation cadence.
  * **Reduced Startup Delay**--Previously, users had to wait for the full scan interval before the first automation actions occurred.

  These improvements ensure new deployments are evaluated quickly while maintaining efficient resource utilization for ongoing operations. See [Pod Scan Configuration](https://github.com/densify-dev/helm-charts/blob/master/charts/kubex-automation-controller/docs/Pod-Scan-Configuration.md) for guidance on configuring scan intervals based on automation scope and cluster size.

  **Infrastructure and Stability Improvements:**

  * **Increased API Timeout**--API timeout values have been increased to handle slower Kubex API responses during peak loads, preventing unnecessary automation failures.
  * **Updated cert-manager Dependency**--The cert-manager version has been updated to the latest stable release, ensuring compatibility with modern Kubernetes clusters and improving certificate management reliability.
</Accordion>

<Accordion title="1.0.6 - December 9, 2025 (Patch)">
  **Webhook Configuration Optimization:**

  Optimized the mutating webhook configuration by removing the UPDATE operation, ensuring the webhook only triggers on pod creation events.

  * **Reduced Webhook Invocations**--The mutating admission controller now only intercepts pod creation events, eliminating unnecessary processing during pod updates.
  * **Improved Cluster Performance**--Reducing webhook triggers decreases API server load and improves overall cluster responsiveness.
</Accordion>

<Accordion title="1.0.5 - November 28, 2025 (Patch)">
  **In-Place Resizing RBAC Support:**

  Added Kubernetes RBAC (Role-Based Access Control) permissions required for in-place pod resizing functionality. This update prepares the controller for the in-place resizing feature, which was still in development at the time of this release.

  * **Future Feature Preparation**--RBAC rules have been added to grant the controller the necessary permissions to perform in-place pod resource updates when the feature becomes generally available.
  * **No Functional Changes**--This release focuses on infrastructure readiness; the in-place resizing feature itself was introduced in version 1.0.7.
</Accordion>

<Accordion title="1.0.4 - November 4, 2025 (Minor)">
  **External Secret Management Support:**

  Added support for external secret management tools, providing greater flexibility and security for enterprise deployments.

  * **External Secrets Integration**--The Helm chart now supports working with secrets created and managed by external secret management tools (e.g., External Secrets Operator, Sealed Secrets), rather than requiring the chart to create secrets internally.
  * **Enhanced Security Posture**--Organizations can now leverage their existing secret management workflows and tools, ensuring secrets are handled according to enterprise security policies and compliance requirements.
  * **Customer-Driven Enhancement**--This feature was developed based on customer feedback to support real-world enterprise deployment scenarios where centralized secret management is required.

  **Flexible Namespace Deployment:**

  Removed namespace restrictions, allowing the Kubex Automation Controller to be deployed in any namespace.

  * **Arbitrary Namespace Support**--The Helm chart can now be deployed in any namespace, not just predefined ones, providing greater flexibility for multi-tenant environments and organizational policies.
  * **Improved Secret Management**--Namespace flexibility complements external secret management by allowing secrets to reside in different namespaces according to security boundaries and access control requirements.
  * **Simplified Multi-Cluster Deployments**--Organizations with standardized namespace naming conventions can now deploy the controller consistently across multiple clusters without chart modifications.
</Accordion>

<Accordion title="1.0.3 - October 31, 2025 (Patch)">
  **Environment Variable Enhancements:**

  Added release namespace information to relevant environment variables, improving namespace-aware operations.

  * **Namespace Context**--Environment variables now include the release namespace, enabling better multi-namespace deployments and troubleshooting.
  * **Improved Configuration**--Simplifies configuration in multi-tenant environments where multiple instances of the controller run in different namespaces.
</Accordion>

<Accordion title="1.0.2 - October 21, 2025 (Major)">
  **Valkey Integration for Recommendation Storage:**

  Replaced the persistent volume claim (PVC) requirement with Valkey (Redis-compatible) for storing optimization recommendations, simplifying deployment and improving scalability.

  * **Simplified Deployment**--Eliminates the need for persistent storage configuration, reducing deployment complexity and storage management overhead.
  * **Improved Performance**--Valkey provides fast in-memory data access for recommendation retrieval, improving controller response times.
  * **Enhanced Scalability**--In-memory storage enables better horizontal scaling capabilities for large-scale deployments.

  **Automated Pod Eviction and Resizing:**

  This release introduces the core Kubex Automation Controller deployment, which automatically manages container resource optimization through intelligent pod scanning and eviction.

  * **Automated Pod Scanning**--The controller continuously scans all pods within the configured scope, evaluating them for optimization opportunities based on Kubex recommendations.
  * **Pre-Eviction Safety Checks**--Before resizing any pod, the controller runs a comprehensive series of checks to ensure safe eviction, including:
    * Validation of workload owner types and controller compatibility
    * HPA (Horizontal Pod Autoscaler) conflict detection
    * Resource quota and limit range compliance
    * Pod disruption budget (PDB) verification
    * Policy specification compliance to verify automation is allowed
  * **Intelligent Pod Eviction**--When a pod passes all safety checks, the controller performs controlled eviction, allowing the mutating admission controller to automatically apply optimized resource specifications when the pod is recreated.
  * **Scope-Based Control**--Administrators define automation scope through Helm values, specifying namespaces and optional pod labels to control which workloads are managed by the automation controller.
</Accordion>

<Accordion title="1.0.1 - August 22, 2025 (Patch)">
  **Security and Infrastructure Improvements:**

  This release focuses on security enhancements and infrastructure improvements for the Kubex Automation Controller deployment.

  * **Gateway Resource Management**--Added resource requests and limits for the gateway container, ensuring predictable resource allocation and preventing resource contention in production environments.
  * **Enhanced Secret Security**--Improved secret handling by switching from environment variables to volume mounts, reducing the risk of secret exposure through process listings and container inspection.
  * **Automated CA Bundle Management**--The webhook configuration now automatically extracts the CA bundle from TLS secrets, eliminating the need for manual CA bundle configuration and reducing deployment complexity.
  * **Simplified Configuration**--Removed the manual `caBundle` dependency from `values-edit.yaml`, streamlining the Helm chart configuration process.
  * **Improved Documentation**--Enhanced certificate generation documentation with detailed examples for multiple certificate creation methods, including OpenSSL, CFSSL, and Bring Your Own Certificate (BYOC) scenarios.
</Accordion>

<Accordion title="1.0.0 - June 25, 2025 (Major)">
  **Initial Kubex Automation Controller Release:**

  This inaugural release introduces the Kubex Automation Controller, rebranded from the Mutating Admission Controller to reflect broader automation capabilities.

  * **Helm Chart Deployment**--Packaged as a Helm release for simplified installation and management.
  * **Automated Setup Script**--Quick deployment script automates setup, including cert-manager installation.
  * **Split Architecture**--Redesigned with separate containers for core webhook logic and secure API communication.

  **Security and Control Features:**

  * **Enhanced Security**--Encrypted credentials, non-root container execution, and seccomp profiles enabled by default.
  * **Selective Automation**--Ability to include or exclude specific workload types (e.g., Deployment, StatefulSet) from automation.
  * **Offline Resilience**--Mutations are cached locally during connectivity issues and synchronized when connection is restored.
</Accordion>


# Container Data Collector
Source: https://docs.kubex.ai/docs/WebHelp_Densify_Cloud/Content/Release_Notes/release_notes_k8s_data_collector



This section lists new features and updates to the Container Data Collector.

A Helm chart bundles all of the components required for container data collection and automates the process. See [Kubex Collection Stack](https://github.com/densify-dev/helm-charts/tree/master/charts/kubex-automation-stack) for details for a single-cluster configuration.

Refer to [Github repository](https://github.com/densify-dev/container-data-collection/blob/main/README.md) for samples and configuration files for multi-cluster configurations.

When deploying the Container Data Collector ensure that the same version is deployed for all of your clusters. See [Data Collection for Containers](../Data_Collection_for_Public_Cloud_Systems/Container_Data_Collection_Overview)

<Accordion title="4.4.0 - March 23, 2026">
  <Accordion title="Ephemeral Storage metrics">
    Introduced ephemeral storage metrics collection (opt-in)

    * Enables support for ephemeral storage analysis and recommendations
  </Accordion>

  <Accordion title="Node Group Detection">
    Added enhanced node group detection using:

    * Kubernetes labels
    * OpenShift machine sets
    * Node roles
  </Accordion>
</Accordion>

<Accordion title="4.3.0 - November 28, 2025">
  <Accordion title="Google Managed Prometheus (GMP) Support">
    This release adds support for collecting data from Google Managed Prometheus (GMP), which is the only supported method for data collection from GKE Autopilot clusters.

    * **GKE Autopilot Compatibility**--GMP is now fully supported, enabling data collection from GKE Autopilot clusters where traditional Prometheus deployments are not possible.
    * **Managed Service Integration**--Leverages Google's managed Prometheus service for seamless data collection without requiring in-cluster Prometheus installations.
  </Accordion>

  <Accordion title="Enhanced Job Configuration">
    * **backoffLimit Support**--The data collector now supports configuring `backoffLimit` for both Job and CronJob resources, providing better control over retry behavior when data collection encounters transient failures.
  </Accordion>
</Accordion>

<Accordion title="4.2.2 - June 16, 2025">
  <Accordion title="Added GPU Metrics">
    This update collects additional GPU metrics.

    * The following GPU metrics are now collected for Containers:

      <table>
        <col />

        <col />

        <tbody>
          <tr>
            <td>
              <ul>
                <li>
                  GPU Utilization in GPUs - Average Container\*
                </li>

                <li>
                  GPU Utilization in Percent - Average Container\*
                </li>

                <li>
                  GPU Memory Utilization in MB - Average Container\*
                </li>

                <li>
                  GPU Memory Utilization (%) - Average Container\*
                </li>

                <li>
                  GPU Power Usage (W) - Average Container\*
                </li>
              </ul>
            </td>

            <td>
              <ul>
                <li>
                  GPU Utilization in GPUs - Busiest Container
                </li>

                <li>
                  GPU Utilization in Percent - Busiest Container
                </li>

                <li>
                  GPU Memory Utilization in MB - Busiest Container
                </li>

                <li>
                  GPU Memory Utilization (%) - Busiest Container
                </li>

                <li>
                  GPU Power Usage (W) - Busiest Container
                </li>
              </ul>
            </td>
          </tr>
        </tbody>
      </table>
    * The following GPU metrics are now collected for nodes:

      <table>
        <col />

        <col />

        <tbody>
          <tr>
            <td>
              <ul>
                <li>
                  GPU Utilization( GPUs)
                </li>

                <li>
                  GPU Utilization(%)\*
                </li>

                <li>
                  GPU Memory Utilization (MB)
                </li>

                <li>
                  GPU Memory Utilization (%)\*
                </li>

                <li>
                  GPU Power Usage (W)\*
                </li>
              </ul>
            </td>

            <td>
              <ul>
                <li>
                  GPU Requests (GPU)
                </li>

                <li>
                  GPU Limit (GPU)
                </li>
              </ul>
            </td>
          </tr>
        </tbody>
      </table>

      Only those metrics indicated with an asterisk(\*) are displayed in the current Kubex user interface. The remaining metrics will be covered in a future release.
  </Accordion>

  <Accordion title="Updated Helm Charts">
    The Helm charts have been updated as follows:

    * All-In-One Kubex Collection Stack has been updated to version 0.9.8;
    * The chart containing only the data forwarder has been updated to version 4.0.6.

    These updates address the following issues:

    * The metrics that are retained in Prometheus are now limited to only the metrics that Kubex requested. This change reduces the resources consumed by Prometheus, in large clusters.
    * Both the pod security context and container security context are now set for all of the AIO chart components, including the Kubex data forwarder, Prometheus, Node exporter etc. This includes using the runtime default seccomp profile, running as a non-root user, no privileges for escalation, mounting the root file system as read-only, etc.
    * A sizing option for Prometheus resources, has been added. The size is based on the cluster size.
    * The Prometheus subchart has been updated to the latest version.
    * The Prometheus scrape configuration has been updated to use the k8s endpointslice. The endpoints that the data forwarder was using were deprecated in the K8s v1.33 API and will be removed in a future release. Endpointslice has been available since K8s v1.21.
    * Installation instructions for offline (or air-gapped) mode are now provided.

    See [Kubex Collection Stack](https://github.com/densify-dev/helm-charts/tree/master/charts/kubex-automation-stack) for details. Ensure that your helm chart has been upgraded to the latest version, using the helm `upgrade` command.
  </Accordion>
</Accordion>

<Accordion title="4.2.1 - May 29, 2025">
  This update contains an upgrade for Go to 1.24 for all package dependencies. This upgrade eliminates security scan warnings preventing some customers from upgrading their data forwarder to the latest version.
</Accordion>

<Accordion title="4.2.0 - May 15, 2025">
  This update adds support for **NVIDIA GPU metrics** and HPA:

  <Accordion title="Collection of NVIDIA GPU Metrics">
    NVIDIA GPU Metrics--With this update, the Kubex data forwarder now collects GPU data from your Kubernetes clusters.

    The analysis and display of the collected metrics will be provided in a future release of Kubex.

    Note the following additional prerequisites to collect the GPU data:

    * NVIDIA-device-plugin--This plugin allows containers to access the NVIDIA GPUs. It must be installed on all your Kubernetes clusters to allocate NVIDIA GPU resources to workloads and to provide the GPU data.
    * dcgm-exporter--This Prometheus exporter exposes GPU metrics from the Data Center GPU Manager (DCGM). It is required to collect GPU data such as, utilization, memory usage, and power usage from NVIDIA GPUs, The dcgm-exporter can be deployed as a DaemonSet, where each node with an NVIDIA GPU runs a pod that exposes these metrics in a format that Prometheus can scrape and the Kubex data forwarder then collects.

    The GPU data collection is currently supported on the following platforms:

    * AKS
    * EKS
    * GKE
  </Accordion>

  <Accordion title="HPA Updates">
    **HPA Scales Based on Multiple Metrics**--With this update Kubex recommendations are not implemented for any containers enabled for HPA that scale based on single or multiple metrics, that are also enabled for automation using the Kubex Automation Engine.

    Previously Kubex did not support HPA-based on multiple metrics.
  </Accordion>

  <Accordion title="Updated Kubex Collection Stack">
    The [Kubex Collection Stack](https://github.com/densify-dev/helm-charts/tree/master/charts/kubex-automation-stack) has been updated to collect data from the NVIDIA DCGM exporter. You must ensure that your helm chart has been upgraded to the latest version (0.9.6) to get GPU data. You will get the updates automatically if you have the following settings, in the data forwarder cronJob specification:

    * image: densify/container-optimization-data-forwarder:4
    * imagePullPolicy: Always

    If the settings are not configured as above, then you need to update the image, manually.
  </Accordion>
</Accordion>

<Accordion title="4.1.3 - April 1, 2025">
  This update resolves an issue with reporting a container's parent node and node groups.
</Accordion>

<Accordion title="4.1.2 - March 17, 2025">
  This update collects new container and node-level metrics to provide more accurate recommendations.

  Upgrade data forwarder v4.1.2 after upgrading to Kubex v2.10.0. New database columns have been added in v2.10.0 that are required by this version of the data forwarder for the new metrics and attributes.

  When updating the data forwarder, you need to ensure that the same version is deployed for all of your clusters.

  <Accordion title="Collection of New Metrics">
    The data forwarder has been updated to collect the following:

    * Horizontal Pod Autoscaler (HPA) target metrics--Three new attributes have been added.
      * hpa\_target\_metric\_name
      * hpa\_target\_metric\_type
      * hpa\_target\_metric\_value
    * Node taints--The configuration attribute and new metrics will be collected:
      * Added the multi-value attribute, “Node Taints” (attr\_NodeTaints)
    * QoS class--The configuration attribute and new metrics will be collected.
      * Added the attribute, Quality of Service Class” (attr\_QOSClass)
    * Node Working Set Memory Metrics--Working set memory is a process (or container) metric, rather than a node metric. It has been added to align with what is already shown in the AKS console. Kubex provides the following additional node memory metrics:
      * working set memory (in bytes)
      * working set memory utilization (percent)
      * memory utilization (percent) (based on memory\_bytes metric)
      * memory actual utilization (percent) (based on memory\_actual\_workload metric)
      * total node memory (in bytes) (configuration attribute)

    Kubex's container analyses will be updated in future releases to utilize this HPA data when generating recommendations.
  </Accordion>

  <Accordion title="Updated Node Identification">
    To improve the identification of a container's parent node, the `provider_id` has been introduced as a third identification component. Currently, nodes are identified using `cluster_name` and `node_name`.

    The `provider_id` is optional and will be used only if required. In Kubernetes clusters without a`provider_id`, node identification will continue to rely on `cluster_name` and `node_name`, ensuring that node IDs remain unchanged.

    Specifically, for EKS and OKE clusters, existing node IDs will change and as a result, node history will be lost since these nodes will receive new IDs.
  </Accordion>

  <Accordion title="Updated Configuration Setting">
    The data forwarder's configmap.yaml file has been updated. The setting, `node_group_list` has been updated to add `label_karpenter_sh_nodepool`. When enabled, Karpenter NodeGroups are discovered and created in Kubex.
  </Accordion>
</Accordion>

<Accordion title="4.1.1 - November 27, 2024">
  This update resolves an issue with reporting CPU and memory reservation percent for nodes, node groups and clusters.
</Accordion>

<Accordion title="4.1.0 - September 19, 2024 ">
  Version 4.1.0 collects new container and node-level metrics to provide more accurate container sizing recommendations.

  <Note>
    Node level metrics and some new container metrics are collected, but will not be available in the Kubex Console until the release of Kubex v2.6.
  </Note>

  <Accordion title="New Container Metrics">
    The following container metrics are now collected:

    * max\_cpu\_throttling\_percent--The Linux kernel allocates "CPU periods" (default = 100 milliseconds) to both processes and containers. The percentage is the number of throttled periods out of the total number of 100-ms periods. This value is a percentage of periods that were throttled vs those that were requested. This provides a more accurate indication of resource limitations.

      For example if the pod was throttled for 8 seconds out of the 5 minutes, this would be 2.7%, but if the CPU was not actually requested for the full 5 minutes, then the 2.7% is not an accurate representation of the state of the container. If the pod was throttled for 8 seconds, and it's request was less that than the 300 seconds the throttled percentage is higher.
    * avg\_cpu\_throttling\_percent--Indicates the average percentage of the number of 100-ms periods that a container is throttled in terms of CPU usage.

      The average and maximum values are collected since the container is likely aggregated. Metrics are aggregated at the highest level of the pod owner. For a deployment of one pod in one container the average and maximum will be the same. If it is a deployment of 10 pods then the average and maximum will not be the same.
    * sum\_cpu\_throttling\_seconds--Aggregates the total time during which throttling has been applied.
    * Container Events--These are not metrics that are collected at 5-minute intervals, but are individual events and the time that the event occurred or was detected. In this version of the data forwarder "process exit" is now collected. The exit code and whether or not this is the main process (i.e. PID #1 using a true/false flag) of the container is collected and stored. In this version process exit will be false only when PID #1 exits with code 137 which corresponds to an OOM kill. In all other cases, process exit will be true.

    CPU and memory request and limit values at the top of the hour are already collected and stored as attributes, once per day. In this release the data forwarder collects the following metrics at 5-minute intervals:

    * CPU Limit--The defined CPU allocation limit for the container.
    * Memory Limit--The defined memory allocation limit for the container.
    * CPU Request--The defined CPU allocation requested for the container.
    * Memory Request--The defined memory allocation requested for the container.

    You must have Kubex v2.5, to see these new metrics in the Container Details report and metrics viewer. See [Optimizing Your Containers - Details Tab](../Densify_Com/Optimizing_Your_Containers_-_Details_Tab#Tabular_Report) and [Using the Metrics Viewer for Containers](../Densify_Com/Using_the_Metrics_Viewer-Containers).
  </Accordion>

  <Accordion title="Node-Level Metrics">
    Kubex currently sets configuration attributes with both the node-level and container-level CPU, memory request and limit values from the top of the hour. This provides a point in time data point that allows you to see how a node’s request and limit values move during the day.

    In this release the data forwarder collects the following metrics at 5-minute intervals:

    * CPU Limit--The defined CPU allocation limit for the node.
    * Memory Limit--The defined memory allocation limit for the node.
    * CPU Request--The defined CPU allocation requested for the node.
    * Memory Request--The defined memory allocation requested for the node.
    * Pod Count--The number of pods running on the selected node.

    If values have not been specified this will be indicated.

    The following node events are collected at 5-minute intervals:

    * oom\_kill\_events--The number of kill events that happened on the node in a 5-minute interval;
    * cpu\_throttling\_events--The number of CPU throttling events that happened on the node in a 5-minute interval;

    The following metrics are calculated from the raw data:

    * cpu\_reservation\_percent--The percentage of the node's total CPU resources that are reserved or guaranteed for workloads, containers, or virtual machines.
    * memory\_reservation\_percent--The percentage of the node's total memory resources that are reserved or guaranteed for workloads, containers, or virtual machines.

    The following configuration details are now collected and stored in attributes:

    * provider\_ID--The provider\_id is available as a Prometheus label of kube\_node\_info metric which is extracted to its own column in the k8s\_node\_v0 postgres table. The relevant node data is then used to facilitate link the Kubernetes node to a cloud instance. This linking will be done in postgres, as will the determination of the relationship between cloud instance and ASGs or VM Scale Sets.
    * k8s\_version--The Kubernetes version of the node is collected and stored in the attribute, k8s\_node.

      This value is collected for each node and for the cluster. This is currently informational only and is not used not used in the analysis.

    The features allowing you to view node details will be provided in Kubex v2.6.
  </Accordion>

  <Accordion title="Cluster-Level Metrics">
    The Kubernetes version of the cluster is collected and stored in the attribute, k8s\_cluster. This is the version of the control plane/API server. It can be higher than those of the nodes in cases where the control plane was upgraded and the nodes have not yet been updated. This is used when determining OOM kills for Kubernetes versions older than 1.28.
  </Accordion>

  <Accordion title="Linking Containers to Node Groups">
    Containers will now be linked to their node group using a provider ID that is populated by each public cloud provider's Kubernetes offerings (i.e. EKS, AKS and GKE). The provider\_id attribute is passed to the kubelet.

    The provider\_id is available as a Prometheus label of kube\_node\_info metric which is extracted to its own column in the k8s\_node\_v0 postgres table. The relevant node data is then used to facilitate linking the Kubernetes node to a cloud instance. This will be done in postgres, as will the relationship between cloud instance and ASGs or VM Scale Sets.
  </Accordion>
</Accordion>

<Accordion title="4.0.0 - May 28, 2024 ">
  Version 4 introduces significant updates to Kubex's container data collection solution. This version resides in a new [Github repository](https://github.com/densify-dev/container-data-collection/blob/main/README.md).

  While the core PromQL queries remain the same, with the exception of some improvements and bug fixes, the data forwarder has been re-architected to support multi-cluster data collection.

  You can upgrade from version 2.x or 3.x to version 4.0. You need to update the image tag to "4":

  * image: densify/container-optimization-data-forwarder:4
  * imagePullPolicy: Always

  When updating the data forwarder, you need to ensure that the same version is deployed for all of your clusters.

  See [Data Collection for Containers](../Data_Collection_for_Public_Cloud_Systems/Container_Data_Collection_Overview) for details of configuring the connection.

  <Accordion title="Supported Third Party Observability Platforms">
    In addition to Prometheus, third party observability platforms are supported. Commercially-available observability platforms do not need to reside within a cluster and can be used to monitor multi-cluster environments. The observability platform must support the Prometheus API and one of the following authentication mechanisms:

    * HTTP basic authentication--Supported by Prometheus and is required by some commercial observability platforms, i.e. [Grafana Cloud](https://grafana.com/docs/grafana-cloud/cost-management-and-billing/analyze-costs/metrics-costs/prometheus-metrics-costs/usage-analysis-api/);
    * Bearer token--Required by [OpenShift Monitoring](https://access.redhat.com/documentation/en-us/openshift_container_platform/4.14/html/monitoring/accessing-third-party-monitoring-apis) and some commercial observability platforms, i.e. [Azure Monitor](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/prometheus-api-promql);
    * AWS SigV4--Required by [Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-secure-queryingl).

    If you are using Amazon Managed Service for Prometheus (AMP), an AWS role is required to associate the Kubernetes service account with Kubex for the purpose of container data collection. The additional required annotations can be added to your Helm charts.

    The following Prometheus dependencies are applicable:

    * AWS Managed Prometheus data ingestion requires Prometheus v2.26.0 or higher.
    * Starting with version 16.0, the Prometheus chart requires Helm 3.7 or higher, to install successfully.

    The following commercial observability platforms are supported:

    * Amazon Managed Service for Prometheus (AMP)--Refer to the [AWS website](https://docs.aws.amazon.com/prometheus/latest/userguide/indexl) for details on AMP. Kubex requires a specially configured role. See [Container Data Collection Using Amazon Managed Prometheus](../Data_Collection_for_Public_Cloud_Systems/Container_Data_Collection_Using_EKS_and_AMP) for configuration examples.
    * Azure Monitor Managed Service for Prometheus (AzMP)--Refer to the [Azure website](https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/prometheus-metrics-overview) for details. Kubex automates the process of acquiring and get and refreshing security tokens. See [Container Data Collection Using Azure Managed Service for Prometheus](../Data_Collection_for_Public_Cloud_Systems/Container_Data_Collection_Using_AzMP) for a configuration example.
    * [Grafana Cloud](https://grafana.com/products/cloud/)--See [Container Data Collection using Basic Authentication](../Data_Collection_for_Public_Cloud_Systems/Container_Data_Forwarder_Basic_Auth) for a configuration example.

    The following self-hosted OSS solutions are supported:

    <table>
      <col />

      <col />

      <tbody>
        <tr>
          <td>
            <ul>
              <li>
                <a href="https://thanos.io/">
                  Thanos
                </a>
              </li>

              <li>
                <a href="https://cortexmetrics.io/">
                  Cortex
                </a>
              </li>
            </ul>
          </td>

          <td>
            <ul>
              <li>
                <a href="https://grafana.com/oss/mimir/">
                  Grafana Mimir
                </a>
              </li>

              <li>
                <a href="https://prometheus.io/docs/prometheus/latest/federation/">
                  Prometheus Federation
                </a>
              </li>
            </ul>
          </td>
        </tr>
      </tbody>
    </table>
  </Accordion>

  <Accordion title="External Cluster Support">
    Version 4 collects data from external Prometheus servers. In this use case Prometheus runs outside the Kubernetes cluster, in which the data collection runs.
  </Accordion>

  <Accordion title="Multiple Kubernetes Clusters Support">
    Since Prometheus can now be run externally, you can now run a single job to collect data for multiple Kubernetes clusters from a single Prometheus server/observability platform. Using Prometheus labels, the job determines which data belongs to which cluster.
  </Accordion>

  <Accordion title="Added Memory Options for Container Data Collection">
    You now have the option to select "container\_memory\_working\_set\_bytes" in addition to "container\_memory\_usage\_bytes" or "container\_memory\_rss" for container data collection. This new metric allows you to determine how aggressively you want to optimize your container memory allocations, when analyzing your Kubernetes environments.

    Using the metrics, "container\_memory\_rss" and "container\_memory\_working\_set\_bytes" provides more aggressive recommendations that allow you to reclaim more memory. Using "container\_memory\_usage\_bytes" and "container\_memory\_rss" provide recommendations that will not result in downsizing recommendations that may lead to out-of-memory (OOM) issues.

    The corresponding workload charts were added to the Containers - Details Tab in v2.2.0. See [Optimizing Your Containers - Details Tab](../Densify_Com/Optimizing_Your_Containers_-_Details_Tab#Lower_Section)

    Contact <a href="mailto:support@kubex.ai">
    [support@kubex.ai](mailto:support@kubex.ai)</a>

    for details on selecting memory utilization for your container data collection.
  </Accordion>

  <Accordion title="Other Features">
    The following updates and bug fixes were made in this release:

    * HTTP retries have been added to the calls to the Prometheus API. This handles observability platform rate limiting.
    * The data forwarder now handles the relabel configs of Node Exporter.
    * Outdated Node Exporter metrics have been addressed.
    * Utilizes improved Horizontal Pod Autoscaler metrics (autoscaling v2).
    * The data forwarder has been upgraded to Go 1.22,
    * Updated examples for both single and multiple cluster configurations are provided in the new [Github repository](https://github.com/densify-dev/container-data-collection/blob/main/README.md).
  </Accordion>

  <Accordion title="End of Support Notice - Container Data Forwarder 3.x.x">
    Kubex will discontinue support of Container Data Forwarder versions 3.x.x on June 30, 2024. Contact <a href="mailto:support@kubex.ai">
    [support@kubex.ai](mailto:support@kubex.ai)</a> for details on migrating to Kubex's current version of the Container Data Forwarder.
  </Accordion>
</Accordion>


# Cloud Cost Estimation
Source: https://docs.kubex.ai/docs/WebHelp_Densify_Cloud/Content/cloud_cost_estimation

Understand how Kubex estimates cloud instance costs from provider list prices and optional billing data.

Kubex estimates cloud costs using CSP list prices based on the instance type, region, and software on the instance (such as Linux, Windows, or SQL Server). Instance uptime is also considered to provide accurate cost estimates.

## Enterprise Discounts

Enterprise discounts can be applied across all instances or scoped to a specific criteria, such as a defined set of accounts. Contact your account team to provide details of discounts in your cloud environment.

## Billing Data Integration

Kubex can also integrate with your billing data to produce more accurate instance costs that better reflect your bill and account for RIs, SPs, and enterprise discounts.

This integration is not enabled by default because it requires additional permissions to access billing data. Contact your account team to have it set up.


# Cloud Analysis Policy
Source: https://docs.kubex.ai/docs/WebHelp_Densify_Cloud/Content/cloud_policy

Configure and understand Kubex Cloud Analysis Policies for rightsizing, risk detection, scale optimization, and Kubernetes cluster recommendations.

# Cloud Analysis Policy

Cloud Analysis Policies define how Kubex evaluates cloud workloads and generates optimization recommendations. Policies control the analysis window, utilization thresholds, scaling constraints, Kubernetes reservation targets, and instance selection preferences.

These settings determine when Kubex recommends:

* **Upsizing** under-provisioned resources
* **Downsizing** over-provisioned resources
* **Terminating** unused instances
* **Optimizing** scale groups
* **Adjusting** Kubernetes cluster reservations
* **Migrating** to more efficient instance families or generations

<Frame>
  <img alt="" />
</Frame>

***

## Operational Windowing

The operational window determines which historical utilization data is included during analysis.

| Setting                   | Value                |
| ------------------------- | -------------------- |
| Workload Range            | 60 Days              |
| Include Weekends          | Yes                  |
| Include Samples Between   | 0 - 100th Percentile |
| Exclude Hours             | None                 |
| Minimum Data for Analysis | 1 Day / 1 Hour       |

### Configuration Details

#### Workload Range

Defines the historical period used for workload analysis.

**Current Setting:** `60 Days`

A longer analysis period captures seasonal trends and workload variability while reducing sensitivity to short-term spikes.

#### Include Weekends

Determines whether weekend utilization data is included.

**Current Setting:** `Yes`

#### Include Samples Between

Filters utilization samples to eliminate statistical outliers.

**Default Setting:** `0 - 100th Percentile`

#### Minimum Data Requirement

| Metric | Value |
| ------ | ----- |
| Days   | 1     |
| Hours  | 1     |

Kubex requires at least this amount of utilization data before generating recommendations.

***

# Resource Risk Detection

Resource Risk Detection identifies workloads that may be undersized and at risk of performance degradation.

Recommendations are generated when **any** configured threshold is exceeded.

## CPU Risk Thresholds

| Metric    | Threshold |
| --------- | --------- |
| Peak      | > 95%     |
| Sustained | > 85%     |
| Average   | > 75%     |

### Recommendation Logic

Kubex recommends an **Upsize** when:

```text theme={null}
Peak CPU > 95%
OR
Sustained CPU > 85%
OR
Average CPU > 75%
```

## Memory Risk Thresholds

| Setting            | Value |
| ------------------ | ----- |
| Evaluated Based On | Peak  |
| Threshold          | > 95% |

### Recommendation Logic

Kubex recommends an **Upsize** when:

```text theme={null}
Peak Memory Utilization > 95%
```

***

# Resource Inefficiency Detection

Resource Inefficiency Detection identifies workloads that are overprovisioned.

Recommendations are generated only when **all** configured conditions are satisfied.

## CPU Inefficiency Thresholds

| Metric           | Threshold |
| ---------------- | --------- |
| Peak             | \< 94%    |
| Sustained        | \< 84%    |
| Average          | \< 74%    |
| Maximum Decrease | 75%       |

### Recommendation Logic

Kubex recommends a **Downsize** when:

```text theme={null}
Peak CPU < 94%
AND
Sustained CPU < 84%
AND
Average CPU < 74%
```

The recommended decrease will never exceed:

```text theme={null}
75%
```

## Memory Inefficiency Thresholds

| Setting            | Value     |
| ------------------ | --------- |
| Evaluated Based On | Sustained |
| Threshold          | \< 95%    |
| Maximum Decrease   | 75%       |

### Recommendation Logic

Kubex evaluates sustained memory utilization and limits reduction recommendations to a maximum 75% decrease.

***

# Unused Instance Detection

Unused Instance Detection identifies workloads that can potentially be terminated.

Recommendations are generated only when all thresholds are met.

## CPU Thresholds

| Metric    | Threshold |
| --------- | --------- |
| Peak      | \< 20%    |
| Sustained | \< 10%    |
| Average   | \< 4%     |

## Memory Thresholds

| Setting            | Value   |
| ------------------ | ------- |
| Evaluated Based On | Peak    |
| Threshold          | \< 100% |

### Recommendation Logic

Kubex recommends a **Terminate** action when:

```text theme={null}
Peak CPU < 20%
AND
Sustained CPU < 10%
AND
Average CPU < 4%
```

This policy identifies workloads that demonstrate consistently negligible resource utilization.

***

# Scale Group Optimization

Scale Group Optimization controls how Kubex recommends adjustments for Auto Scaling Groups and similar scaling constructs.

## Configuration

| Setting          | Value    |
| ---------------- | -------- |
| Group Size       | 1 - 1000 |
| Allowed Decrease | 50%      |
| Allowed Increase | 100%     |

### Recommendation Constraints

Kubex will:

* Reduce scale groups by at most **50%**
* Increase scale groups by at most **100%**
* Analyze groups containing between **1 and 1000 instances**

## Tying Kubernetes Node Groups to the Scale Groups hosting them

When an AWS ASG or Azure ScaleSet hosts an EKS/AKS cluster, scale group optimization cannot rely on utilization metrics alone. Kubernetes CPU and memory requests must also be included in the analysis.

If Kubex is connected to the Kubernetes clusters, it can correlate scale groups with their node groups and produce actionable recommendations.

## CPU Request

| Setting            | Value     |
| ------------------ | --------- |
| Evaluated Based On | Sustained |
| Threshold          | > 90%     |

## Memory Request

| Setting            | Value     |
| ------------------ | --------- |
| Evaluated Based On | Sustained |
| Threshold          | > 90%     |

***

# Rule Engine

The Rule Engine controls how Kubex selects target instance types during optimization.

| Rule                    | Description                                                                                                       |
| ----------------------- | ----------------------------------------------------------------------------------------------------------------- |
| Optimize Family         | Allow alternative instance families when a more cost-effective or performant option exists                        |
| Generation Changes      | Permits migration between instance generations                                                                    |
| Favor Latest Generation | Prioritizes newer generation instance types when available                                                        |
| Older Architectures     | Allow recommendations to older CPU architectures                                                                  |
| Allow Flex Types        | Permits recommendations to flexible instance families where supported                                             |
| Intel ↔ AMD Migration   | Allows cross-architecture recommendations between Intel and AMD platforms when cost or performance benefits exist |
| Allow Storage Optimized | Enables recommendations to storage-optimized instance types when appropriate                                      |
| Allow Burstable         | Allows migration to burstable instance families for suitable workloads                                            |
| Keep Storage Optimized  | Stay on a storage optimized instance                                                                              |
| Keep Local Disk         | Kubex is allowed to recommend instance types without local storage                                                |
| Software Affinity       | Recommendations are not constrained by software-specific affinity requirements                                    |

***

# Recommendation Summary

With this policy configuration:

* Workloads at risk are upsized when CPU or memory utilization exceeds defined thresholds.
* Overprovisioned workloads are downsized based on CPU and memory efficiency rules.
* Nearly idle workloads are flagged for termination.
* Scale groups can shrink by up to 50% or grow by up to 100%.
* Instance recommendations can migrate across families, generations, and CPU vendors to maximize efficiency and cost savings.

This policy balances **performance protection**, **cost optimization**, and **infrastructure modernization** while maintaining operational flexibility.


# Amazon ECS Optimization
Source: https://docs.kubex.ai/docs/WebHelp_Densify_Cloud/Content/ecs_optimization

Optimize Amazon ECS tasks and services with Kubex recommendations for CPU and memory efficiency.

## Amazon ECS Optimization

Kubex continuously analyzes your Amazon Elastic Container Service (ECS) tasks and services to recommend the right CPU and memory settings. This helps reduce waste, prevent performance risk, and operationalize improvements across teams.

* End-to-end ECS optimization visibility: View actionable ECS recommendations across the Kubex UI, the MCP interface, and the Kubex AI Agent, all from a single platform
* Identify risk and waste in seconds: Ask natural-language questions with the Kubex AI Agent to pinpoint inefficiencies quickly, or review the full recommendation list in the ECS view
* Built for AI and automation workflows: Feed ECS optimization insights into your existing AI and automation workflows using the Kubex MCP interface, so recommendations appear where decisions are made

<Frame>
  <img alt="" />
</Frame>