Convert Figma logo to code with AI

boz logokail

kubernetes log viewer

1,970
93
1,970
32

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.

17,537

Faster way to switch between clusters and namespaces in kubectl

26,434

🐶 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:

  1. 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
    
  2. Ensure you have kubectl configured with access to your Kubernetes cluster.

  3. 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.

17,537

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.

26,434

🐶 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 Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

kail: kubernetes tail Build Status

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.

asciicast

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

FlagSelection
-l, --label LABEL-SELECTORmatch pods based on a standard label selector
-p, --pod NAMEmatch pods by name
-n, --ns NAMESPACE-NAMEmatch pods in the given namespace
--svc NAMEmatch pods belonging to the given service
--rc NAMEmatch pods belonging to the given replication controller
--rs NAMEmatch pods belonging to the given replica set
-d, --deploy NAMEmatch pods belonging to the given deployment
--sts NAMEmatch pods belonging to the given statefulset
-j, --job NAMEmatch pods belonging to the given job
--node NODE-NAMEmatch pods running on the given node
--ing NAMEmatch pods belonging to services targeted by the given ingress
-c, --containers CONTAINER-NAMErestrict which containers logs are shown for
--ignore LABEL-SELECTORIgnore pods that the selector matches. (default: kail.ignore=true)
--current-nsMatch pods in the namespace specified in Kubernetes' "current context"
--ignore-ns NAMEIgnore 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

FlagDescription
-h, --helpDisplay help and usage
--context CONTEXT-NAMEUse the given Kubernetes context
--dry-runPrint initial matched pods and exit
--log-level LEVELSet the logging level (default: error)
--log-file PATHWrite output to PATH (default: /dev/stderr)
--since DURATIONDisplay 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, --outputYou 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