hello this is will hallam from servicenow today i'll be showing you an example of how our ability to track changes in your kubernetes clusters can speed up the troubleshooting process the kubernetes api can provide configuration and state data in the form of yaml files the service now kubernetes discovery pattern includes an extension named get kubernetes yaml files and you can see this by navigating to pattern designer discovery patterns and then filter on the name kubernetes and open up the kubernetes discovery pattern then within the main pattern page on the basic tab you'll see a number of extensions which are available and the get kubernetes yaml files extension is the one which queries your various kubernetes objects and then pulls them into your servicenow instance into your cmdb as config files let's see an example of how this can help focus troubleshooting efforts and greatly improve resolution time here i've defined a tag based application service named reg site which is running in a kubernetes cluster it is currently in a warning state now if i drill into it on the details tab under related alerts i can see an alert has been generated due to a non-responsive redis replica service to gain further insight i select service map then from the service map tab select advanced map from the advanced map window i select the highlighted redis replica kubernetes service icon and that'll produce a details pane on the right side and within that details pane if i click on detailed properties that'll provide a list of all the cmdb objects which are related to my misbehaving service from here if i navigate to the tracked configuration file configuration item which is listed on the page i'm given a summary of the current state of that tracked configuration file the current content appears in the in the large middle section at the bottom i can see the recorded iterations the versions of that yaml content by selecting the two most recent and clicking compare i'm giving a side-by-side view of everything that changed between those different points in time due to the highlighting it's it's very easy for the eye to draw to the areas that change and i notice on line 28 it appears that someone might have made a typographical error on updating the file and changed the port number which would certainly account for a service becoming non-responsive from here a quick correction or rollback of the change is all that would be required to bring the service back online the kubernetes discovery pattern supports this functionality with services deployments daemon sets and stateful sets out of the box in a blog article which i'll link below i show how to further extend the pattern to do the same thing with config maps and a similar approach could be used to track other kubernetes objects as well that concludes my demonstration thank you for your time