Kubernetes discovery using patterns

The ServiceNow ITOM Visibility finds Kubernetes and OpenShift components using patterns and creates application services containing them. Discovery also finds Kubernetes events and frequently updates the CMDB to reflect the dynamic Kubernetes environment.

Discovery uses the Kubernetes pattern and its extension sections to discover Kubernetes components:

• The Collect OpenShift info extension section of the Kubernetes pattern discovers the OpenShift components of the Kubernetes deployment. The OpenShift Build Config extension section is available from Store version 1.0.53.
• The Service Mesh extension discovers service mesh details. This information enables the pattern to create service-to-service relations, shown as Connects to::Connected. Service mesh discovery requires deploying Istio on your K8s (Kubernetes) cluster. The Service Mesh extension section is available from Kubernetes extension classes. It’s supported on the ServiceNow AI Platform using the Madrid release or later.
• The Collect Container Repository and extension section finds container registries and images in these registries.

In addition, Discovery uses the Kubernetes Event pattern to discover events for Kubernetes components.

From the 1.0.68 release on ServiceNow Store, Service Mapping can use CI relationships to add the Kubernetes components to application services during tag-based discovery.

Discovery uses the following patterns to discover the entire Kubernetes infrastructure deployed on GCP, AWS, and Azure:

• Google Cloud Platform (GCP) – Get Kubernetes Clusters.
• Amazon AWS Cloud - Get Kubernetes Clusters.
• Microsoft Azure - Get Kubernetes Clusters.

These patterns query the Cloud, collect data on all Kubernetes clusters, and create a serverless schedule for each cluster. When the cluster is deleted, the schedule is marked as inactive. This feature eliminates the overhead of creating and managing multiple credentials and serverless discovery schedules per cluster. The Cloud infrastructure patterns are triggered through standard Cloud discovery.

Starting with Discovery and Service Mapping Patterns version 1.31.0, you can choose to discover Docker image CIs only, without discovering Docker container CIs. Check your entitlements to determine whether you have access to 2026 Container Packaging. For more information, see Disable Docker container CI discovery.

Supported versions

The patterns have been validated with the following Kubernetes and Red Hat OpenShift versions:

Request apps on the Store

Visit the ServiceNow Store to view all the available apps, and for information about submitting requests to the store. For cumulative release notes information for all released apps, see the ServiceNow Store version history release notes.

Prerequisites

Note: For prerequisites for Kubernetes Cloud infrastructure discovery, see below.

Note: Running automatic serverless Kubernetes schedules fetches the Bearer token. Adding credentials is unnecessary.

Perform the following steps so that Discovery can use the pattern to successfully find Kubernetes.

1. Deploy the latest Discovery and Service Mapping Patterns application from ServiceNow Store.

2. On the Kubernetes platform, find the parameters to set up Kubernetes discovery:

   • Find the URL of the kubeapi server:

     1. On the Kubernetes platform, run the following command:

        kubectl cluster-info

     2. In the output, find the line that states the URL of the kubeapi server. For example, Kubernetes control plane is running at

        https://10.154.144.146:443

   • Find the namespaces of the kubeapi server:

     1. On the Kubernetes platform, run this command:

        kubectl get namespaces

     2. In the output, find the line that states the namespaces. For example, kube-system.

        • Find the Kubernetes username and password:

     3. On the Kubernetes platform, run this command:

        kubectl config view

     4. In the output, find the username and password.

        **Note:** If in a certain environment, `kubectl config view` command is not showing the expected details, use the `supported` command from the Kubernetes admin to fetch the user name and password details.

-   Find the valid Bearer token with the proper permissions:
    -   If you know the default token name, use the command in the following format: `kubectl describe secret <default-token-token name>`.

        For example: `kubectl describe secret default-token-g6pwc`.

    -   If you don't know the default token name, use the command: `kubectl describe secret`.

1. Verify that the API Server is reachable from the MID Server for successful Kubernetes discovery.
2. Verify that the user configured on the Kubernetes platform has GET permissions to run the following /api/v1 elements:
   • https://<url>/api/v1/namespaces/
   • https://<url>/api/v1/namespaces/<namespace>
   • https://<url>/api/v1/namespaces/kube-system/endpoints/kube-controller-manager
   • https://<url>/api/v1/services
   • https://<url>/api/v1/pods
   • https://<url>/api/v1/nodes
   • https://<url>/api/v1/replicationcontrollers
   • https://<url>/apis/networking.k8s.io/v1/ingresses
   • https://<url>/apis/apps/v1/deployments
   • https://<url>/apis/apps/v1/statefulsets
   • https://<url>/apis/apps/v1/daemonsets
   • https://<url>/apis/apps/v1/replicasets
   • https://<url>/apis/batch/v1/cronjobs
   • https://<url>/apis/batch/v1/jobs

3. To discover the OpenShift components of the Kubernetes deployment, verify that the user configured on the Kubernetes platform has GET permissions to run the following /api/v1 elements:

   • /apis/apps.openshift.io/v1/deploymentconfigs
   • ​/apis/build.openshift.io/v1/buildconfigs​
   • /apis/route.openshift.io/v1/routes​
   • /apis/user.openshift.io/v1/groups​
   • /apis/user.openshift.io/v1/users​
   • /apis/project.openshift.io/v1/projects​
   • /apis/image.openshift.io/v1/images​

   • /apis/image.openshift.io/v1/imagestreams To discover service mesh information:

   • Deploy Istio on your K8s cluster.

   • Provide the Prometheus URL.
   • Configure Prometheus to scrape metrics from Istio.

   • Activate Get Kubernetes Config Files extension to:

   • Discover configuration files.

   • Create tracked configuration files.
   • Map the configuration files workloads and services with a relationship. Note: Tracked files content is in the JSON format from version 1.0.92. Tracked files content is in YAML format in version 1.0.91 and earlier.

4. Create the Kubernetes credentials on the ServiceNow platform:

   1. On the ServiceNow AI Platform, navigate to All > Discovery > Credentials.
   2. Select New.
   3. Select Kubernetes Credentials.
   4. On the form, fill in the fields.

5.  On the Kubernetes credentials form, select **Update**.

1. Create a serverless discovery schedule for the Kubernetes pattern.

   Create and define the serverless execution pattern as described in the product documentation. Configure the parameters required by the Kubernetes pattern as follows:

1. Create a serverless discovery schedule for the Kubernetes Event pattern. Configure the schedule to run every 5 or 10 minutes.

   Note: When the pattern is run for the first time, it stores an event_timestamp. Later on it collects only the delta events based on the timestamp. The more often the pattern is run, the fewer updates to the CMDB IRE are needed.

   Create a serverless execution pattern for the discovery schedule and assign it to the Kubernetes Events pattern. Configure the parameters required by the Kubernetes pattern as described in Configuring execution pattern attributes.

2. To include discovered components into service instances, enable CI relationships used in tag-based discovery by Service Mapping. These CI relationships are available from the 1.0.68 release on the ServiceNow Store. For operational steps, see Tag-based discovery configuration.

Prerequisites for Kubernetes Cloud infrastructure discovery

For the Google Cloud Platform (GCP) – Get Kubernetes Clusters pattern, perform the following:

1. In the ServiceNow instance, set up a Google Cloud Platform (GCP) service account with valid credentials and permissions.
2. On the GCP infrastructure, set up the MID Server with full access to all Cloud APIs: Set Cloud API access scopes to "Allow full access to all Cloud APIs". The MID Server instance can access only the Clusters specific to the project.

3. Navigate to sys_properties.list and configure the following properties:

   • sn_itom_pattern.k8s_midserver: Specify a valid MID Server name.

   • sn_itom_pattern.k8s_create_schedule_enabled: Set the value to true.

     Note: Enabling the sn_itom_pattern.k8s_create_schedule_enabled property automatically creates a serverless schedule for your cloud clusters, eliminating the need for manual scheduling. If you have an existing manual schedule and want to convert it to an automatic one, enable the property. Your manual schedule will be updated; no additional schedule will be created.

4. Create and run Google Cloud Discovery

   Note:

   To fetch the Bearer token, while running GKE Kubernetes schedule, use the gcloud command:

   gcloud config config-helper --format="value(credential.access_token)"

   Configuring gcloud in the MID Server instance grants access to the GKE cluster to fetch the token.

For the Amazon Elastic Kubernetes Service (EKS) cluster discovery, perform the following:

1. In the ServiceNow instance, set an AWS service account with valid management account credentials and permissions.

   1. Verify that the Amazon Elastic Kubernetes Service (EKS) Cluster has a cluster role with the read-only access to all resources.
   2. Create cluster role binding between the cluster role and a Kubernetes user. For example, read-onlyuser.
   3. Create an AWS IAM role with the policy EKSReadOnly.
   4. Associate the IAM role with the Kubernetes user in one of the following ways:
      • In the cluster, edit the aws-auth ConfigMap.

      • Run the command:

        eksctl create iamidentitymapping --cluster yourClusterName --arnarn:aws:iam::yourAccountID:role/yourIAMRoleName --username read-only-user

2. Run Amazon Elastic Kubernetes Service (EKS) cluster discovery in one of two ways: Using the AWS Command Line Interface (CLI) or without using the AWS CLI. First, set the system property sn_itom_pattern.k8s_aws_cli_to_generate_token to use the model you choose. This system property is set to true by default.

   • Set this system property to true to use AWS CLI to generate a token.

   • Set this system property to false to use Assume Roles to generate a token.

   • Run Amazon Elastic Kubernetes Service (EKS) cluster discovery using AWS CLI:

     1. Set up the MID Server with the AWS CLI configured. Configuring AWS CLI credentials grants access to the Amazon Elastic Kubernetes Service (EKS) cluster.

        Note: The user logged in to the system must be the same as the MID Server user.

     2. To generate the Bearer token, While running the Amazon Elastic Kubernetes Service (EKS) schedule, use the AWS CLI command:aws eks get-token --cluster-name <cluster_name>.

        Configuring the AWS CLI user/role in the MID Server instance grants access to the Amazon Elastic Kubernetes Service (EKS) cluster to generate the token.

   • Run Amazon Elastic Kubernetes Service (EKS) cluster discovery without using AWS CLI:

     Note:

     This feature is supported from Discovery and Service Mapping Patterns version 1.0.96 - December 2022.

     Refer to the following KB for detailed instructions: KB1182188: EKS cluster discovery using STS AssumeRoles (Without AWS CLI)

3. Navigate to sys_properties.list and configure the following properties:

   • sn_itom_pattern.k8s_midserver: Specify a valid MID Server name.

   • sn_itom_pattern.k8s_create_schedule_enabled: Set the value to true.

     Note: Enabling the sn_itom_pattern.k8s_create_schedule_enabled property automatically creates a serverless schedule for your cloud clusters, eliminating the need for manual scheduling. If you have an existing manual schedule and want to convert it to an automatic one, enable the property. Your manual schedule will be updated; no additional schedule will be created.

4. Create and run an AWS Cloud Discovery schedule.

For Microsoft Azure Kubernetes Services (AKS)- Kubernetes cluster discovery, perform the following:

1. Update to the latest Discovery and Service Mapping Patterns version.
2. In the ServiceNow instance, configure the Azure Service Account with valid Azure credentials and permission.

3. Navigate to sys_properties.list and configure the following properties:

   • sn_itom_pattern.k8s_midserver: Specify a valid MID Server name.

   • sn_itom_pattern.k8s_create_schedule_enabled: Set the value to true.

     Note: Enabling the sn_itom_pattern.k8s_create_schedule_enabled property automatically creates a serverless schedule for your cloud clusters, eliminating the need for manual scheduling. If you have an existing manual schedule and want to convert it to an automatic one, enable the property. Your manual schedule will be updated; no additional schedule will be created.

     .

4. If you don't have local accounts with Kubernetes RBAC and want to improve pattern efficiency, navigate to MID Server > Properties and set the sn_itom_pattern.aks_fetch_local_ad_token property to false.

5. Run an Azure cloud discovery schedule.
6. Configure the MID Server in the Discovery schedules according to the cluster account type. If you don't have Local accounts with RBAC, you can ignore this step.

**Note:**

-   The user logged in to the system must be the same as the MID Server user.
-   For detailed information about AKS Cluster Discovery configuration, see the [AKS Cluster Discovery Configuration Details \[KB1220553\]](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1220553) article in the Now Support Knowledge Base.