Top Related Projects
Bash script to tail Kubernetes logs from multiple pods at the same time
This repository is no longer maintained, please checkout https://github.com/JamesTGrant/kubectl-debug.
Faster way to switch between clusters and namespaces in kubectl
🐶 Kubernetes CLI To Manage Your Clusters In Style!
Quick Overview
Kail is a Kubernetes log viewer that allows users to tail logs from multiple pods and containers simultaneously. It provides a convenient way to monitor and debug applications running in Kubernetes clusters by aggregating logs from various sources into a single stream.
Pros
- Easy-to-use command-line interface for viewing logs across multiple pods
- Supports filtering logs based on various criteria (namespace, label, container)
- Real-time log streaming with color-coded output for better readability
- Automatically detects new pods and containers, adjusting the log stream accordingly
Cons
- Limited to command-line usage, lacking a graphical user interface
- May become overwhelming with large numbers of pods or high log volumes
- Requires kubectl access and configuration for the target Kubernetes cluster
- Limited advanced log analysis features compared to dedicated log management tools
Getting Started
To get started with Kail, follow these steps:
-
Install Kail using one of the following methods:
# Using Homebrew (macOS) brew tap boz/repo brew install boz/repo/kail # Using Go go get github.com/boz/kail
-
Ensure you have kubectl configured with access to your Kubernetes cluster.
-
Run Kail to start tailing logs:
# Tail logs from all pods in the default namespace kail # Tail logs from pods with a specific label kail --label app=myapp # Tail logs from a specific namespace kail --ns kube-system
For more advanced usage and filtering options, refer to the project's README on GitHub.
Competitor Comparisons
Bash script to tail Kubernetes logs from multiple pods at the same time
Pros of kubetail
- Written in Bash, making it lightweight and easy to install without dependencies
- Supports custom colors for different pods, improving log readability
- Allows filtering logs by container name within pods
Cons of kubetail
- Limited to tailing logs from pods only, not supporting other Kubernetes resources
- Lacks advanced filtering options compared to kail
- May have performance limitations when dealing with a large number of pods
Code Comparison
kubetail:
kubectl logs -f $pod $container $since | sed -e "s/^/${color}[${pod_name}]${nocolor} /"
kail:
for _, m := range matches {
go k.tailLogs(m, out)
}
Key Differences
kail is written in Go and offers more advanced features like:
- Tailing logs from multiple resource types (pods, deployments, services, etc.)
- Powerful filtering capabilities using labels and annotations
- Better performance for large-scale log tailing
kubetail is simpler and more lightweight, focusing on pod log tailing with basic filtering and colorization options. It's easier to install and use for basic log viewing tasks.
Both tools serve the purpose of tailing Kubernetes logs, but kail is more feature-rich and suitable for complex environments, while kubetail is a straightforward solution for simpler use cases.
This repository is no longer maintained, please checkout https://github.com/JamesTGrant/kubectl-debug.
Pros of kubectl-debug
- Provides an interactive debugging environment for Kubernetes pods
- Supports multiple debugging tools like busybox, netshoot, and custom images
- Allows for real-time troubleshooting without modifying the original pod
Cons of kubectl-debug
- Requires additional setup and permissions in the Kubernetes cluster
- May have performance overhead due to running a separate debugging container
- Limited to debugging running pods, unlike kail which can stream logs from multiple sources
Code Comparison
kubectl-debug:
kubectl debug <pod-name> -it --image=busybox
kail:
kail --deploy=<deployment-name>
Key Differences
- kubectl-debug focuses on interactive debugging of individual pods
- kail is primarily a log streaming tool for multiple Kubernetes resources
- kubectl-debug provides a more comprehensive debugging environment
- kail is simpler to use for quick log analysis across multiple pods
Use Cases
kubectl-debug is ideal for:
- In-depth troubleshooting of specific pod issues
- Debugging network or filesystem problems in containers
kail is better suited for:
- Real-time log monitoring across multiple Kubernetes resources
- Quick identification of issues across deployments or namespaces
Both tools complement each other in a Kubernetes administrator's toolkit, with kubectl-debug offering deeper debugging capabilities and kail providing broader log visibility.
Faster way to switch between clusters and namespaces in kubectl
Pros of kubectx
- Offers both kubectx and kubens tools for managing Kubernetes contexts and namespaces
- Provides shell completion scripts for easier command-line usage
- Supports interactive mode with fzf integration for quick context/namespace switching
Cons of kubectx
- Limited to context and namespace management, unlike kail's log streaming capabilities
- Requires separate installation and setup compared to kail's single binary
- May have a steeper learning curve for users unfamiliar with Kubernetes context management
Code Comparison
kubectx:
kubectx my-cluster
kubens my-namespace
kail:
kail --deploy=my-deployment
kail --svc=my-service
Summary
kubectx focuses on Kubernetes context and namespace management, offering a specialized toolset for these tasks. kail, on the other hand, is primarily designed for log streaming from Kubernetes clusters. While kubectx provides a more comprehensive solution for context switching, kail excels in real-time log monitoring across multiple pods and containers. The choice between the two depends on the specific needs of the user and their Kubernetes workflow.
🐶 Kubernetes CLI To Manage Your Clusters In Style!
Pros of k9s
- More feature-rich with a full terminal UI for managing Kubernetes clusters
- Supports a wider range of Kubernetes resources and operations
- Offers customizable skins and color schemes for better visibility
Cons of k9s
- Steeper learning curve due to more complex interface and features
- Requires more system resources to run compared to kail's lightweight approach
Code Comparison
k9s (configuration example):
k9s:
refreshRate: 2
maxConnRetry: 5
enableMouse: false
headless: false
logoless: false
crumbsless: false
readOnly: false
noIcons: false
kail (usage example):
kail --deploy=myapp --since=5m
k9s offers a more comprehensive Kubernetes management experience with its rich UI and extensive feature set, while kail focuses specifically on log tailing with a simpler command-line interface. k9s is better suited for users who need a full-fledged Kubernetes management tool, whereas kail is ideal for those primarily interested in efficient log monitoring across multiple pods.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
kail: kubernetes tail
Kubernetes tail. Streams logs from all containers of all matched pods. Match pods by service, replicaset, deployment, and others. Adjusts to a changing cluster - pods are added and removed from logging as they fall in or out of the selection.
Usage
With no arguments, kail matches all pods in the cluster. You can control the matching pods with arguments which select pods based on various criteria.
All flags can be set by an environment variable - KAIL_POD=foo kail
is the same as kail --pod foo
.
Selectors
Flag | Selection |
---|---|
-l, --label LABEL-SELECTOR | match pods based on a standard label selector |
-p, --pod NAME | match pods by name |
-n, --ns NAMESPACE-NAME | match pods in the given namespace |
--svc NAME | match pods belonging to the given service |
--rc NAME | match pods belonging to the given replication controller |
--rs NAME | match pods belonging to the given replica set |
-d, --deploy NAME | match pods belonging to the given deployment |
--sts NAME | match pods belonging to the given statefulset |
-j, --job NAME | match pods belonging to the given job |
--node NODE-NAME | match pods running on the given node |
--ing NAME | match pods belonging to services targeted by the given ingress |
-c, --containers CONTAINER-NAME | restrict which containers logs are shown for |
--ignore LABEL-SELECTOR | Ignore pods that the selector matches. (default: kail.ignore=true ) |
--current-ns | Match pods in the namespace specified in Kubernetes' "current context" |
--ignore-ns NAME | Ignore pods in the given namespaces. Overridden by --ns , --current-ns . (default: kube-system ) |
Name Selection
When selecting objects by NAME
(--svc
, --pod
, etc...), you can either qualify it with a namespace to restrict the selection to the given namespace, or select across all namespaces by giving just the object name.
Example:
# match pods belonging to a replicaset named 'workers' in any namespace.
$ kail --rs workers
# match pods belonging to the replicaset named 'workers' only in the 'staging' namespace
$ kail --rs staging/workers
Combining Selectors
If the same flag is used more than once, the selectors for that flag are "OR"ed together.
# match pods belonging to a replicaset named "workers" or "db"
$ kail --rs workers --rs db
Different flags are "AND"ed together:
# match pods belonging to both the service "frontend" and the deployment "webapp"
$ kail --svc frontend --deploy webapp
Other Flags
Flag | Description |
---|---|
-h, --help | Display help and usage |
--context CONTEXT-NAME | Use the given Kubernetes context |
--dry-run | Print initial matched pods and exit |
--log-level LEVEL | Set the logging level (default: error ) |
--log-file PATH | Write output to PATH (default: /dev/stderr ) |
--since DURATION | Display logs as old as given duration. Ex: 5s , 2m , 1.5h or 2h45m (defaults: 1s ). See here for more information on the duration format. |
-o, --output | You can choose to display logs in default, raw (without prefix), json, pretty json and zerolog formats. |
Installing
Homebrew
$ brew tap boz/repo
$ brew install boz/repo/kail
Krew
$ kubectl krew install tail
$ kubectl tail -h
Downloading
Kail binaries for Linux and OSX can be found on the latest release page. Download and install into your $GOPATH/bin
.
Running in a cluster with kubectl
The docker image abozanich/kail is available for running kail
from within a kubernetes pod via kubectl
.
Note: be sure to include the kail.ignore=true
label, otherwise... it's logging all the way down.
Example:
# match all pods - synonymous with 'kail' from the command line
$ kubectl run -it --rm -l kail.ignore=true --restart=Never --image=abozanich/kail kail
# match pods belonging to service 'api' in any namespace - synonymous with 'kail --svc api'
$ kubectl run -it --rm -l kail.ignore=true --restart=Never --image=abozanich/kail kail -- --svc api
Building
Install build and dev dependencies
Install source code and golang dependencies
$ go get -d github.com/boz/kail
$ cd $GOPATH/src/github.com/boz/kail
$ make install-deps
Build binary
$ make
Install run against a demo cluster
$ minikube start
$ ./_example/demo.sh start
$ ./kail
# install image into minikube and run via kubectl
$ make image-minikube
$ kubectl run -it --rm -l kail.ignore=true --restart=Never --image=kail kail
Stress testing
Start minikube with a fair amount of CPU and memory.
$ minikube start --cpus 4 --memory 8192
Start stress.yml
resources.
$ kubectl create -f _example/stress.yml
Wait a while for the pods to run
$ kubectl get pods --namespace stress | grep Running | wc -l
100
Run kail
./kail --ns stress
Top Related Projects
Bash script to tail Kubernetes logs from multiple pods at the same time
This repository is no longer maintained, please checkout https://github.com/JamesTGrant/kubectl-debug.
Faster way to switch between clusters and namespaces in kubectl
🐶 Kubernetes CLI To Manage Your Clusters In Style!
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot