--- title: "How To: Generate the Collector Deployment Manifest" slug: "how-to-generate-the-collector-deployment-manifest" updated: 2026-03-09T16:31:29Z published: 2026-03-09T16:31:29Z canonical: "resources.realtheory.io/how-to-generate-the-collector-deployment-manifest" --- > ## Documentation Index > Fetch the complete documentation index at: https://resources.realtheory.io/llms.txt > Use this file to discover all available pages before exploring further. # How To: Generate the Collector Deployment Manifest The RealTheory [K8sArtifacts](https://api-dev.realtheory.io/swagger/k8sartifacts/index.html) API allows you to tailor the manifest for deploying the RealTheory Collector to a managed Kubernetes Cluster. Alternatively, you can use the RealTheory SaaS portal to provide similar customization ([See Installing RealTheory in a Cluster](/v1/docs/installing-realtheory-in-a-cluster)). ### Get Deployment Manifest To customize and generate a manifest for deploying the RealTheory Collector to a managed Kubernetes Cluster, call the method below on the [K8sArtifacts](https://api-dev.realtheory.io/swagger/k8sartifacts/index.html) endpoint. ``` GET /theory/api/v1/k8sartifacts/collector?os={os}&arch={arch}&cpuCount={cpuCount}&{param1}={value1}&{param2}={value2} ``` where: - `{endpoint}` - is the URL of the RealTheory SaaS portal for your account. - `{os}` - is the operating system of the node pool that the deployment is targeting within the target Cluster. Supported values are 'linux'. This parameter is mandatory. - `{arch}` - is the processor architecture of the node pool that the deployment is targeting within the target Cluster. Supports values are 'amd64', 'arm64', and 'multi-arch'. This parameter is optional and will default to 'multi-arch' if not specified. - `cpuCount` - is the approximate number of cores or vCPUs that the target Cluster has. This parameter is optional but influences the size of the resource request associated with the Collector container. - `param1..n` - is an optional set of query parameters. Supported query parameters are - `THEORY_CLUSTER_NAME` - is used to set the name of the Cluster. - `THEORY_CLUSTER_DESCRIPTION` - is used to set the description of the Cluster. - `THEORY_CLUSTER_LABELS` - is used to set additional labels associated with the Cluster. The corresponding value for this query parameter can contain multiple labels, e.g. `{'key1':'value1', 'key2':'value2', 'key3':'value3'}` - `HTTP_PROXY` - is the URL of the proxy server for HTTP requests to access the Internet. - `HTTPS_PROXY` - is the URL of the proxy server for HTTPS requests to access the Internet. - `NO_PROXY` - is a comma-separated list of host names that shouldn’t go through the proxy server to access the Internet. - `value1..n` - is an optional set of query values that correspond to the query parameters above. **Notes:** - All calls to RealTheory APIs must be authenticated and authorized. See [Authentication](/v1/docs/authentication) for more details. - The query should be URL encoded; otherwise, the request might be rejected. #### Example: ``` GET myendpoint.realtheory.io/theory/api/v1/k8sartifacts/collector?os=linux&arch=multi-arch&THEORY_CLUSTER_NAME=my cluster name&THEORY_CLUSTER_DESCRIPTION=my cluster description&THEORY_CLUSTER_LABELS={'realtheory.io/cluster-name':'my cluster name','realtheory.io/cluster-description':'my cluster description','realtheory.io/account-name':'my account name','realtheory.io/account-owner:'my account owner','realtheory.io/propagate-labels':'true'}&HTTPS_PROXY=https://myusername:mypassword@myproxy.com&NO_PROXY=https://host1.domain.local,https://host2.domain.local ``` **Notes:** - The Cluster name should be included twice; once under the `THEORY_CLUSTER_NAME` query parameter and once under the `THEORY_CLUSTER_LABELS` query parameter, using the following key: 'realtheory.io/cluster-name'. - The Cluster description should be included twice; once under the `THEORY_CLUSTER_DESCRIPTION` query parameter and once under the `THEORY_CLUSTER_LABELS` query parameter, using the following key: 'realtheory.io/cluster-description'. - Any custom labels should be included within the THEORY_CLUSTER_LABELS query parameter value. - To set the [Cloud Account Identifier](/v1/docs/installing-realtheory-in-a-cluster) label, add the 'realtheory.io/account-name' key-value pair to the `THEORY_CLUSTER_LABELS` query parameter. - To Set the [Account Owner](/v1/docs/installing-realtheory-in-a-cluster) label, add the 'realtheory.io/account-owner' key-value pair to the `THEORY_CLUSTER_LABELS` query parameter. - To propagate all custom labels to all Kubernetes objects within a Cluster, add the 'realtheory.io/propagate-labels':'true' key-value pair to the `THEORY_CLUSTER_LABELS` query parameter. which returns the following manifest, which can be used to deploy the RealTheory Collector to a managed Kubernetes Cluster ``` # The namespace used for the Collector. apiVersion: v1 kind: Namespace metadata: labels: name: real-theory-system name: real-theory-system --- # The Service Account used for the Collector. apiVersion: v1 kind: ServiceAccount metadata: name: real-theory-collector namespace: real-theory-system --- # The cluster role grants read only access to key API groups. apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: object-reader rules: - apiGroups: - "" - "apps" - "metrics.k8s.io" - "storage.k8s.io" - "apiextensions.k8s.io" resources: ["*"] verbs: [get, watch, list] --- # The cluster role binding allows the Service Account for the collector in the real-theory-system namespace to read objects in any namespace. apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: read-objects-global roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: object-reader subjects: - kind: ServiceAccount name: real-theory-collector namespace: real-theory-system --- # The deployment creates a replica set to launch the Collector pod. apiVersion: apps/v1 kind: Deployment metadata: labels: app: realtheorycollector name: realtheorycollector namespace: real-theory-system spec: replicas: 1 selector: matchLabels: app: realtheorycollector template: metadata: labels: app: realtheorycollector name: realtheorycollector spec: containers: - env: - name: THEORY_LOGGING_LEVEL value: Info - name: THEORY_LOGGING_FILE_PATH value: /theory/logs/collector.log - name: THEORY_SERVICES_NETWORK_K8SROUTERURL value: https://api-dev.realtheory.io/theory/api/v1/k8srouter - name: THEORY_SERVICES_NETWORK_K8SCOMMANDSURL value: https://api-dev.realtheory.io/theory/api/v1/k8scommands - name: THEORY_SERVICES_AUTHENTICATION_USERTOKEN value: # *** REPLACE WITH USER TOKEN ISSUED FROM REALTHEORY *** - name: THEORY_SECURITY_AUTHENTICATION_TYPE value: InsideCluster - name: THEORY_CLUSTER_NAME value: my cluster name - name: THEORY_CLUSTER_DESCRIPTION value: my cluster description - name: THEORY_CLUSTER_LABELS value: "{"realtheory.io/cluster-name":"my cluster name","realtheory.io/cluster-description":"my cluster description","realtheory.io/account-name":"my account name","realtheory.io/account-owner:"my account owner","realtheory.io/propagate-labels":"true"}" - name: HTTPS_PROXY value: https://myusername:mypassword@myproxy.com - name: NO_PROXY value: https://host1.domain.local,https://host2.domain.local image: realtheory/theory-k8s-collector imagePullPolicy: Always livenessProbe: failureThreshold: 5 httpGet: path: /theory/api/v1/collector/health port: 80 scheme: HTTP periodSeconds: 60 timeoutSeconds: 5 name: realtheorycollector ports: - containerPort: 80 readinessProbe: failureThreshold: 5 httpGet: path: /theory/api/v1/collector/health port: 80 scheme: HTTP periodSeconds: 60 timeoutSeconds: 5 resources: requests: cpu: 100m memory: 128Mi startupProbe: failureThreshold: 20 httpGet: path: /theory/api/v1/collector/health port: 80 scheme: HTTP initialDelaySeconds: 30 periodSeconds: 15 timeoutSeconds: 5 nodeSelector: kubernetes.io/os: linux kubernetes.io/arch: arm64 serviceAccountName: real-theory-collector ```