Service Mapping not discovering backend and database running on Kubernetes

[anburajselvaraj]

Hi Community,

I am working on ServiceNow Discovery and Service Mapping for an internal application hosted on our company servers.

When I create a service mapping entry, I am able to get partial results, but the backend components and database are not discovered. The reason seems to be that the backend application is running on self-hosted Kubernetes (K8s).

Could you please help me understand:

• How to perform discovery and service mapping for applications running on Kubernetes?

• What prerequisites, plugins, or configurations are required?

• Do we need ServiceNow Kubernetes Discovery, patterns, or integration with container platforms (like Kubernetes API, Helm, or a cloud provider)?

•  How to do self-hosted Kubernetes Discovery?

[Vijaya_Mnpram]

@anburajselvaraj  You need to first discover all the company servers before you map them in a Service. 

Go through below course, there is a section for Kubernetes. There you can understand the first structure and how to discover. Hope this helps:

Discovery Extras - ServiceNow University

[Prahlad Kumar]

Hi @anburajselvaraj,

ServiceNow Discovery & Service Mapping for Self-Hosted Kubernetes Applications

This document explains how to perform Discovery and Service Mapping in ServiceNow for applications running on self-hosted Kubernetes (K8s). It includes prerequisites, configuration steps:

2. Why Backend and Database Are Not Discovered
Traditional ServiceNow Discovery is server-based and process-based. In Kubernetes:
- Applications run inside containers, not directly on servers.
- IP addresses are dynamic.
- Backend services and databases are abstracted behind services.
- Without Kubernetes integration, ServiceNow cannot detect these components.

This is why you see only partial results during Service Mapping.

3. High-Level Architecture Diagram
User → Load Balancer / Ingress
|
Frontend Pods (Kubernetes)
|
Backend Services (Kubernetes)
|
Database (Inside or Outside Kubernetes)
|
ServiceNow MID Server
|
ServiceNow Discovery & Service Mapping
|
CMDB
4. Required Plugins and Licenses
You must have:
- ServiceNow Discovery
- Service Mapping
- ITOM Visibility / Container Visibility
- Kubernetes Discovery Plugin
- MID Server

5. Supported Kubernetes Environments
- Self-hosted Kubernetes (On-prem)
- Cloud Kubernetes (AKS, EKS, GKE)
- OpenShift

6. Prerequisites for Self-Hosted Kubernetes Discovery
6.1 Kubernetes Access
You need:
- Kubernetes API Server URL
- A Service Account Token
- CA Certificate (if required)

Permissions required:
- Read-only access to:
- Nodes
- Pods
- Services
- Deployments
- Namespaces
- Endpoints

6.2 MID Server
- Must have network access to the Kubernetes API server.
- Must trust the Kubernetes cluster SSL certificate.

7. Step-by-Step: Self-Hosted Kubernetes Discovery Setup
7.1 Create Kubernetes Service Account
example:
apiVersion: v1
kind: ServiceAccount
metadata:
name: servicenow-discovery
namespace: kube-system

Bind permissions:
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: servicenow-discovery-binding
subjects:
- kind: ServiceAccount
name: servicenow-discovery
namespace: kube-system
roleRef:
kind: ClusterRole
name: view
apiGroup: rbac.authorization.k8s.io

Retrieve token:
kubectl get secret -n kube-system | grep servicenow-discovery
kubectl describe secret <secret-name> -n kube-system
7.2 Create Credential in ServiceNow
Go to:
Credentials → Discovery Credentials → New → Kubernetes Credential
Enter:
- API Server URL
- Token
- CA Certificate (if required)

7.3 Create Kubernetes Discovery Schedule
Go to:
Discovery → Discovery Schedules → New
Select:
- Type: Kubernetes
- MID Server: Your on-prem MID Server
- Credential: Kubernetes credential
- Target: Kubernetes API endpoint

Run discovery.
7.4 Validate CMDB Population
Check the following CMDB tables:
- cmdb_ci_kubernetes_cluster
- cmdb_ci_kubernetes_node
- cmdb_ci_kubernetes_pod
- cmdb_ci_kubernetes_service
- cmdb_ci_kubernetes_deployment
- cmdb_ci_container

8. Service Mapping for Kubernetes Applications

8.1 Identify Entry Point
Use:
- Ingress URL
- Load balancer IP
- API Gateway endpoint

8.2 Create Service Mapping Entry Point
Use:
- URL-based entry point
- Or IP and port

8.3 Enable Kubernetes and Container Patterns
Ensure:
- Kubernetes service patterns are active.
- Container discovery patterns are enabled.
- Database patterns are active.

8.4 Run Service Mapping
Service Mapping will:
- Discover frontend pods
- Trace backend services
- Identify database connections (if accessible)

9. Database Discovery Scenarios
Scenario 1: Database Outside Kubernetes (VM or Bare Metal)
- Use standard DB discovery with credentials.
Scenario 2: Database Inside Kubernetes
- Requires Kubernetes Discovery + DB patterns.
- Ensure DB ports are reachable.
- Ensure DB credentials exist.

Scenario 3: Cloud Managed Database
- Requires cloud integration plugin.

10. Limitations and Constraints
- Pod IPs are dynamic; mapping is service-based.
- Short-lived containers may appear and disappear quickly.
- Service Mapping does not inspect application code.
- Database discovery depends on network visibility and credentials.
- Without Kubernetes Discovery, backend and DB will not be mapped.

11. Best Practices
- Always enable Kubernetes Discovery for containerized apps.
- Use read-only service accounts.
- Keep MID Server close to the cluster.
- Label Kubernetes workloads properly.
- Validate CMDB before running Service Mapping.
- Test in non-production first.

12. Summary
- Traditional Discovery alone cannot map Kubernetes applications fully.
- Kubernetes Discovery is mandatory for backend and database visibility.
- Self-hosted Kubernetes is fully supported using MID Server and API integration.
- Once Kubernetes is discovered, Service Mapping will trace frontend → backend → database correctly.

Thanks & Happy to Help,
Prahlad Kumar (Tera Guru)
Solution Architect at HumIT
ITOM | ITAM | ITSM | CMDB | HRSD
LinkedIn: https://www.linkedin.com/in/prahlad-kumar-92a877117/

If this helps, please mark it as Helpful.👍