Manage Cloud Resources for Cluster Using the C3 AI Cluster Management Environment
The C3 Agentic AI Platform is a multi-environment platform, which means a single C3 AI Cluster can have one or more environments. By default, a C3 AI Cluster includes one active C3 AI Environment that functions as the C3 AI Cluster Management Environment. Access the C3 AI Cluster Management Environment by going to the C3 AI Cluster URL (https://mydomain.mycluster/c3/c3/console/index.html) and opening the C3 AI console.
The Cluster Administrator uses the C3 AI Cluster Management Environment to perform cluster-level administrative work: such as, user creation, role assignment, regular environment creation, and resource allocation and management.
The following sections provide instructions for using the C3 AI Cluster Management Environment to manage cloud resources, including: using basic functions and specifications for cloud resource management, configuring default settings, and using JSON templates to define specifications and metadata for those resources.
See also CloudResource.
Use basic functions and specifications to manage cloud resources
The process for creating a cloud resource or modifying an existing resource starts with the startEnv spec.
Use the startEnv Spec
Use the Cluster#startEnv Spec to start an Env from a Cluster from which you can start applications within the environment to accept API requests.
Use the following console command to create a Single Node Environment (SNE).
NOTE: Environment names must be in all lowercase alphanumeric characters only. Environment names must be unique within the same cluster.
Cluster.startEnv({name: 'myenv', serverVersion: 'myServerVersion', singleNode: true})Alternatively, use the following console command to create a shared environment.
Cluster.startEnv({name: 'myenv', serverVersion: 'myServerVersion', singleNode: false})To start an existing environment, use the following console command:
Cluster.startEnv({name: 'myenv'})Use the startApp spec
Use the Env#startApp spec to deploy an App from an Env. This method enables the C3 AI Application to be available to accept API requests. See the following example:
Env.forId('mycluster-myenv').startApp({name: 'myapp', rootPkg: 'mypackage'})Functionalities of fromId
CloudResourceFields#fromId constructs an instance of a CloudResource from the ID that is passed as a parameter. This method populates information such as the ID, Cluster, Env, App, Func, and Role of that cloud resource.
The semantics for the CloudId are <cluster>-<env>-<app>-<func>[-<role>][-<seq>][-<subseq>]. An example for using this method is provided below:
K8sHorizontalPodAutoscaler.fromId("v8-c3-test-k8shpa-l");If the Func is not for this Cloud Resource Type, then fromId translates to an appropriate one. This logic is done within CloudResourceFields#fromCloudId.
Functionalities of upsertResource
CloudResource#upsertResource deals with the creation or modification of a particular cloud resource.
Below is an example for upserting a K8sResource:
<CloudResource>.fromId(...).upsertResource(...);The following example includes logic for how a resource is created or modified is specified below using upsertResourceCommon():
public CloudResource upsertResource(CloudResource ths, CloudResourceOperationSpec spec) {
return upsertResourceCommon(ths, spec, (input, client) -> {
// creation logic
}, (input, existing, client) -> {
// modification logic
} In the above example, CloudResourceUpsertLogic determines whether to step through the create or modify lambda. The procedures for both are different as depicted below:
| Logic | create | modify |
|---|---|---|
| getResource | null | not null |
| existing | false | true |
| retry logic | exists | exists |
| withDefaultConfig | called | not called |
withDefaultConfig
CloudResourceFields#withDefaultConfig populates default values for all uninitialized configurable fields.
JSON templating
JSON templates are used to define what metadata and specs each resource should have. Each JSON template has bindings, such as {namespace} and {cluster}, that are populated through a key-value mapping at runtime.
There are two types of bindings. Both key-value mappings merge before they are used to populate the JSON bindings.
C3 AI specific values common across Kubernetes, AWS, and Local (for example,
{cluster}or{env})- key-value mapping generated through CloudResource#templateBindings
Cloud provider specific values (for example,
{namespace})
The exact JSON templates to be used are determined in CloudResourceFields.keys(). These JSON files are then merged through CloudResourceFields.fromConfigTemplate().
| JSON | Example |
|---|---|
| Base JSON | _.json |
| Cloud JSON | k8s.json |
| Func JSON | k8shpa.json |
| Role JSON | k8shpa-l.json |
The merged JSON template is then populated through the key-value mappings using the FreeMarker Templating Language (FTL) as part of CloudResourceFields.fromJson().
The resulting JSON template is then used as a payload sent to the Kubernetes API Server through a REST call to upsert the resource.
Cloud annotations
Annotations are intended to reduce code for common logic between cloud resources.
As an example, cloudFunc is a field that is common across cloud resources. Instead of having the following for each cloud resource:
public String cloudFunc() {
return "k8singr";
}It is possible as an alternative to use annotations:
@cloud(cloudFunc='k8singr')
private type K8sIngress mixes K8sResourceThe full list of possible annotations are provided in the Ann.Cloud Type.