K9s Select Multiple Pods
To use the k9s select multiple pods feature, mark target rows in the pod view. You can then run one bulk action across every marked pod at once. Teams use this terminal workflow to clear bad pods or restart a stuck app fast. Still, broad cluster roles make bulk actions risky in live systems. One wrong key press can wipe out healthy workloads across a whole namespace. How the k9s select multiple pods workflow works K9s gives engineers a fast terminal view of their cluster resources. Instead of
Select Multiple Pods: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To use the k9s select multiple pods feature, mark target rows in the pod view. You can then run one bulk action across every marked pod at once. Teams use this terminal workflow to clear bad pods or restart a stuck app fast. Still, broad cluster roles make bulk actions risky in live systems. One wrong key press can wipe out healthy workloads across a whole namespace.
How the k9s select multiple pods workflow works
K9s gives engineers a fast terminal view of their cluster resources. Instead of typing long commands, users move a cursor up and down a pod list. When an engineer marks a pod row, the tool adds it to a batch group. The user can move down the list and mark more pods one by one. Users can also mark a full range of pods from top to bottom.
Once the batch is ready, the engineer picks an action like delete or restart. The terminal tool loops through the marked list and sends requests to the cluster API. Each pod gets its own request in a fast burst. The cluster checks the user role for that namespace and runs the change. Within seconds, all marked pods stop or restart based on the chosen action.
Teams filter the pod list before they mark any rows. A text filter narrows the view to one app or one broken state. This step lowers the chance of marking a healthy database pod by mistake. Still, the filter only hides rows on the screen and does not block permissions.
Why native roles leave bulk pod actions exposed
Kubernetes role bindings solve the basic question of who can enter a namespace. You can give an engineer a role that allows pod deletes in staging or production. That setup blocks outside users and stops read-only accounts from changing workloads. It works well for normal day-to-day checks and automated deploy tools.
The gap appears when a real person logs in during a tense outage. Native roles decide who logs in, not what individual requests do in flight. If a role allows pod deletion, it allows deleting one pod or fifty pods. The cluster API sees fifty valid delete requests and runs all of them right away.
Select Multiple Pods: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Shared admin files and long-lived local tokens make this risk much worse. When engineers keep broad rights on their laptops, every bulk selection carries high blast radius. Teams also struggle to see which human ran a batch action if accounts are shared. Also, viewing logs across multiple pods can pull raw user data onto local screens. Masking rules that rewrite emails, phone numbers, card numbers, and national IDs help reduce exposure.
Managing risk during bulk cluster operations
To keep live apps safe, teams should split daily viewing rights from bulk write actions. Engineers need read access to check pod health, read events, and view container states. They rarely need standing permission to delete dozens of pods at any hour. Removing standing write roles stops a stray selection from taking down a live service.
When a batch restart is needed, teams benefit from a quick peer check first. Having a second engineer approve the action catches bad filters before pods go down. Detailed command logs also help teams review what changed after an incident ends.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Can I run bulk actions across different namespaces at once?
Yes, if you switch the view to show all namespaces first. You can mark pods from different namespaces and run one action on the whole group.
What actions work when I mark multiple pods in K9s?
The most common bulk actions are deleting pods and killing stuck containers. Some single-pod actions like opening a shell only work on one pod at a time.
How do I clear my marked pods if I make a mistake?
You can toggle the mark on a single row to remove it from the batch. You can also use the clear command to unmark all rows before running an action.