Is this page helpful?

Application Profiles#

An ApplicationProfile in the AP (Application & Profile) service defines how a Kit Application version is deployed, including resource allocation, Helm chart values, and other environment-specific configurations. Below are the primary sections within the ApplicationProfile CRD that are relevant for configuring it:

Additional resources:

Creating an Application Profile - step-by-step deployment instructions
Samples and Resources - contains a number of example application profiles

1. Metadata#

metadata.name: Specifies the name of the application profile, which must be unique within the namespace.

Example:#

metadata:
   name: production-profile

Purpose: This section uniquely identifies the profile in the cluster and allows you to reference it in other resources.

2. Spec Section#

The spec section is where the bulk of the configuration happens. Below are the key fields within the spec that are critical for configuring an application profile:

2.1. Name and Description#

spec.name: A user-friendly name for the profile.
spec.description: A brief description of the profile’s purpose.

Example:#

spec:
   name: Production Profile
   description: Profile for production deployment of My Application.

Purpose: Helps provide clarity on the profile’s role and usage, especially in environments with multiple profiles.

—

2.2. Supported Applications#

spec.supportedApplications: Defines which applications and versions this profile applies to.
- name: The name of the application the profile applies to.
- versions: A list of supported versions of the application. You can use wildcards like “*” to support multiple versions.

simple

Example: profile for one application and two explicit versions#

supportedApplications:
   - name: "my-application"
      versions:
         - "1.0.0"
         - "1.1.0"

version wildcards

Example: profile for one application and a mix of explicit and wildcard versions#

supportedApplications:
   - name: "my-application"
      versions:
         - "1.5.0"
         - "1.6.0"
         - "2.*"

multiple applications

Example: profile for one explicit and a wildcard application and a mix of explicit and wildcard versions#

supportedApplications:
   - name: "my-application"
      versions:
         - "1.5.0"
         - "1.6.0"
         - "2.*"
   - name: "usd-*"
      versions:
         - "*"

Purpose: This section ties the profile to specific applications and versions. It enables the APS to apply this profile when a corresponding application version is deployed.

—

2.3 Chart Mappings#

spec.chartMappings: This section defines mappings between the profile and Helm chart values they should override.

Example: maps streamingKit.image.repository and tag to override the ApplicationVersion container settings.#

chartMappings:
   container: streamingKit.image.repository
   container_version: streamingKit.image.tag
chartValues:
   streamingKit:
      image:
         repository: nvcr.io/nvidia/omniverse/usd-viewer
         pullPolicy: Always
         tag: '110.1.3'

Purpose: Provides a mapping mechanism between settings defined in spec.chartValues and what they should override in the Helm chart.

—

2.4 Chart Values#

spec.chartValues: Values to apply to the helm chart that is installed.

Example: container image values that override those defined in the ApplicationVersion.#

chartValues:
   streamingKit:
      image:
         repository: nvcr.io/my-app-repo/my-application
         tag: '1.0.0'

Purpose: The chartValues section specifies values within the application-profile that should override settings in the Helm chart used to start the Kit App. The possible values are based entirely on the extent of the underlying Helm chart. In situations where dynamic NLB or Authorization are required, for example, this can be quite extensive.

Note

With the exception of global, all session-chart values live under the streamingKit key; values placed at the top level of chartValues are silently ignored by Helm. Commonly overridden values and their chart defaults: streamingKit.service.type (default NodePort; most shipped samples set LoadBalancer, which the Generic backend’s route resolution requires unless the manager is configured with the NodePortResolver backend, while the AWS TargetGroupBinding samples intentionally leave it unset), streamingKit.shader_cache.enabled (default true, pointing at hsscdns://memcached-service-r3), streamingKit.image.pullPolicy (the shipped samples set Always for evaluation convenience, which re-pulls the multi-gigabyte image on every session start and makes each session depend on registry reachability and a valid regcred; for production, pin a specific version tag and use IfNotPresent, and never combine IfNotPresent with a mutable tag such as latest), and streamingKit.envoy.tls (default disabled). streamingKit.imagePullSecrets takes precedence over global.imagePullSecrets, and the regcred secret referenced by the samples must be created by the operator.

Note

How values are resolved: profile chartValues are layered over the session chart’s defaults, so any value the profile omits keeps its chart default. Per-session settings are applied last and take precedence: a stream request that supplies usd_stage_uri sets the USD_PATH environment variable, overriding any USD_PATH in the profile. Environment variable lists are merged by variable name rather than replaced, so other profile variables are preserved (release 1.12.1 and later; earlier releases replaced the profile’s variables entirely in this case), and entries without a name are discarded with a warning. chartMappings targets are not validated: a mistyped path is created as a new, unused key and the mapping silently has no effect, so verify the result with kubectl get helmrelease <session> -o yaml.

3. Resource Requests and Limits#

Define the resource requests and limits for the application, specifying how much memory, CPU, or GPU the application needs.

Example: 8-16 cores, 32Gi-64Gi memory and 1 gpu#

chartValues:
   streamingKit:
      resources:
         requests:
            memory: "32Gi"
            cpu: "8"
            nvidia.com/gpu: "1"
         limits:
            memory: "64Gi"
            cpu: "16"
            nvidia.com/gpu: "1"

Purpose: This ensures that the application has sufficient resources to run efficiently and prevents resource overcommitment on the cluster.

4. Environment-Specific Configuration#

External access: configured per session through streamingKit.service.type and provider-specific streamingKit.service.annotations; the session chart does not create Ingress resources.
Storage and Volumes: If the application requires persistent storage, you can define it here (optional).
Security Settings: TLS for the WebRTC signaling channel, configured under streamingKit.envoy.tls or terminated at the load balancer.

Note

The session chart does not create Ingress resources, and top-level ingress values in a profile are ignored. External access for a session is configured through streamingKit.service.type (for example LoadBalancer) and provider-specific streamingKit.service.annotations; see the AWS, Azure, and MetalLB profile samples. TLS for the signaling channel is configured under streamingKit.envoy.tls or terminated at the load balancer (see Traffic Encryption).

Purpose: Allows customization of the deployment based on the environment (production, development, staging) or infrastructure type (cloud, on-prem).

5. Logging and Monitoring Configuration#

Logging Settings: Define logging levels and outputs (optional).
Prometheus Monitoring: Integrate monitoring tools like Prometheus to track application performance.

Note

The session chart does not create ServiceMonitor resources, so monitoring values in a session profile have no effect. Prometheus monitoring is configured on the platform services (Applications, RMCP, Streaming Manager, and the AWS NLB Manager) through their own chart values; see Installation.

Purpose: Application-level logging remains the responsibility of the Kit App developer.

6. Wildcard Support#

Wildcards can be used for both application names and versions, making it easier to manage profiles that apply to many applications or versions without explicit enumeration.

Example:#

supportedApplications:
   - name: "usd-viewer"
      versions: ["*"]
   - name: "usd-explorer"
      versions:
         - "1.1.5"
         - "1.2.*"
         - "2.*"
   - name: "omni-*-viewer"
      versions: ["*"]

7. Default Application Profile#

You can define a default profile by using wildcards for all applications and versions, ensuring that a default configuration is applied when none is specified.

Example:#

apiVersion: omniverse.nvidia.com/v1
kind: ApplicationProfile
metadata:
   name: default-profile
spec:
   supportedApplications:
      - name: "*"
        versions: ["*"]

Purpose: The default profile acts as a fallback for any application or version without a specifically assigned profile.

8. Defining Environment Variables#

Environment variables can be added to the chartValues.streamingKit.env section of the applicationprofile.yaml. These variables are then passed to the application when it is deployed.

sparse

spec:
  chartValues:
    streamingKit:
      env:
        - name: APP_ENV
          value: "production"
        - name: LOG_LEVEL
          value: "info"
        - name: USD_PATH
          value: "'${omni.usd_viewer.samples}/samples_data/stage01.usd'"

full

apiVersion: omniverse.nvidia.com/v1
kind: ApplicationProfile
metadata:
  name: default
spec:
  name: Default profile
  description: Updated memory and CPU settings with env_vars
  supportedApplications:
    - name: "usd-viewer"
      versions:
        - "*"
  chartMappings:
    container: streamingKit.image.repository
    container_version: streamingKit.image.tag
    name: streamingKit.name
  chartValues:
    global:
      imagePullSecrets:
        - name: regcred
    streamingKit:
      resources:
        requests:
          cpu: "8"
          memory: "32Gi"
          nvidia.com/gpu: "1"
        limits:
          cpu: "16"
          memory: "64Gi"
          nvidia.com/gpu: "1"
      env:
        - name: APP_ENV
          value: "production"
        - name: LOG_LEVEL
          value: "info"
        - name: USD_PATH
          value: "'${omni.usd_viewer.samples}/samples_data/stage01.usd'"

Purpose: This allows dynamic configuration to be injected into the Kit Application at runtime, making it easier to manage different deployment environments (e.g., production, staging). The logic to respond to the environment variables is the responsibility of the Kit App developer.

Warning

The single quotes inside the USD_PATH value are intentional and must be preserved: value: "'${omni.usd_viewer.samples}/samples_data/stage01.usd'". The Kit container entrypoint shell-expands this variable, and ${omni.usd_viewer.samples} is a Kit token, not a shell variable; without the embedded single quotes the shell attempts the substitution and the container exits at startup with a bad substitution error.

Verifying Environment Variables#

To confirm that environment variables are correctly set in an application pod, you can use the following commands:

Output all environment variables for the specified POD.#

kubectl exec -it <POD_NAME> -- env

Check the value of a specific environment variable on the specified POD#

kubectl exec -it <POD_NAME> -- env | grep <ENV_VAR>

Conclusion#

These primary sections within the ApplicationProfile CRD allow for detailed customization of how Omniverse Kit Apps are deployed within the Omniverse Application Streaming API environment. By carefully defining the supportedApplications, chartMappings, chartValues, and resource requests, you can ensure each application is optimized for its deployment environment, whether cloud, on-premise, production, or development.