Deploying Global View on Virtana Platform
Global View is one of the core components of the Virtana Platform (VP). Global View provides a centralized, unified dashboard to monitor and manage performance across your entire infrastructure. It helps you gain visibility into distributed environments by consolidating insights from multiple sources into a single view.
Create a new Helm input file
The global-view-values.yaml file is required because it serves as the single source for your environment-specific configuration and secrets. Helm uses this file to deploy Global View's infrastructure and services, keeping these specific values separate from the generic chart defaults. This file defines settings, such as your database sizes, login credentials, and DNS hostnames.
global:
controlplane:
ingress:
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: "false"
nginx.ingress.kubernetes.io/force-ssl-redirect: "false"
postgresql:
storage:
size: 50Gi
environment: app
secret_source: valuesfile
storageClass: &defaultStorageClass ""
dockerRegistryCredentials:
DOCKER_SERVER: "https://index.docker.io/v2/"
DOCKER_USERNAME: "username"
DOCKER_PASSWORD: "password"
keycloak:
hostname: <KEYCLOAK_HOSTNAME>
adminUser: "vpadmin"
adminPassword: " "
public_dns_host_name: <GLOBAL_VIEW_HOSTNAME>
public_dns_host_am_suffix: -oc-<GLOBAL_VIEW_HOSTNAME>
organization_details:
organization_name: "<TENANT_NAME>"
first_name: " "
last_name: " "
contact_email: "xxxx.xxxx@domain.com"
create_tls_selfsigned_certs: true
affinity: &affinity {}
nodeSelector: &nodeSelector {}
tolerations: &tolerations []
cp-configs:
smtp: # Provide SMTP details
smtpHost: smtp.gmail.com
smtpPort: "587"
smtpUsername: ""
smtpPassword: ""
smtpFromEmail: "noreplies@virtana.com"
smtpTlsInsecureSkipVerify: "false"
growthbook:
ingress:
enabled: true
annotations:
nginx.ingress.kubernetes.io/cors-allow-origin: "https://<GROWTH_BOOK_HOSTNAME>"
appOriginName: <GROWTH_BOOK_HOSTNAME>
apiHostName: <GROWTH_BOOK_API_HOSTNAME>
affinity: *affinity
nodeSelector: *nodeSelector
tolerations: *tolerations
cp-mongodb:
affinity: *affinity
nodeSelector: *nodeSelector
tolerations: *tolerations
migration:
enabled: false
persistence:
size: 50Gi
minio:
affinity: *affinity
nodeSelector: *nodeSelector
tolerations: *tolerations
persistence:
size: 20Gi
redis:
persistentVolumeClaim:
size: 50Gi
imagePullSecrets:
- name: dhi-reg-cred
resources:
requests:
cpu: 100m
memory: 256Mi
limits:
cpu: 500m
memory: 256Mi
strimzi-kafka-operator:
controller:
persistence:
size: 50Gi
cloud-native-postgresql-cluster:
affinity: *affinity
cp-metrics-service:
victoria-metrics-single:
rbac:
create: true
namespaced: true
server:
size: 16Gi
alerts-service:
solrdb:
enabled: false
persistent_ebs:
spec:
resources:
requests:
storage: 100Gi
solr:
enabled: true
persistence:
size: 50Gi
zookeeper:
persistence:
size: 20Gi
alerts-service:
solr:
securityContext:
runAsUser: <user_id>
runAsGroup: <group_id>
podSecurityContext:
fsGroup: <fsgroup_id>
zookeeper:
securityContext:
runAsUser: <user_id>
runAsGroup: <group_id>
podSecurityContext:
fsGroup: <fsgroup_id>Global security parameters
These parameters allows you to access Global View and its interaction with your environment:
Field | Description | Default value |
|---|---|---|
| Controls the behavior of the NGINX Ingress for the control plane. | |
| Controls automatic HTTP to HTTPS redirection. The default value decides the outcome. | false |
| Diables all incoming traffic to be served via HTTPS. | false |
| The PostgreSQL database backing the platform. | |
| Size of the persistent volume for PostgreSQL. | 50 Gib |
| Represents the deployment environment name or type. | app |
| Specifies where secrets should come from. | valuesfile/none |
| Default Kubernetes StorageClass name for PVCs. | &defaultStorageClass "" If blank, use the default storageClass. |
| Credentials to pull container images from a Docker registry. | |
| If you are deploying in an air gapped environment and using a private docker registry to pull container images then use private registry URL. | https://index.docker.io/v2/ |
| Private registry username. | "username" |
| Private registry password | "password" |
| Integrates the platform with a Keycloak identity provider. | |
| Public hostname where Keycloak is accessible | <KEYCLOAK_HOSTNAME> |
| Credentials for the Keycloak admin account used to configure realms, clients, or users for this platform. | |
| Main DNS name for accessing the Virtana Global View UI. | <GLOBAL_VIEW_HOSTNAME> |
| Suffix used to construct additional hostnames, likely for auxiliary or AM services. | -oc-<global_view_hostname> |
| Metadata about the tenant or organization | |
| Tenant or company name | <TENANT_NAME> |
| Primary contact person | |
| Contact email for notifications or support | xxxx.xxxx@domain.com |
| Controls TLS certificate handling | true |
| Kubernetes pod affinity/anti‑affinity rules. Empty {} means pods can be scheduled anywhere. | &affinity {} |
| Simple mapping of labels > nodes. Empty {} means no node label constraints. | &nodeSelector {} |
| Allows pods to be scheduled onto tainted nodes. Empty [] means no special tolerations. | &tolerations [] |
SMTP parameters
These settings control the outgoing email, such as alerts or notifications.
Fields | Description | Default value |
|---|---|---|
| SMTP server hostname | smtp.gmail.com |
| SMTP port | "587" |
| Credentials for authenticating to SMTP | " " |
| Sender address used in outgoing emails | "abcd1234@virtana.com" |
| "false": TLS certificates are verified "true": skip TLS verification | false/true |
GrowthBook parameters
GrowthBook is typically used for feature flags and testing.
Fields | Description | Default values |
|---|---|---|
| Exposes GrowthBook via an Ingress | true |
| Ensures that web apps loaded from this origin can call the GrowthBook API from browsers | "https://<GROWTH_BOOK_HOSTNAME>" |
| Hostname for the GrowthBook web UI | <GROWTH_BOOK_HOSTNAME> |
| Hostname for the GrowthBook API endpoint | <GROWTH_BOOK_API_HOSTNAME> |
| Reuse the global scheduling rules via YAML aliases |
Storage and infrastructure component configuration
Configure the core storage and messaging services required for MongoDB, MinIO, Redis, Kafka, PostgreSQL, VictoriaMetrics, and Solr-based alerting components. This section defines capacity, persistence, and scheduling parameters to ensure reliable data retention, performance, and resilience across the platform.
Fields | Description | Default value |
|---|---|---|
| Uses the global scheduling policies | |
| Toggles MongoDB data migrations. If the customer is running GV version 2026121 or above, then this value must always be false. | false |
| Persistent storage allocated for MongoDB | 50 Gib |
| Size of the MinIO data volume | 20 Gib |
| Disk size for persistent Redis data | 50 Gib |
| Size of persistent volume used by the Strimzi controller | 50 Gib |
| Applies affinity rules to the Cloud Native PostgreSQL operator’s cluster resources | |
| VictoriaMetrics is a time‑series database for metrics | |
| Creates necessary RBAC (Roles/RoleBindings) for this component | true |
| RBAC resources are namespaced instead of cluster‑wide | true |
| Persistent volume size for VictoriaMetrics | 100 Gib |
| Enables the SolrDB component | true |
| Size of the underlying persistent volume | 100 Gib |
| Disables the in‑chart Solr deployment | false |
| The disk size for Solr | 50 Gib |
| Zookeeper persistence volume size for Solr’s coordination service | 20 Gib |
Overriding the private container registry
By default, the deployment process pulls container images from Virtana's official Docker registry. However, your organization might require you to use a private or internal container registry to comply with security policies or to manage network traffic.
If you choose to use a private registry as an optional setting, you must create a configuration file that tells the system where to find the images for various services, such as Redis, Minio, and Virtana AI components.
Note
This setting is needed only in case you want to use your own container image registry instead of Virtana's official Docker registry.
To redirect the image pull requests to your private repository, follow these steps:
Create a new file named
global-view-image-registry.yamlin your local deployment directory.Copy the following code into the file:
global: image_registry: <REGISTRY_NAME> imageRegistry: <REGISTRY_NAME> growthbook: image: repository: <REGISTRY_NAME>/growthbook redis: image: repository: <REGISTRY_NAME>/redis cloudnative-pg: image: repository: <REGISTRY_NAME>/cloudnative-pg cloud-native-postgresql-cluster: image: registry: <REGISTRY_NAME> strimzi-kafka-operator: defaultImageRegistry: <REGISTRY_NAME> minio: image: repository: <REGISTRY_NAME>/minio mcImage: repository: <REGISTRY_NAME>/mc cp-mongodb: image: registry: <REGISTRY_NAME> cp-metrics-service: victoria-metrics-single: server: image: repository: <REGISTRY_NAME>/victoria-metrics alerts-service: solr: image: registry: <REGISTRY_NAME> zookeeper: image: registry: <REGISTRY_NAME>/bitnamilegacyThe following table describes each field in the configuration file. Replace every instance of
<REGISTRY_NAME>with the URL of your private container registry.Table 5.Fields
Description
Default value
global.image_registryBase registry used by charts/components that reference this key for Virtana-maintained images.
<REGISTRY_NAME>global.imageRegistryBase registry for upstream/open-source images consumed by the stack.
<REGISTRY_NAME>growthbook.image.repositoryThe full repository path for the GrowthBook image.
<REGISTRY_NAME>/growthbookredis.image.repositoryRepository for the Redis server image used by the deployment.
<REGISTRY_NAME>/rediscloudnative-pg.image.repositoryThe full image repository path for the CloudNativePG operator image.
<REGISTRY_NAME>/cloudnative-pgcloud-native-postgresql-cluster.image.registryThe registry hostname where the PostgreSQL cluster images are hosted.
<REGISTRY_NAME>strimzi-kafka-operator.defaultImageRegistryThe default registry used for all Kafka-related images pulled by Strimzi.
<REGISTRY_NAME>minio.image.repositoryRepository for the MinIO server image.
<REGISTRY_NAME>/miniominio.mcImage.repositoryRepository for the MinIO Client (mc) image used for bucket/user/ILM automation.
<REGISTRY_NAME>/mccp-mongodb.image.registryThe registry hostname for the MongoDB container image.
<REGISTRY_NAME>cp-metrics-service.victoria-metrics-single.server.image.repositoryRepository for the VictoriaMetrics single-node image backing the control-plane metrics service.
<REGISTRY_NAME>/victoria-metricsalerts-service.solr.image.registryThe registry hostname for the Apache Solr image, used for search in the alerts pipeline.
<REGISTRY_NAME>alerts-service.solr.zookeeper.image.registryThe registry hostname for the ZooKeeper image used by Solr for coordination.
<REGISTRY_NAME>/bitnamilegacyReplace every instance of
<REGISTRY_NAME>with your actual registry URL, for example,<registry.mycompany.com/virtana>.Save the file.
Note
When you run your Helm installation or upgrade command, you must include this file using the -f flag to apply your overrides: -f global-view-image-registry.yaml.
Deploying Global View
The deployment process is divided into three main phases: deploying Custom Resource Definitions (CRDs), deploying infrastructure modules, and deploying service modules. You can perform these steps using the Helm CLI, Argo CD, or Terraform.
Update your Helm repository to ensure you have the latest version of the Virtana charts:
helm repo update helm search repo virtana-repo/virtana-global-view
Deploying Global View on an OpenShift Kubernetes cluster
OpenShift enforces strict Security Context Constraints (SCCs) that control which user and group IDs a container is allowed to run as. Before deploying GlobalView, you must configure the security contexts for each service so that the IDs fall within the range permitted by your target OpenShift cluster.
Before you begin, obtain the following values from your OpenShift cluster administrator:
<user_id>: A numeric user ID (UID) that is within the allowed UID range for your OpenShift project or namespace.<group_id>: A numeric group ID (GID) within the allowed GID range.<fsgroup_id>: A numeric supplemental group ID used to set ownership of mounted volumes, also within the allowed range.
Note
You can find the allowed UID or GID ranges by inspecting the namespace annotation. Run the following command:
oc describe namespace <your-namespace> | grep sa.scc
Perform the following steps:
Open your
global-view-values.yamlfile in a text editor.Add the following security context configuration, replacing
<user_id>,<group_id>, and<fsgroup_id>with the values obtained from your cluster administrator:redis: securityContext: runAsUser: <user_id> runAsGroup: <group_id> fsGroup: <fsgroup_id> strimzi-kafka-operator: podSecurityContext: fsGroup: <fsgroup_id> securityContext: runAsUser: <user_id> runAsGroup: <group_id> cp-mongodb: securityContext: runAsUser: <user_id> runAsGroup: <group_id> podSecurityContext: fsGroup: <fsgroup_id> minio: securityContext: runAsUser: <user_id> runAsGroup: <group_id> fsGroup: <fsgroup_id> cloudnative-pg: containerSecurityContext: runAsUser: <user_id> runAsGroup: <group_id> podSecurityContext: fsGroup: <fsgroup_id>The following table describes the security context parameters used across each service:
Table 6.Parameter
Description
runAsUserThe numeric user ID that the container process runs.
runAsGroupThe primary numeric group ID assigned to the container process.
fsGroupA supplemental group ID is applied to all mounted volumes.
The following table shows which security context parameters apply to each service:
Table 7.Service
runAsUserrunAsGroupfsGroupDescription
redis
✅
✅
✅
All three parameters are set under a single securityContext block.
strimzi-kafka-operator
✅
✅
✅
runAsUserandrunAsGroupare set under securityContext (container-level), whilefsGroupis set separately under podSecurityContext (pod-level).cp-mongodb
✅
✅
✅
Similar to Strimzi, container-level and pod-level contexts are split across securityContext and podSecurityContext.
minio
✅
✅
✅
All three parameters are set under a single
securityContextblock.cloudnative-pg
✅
✅
✅
Uses
containerSecurityContextforrunAsUserandrunAsGroup, andpodSecurityContextforfsGroup.Important
If any value is missing or falls outside the allowed range, OpenShift rejects the pod, and it fails to start.
Save the file.
Deploy Custom Resource Definitions (CRDs)
CRDs define the unique object types that Global View uses within your Kubernetes cluster. You must install these before the other modules.
You can deploy CRDs using three different methods. Choose the one that matches your application environment.
Run the following command in your terminal:
helm upgrade --install controlplane-crds virtana-repo/virtana-global-view \ --namespace controlplane --create-namespace \ --set tags.crds=true -f global-view-values.yaml \ --version <LATEST_VERSION>
Create a file named virtana-cp-crds.yaml and apply it to your Argo CD controller. Ensure you set the tags.crds parameter to true.
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: virtana-cp-crds
namespace: argocd
finalizers:
- resources-finalizer.argocd.argoproj.io
spec:
destination:
server: "https://kubernetes.default.svc"
namespace: controlplane
source:
chart: virtana-global-view
repoURL: "https://virtana.gitlab.io/helm-charts/"
targetRevision: <LATEST_VERSION>
helm:
releaseName: controlplane-crds
parameters:
- name: "tags.crds"
value: "true"
values: |
<contents of global-view-values.yaml>
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=trueDefine a helm_release resource in your Terraform configuration (for example, virtana-cp-crds.tf). Set the tags.crds value to true.
resource "helm_release" "cp-crds" {
create_namespace = true
chart = "virtana-global-view"
name = "controlplane-crds"
namespace = "controlplane"
repository = "https://virtana.gitlab.io/helm-charts"
version = var.helm_version
timeout = 1200
wait = true
set {
name = "tags.crds"
value = "true"
}
}Deploy infrastructure modules
Infrastructure modules include the backend components that Global View relies on, such as databases and messaging queues (for example, Kafka and PostgreSQL).
You can deploy infrastructure modules using three different methods. Choose the one that matches your application environment.
Run the following command in your terminal:
helm upgrade --install controlplane-infra virtana-repo/virtana-global-view \ --namespace controlplane --create-namespace \ --set tags.infra=true -f global-view-values.yaml \ --version <LATEST_VERSION>
Once the command completes, verify that all infrastructure pods are in a Running and Ready state before proceeding:
watch kubectl get pods -n controlplane
Create a file named virtana-cp-infra.yaml. In the values section, include the full contents of your global-view-values.yaml file and set tags.infra to true.
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: virtana-cp-infra
namespace: argocd
finalizers:
- resources-finalizer.argocd.argoproj.io
spec:
destination:
server: "https://kubernetes.default.svc"
namespace: controlplane
source:
chart: virtana-global-view
repoURL: "https://virtana.gitlab.io/helm-charts/"
targetRevision: <LATEST_VERSION> # Provide latest version
helm:
releaseName: controlplane-infra
parameters:
- name: "tags.infra"
value: "true"
values: |
<contents of global-view-values.yaml>
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=trueIn your virtana-cp-infra.tf file, use a templatefile function to pass your environment variables (like passwords and hostnames) into the Helm release.
resource "helm_release" "cp-infra" {
create_namespace = true
chart = "virtana-global-view"
name = "controlplane-infra"
namespace = "controlplane"
repository = "https://virtana.gitlab.io/helm-charts"
version = var.helm_version
timeout = 1200
wait = true
values = [
templatefile("${path.module}/../values/controlplane-values.yaml", {
storage_class = var.storageclass
docker_password = var.docker_password
docker_username = var.docker_username
keycloak_hostname = var.keycloak_hostname
keycloak_password = var.keycloak_password
keycloak_username = var.keycloak_username
global_view_hostname = var.global_view_hostname
tenant_name = var.tenant_name
user_first_name = var.user_first_name
user_last_name = var.user_last_name
user_email = var.user_email
smtp_from_mail = var.smtp_from_mail
smtp_password = var.smtp_password
smtp_port = var.smtp_port
smtp_server = var.smtp_server
smtp_to_mail = var.smtp_to_mail
smtp_username = var.smtp_username
growthbook_hostname = var.growthbook_hostname
growthbook_api_hostname = var.growthbook_api_hostname
})
]
set {
name = "tags.infra"
value = "true"
}
}Deploy service modules
The final step is to deploy the service modules. These are the functional applications that provide the user interface and API for Global View.
You can deploy service modules using three different methods. Choose the one that matches your application environment.
Run the following command in your terminal:
helm upgrade --install controlplane-service virtana-repo/virtana-global-view \ --namespace controlplane --create-namespace \ --set tags.service=true -f global-view-values.yaml \ --version <LATEST_VERSION>
Create a file named virtana-cp-service.yaml. Similar to the infra step, include your values file and set the tags.service parameter to true.
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: virtana-cp-service
namespace: argocd
finalizers:
- resources-finalizer.argocd.argoproj.io
spec:
destination:
server: "https://kubernetes.default.svc"
namespace: controlplane
source:
chart: virtana-global-view
repoURL: "https://virtana.gitlab.io/helm-charts/"
targetRevision: <LATEST_VERSION> # Provide latest version
helm:
releaseName: controlplane-service
parameters:
- name: "tags.service"
value: "true"
values: |
<contents of global-view-values.yaml>
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=trueConfigure the virtana-cp-service.tf resource. Ensure all SMTP and Keycloak variables are correctly mapped so that the services can communicate and send notifications.
resource "helm_release" "cp-service" {
create_namespace = true
chart = "virtana-global-view"
name = "controlplane-service"
namespace = "controlplane"
repository = "https://virtana.gitlab.io/helm-charts"
version = var.helm_version
timeout = 1200
wait = true
values = [
templatefile("${path.module}/../values/controlplane-values.yaml", {
storage_class = var.storageclass
docker_password = var.docker_password
docker_username = var.docker_username
keycloak_hostname = var.keycloak_hostname
keycloak_password = var.keycloak_password
keycloak_username = var.keycloak_username
global_view_hostname = var.global_view_hostname
tenant_name = var.tenant_name
user_first_name = var.user_first_name
user_last_name = var.user_last_name
user_email = var.user_email
smtp_from_mail = var.smtp_from_mail
smtp_password = var.smtp_password
smtp_port = var.smtp_port
smtp_server = var.smtp_server
smtp_to_mail = var.smtp_to_mail
smtp_username = var.smtp_username
growthbook_hostname = var.growthbook_hostname
growthbook_api_hostname = var.growthbook_api_hostname
})
]
set {
name = "tags.service"
value = "true"
}
}Verifying the deployment
Once all three phases are complete, check the status of your pods in the controlplane namespace:
kubectl get pods -n controlplane
All pods should show a status of Running or Completed.
Finalizing your Global View setup
Once the deployment process is complete, you must register your organization and verify that the system is running correctly. You can also configure optional features like Virtana AI or advanced database settings.
Complete registration
After the Helm charts finish installing, the system automatically sends a registration email.
Look for an email sent to the address you provided in the
global.organization_details.contact_emailfield of yourglobal-view-values.yamlfile.Click the link in the email to set your password and complete the account setup.
Verify the installation
To ensure Global View is accessible, perform the following steps:
Open your web browser and navigate to
https://<global_view_hostname>/ui. Replace<global_view_hostname>with the hostname you defined during configuration.Log in using the organizational email address and the password you created during registration.
Adding additional tenants (optional)
Global View supports multi-tenancy, allowing you to manage multiple isolated organizations from a single control plane. To add a new tenant, use a curl command to send a request to the Organization Service.
To add a tenant, perform the following steps:
Run the following command in your terminal, replacing the placeholders with your specific tenant details:
curl --location 'https://<global_view_hostname>/organization' \ --header 'Content-Type: application/json' \ --data-raw '{ "name": "<TENANT_NAME>", "contactName": "Administrator Name", "contactEmail": "admin.email@example.com", "licenseType": "Professional", "licenseModule": "ipm", "createSFDCArtifacts": true, "utmCodes": { "utm_source": "website", "utm_medium": "try Virtana", "utm_campaign": "perpetual" } }'The output of this command will contain a unique
OrgID.Save this ID for your records, as you will need it for tenant-specific configurations.
Advanced configuration options (optional)
You can further customize your deployment by modifying the global-view-values.yaml file. After making changes, you need to re-run the appropriate Helm upgrade command depending on which component the configuration affects. Run the services upgrade command after Virtana AI is enabled, and run the infra upgrade command after configuring the SolrDB setting.
Enable Virtana AI (Copilot Chatbot)
Virtana AI is a chatbot that helps you interact with documentation, query alerts, and generate policies using natural language. Refer Setting up the Virtana AI Copilot Chatbot for more details.
Global View and IO MCP integration
IO MCP details, such as endpoint and API key, should be provided to the Global View virtana-ai service using the below values. Add the following config to the global-view-values.yaml file:
cp-configs:
iomcpsecret:
io_mcp_endpoint: '{"<tenant-id>": {"<instance-name>": {"url": "https://<io-server>/api/sdk/mcp/", "headers": {"Authorization": "Bearer <your-io-token>"}}}}'Replace the placeholder values as follows:
Placeholder | Description |
|---|---|
<tenant-id> | Your tenant identifier. |
<instance-name> | A name for the target IO instance. |
<io-server> | The hostname of the IO server. |
<your-io-token> | A valid API bearer token. |
Refer to Virtana’s Model Context Protocol Server for more details.
Configure Solr database settings
Global View uses Solr to manage alert data. You can choose between a simple standalone setup or a high-availability SolrCloud setup.
Standalone SolrDB (Default): Select this for smaller environments or testing.
alerts-service: solrdb: enabled: trueNote
Following configration is already hardcoded, and Standalone SolrDB is deployed by default. No additional changes needed.
SolrCloud (Multi-Node): Select this for production environments that require better performance.
alerts-service: solrdb: enabled: false solr: enabled: true ## Set this to true, if you want to maintain one collection per Tenant. solrCollectionPerTenant: false ## Set this to true, if you are running Standalone SolrDB and want to migrate to SolrCloud solrMigrationenable: falseFields
Default value
Description
solrCollectionPerTenantfalse/true
Set this to true if you want to maintain one collection per Tenant.
solrMigrationenablefalse/true
Set this to true if you are running Standalone SolrDB and want to migrate to SolrCloud.
Remove a cluster
Global View is the control plane. It doesn't generate any data on its own. It aggregates alerts, metrics, topology, and inventory from downstream data sources, such as IO instances and CO clusters. If you don't register at least one cluster or IO instance, Global View has nothing to display. To remove a registered cluster from Global View, use the organization-service pod.
To remove a registered cluster, complete the following steps:
Enter the pod shell:
kubectl exec -it deploy/organization-service -n controlplane -- sh
Set your variables and run the delete request:
REALM_NAME=" " CLUSTER_NAME=" " curl -k -sS --request DELETE --location \ "http://organization-service-svc.controlplane.svc.cluster.local:5000/internal/organization/${REALM_NAME}/sources/${CLUSTER_NAME}?type=oc"Type
exitto return to your local terminal.