← All articles
CONTAINERS Kubernetes Developer Tools: kubectl, k9s, Helm, and ... 2026-02-09 · 6 min read · kubernetes · kubectl · k9s

Kubernetes Developer Tools: kubectl, k9s, Helm, and Local Clusters

Containers 2026-02-09 · 6 min read kubernetes kubectl k9s helm docker containers

Kubernetes Developer Tools: kubectl, k9s, Helm, and Local Clusters

Kubernetes has a steep learning curve, and the tooling you choose dramatically affects how painful that climb is. This guide covers the essential tools for developers who work with Kubernetes, from kubectl basics to local development workflows.

kubectl Essentials

kubectl is the command-line interface for Kubernetes. Everything you can do with Kubernetes, you can do through kubectl.

Most-Used Commands

# Context and namespace
kubectl config get-contexts
kubectl config use-context staging
kubectl config set-context --current --namespace=my-app

# Get resources
kubectl get pods
kubectl get pods -o wide                    # more columns
kubectl get pods -o yaml                    # full YAML
kubectl get pods --all-namespaces           # all namespaces
kubectl get pods -l app=web                 # filter by label
kubectl get pods --field-selector status.phase=Running

# Describe (detailed info + events)
kubectl describe pod my-pod-abc123

# Logs
kubectl logs my-pod-abc123
kubectl logs my-pod-abc123 -f              # follow/stream
kubectl logs my-pod-abc123 -c sidecar      # specific container
kubectl logs my-pod-abc123 --previous      # previous crashed instance
kubectl logs -l app=web --all-containers   # all pods with label

# Exec into a pod
kubectl exec -it my-pod-abc123 -- /bin/sh
kubectl exec -it my-pod-abc123 -c sidecar -- /bin/sh

# Port forwarding
kubectl port-forward pod/my-pod-abc123 8080:80
kubectl port-forward svc/my-service 8080:80

# Apply and delete
kubectl apply -f deployment.yaml
kubectl delete -f deployment.yaml
kubectl apply -k ./overlays/staging         # kustomize

Useful kubectl Plugins (via krew)

krew is the plugin manager for kubectl. Install it, then add plugins:

# Install krew
# (see https://krew.sigs.k8s.io/docs/user-guide/setup/install/)

# Essential plugins
kubectl krew install ctx        # switch contexts quickly
kubectl krew install ns         # switch namespaces quickly
kubectl krew install neat       # clean up YAML output
kubectl krew install images     # show container images in use
kubectl krew install tree       # show resource hierarchy

# Usage
kubectl ctx staging             # switch context
kubectl ns my-app               # switch namespace
kubectl get pod my-pod -o yaml | kubectl neat  # clean YAML

kubectl ctx and kubectl ns save significant typing compared to the built-in context and namespace switching commands.

Shell Aliases

# .bashrc or .zshrc
alias k='kubectl'
alias kgp='kubectl get pods'
alias kgs='kubectl get services'
alias kgd='kubectl get deployments'
alias kl='kubectl logs'
alias kex='kubectl exec -it'
alias kaf='kubectl apply -f'
alias kdf='kubectl delete -f'

# Auto-completion
source <(kubectl completion bash)  # or zsh
complete -o default -F __start_kubectl k

k9s: TUI Management

k9s is a terminal-based UI for Kubernetes that makes cluster navigation fast and intuitive. It's the single best quality-of-life improvement for Kubernetes developers.

# Install
brew install derailed/k9s/k9s
# or
go install github.com/derailed/k9s@latest

# Launch
k9s
k9s -n my-namespace
k9s --context staging

Key Features

k9s reads your kubeconfig and supports multiple clusters and namespaces. The learning curve is about 10 minutes. After that, you'll reach for k9s before kubectl for most interactive tasks.

k9s vs kubectl

Use k9s for exploration, debugging, and interactive management. Use kubectl for scripting, CI/CD pipelines, and reproducible operations. They complement each other.

Lens IDE

Lens is a desktop Kubernetes IDE with a graphical interface. It provides cluster visualization, resource management, log viewing, and terminal access in a point-and-click interface.

Strengths: Lower learning curve than kubectl or k9s. Visual cluster overview. Built-in Prometheus metrics visualization. Multi-cluster management.

Weaknesses: Electron-based (heavy on resources). The open-source version (OpenLens) was forked from the commercial version and has fewer features. Some workflows are slower than k9s for experienced users.

Best for: Developers who are new to Kubernetes or prefer GUIs. Teams where not everyone needs to be a kubectl expert.

Helm for Package Management

Helm is the package manager for Kubernetes. It packages Kubernetes manifests into reusable "charts" with configurable values.

Basic Usage

# Add a repository
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

# Search for charts
helm search repo postgresql

# Install a chart
helm install my-db bitnami/postgresql --set auth.postgresPassword=secret

# Install with values file
helm install my-db bitnami/postgresql -f values.yaml

# List releases
helm list

# Upgrade
helm upgrade my-db bitnami/postgresql -f values.yaml

# Rollback
helm rollback my-db 1

# Uninstall
helm uninstall my-db

# See what would be applied (dry run)
helm install my-db bitnami/postgresql -f values.yaml --dry-run

Values Files

# values.yaml
replicaCount: 2

image:
  repository: my-app
  tag: "1.2.3"

service:
  type: ClusterIP
  port: 80

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 256Mi

ingress:
  enabled: true
  hostname: app.example.com

When to Use Helm

Helm is most valuable for installing third-party software (databases, monitoring tools, ingress controllers) into your cluster. For your own applications, consider whether Helm's templating complexity is justified versus plain Kubernetes manifests or Kustomize.

The trade-off: Helm charts abstract away Kubernetes details, which is great until you need to debug a problem. Then you're debugging both Kubernetes and Helm's templating layer.

Skaffold and Tilt for Local Development

The inner development loop in Kubernetes (code change, build image, deploy, test) is slow without the right tools. Skaffold and Tilt automate this loop.

Skaffold

Skaffold watches your source code, rebuilds container images, and redeploys to Kubernetes when files change.

# skaffold.yaml
apiVersion: skaffold/v4beta6
kind: Config
build:
  artifacts:
    - image: my-app
      context: .
      docker:
        dockerfile: Dockerfile
deploy:
  kubectl:
    manifests:
      - k8s/*.yaml
# Development mode (watch + rebuild + redeploy)
skaffold dev

# One-time deploy
skaffold run

# Render manifests without deploying
skaffold render

Skaffold's dev mode provides file sync (for interpreted languages, it copies changed files into the container without rebuilding), port forwarding, and log tailing. It integrates with Docker, Buildpacks, Jib, and ko for building images.

Tilt

Tilt takes a similar approach but uses a Tiltfile (written in Starlark, a Python dialect) for more programmable configuration.

# Tiltfile
docker_build('my-app', '.')
k8s_yaml('k8s/deployment.yaml')
k8s_resource('my-app', port_forwards='8080:80')
tilt up

Tilt provides a web dashboard at localhost:10350 showing build status, logs, and resource health. It's more opinionated than Skaffold but provides better visibility into your development environment.

Skaffold vs Tilt

Feature Skaffold Tilt
Config format YAML Starlark (Python-like)
UI Terminal only Web dashboard
File sync Yes Yes
Learning curve Lower Higher
Extensibility Moderate High
Google backing Yes Docker (acquired)

For simple projects, Skaffold's YAML-based config is easier to start with. For complex multi-service setups where you need custom build logic, Tilt's programmable Tiltfile is more powerful.

Kind and minikube for Local Clusters

You need a local Kubernetes cluster for development. The two main options are Kind and minikube.

Kind (Kubernetes in Docker)

Kind runs Kubernetes clusters using Docker containers as nodes. Each "node" is a Docker container running the Kubernetes components.

# Install
brew install kind
# or
go install sigs.k8s.io/kind@latest

# Create a cluster
kind create cluster

# Create with custom config
kind create cluster --config kind-config.yaml

# Load local images (no registry needed)
kind load docker-image my-app:latest

# Delete cluster
kind delete cluster
# kind-config.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
    extraPortMappings:
      - containerPort: 30000
        hostPort: 80
  - role: worker
  - role: worker

Strengths: Fast startup (under 60 seconds), multi-node clusters, no VM overhead, runs in CI easily. Weaknesses: No built-in dashboard, no LoadBalancer support without extras, networking can be tricky.

minikube

minikube creates a local Kubernetes cluster in a VM (or Docker container).

# Install
brew install minikube

# Start
minikube start
minikube start --cpus 4 --memory 8192

# Addons
minikube addons enable ingress
minikube addons enable metrics-server
minikube addons enable dashboard

# Dashboard
minikube dashboard

# Access services
minikube service my-service

# Stop/delete
minikube stop
minikube delete

Strengths: Addons system (ingress, dashboard, metrics), LoadBalancer support via minikube tunnel, more beginner-friendly. Weaknesses: Slower startup than Kind, single-node by default, higher resource usage.

Which to Choose

Factor Kind minikube
Startup speed Fast Moderate
Multi-node Easy Possible but harder
CI/CD Excellent Possible
Addons Manual Built-in
Resource usage Lower Higher
LoadBalancer Needs MetalLB minikube tunnel

Use Kind for CI pipelines, testing, and when you want a lightweight cluster that starts fast. Use minikube for local development when you want built-in addons (ingress, dashboard) and a more complete environment.

Recommendations