Cloud onboarding

Getting started with managed Kubernetes: a checklist for a useful pilot

A pilot should support a concrete decision: does the managed operating model fit our application? That needs a limited use case and verifiable goals.

  • Choose a use case
  • Agree acceptance
  • Review operations
In short

Choose a representative, bounded workload. Record resources and dependencies, agree responsibilities and evaluate operations and exit against clear criteria. A successful test cluster alone does not establish production readiness.

01

1. Choose a representative application

Pick a workload your team understands. Include enough real requirements to learn something: for example public HTTP access, configuration and persistent data. Keep the scope small enough to assess the result clearly.

Start with test data and a specific goal. For example: the application deploys using a documented procedure, is reachable through the intended endpoint and retains data during an agreed test. Avoid real customer data when it is not needed for the decision.

02

2. Record capacity and dependencies

Document expected CPU, memory, storage and peaks. Describe external databases, APIs, certificates and DNS dependencies. Derive a machine configuration from these requirements rather than a generic node count.

  • Identify application, images and deployment method
  • Estimate CPU, memory, storage, traffic and peaks
  • Distinguish public and internal access
  • Record data growth and external dependencies
03

3. Agree responsibilities before starting

Managed Kubernetes does not automatically define who operates every application. Record who manages the cluster, infrastructure, application and data. Also define who approves updates and makes incident decisions.

Kubernetes documentation identifies availability, scaling, security and access as important production considerations. Translate these into the pilot scope: which configuration will be tested, what limitations remain and what evidence does your team need?

Questions for a pilot proposal
AreaSpecific question
Infrastructure and clusterWhich tasks does the operator take on?
Application and dataWhat remains with our team?
Maintenance and incidentsWho contacts whom, and what support is agreed?
Backup and restoreWhich data is protected and how is restore tested?
Cost and exitWhich fees, notice periods and export options apply?
04

4. Agree measurable acceptance criteria

Define a satisfactory result before testing. Cluster status can be one criterion; the application also needs to be reachable and fulfil its relevant functions. Agree which failure or recovery scenarios belong in the pilot.

Record results, test dates, versions and remaining limitations. Explain deviations and repeat affected checks after changes. This turns a demonstration into evidence for a decision.

  • Check application deployment and reachability
  • Review access and agreed permissions
  • Test persistent data and any agreed restore procedure
  • Record cost, open questions and next steps together
05

5. Plan the exit too

A pilot has a limited duration and scope. Decide beforehand whether and how it can be extended. Check which data can be exported and how you will verify it remains usable. This matters even when the pilot succeeds.

Remove resources only after a verified handover. The proposal should cover cancellation, retention, deletion and any remaining costs. An automated customer portal does not replace that agreement.

06

6. Request a ClusterPilot Cloud pilot

ClusterPilot Cloud is intended for teams that want Kubernetes and infrastructure from one contact. The pilot phase is in preparation. The planned model does not require a customer cloud provider account.

Select Starter, Pro or Business and monthly or annual platform billing as your preference. The form currently prepares an email with your details for you to send yourself. The inquiry is non-binding. Prices, timing and operating services are separately confirmed before a paid pilot.

07

First managed Kubernetes pilot questions

Do I need a finished Kubernetes application?+

Not necessarily. Describe your current state and goal. The proposal defines which preparation belongs in the pilot.

Does a successful pilot prove production readiness?+

Only for the criteria and configurations actually tested. Production operations, availability, restoration and support require their own qualified scope.

Is an inquiry already an order?+

No. A paid pilot starts after review, with a separate proposal and agreement.

Next step

Plan your managed Kubernetes pilot.

Describe your application and resource needs. We review scope and configuration for an individual pilot proposal.

hello@clusterpilot.de