License capacity reporting

Scrydon licenses are measured against the capacity deployed for Scrydon: CPU, RAM, worker nodes, and accelerator VRAM. Online installations measure that capacity locally every hour and include the resulting high-water mark in the existing license validation request every 24 hours.

Dedicated cluster required. Deploy Scrydon on a dedicated Kubernetes cluster. The measurement covers every eligible worker node in the cluster; it cannot distinguish capacity reserved for unrelated workloads.

Schedule and network behavior

An hourly sample only calls the in-cluster Kubernetes API. It does not contact Scrydon. If the daily request fails, the accumulated high-water window remains in the customer database and is retried on the next validation.

In offline mode—including fully air-gapped installations—Scrydon makes no outbound license request. Capacity is handled through the manual attestation process agreed in your license contract.

What is measured

The collector reads status.allocatable from schedulable worker nodes. It excludes nodes that:

• have spec.unschedulable: true;
• carry node-role.kubernetes.io/control-plane; or
• carry the legacy node-role.kubernetes.io/master label.

For each one-hour sample, Scrydon sums (rounding fractional millicores and MiB upward so capacity is never understated):

• CPU as integer millicores;
• RAM as integer MiB;
• accelerator units and their configured VRAM as integer MiB; and
• eligible worker-node count.

The daily report contains the highest observed value of each dimension during the reporting window. Each dimension has an independent high-water mark. CPU comes from allocatable.cpu; RAM comes from allocatable.memory. One licensed RAM or VRAM GB unit is compared as 1,024 MiB, and one licensed CPU core is compared as 1,000 millicores.

The first release is audit-only. A report above an entitlement is recorded for review but does not block workloads or change the response for an otherwise valid license.

Accelerator and GPU configuration

Kubernetes accelerator resources normally expose a unit count, not VRAM. Configure how much VRAM one allocatable unit represents. The mapping is vendor-neutral and supports NVIDIA, AMD, Intel, custom device plugins, and partition resources such as MIG profiles.

license:
  capacity:
    acceleratorResources:
      - resourceName: nvidia.com/gpu
        vramMiBPerUnit: 24576
      - resourceName: amd.com/gpu
        matchLabels:
          accelerator.scrydon.com/model: mi300x
        vramMiBPerUnit: 196608
      - resourceName: gpu.intel.com/i915
        vramMiBPerUnit: 16384
      - resourceName: nvidia.com/mig-1g.10gb
        vramMiBPerUnit: 10240

Use matchLabels when the same extended-resource name represents devices with different VRAM sizes. Labels are used only for selecting the mapping; their keys and values are never sent in the license request. Do not configure two mappings that can match the same resource on the same node.

When the license includes VRAM but a deployed accelerator resource has no unambiguous mapping, the report is marked incomplete rather than estimating capacity.

Data sent to Scrydon

Contractual data is separate from optional diagnostics.

The request does not include node names, IP addresses, Kubernetes labels, resource names, GPU serial numbers, pod or workload names, namespaces, user data, prompts, documents, or customer content. Raw license reports are retained by the Scrydon license service for three months.

Disable optional diagnostics without disabling contractual capacity reporting:

license:
  diagnostics:
    enabled: false

Kubernetes access

In online mode the Helm chart binds a narrowly scoped ClusterRole to the api-platform service account. It grants only:

apiGroups: [""]
resources: ["nodes"]
verbs: ["get", "list"]

No permission to create, update, patch, delete, or read Kubernetes Secrets is added by capacity reporting.

If you enable the chart's default-deny NetworkPolicies, also allow the Kubernetes API Service IP. Keep the CIDR as narrow as your CNI permits:

kubectl get service kubernetes -o jsonpath='{.spec.clusterIP}{"/32\\n"}'

networkPolicies:
  kubernetesApiEgress:
    enabled: true
    cidr: 10.96.0.1/32 # replace with the command output
    port: 443

Troubleshooting incomplete reports

An incomplete report preserves the data that was measured and adds one or more bounded reasons:

• Kubernetes API unavailable;
• no eligible worker nodes;
• invalid Kubernetes quantity;
• missing accelerator mapping; or
• ambiguous accelerator mapping.

Check the api-platform logs, confirm its service account can list nodes, and review license.capacity.acceleratorResources. A temporary failure does not erase the current high-water window.

Related

• Licensing
• Helm values reference
• Air-gapped deployment