Kubernetes Visibility Agent

[Pratiksha]

Kubernetes Visibility Agent

Let’s break down how the Kubernetes Visibility Agent functions, step by step, so you can clearly understand how it helps populate your CMDB in ServiceNow:

Where It Works

The Kubernetes Visibility Agent supports visibility into:

• ✅ On-premises Kubernetes clusters
• ☁️ Cloud-hosted Kubernetes services like:
• Amazon EKS (Elastic Kubernetes Service)
• Google GKE (Google Kubernetes Engine)
• Microsoft AKS (Azure Kubernetes Service)
• Red Hat OpenShift
• Rancher

• This broad compatibility means you can monitor hybrid and multi-cloud environments from a single ServiceNow instance.

1. Deployment in Kubernetes

• When you deploy the Kubernetes Visibility Agent, Kubernetes creates a Deployment resource inside your cluster.
• This Deployment is responsible for running the agent.
• To securely connect to your ServiceNow instance, it uses a Kubernetes secret that holds the necessary credentials.

2. Role of the Informer Pod

• Inside this Deployment, a pod called Informer is created.
• The Informer plays a critical role—it connects to the Kubernetes API Server.
• It listens to events and changes happening across the cluster—like new pods, services, or nodes being added or removed.

3. Sending Data to ServiceNow

• Once the Informer collects this data, it sends it to ServiceNow.
• It does this by using the ServiceNow Table API to interact with the ECC Queue table (External Communication Channel).
• The ECC Queue acts as a communication channel between your Kubernetes cluster and the ServiceNow platform.

4. Updating the CMDB

• After reaching the instance, the data is processed.
• The appropriate CMDB tables are updated with the discovered Kubernetes resources—like clusters, nodes, namespaces, workloads, etc.
• This ensures your CMDB reflects the real-time state of your Kubernetes environment.

Key Benefits

• Real-time visibility into your containerized environment.
• Automated population of CMDB with accurate and timely data.
• Seamless integration between Kubernetes and ServiceNow using existing platform features like the ECC Queue and Table API.

Some important links : https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1532614

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1700730

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1781212

[andrewrouch]

How is the agent configured to authenticate with the EKS or GKE K8s API?

[Pratiksha]

@andrewrouch The Kubernetes Visibility Agent Deployment resource contains a pod called Informer, which connects to the Kubernetes API server and receives events on the resources in the cluster from it. The Informer sends the collected data to the instance through the External Communication Channel (ECC) Queue table, using the ServiceNow Table API to read from and write to the queue. The Informer then updates the appropriate tables in the CMDB.

Go through this : https://www.servicenow.com/docs/bundle/zurich-it-operations-management/page/product/cloud-native-ope...

[andrewrouch]

Actually I discovered in a KB article https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1532614 that the Helm chart for the KVA can include the ClusterRole assigned, so the answer is that an IAM Role on AWS or GCP gets assigned to the ClusterRole and that role name is entered in the Helm chart.  It's a pity that this information is buried in a KB article and not in the public product documentation.

[Pratiksha]

@andrewrouch Thanks for adding the point. Updated the article with few more KB's. 

Thanks Pratiksha

[andrewrouch]

Thanks Pratiksha for the updates.  Authentication and role requirements are important topics for financial institutions so would be good to have that included in the standard product documentation, however this article is a good explainer of the end to end process in any case.