Learning Kubernetes - Episode 17 - Working with All Resources in Kubernetes
In this episode, we'll discuss the kubectl all keyword for managing multiple Kubernetes resources at once. We'll learn how to use kubectl get all, kubectl delete all, and understand what resources are included in all.
#Introduction
Note
If you want to read the previous episode, you can click the Episode 16 thumbnail below
Episode 16In the previous episode, we learned about Node Selector for controlling Pod placement on specific nodes. In episode 17, we'll discuss the all keyword in kubectl, which provides a convenient way to work with multiple Kubernetes resources at once.
Note: Here I'll be using a Kubernetes Cluster installed through K3s.
When managing Kubernetes clusters, you often need to view or manage multiple resource types simultaneously. Instead of running separate commands for Pods, Services, Deployments, etc., kubectl provides the all keyword as a shortcut to work with common resources together.
#What Is the All Keyword?
The all keyword in kubectl is a special resource type that represents a collection of commonly used Kubernetes resources. When you use kubectl get all, it retrieves multiple resource types in a single command, giving you a comprehensive view of your application's components.
Think of all like a preset filter that includes the most frequently accessed resources - it's not literally "all resources" in your cluster, but rather a curated list of common workload-related resources.
Key characteristics of the all keyword:
- Multiple resource types - Retrieves several resource types at once
- Convenience shortcut - Saves time compared to individual commands
- Namespace-scoped - Works within a specific namespace
- Predefined list - Includes specific resource types, not everything
- Read and delete operations - Works with get, delete, and describe commands
- Label filtering - Can be combined with label selectors
#Resources Included in All
The all keyword includes these resource types:
- pods (po) - Running containers
- services (svc) - Network services
- deployments (deploy) - Deployment controllers
- replicasets (rs) - ReplicaSet controllers
- statefulsets (sts) - StatefulSet controllers
- daemonsets (ds) - DaemonSet controllers
- jobs - One-time tasks
- cronjobs (cj) - Scheduled tasks
- replicationcontrollers (rc) - Legacy ReplicationController
Important
Important: The all keyword does NOT include all resource types. It excludes ConfigMaps, Secrets, PersistentVolumes, PersistentVolumeClaims, Namespaces, Nodes, and many other resources.
#Using kubectl get all
The most common use of all is with the get command.
#Basic Usage
Get all resources in the current namespace:
sudo kubectl get allOutput example:
NAME READY STATUS RESTARTS AGE
pod/nginx-deployment-abc123-xyz 1/1 Running 0 5m
pod/nginx-deployment-abc123-def 1/1 Running 0 5m
pod/nginx-deployment-abc123-ghi 1/1 Running 0 5m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.43.0.1 <none> 443/TCP 30d
service/nginx ClusterIP 10.43.100.50 <none> 80/TCP 5m
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/nginx-deployment 3/3 3 3 5m
NAME DESIRED CURRENT READY AGE
replicaset.apps/nginx-deployment-abc123 3 3 3 5m#Get All in Specific Namespace
View resources in a specific namespace:
sudo kubectl get all --namespace productionOr using the shorthand:
sudo kubectl get all -n production#Get All Across All Namespaces
View resources across all namespaces:
sudo kubectl get all --all-namespacesOr using the shorthand:
sudo kubectl get all -AOutput includes namespace column:
NAMESPACE NAME READY STATUS RESTARTS AGE
default pod/nginx-abc123 1/1 Running 0 5m
production pod/api-xyz789 1/1 Running 0 10m
development pod/test-def456 1/1 Running 0 2m
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)
default service/kubernetes ClusterIP 10.43.0.1 <none> 443/TCP
production service/api ClusterIP 10.43.100.50 <none> 8080/TCP#Get All with Wide Output
Show additional details like node placement and IP addresses:
sudo kubectl get all -o wide#Get All with Label Selector
Filter resources by labels:
sudo kubectl get all -l app=nginxGet resources with specific label value:
sudo kubectl get all -l environment=productionGet resources with multiple labels:
sudo kubectl get all -l app=nginx,environment=production#Get All with Field Selector
Filter by field values:
sudo kubectl get all --field-selector status.phase=Running#Watch All Resources
Monitor resources in real-time:
sudo kubectl get all --watchOr using the shorthand:
sudo kubectl get all -w#Using kubectl delete all
The all keyword also works with the delete command to remove multiple resources at once.
Warning
Warning: Be extremely careful with kubectl delete all as it removes multiple resources simultaneously. Always verify the namespace and use label selectors to avoid accidental deletions.
#Delete All in Current Namespace
Delete all resources in the current namespace:
sudo kubectl delete all --allThis deletes all Pods, Services, Deployments, ReplicaSets, etc. in the current namespace.
#Delete All in Specific Namespace
Delete all resources in a specific namespace:
sudo kubectl delete all --all --namespace developmentOr:
sudo kubectl delete all --all -n development#Delete All with Label Selector
Delete only resources matching specific labels:
sudo kubectl delete all -l app=nginxDelete resources with multiple label criteria:
sudo kubectl delete all -l app=nginx,environment=development#Dry Run Before Deleting
Preview what would be deleted without actually deleting:
sudo kubectl delete all --all --dry-run=clientOr with server-side dry run:
sudo kubectl delete all --all --dry-run=server#Delete with Confirmation
Get a list of resources before deletion:
# First, see what will be deleted
sudo kubectl get all -l app=nginx
# Then delete
sudo kubectl delete all -l app=nginx#Using kubectl describe all
You can also use describe with all:
sudo kubectl describe allThis shows detailed information for all resources in the current namespace.
Describe all resources with specific label:
sudo kubectl describe all -l app=nginx#Practical Examples
#Example 1: View Application Resources
Check all resources for a specific application:
sudo kubectl get all -l app=web-appOutput:
NAME READY STATUS RESTARTS AGE
pod/web-app-abc123-xyz 1/1 Running 0 10m
pod/web-app-abc123-def 1/1 Running 0 10m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/web-app ClusterIP 10.43.50.100 <none> 80/TCP 10m
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/web-app 2/2 2 2 10m
NAME DESIRED CURRENT READY AGE
replicaset.apps/web-app-abc123 2 2 2 10m#Example 2: Clean Up Development Environment
Remove all development resources:
# First, verify what will be deleted
sudo kubectl get all -n development
# Then delete
sudo kubectl delete all --all -n development#Example 3: Monitor Application Deployment
Watch resources during deployment:
sudo kubectl get all -l app=api -w#Example 4: Check Resources by Environment
View production resources:
sudo kubectl get all -l environment=production -n productionView staging resources:
sudo kubectl get all -l environment=staging -n staging#Example 5: Clean Up Failed Jobs
Delete all failed jobs and their pods:
# View failed jobs
sudo kubectl get jobs --field-selector status.successful=0
# Delete all resources for failed jobs
sudo kubectl delete all -l job-name=<job-name>#Example 6: Application Lifecycle Management
Deploy and verify application:
# Deploy application
sudo kubectl apply -f app-deployment.yml
# Check all resources
sudo kubectl get all -l app=myapp
# If issues, delete and redeploy
sudo kubectl delete all -l app=myapp
sudo kubectl apply -f app-deployment.yml#What's NOT Included in All
Important resources NOT included in all:
#ConfigMaps and Secrets
# Not included in 'all'
sudo kubectl get configmaps
sudo kubectl get secrets#Persistent Volumes and Claims
# Not included in 'all'
sudo kubectl get persistentvolumes
sudo kubectl get persistentvolumeclaims#Namespaces
# Not included in 'all'
sudo kubectl get namespaces#Nodes
# Not included in 'all'
sudo kubectl get nodes#Service Accounts
# Not included in 'all'
sudo kubectl get serviceaccounts#Ingress
# Not included in 'all'
sudo kubectl get ingress#Custom Resources
# Not included in 'all'
sudo kubectl get customresourcedefinitions#Getting Truly All Resources
To get ALL resource types (including those not in all):
sudo kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get --show-kind --ignore-not-found -n <namespace>Or for all namespaces:
sudo kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get --show-kind --ignore-not-found -A#Common Use Cases
#Use Case 1: Quick Application Overview
Get a quick overview of your application:
sudo kubectl get all -l app=myapp -o wide#Use Case 2: Namespace Cleanup
Clean up an entire namespace:
# Preview
sudo kubectl get all -n temp-namespace
# Delete
sudo kubectl delete all --all -n temp-namespace#Use Case 3: Troubleshooting
Check all resources when troubleshooting:
# Check current state
sudo kubectl get all
# Watch for changes
sudo kubectl get all -w
# Get detailed info
sudo kubectl describe all#Use Case 4: Environment Comparison
Compare resources across environments:
# Production
sudo kubectl get all -n production -l app=api
# Staging
sudo kubectl get all -n staging -l app=api#Use Case 5: Release Management
Manage application releases:
# Check current release
sudo kubectl get all -l release=v1.0
# Delete old release
sudo kubectl delete all -l release=v0.9
# Deploy new release
sudo kubectl apply -f release-v1.1.yml#Common Mistakes and Pitfalls
#Mistake 1: Assuming All Means Everything
Problem: Expecting all to include ConfigMaps, Secrets, PVCs, etc.
Solution: Remember all only includes workload resources. Check other resources separately:
sudo kubectl get all
sudo kubectl get configmaps
sudo kubectl get secrets
sudo kubectl get pvc#Mistake 2: Deleting Without Verification
Problem: Running kubectl delete all --all without checking first.
Solution: Always verify before deleting:
# First, see what will be deleted
sudo kubectl get all
# Then delete if sure
sudo kubectl delete all --all#Mistake 3: Wrong Namespace
Problem: Deleting resources in the wrong namespace.
Solution: Always specify namespace explicitly:
# Check current namespace
sudo kubectl config view --minify | grep namespace
# Specify namespace explicitly
sudo kubectl delete all --all -n development#Mistake 4: Not Using Label Selectors
Problem: Deleting more than intended.
Solution: Use label selectors for precision:
# Instead of deleting everything
# sudo kubectl delete all --all
# Delete specific app
sudo kubectl delete all -l app=myapp#Mistake 5: Forgetting Dependent Resources
Problem: Deleting all but leaving ConfigMaps, Secrets, PVCs.
Solution: Delete dependent resources separately:
sudo kubectl delete all -l app=myapp
sudo kubectl delete configmap -l app=myapp
sudo kubectl delete secret -l app=myapp
sudo kubectl delete pvc -l app=myapp#Mistake 6: Not Using Dry Run
Problem: Accidentally deleting production resources.
Solution: Use dry run first:
# Dry run to see what would be deleted
sudo kubectl delete all --all --dry-run=client
# If correct, run actual delete
sudo kubectl delete all --all#Best Practices
#Always Specify Namespace
Be explicit about namespace:
# Good
sudo kubectl get all -n development
# Risky (uses default namespace)
sudo kubectl get all#Use Label Selectors
Filter resources with labels:
# Good - specific
sudo kubectl get all -l app=myapp,version=v2
# Less specific
sudo kubectl get all#Verify Before Deleting
Always check before deletion:
# Step 1: View
sudo kubectl get all -l app=myapp
# Step 2: Verify it's correct
# Step 3: Delete
sudo kubectl delete all -l app=myapp#Use Dry Run for Destructive Operations
Test deletions first:
sudo kubectl delete all --all -n temp --dry-run=client#Combine with Other Resource Types
Don't forget non-all resources:
# Delete application completely
sudo kubectl delete all -l app=myapp
sudo kubectl delete configmap -l app=myapp
sudo kubectl delete secret -l app=myapp
sudo kubectl delete pvc -l app=myapp
sudo kubectl delete ingress -l app=myapp#Use Output Formatting
Get better visibility:
# Wide output
sudo kubectl get all -o wide
# Custom columns
sudo kubectl get all -o custom-columns=NAME:.metadata.name,KIND:.kind,STATUS:.status.phase
# JSON for scripting
sudo kubectl get all -o json#Document Your Cleanup Scripts
Create documented cleanup scripts:
#!/bin/bash
# Cleanup development environment
echo "Cleaning up development namespace..."
# Show what will be deleted
echo "Resources to be deleted:"
kubectl get all -n development
# Confirm
read -p "Continue with deletion? (yes/no): " confirm
if [ "$confirm" = "yes" ]; then
kubectl delete all --all -n development
kubectl delete configmap --all -n development
kubectl delete secret --all -n development
echo "Cleanup complete"
else
echo "Cleanup cancelled"
fi#Monitor During Operations
Watch resources during operations:
# Terminal 1: Watch resources
sudo kubectl get all -w
# Terminal 2: Perform operations
sudo kubectl apply -f deployment.yml#Alternative Commands
#Get Specific Resource Types
Instead of all, specify exact types:
sudo kubectl get pods,services,deployments#Get Resources by API Group
Get resources from specific API group:
sudo kubectl get deployments.apps,statefulsets.apps#Use Custom Aliases
Create shell aliases for common operations:
alias kga='kubectl get all'
alias kgaa='kubectl get all --all-namespaces'
alias kdaa='kubectl delete all --all'#Conclusion
In episode 17, we've explored working with the all keyword in Kubernetes. We've learned what all includes, how to use it with get and delete commands, and important considerations when working with multiple resources.
Key takeaways:
- all is a shortcut for common workload resources
- Includes Pods, Services, Deployments, ReplicaSets, StatefulSets, DaemonSets, Jobs, CronJobs
- Does NOT include ConfigMaps, Secrets, PVCs, Namespaces, Nodes, and many others
- Works with
get,delete, anddescribecommands - Can be combined with label selectors and namespace filters
- Always verify before deleting with
all - Use dry run for destructive operations
- Specify namespace explicitly to avoid mistakes
- Remember to handle non-all resources separately
- Use label selectors for precise resource management
The all keyword is a convenient tool for managing Kubernetes resources, but it requires careful use, especially with delete operations. By understanding what's included and following best practices, you can efficiently manage your cluster resources while avoiding common pitfalls.
Are you getting a clearer understanding of working with all resources in Kubernetes? In the next episode 18, we'll discuss Service, one of the most fundamental concepts in Kubernetes networking for exposing and accessing applications. Keep your learning momentum going and look forward to the next episode!
Note
If you want to continue to the next episode, you can click the Episode 18 thumbnail below
Episode 18