Hidden requirements
Quota, network, image or access problems often appear only after a change has started.
Cluster lifecycle management
Manage the full Kubernetes lifecycle with one clear process.
ClusterPilot brings setup, hardening, cluster creation and later changes into one tracked process. Every run has a plan, safety checks, ordered steps and recovery details.
Operational challenge
The risk is the whole change, not one command.
Creating, scaling or upgrading a cluster affects infrastructure, hosts and Kubernetes. Safe work needs the right order, compatible versions and a clear recovery path.
Steps known by one person
Drain, replacement and upgrade order often live in runbooks or individual experience.
Too little recovery detail
A failed pipeline may show an error but not enough information for a safe retry or cleanup.
Enterprise value
One process from infrastructure to approval.
The value comes from shared state, explicit ownership and reviewable execution.
Plan before mutation
Provider-safe defaults, roles, topology, resource effects, compatibility and risk are visible before assignment.
Harden before preparation
A persisted OS profile is inspected, sealed, applied transactionally, rebooted when bounded, and revalidated before node preparation.
Operate from durable state
Queued, running, blocked, failed, cleanup and terminal states retain ordered steps, evidence and next actions.
Controlled workflow
The ClusterPilot lifecycle path
Each transition uses the same Plan → Admit → Run → Evidence → Recover structure.
Connect and validate
Register write-only provider credentials, validate account access and save provider-specific infrastructure defaults.
Provision and harden
Review the role-based infrastructure plan, create resources and apply the persisted operating-system hardening profile.
Create Kubernetes Core
Prepare nodes, initialize the control plane, join roles, install networking and prove semantic health.
Operate day two
Scale, upgrade, replace, inspect or delete through bounded runs with cancellation, retry and cleanup contracts.
Evidence
Lifecycle evidence that survives the terminal session.
The complete operation remains reviewable by platform, operations, QA and support teams.
Admission evidence
Exact intent, actor, target, version, topology, gates, compatibility and plan.
Execution evidence
Step order, timestamps, events, logs, command results, artifacts and stable error code.
Recovery evidence
Retry budget, cancellation, cleanup, residual state, next action and accepted terminal result.
Honest product boundary
Current v0.0.1 boundary
- Cluster lifecycle is enabled only behind explicit production gates and environment approval.
- Hetzner and IONOS are enabled, supported and production-gated; AWS and Azure remain disabled.
- Sensitive Kubernetes mutations such as exec, port-forward and generic resource writes are not sold as available capabilities.
Frequently asked questions
Questions about Kubernetes Lifecycle Management
Clear answers about fit, boundaries and the evaluation path.
Which lifecycle operations are represented in v0.0.1?+
The documented gated scope covers inventory, node preparation, kubeadm create/join, health, scale, upgrade, replace and delete.
Does ClusterPilot replace infrastructure-as-code?+
No. It can standardize the provider-to-cluster operating path, while existing infrastructure and policy tooling can remain part of the customer architecture.
How are failed operations handled?+
OperationRuns retain ordered steps, stable codes, logs, artifacts and recovery context. Retry and cleanup are bounded by the capability contract rather than hidden automation.
Capability scope: v0.0.1 release candidate. Review the current release boundary →
Start with a measurable workflow
Translate the requirements into a bounded technical evaluation.
We will review the environment, operational bottleneck, control boundaries and evidence needed for a decision.
hello@clusterpilot.de