kwd v0.2.1 · frühe Entwicklung

Wissen ob der Rollout ready ist
ohne in kubectl zu starren

Kleines Go CLI das Readiness mit client-go prüft. Einmaldurchlauf für Cron und CI, oder Daemon mit Slack und HTTP Probes.

Live Traffic auf gghstats · Cosign signierte Releases · MIT

Readiness ohne Monitoring Stack. Workloads deklarieren. Urteil bekommen.

Für Operatoren die jetzt ein Urteil brauchen

Eine Antwort für Cron und CI
interval 0 läuft einmal und endet mit 0 oder 1. Ohne zuerst Prometheus aufzubauen.
Gleicher Check Pfad im Daemon
interval größer 0 wiederholt denselben Readiness Pfad, benachrichtigt bei Übergängen, optional HTTP healthz und metrics.
Nur client-go
Kein kubectl Binary im PATH. Nur Lesen gegen die API. Distroless Image und Cosign signierte Releases.
Config first
Deployments und StatefulSets in YAML deklarieren. Sample und Operator Manifeste liegen beim CLI.

01
Installieren
Homebrew, get Install Script, Release Tarball oder GHCR Image.
02
Refs deklarieren
Sample Profil ausgeben, kube Context setzen, relevante Workloads listen.
03
Prüfen oder watchen
Einmal für CI, oder Daemon mit Slack und Probes laufen lassen.

Hauptweg: Homebrew oder das verifizierte Install Script. ghcr.io/hrodrig/kwd:v0.2.1

Homebrew

brew install hrodrig/kwd/kwd

One Liner (Linux / macOS)

curl -fsSL https://get.kwd.hermesrodriguez.com/install.sh | sh

Operator Manifeste · Vertrag: kwd-selfhosted · SPECIFICATIONS

Ist kwd als einziges Production Readiness Gate bereit?

Noch nicht. Bis v1.0.0 frühe Entwicklung. Zum Lernen und Ergänzen nutzen, nicht als einziges Gate. Nutzung auf eigenes Risiko (MIT).

Welche Kinds werden heute unterstützt?

deployment und statefulset. daemonset, service und pvc stehen auf der Roadmap. SPECIFICATIONS beschreibt den v0 Zielvertrag.

Braucht es kubectl?

Nein. kwd spricht mit client-go zur API. Du brauchst trotzdem kubeconfig oder In Cluster Credentials.

Wie funktionieren Notifications?

Heute Slack Incoming Webhooks. Im Daemon Alerts bei ready / not ready Übergängen, optional Hysterese und repeat while firing.

Wo betreibe ich es?

Bastion Cron oder systemd, docker run, oder In Cluster CronJob und Deployment. Siehe kwd-selfhosted.

Wie verifiziere ich ein Release?

GitHub Releases liefern Cosign Signaturen und SBOMs. Das get Script kann mit cosign prüfen wenn vorhanden.

Gleiche Install Wege. Pre 1.0: prüfen bevor du allein in Production vertraust.