Kubernetes is hard. Whether your crashing application needs rescue, you’re doing a routine audit, should update config maps or load balancer settings, workload permissions, or need to retire a microservice safely, the first thing to do would be to search for YAMLs of interest. The kubectl lets you see and edit configs once the exact resource is identified. At best, kubectl lets you do the exact label filter, which is not always easy to use.
A bigger challenge is to find configurations within the context of applications and related YAMLs, for example, searching for particular AWS ELB load balancer annotation in Services that are exposed using Ingress? Or searching for configmap mounted to a workload that uses more than 4GB memory and is granted write permissions to cluster APIs.
Doing this across multiple clusters complicates Kubernetes operators’ (human operator) lives even more. This article will describe how we approach this problem, the capabilities involved in Kubevious Search Engine, and how to use it.
We looked at how modern travel, vacation rental, and car sale sites solved the search problem. That usually involves a text-based search that allows partial and fuzzy matching. Then, the search results are narrowed down using predefined filters. Lastly, we added the ability for any arbitrary programmatical filters (see markers below).
As you might have already guessed, all this is working across all clusters that are registered within Kubevious.
As the name suggests, this is a Google-like search that scans YAML configurations. Any terms visible in the Kubevious Browser can be used in the search criteria. The search operation is hierarchy and application-aware, so names of deployments, pods, services, config maps, etc., can be used to return contextualized results. Partial and approximate terms are also acceptable.
In the example below, we are searching for “redis”. The search engine returns 16 results from the “test-cluster-6” and 84 from the “saas-prod” clusters.
Clicking on any of the search results would navigate to the cluster browser screen for further inspection.
We can extend the search query with additional terms like “redis port master” to find which ports are redis master nodes listening to:
Or search for persistent volumes attached to all redis nodes using “redis pvc” search criteria:
Kubevious Search allows narrowing down search results using the additional filters on the left side. Multiple filters can be used at a time to help you find the resource that needs attention.
As you might have noticed, results include all kinds of resources as long as there is a text match. Kind Filter is helpful to reduce the results to a particular kind of object, such as Cluster Role, Config Map, or even synthetic object kinds like Application, Init Container, etc.
Below we are searching for all “redis” related Config Maps.
The Kind Filter can be used without providing a search term. For example, we can search for all applications that are starting with Init Containers.
Label filter is self-explanatory. It can filter configuration just like kubectl. But unlike kube control, Label Filter comes with label autocompletion (yes, partial and using approximate string matching!).
And also value auto-completion. Please note that label value autocompletion results are relevant to the label provided.
Just like in the case of text search results include all kinds of entries.
You can narrow down further using additional label filters, kind filter or search terms. Below we search for “heapster” related workloads that have “addonmanager.kubernetes.io/mode=Reconcile” label set.
The Annotation filter works exactly like the Label filter, including key and value autocompletion, except search is performed across annotation entries. The Annotation filter can be combined with other filters.
In the example below, we are looking for resources with “service.beta.kubernetes.io/aws-load-balancer-backend-protocol=http” annotation set.
Kubevious identifies misconfigurations, conflicts, and violations of best practices and marks resources as such with warnings and errors. Kubevious is also equipped with Rules Engine, which allows coding custom rules to raise custom errors and warnings on resources
Kubevious Search also allows filtering results to resources that have (or don’t have) errors and/or warnings.
Clicking on the search result would navigate to the cluster browser, where additional details of the error can be further introspected.
Just like with other filters, warning and error filters can be combined with text criteria and others.
Markers filter is probably the most powerful way of finding YAMLs that need attention. Before getting into filtering by marker, we should have a step back and give a quick introduction on “markers”. Using Rules Engine, users can write their own custom scripts to associate user-defined icons (the markers).
In the example rule below, we check if any network policies are defined for applications if associate “ingress-network-policy-not-defined” accordingly.
Those markers are visible in the cluster browser. It’s an entirely separate topic on its own, so you can learn more about Rules Engine here.
Getting back to markers filter. The search engine also allows additionally filtering by markers. In the example below, we are looking for redis (the label filter) applications (the kind filter) that don’t have any network policies applied (the marker filter). Multiple markers filters can be selected.
Such search capabilities are not available in kubectl or other tools, leaving operators in the dark. This is crucial to deploy and manage applications on Kubernetes successfully. Kubevious helps with quickly identifying resources that need urgent attention. That especially important when application health is degraded, and operators need to perform search and rescue across multiple clusters. You can get started and achieve clarity in your Kubernetes right now by visiting and signing up at Kubevious Portal. Self-service onboarding takes 5 minutes.
Good luck, and happy Kubing!