DEV Community

Cover image for A Script for Simpler Kubernetes Cluster Management for Lean Teams
Vinuja Khatode
Vinuja Khatode

Posted on • Edited on

A Script for Simpler Kubernetes Cluster Management for Lean Teams

I recently worked through a common infrastructure challenge - how can a small team or startup effectively manage Kubernetes without getting bogged down in operational complexity? My exploration led to the development of a CLI script designed to streamline essential cluster tasks. This post isn't just about the script itself, but the thought process behind it, the trade-offs considered, and the solutions chosen to make Kubernetes a bit more approachable.

What are we trying to solve? Kubernetes Management Overhead for Lean Teams

Image description

Imagine a startup or a lean engineering team. They want the power and scalability of Kubernetes, but they don't have a dedicated DevOps army. They need to:

  1. Automate common Kubernetes operations efficiently via a CLI.
  2. Ensure essential tools like Helm (for package management) and KEDA (for event-driven scaling) are consistently installed and configured.
  3. Quickly spin up new deployments that can scale dynamically based on application needs (e.g., message queue length, CPU/memory pressure).
  4. Have a straightforward way to monitor the health and status of these deployments without deep-diving into kubectl enchantments for every check.
  5. Maintain clear documentation for these processes and tools.

This scenario often leads to a significant amount of repetitive manual work or the need to learn multiple complex tools. The goal here was to explore a lightweight, script-based approach to relieve some of this burden.

Image description

The Approach: Keep it Simple, Keep it Bash

For this exploration, Bash was chosen for its ubiquity in DevOps environments and its directness for orchestrating system commands. While tools like Python with Kubernetes client libraries or IaC solutions like Terraform offer richer abstractions, the aim was to create a self-contained CLI tool with minimal external dependencies, aligning with the need for simplicity for a smaller team. The focus was on direct command orchestration and native OS integration, rather than abstracting away the underlying Kubernetes primitives entirely.

The script, k8s-manager.sh, is structured modularly, with distinct functions for each core task. This design promotes maintainability and extensibility. It also includes OS detection to ensure compatibility between Linux and macOS environments.

Key Capabilities of k8s-manager.sh

Let's look at how k8s-manager.sh addresses some of the common operational tasks. The script uses colored output for clearer operational feedback to make the output user-friendly for better readability and also because it is fun.

1. check_kubectl(): Ensuring the Foundation

Any interaction with Kubernetes starts with kubectl. This function ensures it's available, installing it if necessary. This removes a common initial friction point.

You'd run it like this:
./k8s-manager.sh check-kubectl

And here it is in action on Ubuntu:
kubectl on Ubuntu

2. context(): Smooth Cluster Navigation

For teams managing multiple environments (dev, staging, prod), switching contexts can be frequent. This function simplifies that, allowing users to specify a kubeconfig and context name.

How to use it:
./k8s-manager.sh context CONTEXT_NAME [path_to_kubeconfig]

Here are some examples:

  • Trying a non-existent context:

Image description

  • Switching to a valid context:

Image description

  • Running with no arguments:

Image description

3. install_helm(): Managing Kubernetes Packages

Helm is indispensable for managing third-party applications on Kubernetes. This function automates the installation process, ensuring a consistent setup.

Command:
./k8s-manager.sh install-helm

In action on Ubuntu:

Helm on Ubuntu

4. install_keda(): Enabling Event-Driven Scaling

Modern applications often benefit from scaling based on event queues, metrics, or other triggers beyond just CPU/memory. KEDA enables this. This function handles KEDA's installation via its Helm chart, a common deployment method.

Run it with:
./k8s-manager.sh install-keda

  • Successful installation:
    KEDA success 1
    KEDA success 2

  • When things go wrong (e.g., namespace issues):
    KEDA namespace terminating

  • If kubectl is missing:
    KEDA kubectl not found

5. create_deployment(): Streamlined Application Deployment

This is a core piece of the script. Instead of manually crafting multiple YAML files for a deployment, service, and autoscaler, this function interactively gathers the necessary parameters and generates these resources. It aims to reduce boilerplate and enforce consistency. The inclusion of KEDA ScaledObject generation here directly supports the goal of event-driven applications.

The command:
./k8s-manager.sh create-deployment

  • A successful run: Create deployment success And the HPA gets created too: HPA created
  • When inputs are incorrect: Create deployment fail

6. install_metrics_server(): Powering Resource-Based Autoscaling

For standard CPU/memory autoscaling (often used alongside KEDA or as a baseline), the Metrics Server is essential. This automates its setup.

Command:
./k8s-manager.sh install-metrics-server

See it in action:
Metrics server install 1
Metrics server install 2

7. check_health(): Quick Deployment Status Checks

Post-deployment, check_health() offers a consolidated view of an application's status. Given a deployment name, it searches across namespaces and aggregates critical information:

  • Deployment status
  • Pod status
  • Service status
  • Resource utilization (if Metrics Server is active)
  • KEDA ScaledObject status
  • HPA status
  • Recent events
  • Paths to the generated configuration files

This provides a quick and comprehensive health check, invaluable for troubleshooting or routine monitoring.

Command:
./k8s-manager.sh check-health DEPLOYMENT_NAME

An example output:
Check health output

Reflections and Trade-offs

Developing this script highlighted a few common infrastructure considerations:

  • Cross-Platform Compatibility: Ensuring script portability between Linux and macOS required careful consideration of shell command variations and installation paths.
  • Input Validation: Implementing comprehensive validation for create_deployment inputs was critical to prevent malformed resource definitions. This involved handling various Kubernetes naming conventions and resource unit formats.
  • YAML Management: While the script generates YAML, it doesn't manage state in the way Terraform does. For managing many deployments, a proper stateful tool is generally preferred. This script is more for bootstrapping and ad-hoc management.
  • Simplicity vs. Abstraction: While Bash offers simplicity, it lacks the robust error handling and testing frameworks of higher-level languages. For more complex scenarios, a Python-based tool or Terraform/Pulumi might be a better trade-off, despite their steeper learning curves for some ops tasks.
  • Idempotency: Care was taken to make functions like installers check for existing installations. True idempotency in shell scripting can be tricky and is a key reason why declarative IaC tools are popular.

The process reinforced that even for powerful platforms like Kubernetes, simple scripting can still provide significant value in automating repetitive tasks and reducing the cognitive load for common operations, especially for teams that prioritize straightforward, imperative tooling for certain tasks.

Full documentation for the script, outlining its usage in more detail, can be found here.

Interested in the code? The full script is available in my repository: k8s-manager.sh

Future Considerations

If this were to evolve into a more widely used tool, I'd focus on:

  • Enhanced Input Validation & Error Handling: Making it more resilient to unexpected inputs or cluster states.
  • RBAC Hardening: Ensuring the script operates with the least privilege necessary.
  • Testing Framework: Implementing a more formal testing approach.
  • Configuration Templating: Moving beyond simple cat <<EOF for YAML generation.

Wrapping Up

This exploration into building k8s-manager.sh was a practical exercise in addressing common Kubernetes operational hurdles with a relatively lightweight solution.

If you've reached this point, I'd love to hear your thoughts or if you've tackled similar challenges with different approaches.

Resource References (from original report, for further reading on technologies used):

Top comments (0)

Some comments may only be visible to logged-in visitors. Sign in to view all comments.