# A Search Box That Only Sees the Current Page Is Not Search > A search box that filters only the page you are on is not search, it is a per-page filter wearing search's clothes. Source: https://zop.dev/resources/blogs/kubernetes-cluster-wide-resource-search Published: 2026-07-24 · Author: riya-mittal · Tags: kubernetes, devops --- A search box that filters only the page you are on is not search, it is a per-page filter wearing search's clothes. The difference is invisible until the list is long enough to paginate. Then it becomes the gap between finding the object you need and concluding, wrongly, that it is not there. ## The list you could not actually search Kubernetes clusters are large. One namespace can hold hundreds of pods, and a cluster carries thousands of objects across Pods, Deployments, ConfigMaps, Secrets, Jobs, and Nodes. Any view of them has to paginate. When the search box only matches rows already loaded on the current page, the object you are hunting is invisible unless it happens to sit on that page. You type a name, get nothing, and move on, even though the pod is right there on page four. Worse, several list types had no search at all. The only options were to page through by hand or drop back to the command line. Architecture diagram ## Search that covers the whole cluster, on every list ZopDay now puts a search box on every Kubernetes [resource list](https://zop.dev/resources/blogs/zopnight-atlas-region-aware-cloud-mapping), Pods, Deployments, Namespaces, ConfigMaps, Secrets, Jobs, Nodes, and more, and it filters by name across the entire cluster rather than the loaded page. Type a name and the match surfaces wherever it lives, whether that is page one or page forty. The lists that were not searchable at all are searchable now. The behavior is the same everywhere, so you no longer have to remember which views support finding a resource and which force you to scroll. Search means the same thing on every list: look through all of it. ## What changes when you go looking for one object The point of a resource list is to answer "where is this thing." Page-scoped search answered a narrower question, "is this thing on the screen right now," and let you mistake one for the other. | | Before | Now | |---|---|---| | Lists with search | Some | Every Kubernetes list | | Search scope | The current page | The whole cluster | | Object on a later page | Reported as not found | Found | | Fallback | Page by hand or use the CLI | Type the name | ## When it matters, and when it does not On a small cluster where every list fits on one page, page-scoped and cluster-wide search return the same result, and this changes nothing you would notice. It matters the moment a cluster is large enough to paginate, which is exactly when you least want to search by hand: a crashlooping pod during an incident, the ConfigMap behind a bad rollout, the secret nobody wrote down. That is the moment "search the page" and "search the cluster" stop being the same thing, and the difference is whether you find it now or conclude it is missing.