Kubernetes Consultancy: Scope, Buyer Criteria & Acceptance Tests

A Kubernetes consultancy should reduce a defined delivery or operational risk and leave the internal team able to run the platform. Buy a bounded outcome—such as a platform assessment, production baseline, migration slice, security remediation, or upgrade—not an open-ended promise to “implement best practices.” Acceptance should be demonstrated through failure and recovery tests.

Confirm that Kubernetes is the right problem boundary

Kubernetes is justified when several teams need a shared workload platform, declarative scheduling, portable controllers, or consistent policy across meaningful operational scale. A single stateless service may be cheaper and safer on a managed application or container service. Compare the value of Kubernetes against the permanent cost of cluster upgrades, networking, identity, observability, storage, policy, and on-call.

Inventory workload dependencies, state, traffic, deployment frequency, recovery objectives, regulatory boundaries, team skills, and infrastructure constraints. The official Kubernetes production-environment guidance distinguishes learning clusters from production and calls out control-plane resilience, access management, capacity, certificates, networking, and ongoing maintenance. A proposal should cover those responsibilities whether the control plane is managed or self-operated.

Scope the engagement around verifiable deliverables

A useful statement of work names environments, workloads, excluded systems, provider responsibilities, deliverables, client inputs, decision owners, acceptance tests, and handover. Typical artefacts include an architecture and threat model, cluster and namespace policy, identity and access design, network and ingress model, storage and backup design, deployment workflow, observability baseline, cost model, upgrade path, runbooks, and recorded decisions.

Make choices reversible where possible. A managed control plane can remove significant undifferentiated work, but the operator still owns workload policy, nodes or node configuration, dependencies, data, and application recovery according to the service boundary. Self-management requires a reason tied to control, environment, economics, or capability—not a generic portability claim.

Evaluate consultants by evidence, not tool lists

Ask candidates to walk through a production incident, an upgrade, a restore, and a design they decided not to deploy. Request anonymised decision records and runbooks, and ask what evidence changed their original plan. Certifications such as the CNCF's Certified Kubernetes Administrator validate a defined skills exam; they do not prove architecture judgement, communication, or sustained production ownership.

Check experience with the selected provider, container runtime, networking and storage interfaces, workload type, and regulatory context. Require disclosure of reseller relationships and referral incentives. A consultant tied to one platform can still be appropriate, but the commercial boundary should be visible in option analysis and cost estimates.

Require a security and tenancy model

Define human authentication, service accounts, RBAC, admission policy, workload identity, network policy enforcement, secret handling, image provenance, node isolation, audit retention, and emergency access. The official Kubernetes security checklist explicitly warns that a checklist is only a baseline and must be adapted to the environment.

Test negative cases: a developer must not read another namespace's secrets; a workload must not reach a prohibited destination; an unsigned or privileged image must be rejected where policy requires; terminated staff must lose access; and break-glass use must be time-bound and audited. NetworkPolicy manifests provide no protection unless the selected network implementation enforces them.

Make upgrades, recovery, and cost acceptance criteria

The engagement is not complete when the sample application deploys. Rehearse loss of a node and zone, an unavailable dependency, a failed rollout, expired credentials, a full data restore, and a control- plane or cluster rebuild within documented objectives. Upgrade a non-production environment and validate APIs against Kubernetes' version-skew policy. Record add-on, controller, and custom-resource compatibility separately.

Load-test representative traffic and failure recovery. Validate requests and limits, autoscaling bounds, quotas, disruption budgets, queue behaviour, and observability cost. Report cost per workload or business operation, not only cluster utilisation; a highly utilised shared cluster can still have one tenant subsidising another.

Contract for knowledge transfer and an exit

Internal operators should pair on implementation, lead an upgrade and incident exercise, and modify a policy before acceptance. Deliver editable infrastructure and configuration sources, dependency and ownership maps, runbooks, access inventory, known risks, and a prioritised backlog. Avoid proprietary automation that only the consultancy can run unless that managed-service dependency is intentional.

Agree how defects, follow-up support, and scope changes are handled, then set an end date. Warning signs include a tool catalogue before workload discovery, cluster creation without application migration, security claims without negative tests, backups without restores, and documentation generated only at the end. A successful consultancy makes the next routine change possible without the consultant.