Kubectl-Get-All Resource Exhaustion

The standard operational interface for Kubernetes, kubectl, provides a wide array of capabilities for interacting with cluster objects. However, a persistent point of friction for administrators and developers is the behavior of the kubectl get all command. While the phrasing suggests a comprehensive retrieval of every object within a namespace or cluster, the actual execution is limited to a specific subset of resources. This creates a visibility gap where critical components such as Secrets, ConfigMaps, and Custom Resource Definitions (CRDs) remain hidden, potentially leading to incomplete debugging sessions or missed configuration errors. To bridge this gap, the community has developed specialized plugins and shell-based workarounds that allow for the genuine exhaustion of all available Kubernetes resources.

The Limitations of Standard kubectl get all

The primary issue with the native kubectl get all command is that it does not actually return all resources. Instead, it returns a curated, limited set of the most common workload-related objects.

The resources included in a standard kubectl get all call are:

• pods
• services
• daemon sets
• deployments
• replica sets
• jobs
• cronjobs
• stateful sets

The impact of this limitation is significant for the end user. For instance, if a developer is attempting to audit the security posture of a namespace, they might run kubectl get all and conclude that no sensitive data is present, failing to realize that Secrets and ConfigMaps are not included in that output. This discrepancy is intentional from a design perspective—likely to avoid flooding the terminal with thousands of lines of low-level system data—but it creates a blind spot for those needing a complete inventory of their environment.

Consequently, the native command fails to surface:

• Ingress objects
• Secrets
• ConfigMaps
• Custom Resource Definitions (CRDs)
• PersistentVolumeClaims (PVCs)
• and other critical API-level resources.

The kubectl-get-all Plugin Solution

To resolve the shortcomings of the native command, the kubectl-get-all plugin (a fork of ketall) has been developed. This tool is designed to provide a truly exhaustive list of every resource the Kubernetes cluster has to offer, effectively ignoring the filters imposed by the standard kubectl binary.

The core functionality of kubectl-get-all is to iterate through the cluster's API and retrieve every resource that is actually present. This ensures that nothing is missed, regardless of whether it is a standard object or a custom resource provided by an operator.

Plugin Capabilities and Flag Options

The kubectl-get-all plugin introduces several powerful flags to refine the exhaustive search, allowing users to filter by time, scope, and content.

• General Resource Retrieval
  The basic execution of kubectl-get-all lists all resources. By default, this tool excludes events. The rationale for this is that events are generated at such a high volume that they are hardly ever useful in a general resource list and would otherwise clutter the output.

• Including Events
  If a user specifically requires the event logs as part of their global resource sweep, they can use the following flag:
  kubectl-get-all --exclude=
  By passing an empty value to the exclude flag, the plugin is instructed to include events in the output.

• Temporal Filtering
  The plugin allows users to filter resources based on their creation time. This is particularly useful for identifying what was deployed during a specific window of time.
  kubectl-get-all --since 1m
  The --since flag supports human-readable durations, allowing for flexible timeframes such as 1m (one minute) or more complex strings like 1y1d1h1m1s (one year, one day, one hour, one minute, and one second).

• Namespace and Scope Control
  Users can restrict the exhaustive search to a specific namespace:
  kubectl-get-all --namespace=default
  Alternatively, if the goal is to see resources that exist at the cluster level (non-namespaced resources), the following flag is used:
  kubectl-get-all --only-scope=cluster

• Performance and Caching
  To speed up the retrieval process, the plugin can utilize a cache of server resources:
  kubectl-get-all --use-cache
  The impact of this option is a faster response time, although it carries the risk of failure or inaccuracy if the HTTP cache has become stale.

• Advanced Integration with kubectl Options
  Because kubectl-get-all is designed to complement the standard toolset, it can be combined with common kubectl options. This allows for complex filtering and output formatting. For example, to target a specific context and namespace while filtering for a specific selector:
  KUBECONFIG=otherconfig kubectl-get-all -o name --context some --namespace kube-system --selector run=skaffold

Installation Pathways for kubectl-get-all

There are multiple methods to integrate kubectl-get-all into a workflow, depending on the user's preference for package management or manual binary installation.

Installation via Krew

The recommended method for installation is via Krew, which serves as the primary plugin manager for kubectl. Krew simplifies the lifecycle of plugins, handling installation, updates, and removals.

If Krew is already installed, the command to add the plugin is:
kubectl krew install get-all

Once installed via Krew, the plugin is accessed as kubectl get-all. If Krew is not yet present on the system, it can be obtained from https://github.com/kubernetes-sigs/krew.

Manual Binary Installation

For users who prefer not to use a plugin manager, the plugin can be installed directly from the release binaries. This involves downloading the appropriate archive for the system architecture, extracting it, and ensuring the binary is executable.

For Linux AMD64:
curl -Lo get-all.gz https://github.com/stackitcloud/kubectl-get-all/releases/latest/download/get-all-linux-amd64.tar.gz && \
tar -xvf get-all.tar.gz && chmod +x get-all

For Darwin ARM64 (macOS):
curl -Lo get-all.gz https://github.com/stackitcloud/kubectl-get-all/releases/latest/download/get-all-darwin-arm64.tar.gz && \
tar -xvf get-all.tar.gz && chmod +x get-all

Building from Source

For developers or those who wish to audit the code before execution, building from source is an option. This requires the installation of go and git. The process is initiated by running:
go build

Shell-Based Alternatives for Resource Discovery

In environments where installing plugins is prohibited, administrators can utilize a combination of native kubectl commands and shell utilities like xargs to achieve a similar result to kubectl-get-all.

The API-Resource Pipeline

The most effective way to list all resources in a namespace using only native tools is to query the API for all listable, namespaced resources and then iterate through them.

The following command achieves this:
kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get --show-kind --ignore-not-found -n <namespace>

This pipeline works in three distinct layers:
1. kubectl api-resources --verbs=list --namespaced -o name: This retrieves a raw list of every resource type that supports the "list" verb and is constrained to a namespace.
2. xargs -n 1: This takes each resource type from the previous list and passes it as a single argument to the next command.
3. kubectl get --show-kind --ignore-not-found -n <namespace>: This executes the get command for that specific resource type. The --show-kind flag is critical here, as it ensures the output identifies what type of resource is being displayed, and --ignore-not-found prevents the terminal from being flooded with errors for resource types that are defined in the API but not currently utilized in that specific namespace.

Discovering Resource Definitions

To understand the full scope of what is available in a cluster without necessarily retrieving the instances of those resources, the following command is used:
kubectl api-resources -o wide

This provides a broad overview of all resource definitions, including their short names, API groups, and whether they are namespaced.

Advanced Data Retrieval and Formatting

While kubectl-get-all and the API pipeline solve the problem of visibility, the native kubectl get command provides deep-drill capabilities for extracting specific data from the resulting resources.

Output Formatting Options

The -o flag allows users to transform the raw output of a get command into more usable formats.

• YAML Output
  To retrieve the full configuration of a specific pod in YAML format:
  kubectl get pod my-pod -o yaml

• JSONPath for Precise Extraction
  JSONPath allows users to target specific fields within a resource. For example, to retrieve the ca.crt from a ConfigMap:
  kubectl get configmap myconfig -o jsonpath='{.data.ca\.crt}'

• Template Output
  For more complex logic, the --template flag can be used. To retrieve a base64 encoded value from a secret where the key contains dashes:
  kubectl get secret my-secret --template='{{index .data "key-name-with-dashes"}}'

Custom Columns and Filtering

Custom columns allow users to define exactly which fields they want to see in the output, removing the noise of default views.

• Custom Column Example
  To see the container name and image for a specific pod:
  kubectl get pod test-pod -o custom-columns=CONTAINER:.spec.containers[0].name,IMAGE:.spec.containers[0].image

• Field Selectors
  Field selectors allow for filtering based on the state of the object. To list only pods that are currently in the Running phase:
  kubectl get pods --field-selector=status.phase=Running

• Label Selectors
  Labels are the primary way to organize resources in Kubernetes. To get the version label of all pods associated with a specific application:
  kubectl get pods --selector=app=cassandra -o jsonpath='{.items[*].metadata.labels.version}'

Resource Management and Analysis

Beyond simply listing resources, kubectl provides tools to analyze the state of those resources and manage their lifecycle.

Sorting and Organization

Large lists of resources can be difficult to navigate. The --sort-by flag allows users to organize data logically.

• Sort by Name
  kubectl get services --sort-by=.metadata.name

• Sort by Restart Count
  To identify unstable pods:
  kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'

• Sort by Capacity
  To analyze storage allocation:
  kubectl get pv --sort-by=.spec.capacity.storage

• Sort by Timestamp
  To see events in chronological order:
  kubectl get events --sort-by=.metadata.creationTimestamp

Subresource Exploration

Some resources have subresources that provide additional detail without needing to dump the entire object.

• Status Subresource
  To view the status of a specific pod:
  kubectl get pod web-pod-13je7 --subresource status

• Deployment Status
  To view the status of a deployment:
  kubectl get deployment nginx-deployment --subresource=status

Comparison and Diffing

To prevent accidental configuration drift, the diff command allows users to compare the current cluster state against a local manifest.
kubectl diff -f ./my-manifest.yaml

Resource Interaction and Modification

Once resources are identified via exhaustive listing, they can be modified or rolled back.

• Updating Images
  To perform a rolling update of a container image in a deployment:
  kubectl set image deployment/frontend www=image:v2

• Rollout History and Undo
  Users can track the history of a deployment:
  kubectl rollout history deployment/frontend
  And revert to a previous version:
  kubectl rollout undo deployment/frontend
  Or revert to a specific revision:
  kubectl rollout undo deployment/frontend --to-revision=2

• Monitoring Rollout Status
  To watch the progress of a rollout:
  kubectl rollout status -w

Summary of Resource Retrieval Commands

The following table compares the different methods for listing resources in a Kubernetes environment.

Analysis of Exhaustive Resource Retrieval

The transition from kubectl get all to kubectl-get-all represents a shift from a "convenience-first" approach to an "accuracy-first" approach. The native kubectl get all command is a curated view, designed for the most common 80% of user interactions. While this reduces cognitive load for beginners, it is a liability for experienced operators who must ensure that no "orphan" resources (such as an unused Secret or a lingering ConfigMap) are left in a namespace.

The implementation of the kubectl-get-all plugin and the shell-based API pipeline solves this by treating the Kubernetes API as a source of truth rather than a filtered list. By iterating through the results of kubectl api-resources, these tools ensure that the operator sees every single object.

The impact of this capability is most evident during disaster recovery or cluster migration. When moving workloads between clusters, missing a single Secret or ConfigMap can lead to a cascading failure of the application. By using an exhaustive listing method, an administrator can create a comprehensive manifest of every resource required for the application to function.

Furthermore, the ability to filter by --since allows for a "time-travel" debugging approach. If a cluster began exhibiting errors at 10:00 AM, running kubectl-get-all --since 10m (assuming the current time is 10:10 AM) allows the user to see exactly what changed in the environment during that window. This is significantly more efficient than manually checking every possible resource type.

In conclusion, while the native kubectl tool provides the building blocks for resource retrieval, the gap in the get all command necessitates the use of plugins or advanced shell scripting. For any professional environment, relying on kubectl get all is insufficient; the adoption of kubectl-get-all or the api-resources pipeline is mandatory for achieving total cluster visibility.

Sources

1. kubectl-get-all GitHub
2. Fabian Lee - Kubernetes Resources in a Namespace
3. Kubernetes Quick Reference
4. Kubernetes kubectl get Reference