In this post, we will discuss several essential tools for Kubernetes (K8s); the most common are kubectl, Kind, Minikube, and K9s.

What is Kubernetes?

In full, Kubernetes (K8s) is an open-source orchestration platform designed to automate the deployment, scaling, and management of containerized applications.

1. The “Desired State”

The fundamental logic of K8s is the Desired State. Instead of manually starting containers, you tell Kubernetes: “I want three copies of my EMR application running on port 80.”. If one container crashes, K8s detects the failure and automatically restarts it to maintain that state.

2. Control Plane vs. Nodes

Kubernetes operates as a cluster, divided into two main sections:

The Control Plane

This is the “Management” layer that makes global decisions about the cluster.

  • API Server: The front end of the control plane (what kubectl talks to).

  • etcd: A consistent and highly-available key-value store used as Kubernetes’ backing store for all cluster data.

  • Scheduler: Matches new Pods to the healthiest Nodes based on resource requirements.

Nodes

These are the physical or virtual machines where your applications actually run.

  • Kubelet: An agent that runs on each node in the cluster, ensuring that containers are running in a Pod.

  • Container Runtime: The software responsible for running containers (like Podman or Docker).

3. Key Kubernetes Objects

These are the objects you will interact with most:

  • Pod: The smallest deployable unit in K8s; a wrapper around one or more containers.

  • Service: An abstract way to expose an application running on a set of Pods as a network service (provides a stable IP).

  • Deployment: Manages the lifecycle of Pods, providing declarative updates for Pods and ReplicaSets.

  • Namespace: A virtual cluster within a physical cluster, used to organize resources (e.g., development vs. production).

4. Why Kubernetes?

  • Scalability: Handling surges in healthcare data or user traffic.

  • Portability: Moving workloads between local VPS providers and major cloud platforms without changing your code.

  • Standardization: Using FHIR standards or EMR systems within a consistent, automated environment.

What is kubectl?

kubectl is the official Command Line Interface (CLI) for Kubernetes (K8s). It acts as the “translator” between you and the Kubernetes cluster. When you run a command, kubectl sends a request to the Kubernetes API Server, which then carries out the instructions across your servers.

Essential Command

kubectl follows the same diagnostic logic as standard Unix tools.

1. Monitoring & State (ls equivalent)

The get command is used to list any resource in the cluster.

kubectl get pods -A

This shows you every container (pod) currently running or failing across the entire cluster.

2. Deep Inspection (dmesg / journalctl equivalent)

If a pod is stuck, you need to see the “Events” happening in the background.

kubectl describe pod <pod_name>

This reveals why a container failed to start, such as “ImagePullBackOff” or “OOMKilled”.

3. Live Logs (tail -f equivalent) To see what the application is doing in real-time.

kubectl logs -f <pod_name>

This streams the standard output directly to your terminal.

4. Interactive Shell (ssh equivalent) If you need to enter the container to check files or network connectivity.

kubectl exec -it <pod_name> -- /bin/bash

This drops into a shell inside the container’s isolated environment.

GoalLinux Desktopkubectl
List Processesps auxkubectl get pods
Check Healthtop / htopkubectl top pod
System Eventsdmesgkubectl describe
Service Logsjournalctl -u servicekubectl logs

The logical difference when running kubectl with Podman versus Docker depends entirely on how you set up your local cluster (using tools like Kind or Minikube).

1. The Logical Difference: Daemon vs. Daemon-less

  • Docker: kubectl talks to a cluster where the “nodes” are managed by the Docker daemon. Docker must be running as a background service.

  • Podman: kubectl talks to a cluster where the nodes are Podman containers. This is “daemon-less” and can be “rootless,” meaning it is more secure and integrates better with standard Linux security features.

2. Interaction with Kind (Kubernetes in Docker/Podman)

If you are using Kind, the experience is nearly identical, but the setup command changes:

  • Docker: Kind defaults to Docker.

  • Podman: You must tell Kind to use the Podman socket:

KIND_EXPERIMENTAL_PROVIDER=podman kind create cluster

3. Command Comparison for Troubleshooting

Once the cluster is up, ‘kubectl’ commands are the exact same. However, if you need to debug the nodes themselves from your Linux host, your commands will change:

GoalDockerPodman
List K8s Nodesdocker pspodman ps
Check Node Logsdocker logs <node_id>podman logs <node_id>
Inspect Node Networkdocker inspect <node_id>podman inspect <node_id>
Enter a Nodedocker exec -it <node_id> shpodman exec -it <node_id> sh

Kind vs Minikube

To understand the difference between these tools, it is helpful to categorize them by their role in the Kubernetes lifecycle: Cluster Management (Kind/Minikube) vs. Resource Management (kubectl).

  • Kind (Kubernetes in Docker): It runs K8s nodes as containers. It is fast, lightweight, and perfect for testing.

  • Minikube: It usually runs K8s inside a Virtual Machine. It’s feature-heavy but uses more RAM.

Comparing Kind vs Minikube

FeatureKindMinikube
ArchitectureRuns K8s nodes as Containers.Runs K8s nodes inside a Virtual Machine (usually).
SpeedVery fast to start/stop.Slower due to VM overhead.
Resource UsageLightweight (Lean).Heavier on RAM and CPU.
Driver SupportOptimized for Podman and Docker.Supports KVM, VirtualBox, Docker, etc.

Which one is better for you?

Here is the decision matrix:

  • Choose Kind if:

You want speed: It starts and stops significantly faster than a VM.

You use Kind with Podman: It integrates perfectly with “daemon-less” services.

You have limited RAM: It is much lighter on system resources because it shares your Linux kernel.

  • Choose Minikube if:

You need “Add-ons”: Minikube has built-in commands like minikube dashboard or minikube ingress that automate complex setups.

You need persistent state: It is generally easier to “stop” and “resume” a Minikube VM than a Kind cluster.

K9s

K9s is not an acronym and does not “stand for” a string of words. It is a play on words (a pun) following the naming convention of Kubernetes. It is a phonetic pun on “Canines”.

While kubectl is essential for scripts, typing long commands repeatedly is inefficient. For daily monitoring, K9s is far superior as dashboard.

Think of K9s as htop for Kubernetes. It is a Terminal User Interface (TUI) that provides a real-time, interactive dashboard. Instead of typing, you use keyboard shortcuts:

l: View logs.

s: Shell into the pod.

d: Describe resource.

0: View all namespaces.

Compare Linux CLI with kubectl and K9s

GoalLinux CLIKubectlK9s Shortcut
View All Namespacesps -efkubectl get pods -APress 0
Live Logstail -f / journalctl -fkubectl logs -f <pod>Press l
Describe / Eventsdmesg / statkubectl describe pod <pod>Press d
Interactive Shellsshkubectl exec -it <pod> -- shPress s
Edit Resourcevim /etc/configkubectl edit pod <pod>Press e
Delete / Killkill -9kubectl delete pod <pod>Ctrl + d
Sort by CPUtop (by %CPU)kubectl top podsShift + p
Sort by Memorytop (by %MEM)kubectl top podsShift + m