Configuring Kyvos Native Compute Cluster from Kyvos Manager
You can change from an external compute cluster to Kyvos Native for processing semantic models through Kyvos Manager on the Compute Cluster page:
Important
From Kyvos 2025.3 onwards, you can process data on a dedicated compute cluster on all clouds.
Switching from Kubernetes, shared Query Engine, or External Compute (EMR, Dataproc, and Databricks) to a dedicated compute cluster is supported. You can switch it from Kyvos Manager on the Compute Cluster page.
If using a shared Kubernetes cluster with a dedicated user node pool, ensure that the user node pool has dedicated taints. refer to the Adding Taints and Configure Tolerations in Kyvos worker pods section.
For shared K8s cluster, provide the compute namespace that has already been created.
You can optionally use the K8s cluster on a shared basis (AWS, Azure, and GCP).
You can now increase or decrease the Kubernetes node pool Maximum Compute Server Count. This applies only to a dedicated node pool.
If you have deployed Kyvos with the Kyvos Native compute cluster, you cannot switch to the External Compute cluster to process semantic models.
Prerequisites for Kubernetes cluster to be used with Kyvos
The following are the prerequisites for the K8s cluster to be used with Kyvos.
The Kubernetes cluster must be in the same region in all cloud environments.
For GCP, the Kubernetes must be in the same project.
For Azure, the Kubernetes cluster is supported even in a different Resource Group.
Note
To fetch the Kubernetes cluster from a different resource group, ensure that Kyvos Managed Identity must have reader on that Kubernetes.
For shared K8s cluster, provide the compute namespace already created. Currently, only in the case of a dedicated (non-shared) K8s cluster will the system attempt to create a comput namespace with the provided name on Azure Enterprise.
Configure Kyvos Native Cluster configurations
To configure the Compute cluster, perform the following steps.
Click the cluster name > Kyvos and Ecosystem > Compute Cluster on the navigation pane to view this information.
The Compute Cluster page displays the two tabs:
Kyvos Native: To process the semantic model using Kyvos native, click this tab to select the containerized Kubernetes, Shared Query Engines, or Dedicated Compute as a compute cluster.
External: Click this tab to view the External compute cluster details.
Enter the details as:
Kyvos Native
External: To know more about the External Compute Cluster, see the Hadoop Ecosystem Configuration section.
Changing the default compute configurations
Note
By default, each semantic model is processed using the default compute type. If you want to override the compute type for a particular semantic model, change the value for the kyvos.process.compute.type property from the advanced semantic model property.
To process all of your semantic models using a different compute type, you can change the default compute configurations for all semantic models at once, rather than modifying each one individually. This approach eliminates the need to configure the property for each model separately.
You can Change the Node Pool Instance Type for Kyvos Enterprise (AWS, Azure, and GCP).
This functionality is only available for dedicated user node pool.
The option to delete the older node pool is available only for dedicated (non-shared) user node pool. If node pool deletion permissions are there, after selecting node pool deletion, it will be deleted automatically to avoid manual deletion of node pool from external to system.
If you are not deleting the older node pool, ensure to remove the taints from older node pool. If you want to configure new taints and toleration, then refer the Adding Taints and Configure Tolerations in Kyvos worker pods
The instance type configured for a node pool must be associated with a single instance type, even if multiple instance types are supported for the node pool in any cloud environment.
Changing the instance type for a Kubernetes (K8s) cluster node pool should only be supported for the node pool where Kyvos jobs will execute. Therefore, there will be no support for changing the instance type of any other node pool not configured in Kyvos. For Azure, only the user node pool will support instance type changes, while the system node pool will not support such changes.
For Azure, following permissions are required to change node pool instance type.
"Microsoft.ContainerService/managedClusters/agentPools/write",
"Microsoft.ContainerService/managedClusters/agentPools/read",
"Microsoft.ContainerService/managedClusters/agentPools/delete"
To support K8s cluster node pool instance type, change, add below required permissions to AWS Automated and Wizard based deployment IAM role.
Create Node Group
"eks:CreateNodegroup"
"eks:TagResource"
"iam:GetRole"
"ec2:DescribeKeyPairs"Delete Node Group
"eks:DeleteNodegroup"
To change the default compute cluster for the Kyvos semantic model, perform the following steps.
Click the cluster name > Kyvos and Ecosystem > Compute Cluster on the navigation pane to view this information.
On the Compute Cluster page, click the Click to change link on the right of the page. The following dialog box is displayed.
Select the required Default Compute Type from the list.
Enter your Kyvos Manager password.
Click Save. The default compute cluster is configured.
Creating a dedicated compute cluster
You can create a dedicated compute cluster either by downloading the JSON file or manually create a compute cluster.
For AWS
Supported dedicate compute instance types
Graviton: m6g.4xlarge
Non graviton: m5.4xlarge
Disk size: 250GB
Case 1: By downloading the ‘PostCreationDedicatedComputeAWS.json’ template
Note
If you use ARM architecture instances (Graviton) for Kyvos, you must also use them for dedicated compute, similarly for non-Graviton instances.
The following permission must be manually added to the Lambda role. You can remove the permissions once the external dedicated compute is created from the stack.
In the case of post-configuration, the following permissions are required on the lambda role to create a separate autoscaling group.
CloudFormation:DescribeStacks: This is used to get stack tags.
ec2:DescribeLaunchTemplates: It is used to describe a launch template.
ec2:CreateLaunchTemplateVersion: This is used to create a new version of a launch template, as tags are not attached to the autoscaling group. Hence, provide tags using the lambda function.
ec2:ModifyLaunchTemplate: This is required to modify an existing launch template.
Once the above-mentioned permissions are added to the Lambda role, create a stack using the PostCreationDedicatedComputeAWS.json JSON file available in the AWS installation Files folder, which will create a dedicated auto-scaling group. After creating the stack, configure the dedicated compute from the Compute Cluster page using Kyvos Manager.
Download the PostCreationDedicatedComputeAWS.json JSON file available in the AWS installation Files folder.
On the AWS CloudFormation Console, Create Stack > With New Resources (Standard) option.
Step 1: Specify template
In the Prerequisite - Prepare template, select the Choose an existing template option.
In the Specify template, select the Upload a template file option to upload your CloudFormation template using the Choose File button.
Click NEXT.
Step 2: Specify stack details
Enter a Stack name. Stack name can contain letters (A-Z and a-z), numbers (0-9), and dashes (-). The Kyvos cluster will be deployed in this name, and you cannot edit the name after deployment.
The Parameters area displays the configurations defined in your template. It also allows you to enter custom values to create or update a stack.
Parameter | Description |
---|---|
Subnets | Select the subnet to be attached to the Autoscaling Group. You must select two subnets from different availability zones. |
Ec2IamRole | Enter the name of the EC2 IAM Role that will be attached to Autoscaling group instances. NOTE: Use the same role which is used for KM Instance. |
LambdaIamRole | Enter the name of the lambda IAM role that will be attached to Autoscaling group instances. Use the same role which is used for Kyvos Manager Instance. |
InstanceSecurityGroupOtherVMs | Enter the ID of the security group attached to the BI Server. |
BucketName | Enter the name of S3 bucket used in Kyvos deployment. |
DedicatedComputeMaxNodes | The maximum desired dedicated compute cluster nodes. |
CustomPrefixEc2 | Enter the prefix you want to append to the names of EC2 instances of Autoscaling group used with Kyvos. The prefix can be up to 20 characters long and must begin and end with a word character. |
PemFile | A key pair consisting of a public key (stored by AWS), and a private key file (stored by user). Together, they allow you to connect to your instance securely. Use the same key which was used in Kyvos deployment. |
KyvosWorkDir | Enter the work directory path used in the Kyvos deployment. |
GravitonInstance | Select true if the Instances type of Autoscaling group is graviton. |
InstanceType | Instances type of Autoscaling group. If the ‘GravitonInstance’ parameter is true, use r6g.4xlarge instance type. |
CustomAMI | Select true if the Dedicated Compute instance will be created using custom image. |
AmiDefaultUserName | Fill this parameter only if parameter CustomAMI is true. Each Linux instance launches with a default Linux system user account. For more details, see AWS documentation. |
AmiId | Fill this parameter only if the parameter CustomAMI is set to true. |
Case 2: Manually creating a dedicated compute cluster
Step 1: Update the Launch Template or Launch Configuration
Cloud Init scripts are configured at instance launch update the Launch Template used in ASG.
To find the Launch Template associated with your Auto Scaling Group (ASG), perform the following steps:
Open the EC2 Console.
Go to the AWS EC2 Console.
Navigate to Auto Scaling Groups:
On the left sidebar, click Auto Scaling Groups under the Auto Scaling section.
Select Your ASG:
Find and click on the name of the Auto Scaling Group you want to check.
View Details:
In the Details tab, look for Launch Template: Shows the template name and version (if using Launch Templates).
Update Launch Template:
Log in to the AWS and navigate to EC2.
Select Launch Templates from the left pane.
Find your template and choose Actions > Modify Template (Create new version).
In Advanced Details, locate the User data section.
Paste the content of mannualCreationDedicatedComputeUserData.sh (available in AWS Installation Files folder) script here.
Save the new version.
Step 2: Update Auto Scaling Group to Use the New Template/Configuration
Go to Auto Scaling Groups in the EC2 console.
Select your ASG and click Edit.
Under Launch template version, choose Latest version or the specific version you created.
Save changes.
NEXT: Refer to the wizard-based deployment section for further details on deploying Kyvos.
For Azure
Note
The resource group of the dedicated compute cluster must be the same as the Kyvos cluster deployment resource group.
Supported dedicate compute instance types
Dsv4 size series (recommended Standard D16s v4)
Disk Size (recommended 250GB)
CASE 1: By downloading the ‘DedicatedCompute_VMSS’ JSON file
Download the DedicatedCompute_VMSS JSON file available in the Azure Installation Files folder.
Log in to Azure portal.
Search for ‘Deploy a custom template’ in the search bar.
Upload the downloaded JSON file.
Provide the same parameter that you mentioned while creating Kyvos cluster.
CASE 2: Manually creating a dedicated compute cluster
Go to Azure Portal.
Click On create a virtual Machine Scale Set (VMSS).
Select Subscription, Resource Group, and provide the Virtual Machine Scale Set name.
Orchestration mode for Dedicated Compute Cluster must be Uniform only.
Verify that the instance count must be 0.
From the Image drop-down, choose the supported RHEL version from the list.
Red Hat Enterprise Linux 8.6 - Gen 2 option (recommended).
Red Hat Enterprise Linux 9.4 - Gen 2
Red Hat Enterprise Linux 7.8 - Gen 1
Once the machine is created, you must attach the Managed Identity that is used for the deployment stack.
Add the following tags to the created VMSS.
ROLE: KYVOS_COMPUTE_CLUSTER
LAYER: Cube_Build
Download the Dedicated_Compute.sh script located in the Azure Installation Files folder.
In the script, update the blank parameters that required deployment-specific information.
Fill the information for those parameters.
Now, convert the script in base64 encryption.
Update the resource group name, VMSS name, and the script value in the command and then execute it.
az vmss extension set \ --resource-group <RESOURCE_GROUP_NAME> \ --vmss-name <VIRTUAL_MACHINE_SCALE_SET_NAME> \ --name CustomScript \ --publisher Microsoft.Azure.Extensions \ --no-auto-upgrade false \ --version 2.0 \ --settings '{"script":"<BASE_64_FORMAT_OF_SCRIPT>"}'
It will add extension to the VMSS and whenever any instance will launch, it will download the prerequisites on the instance.
NEXT: Refer to the wizard-based deployment section for further details on deploying Kyvos.
For GCP
Note
The working directory and bucket name used by the dedicated compute must be the same as the deployment.
Case 1: By downloading the terraform.tar bundle file
Download the terraform.tar bundle file, which is available in the GCP Installation Files folder.
Log in to GCP portal and upload the terraform.tar bundle file to cloud shell.
Navigate to conf folder and open the kyvosparams.tfvars file.
In the file, set the value of the dedicatedCompute parameter to true. Also, set the value of other parameters to false.
Now, go to the bin folder and execute the deploy.sh file.
CASE 2: Manually creating a dedicated compute cluster
Log in to GCP portal and navigate to the Instance Group.
Select the Instance Group that you want to modify.
In the selected instance group, find the associated Instance Template.
Note that you cannot directly edit an existing template.Since existing templates cannot be edited, click Create Similar to duplicate the current template.
Modify the PostCreationDedicatedComputeGCP.sh available in the GCP Installation Files folder.
In this script, modify the required details for the ZONE, BUCKET_NAME and KYVOS_WORK_DIR, and save the Changes.
In the newly created template, under the Management section, go to Automation.
Update the bootstrap script with the content of modified PostCreationDedicatedComputeGCP.sh and click Create.
Attach the Updated Instance Template to the instance group.
This process will create a new instance template with your required modifications and ensure that the changes are applied to the instance group accordingly.
NEXT: Refer to the wizard-based deployment section for further details on deploying Kyvos.
Copyright Kyvos, Inc. All rights reserved.