DISCLAIMER: this example of enhancing a discovery pattern comes with no support or warranty. Caveat Emptor!

One of the great things the Kubernetes discovery pattern does out of the box is track changes to deployments, daemonsets, statefulsets, and services. It pulls in the YAML for all those things and tracks it as a Tracked Configuration File. This provides a handy interface for seeing exactly what changed between iterations of those objects. For an example, see this video.

NOTE: this functionality is provided by the "Get Kubernetes YAML Files" extension of the "Kubernetes Cluster" pattern, which may not be enabled by default on your instance.

Given that everything in Kubernetes can be represented as a YAML file, I thought it would be a worthy exercise to try and extend that base functionality to another commonly-used Kubernetes construct, the configmap. In the end it didn't prove very difficult to get a basic enhancement working, here's how I did it.

Create a New CI Class

First I had to create a table to store the configmap information; I did this by following the documentation here. I created my Kubernetes Configmap class as a child of Kubernetes Workload, which already contained deployments, services, etc. For my initial effort I chose to simply inherit all the attributes from the parent class and accept the default relationship, which was a Hosts:Hosted On relationship to the Kubernetes Cluster record. I made a note of the new table name, "u_cmdb_ci_kubernetes_configmap".

Update Pattern

My next step was to update the Kubernetes Cluster pattern so that it queried the "configmaps" API endpoint and populated my new CMDB table. Code re-use was heavy here, as the pattern already extracts data from similar endpoints.

NOTE: in my example I opted to modify the existing Kubernetes Pattern; in your own environment, especially anything considered "production", you may wish to maintain separation between ServiceNow-provided code and your own, for example make your own copy of the pertinent patterns, libraries and extensions and modify those.

On loading the Kubernetes Cluster pattern into Pattern Designer and then opening the "identification" section, I did a search on "deployment" to find that the existing code which populates cmdb_ci_kubernetes_deployment is part of a library named "Kubernetes Workload Components".

Expanding that library within the pattern revealed a large number of steps, so rather than copying each step by hand via the UI, I navigated back to Pattern Designer->Discovery Patterns page, then opened "Kubernetes Workload Components" directly and copied the "Pattern text" field contents from the "Pattern" tab into a text editor.

From my text editor, I was able to copy all the existing steps involving deployments and paste them to the bottom of the file. I then copied and pasted the updated text back into the "Pattern text" field.

NOTE: I could have skipped transferring the text into an editor, but doing so helped me make sure to match up all the brackets.

Copying the existing deployment steps gave me a base from which to more easily generate comparable steps for configmaps. What followed was returning to the Kubernetes Cluster pattern in Pattern Designer and clicking through the new steps, changing "deployment" or "deployments" to "configmap" and modifying the table name to match my new CI class ("u_cmdb_ci_kubernetes_configmap").

After completing this exercise, I performed a test run of the pattern against a cluster to verify that u_cmdb_ci_kubernetes_configmap was being populated. I was pleased to have success without having to go back and tweak things more than once or twice.

Update YAML Extension

Once I had my new CMDB table being populated, the next step was to similarly enhance the Get Kubernetes YAML Files extension to include configmaps. I did this directly in the Pattern Designer UI, as there weren't a lot of steps to be copied. First I copied the existing "get deployment yaml files", "create tracked files for deployment", and "create relations from files to deployment" steps, renaming them accordingly to apply to the configmap objects and the new configmap table. The last bit of work was to augment the union operations which pulled all the separate object types together.

Result

With my enhancement effort completed, upon running a discovery against my Kubernetes cluster I could now see all its configmap objects reflected as tracked config files in my CMDB.

When viewing the dependencies for my cluster, I could see the Hosts:Hosted On relationship reflected as well.

After going through this exercise once, I'm looking forward to exploring this approach by further refining the relationships and adding more Kubernetes objects to my CMDB.