Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.katakate.org/llms.txt

Use this file to discover all available pages before exploring further.

This guide explains how to use the helper scripts under utils/.

​
Wipe a disk for thin‑pool provisioning

Script: utils/wipe-disk.sh
Destructive operation. This irreversibly erases all partitions, RAID metadata, filesystems, and attempts discards on the target device. Double‑check the device path.

​
Usage

sudo ./utils/wipe-disk.sh /dev/nvme2n1
You will be prompted to type YES to proceed. The script will:
  • Remove filesystem signatures (wipefs -a)
  • Zap the partition table (sgdisk --zap-all)
  • Zero the beginning and end of the disk (dd)
  • Attempt block discard (blkdiscard) if supported
List disks to find the correct device: 
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT
Requirements: Linux with wipefs, sgdisk, and blkdiscard; run as root or via sudo.

​
High‑density CPU/memory stress test

Script: utils/stress_test.sh This script launches many sandboxes to validate CPU limit enforcement and observe resource behavior.

​
What it does

  • Creates namespace stress-test
  • Generates k7-stress-*.yaml files, each with:
    • before_script that installs stress-ng and htop via apk
    • CPU and memory limits per sandbox
  • Launches sandboxes in batches (default 50 total, batches of 10)
  • Sets up a cleanup trap on Ctrl+C to delete resources and namespace
Default parameters (edit inside the script if desired):
  • COUNT=50
  • NAMESPACE="stress-test"
  • CPU_LIMIT="300m"
  • MEM_LIMIT="2Gi"
  • STRESS_MEM="1500M"

​
Run

bash utils/stress_test.sh
Monitor during the test: 
k7 top -n stress-test
watch 'k3s kubectl top pods -n stress-test --sort-by=cpu'
Cleanup when done (also done automatically on Ctrl+C): 
k7 delete-all -n stress-test -y
rm k7-stress-*.yaml
k3s kubectl delete namespace stress-test
Notes:
  • The generated YAML uses Alpine and installs packages in before_script. Ensure the container can run apk (i.e., not forced non‑root during setup). If you enforce strict non‑root, consider prebuilding an image with dependencies.
  • Ensure your node(s) have sufficient CPU/RAM to handle the configured load.