Kubernetes implementation plan and cost

What a Kubernetes implementation involves and when teams start one

A Kubernetes implementation is priced by its scope and by the platform team the organization needs afterwards. Most organizations split the work between an internal team and an outside partner, with the internal team keeping ownership of the clusters once they are running. Kubernetes is open source under the Apache 2.0 license, so there is no license fee for upstream Kubernetes itself. The cost sits in three places: labor to design and build the platform, infrastructure in your own cloud accounts or data centers, and the support model that keeps clusters patched and running after handover.

Teams usually start this work for one of three reasons. The first is a move off virtual machines, where application teams want container scheduling and a common deployment model. The second is a shared administrative cluster that has grown past its original setup, with unclear ownership, shared kubeconfig files and no clear upgrade path. The third is a regulated workload that must run inside infrastructure the organization controls, where the platform has to satisfy internal security reviews and external assessments before the first production deployment. Each trigger leads to a different scope, so the first step is to write down which one applies and which teams depend on the result.

Before requesting a quote, confirm a short list of inputs. Ask which infrastructure the clusters will run on (a private data center, a cloud account, or a network without internet access), how many clusters and environments you expect, and whether any workloads are stateful. Identify who will own the platform day to day and how many engineers that team can commit. Check whether your organization already runs a container registry, identity provider, secrets store, logging pipeline and monitoring stack that the clusters must use. These answers determine the phases, the roles and the effort more than the Kubernetes version does.

Plan for the work to continue after the first cluster is live. Kubernetes releases come roughly three times a year, and the project supports only the three most recent minor releases, so each cluster needs a scheduled upgrade path with staging rehearsals. Decide early who owns that calendar, who approves changes and how long your organization will tolerate running an unsupported version. The distribution choice, upgrade rules, migration approach and long-term cost of ownership each have their own pages in this series, and those decisions should be settled before the implementation plan is final.

What the implementation work includes and what you receive at the end

A typical Kubernetes build moves through a fixed set of work packages, each ending in a named deliverable that your team keeps. The packages depend on each other, so a decision made early, such as distribution or topology, sets the scope of the later ones. Scope, deliverables and timelines are agreed in writing before work starts.

Requirements and architecture decisions

This package records the workloads, availability targets, data residency rules, network zones and identity sources the cluster must meet. The main output is an architecture decision record for each open choice, such as cluster count, node sizing and whether the environment has internet access. Check that the record names the owner of each decision and the conditions under which it would be reopened, since these choices drive every cost line that follows.

Distribution and topology decisions

This package selects the Kubernetes distribution and the control plane topology, either stacked etcd or an external etcd cluster, with a load balancer in front of the API server. It also confirms conformance and the vendor support lifecycle for the chosen version. The deliverable is a written decision with its trade-offs, including how many control plane nodes and failure domains the design needs. Ask which upstream minor releases are supported at the planned go-live date.

Cluster provisioning and control plane setup

This package builds the nodes, installs the control plane and joins workers, then runs the cluster through functional tests such as node readiness, scheduling and API reachability. The deliverable is an installed and tested cluster with build scripts or configuration kept in your repository. Confirm where the container images come from, since clusters without internet access need a private registry populated before installation starts.

Networking and storage

This package sets the pod and service address ranges, the CNI plugin, load balancer integration and the default storage class with its CSI driver. It also defines how persistent volumes are backed up and which storage tier each workload uses. The deliverable is a network and storage design document plus test results for pod-to-pod traffic and volume provisioning. Check the address ranges against existing routed networks before any node is built.

Platform tooling

This package installs ingress, certificate management, centralized logging, monitoring and a GitOps controller, so the cluster state is defined in version control. The deliverable is the deployed tooling, its configuration in Git and a list of the add-on versions in use. Each add-on adds upgrade work later, so confirm which versions your upgrade plan will need to track and who owns each component after handover.

Identity and hardening baseline

This package connects user sign-in to your identity provider, maps groups to RBAC roles, and applies a baseline of Pod Security Admission levels, network policies, audit logging and Secrets encryption at rest. The deliverable is a hardening baseline mapped to the CIS Kubernetes Benchmark recommendations that apply to your distribution, with the scan output kept as evidence. Note that DeployOpen prepares these controls and evidence but does not issue audit reports or certifications.

etcd backup and restore

This package configures scheduled etcd snapshots, stores them off the cluster with encryption, and documents the restore path with etcdutl. It also includes a restore drill in a non-production environment to prove the snapshots can rebuild the control plane. The deliverables are the backup configuration, the restore runbook and a drill record. Ask who holds the backup keys and how long snapshots are retained, since both are set by your policy.

Handover and runbooks

This package transfers operation of the cluster to your platform team through runbooks, a handover session and supervised first tasks such as a node drain and an add-on update. The deliverables are the runbooks for routine and failure procedures, the handover session, and a list of open items with owners. Ask for the runbooks to be tested by your team before the handover is signed off, because untested procedures tend to fail during the first incident.

Which factors make a Kubernetes build cost more or take longer

This table lists the main factors that move effort and duration in a Kubernetes build, why each one matters, and how to keep it manageable. Read each row as a lever: the fixed minimums are set by the project, while the other drivers depend on scope and should be confirmed against your own environment before you ask for a quote.

Driver	Why it changes effort	How to keep it down
Number of clusters and environments	Each cluster needs its own install, upgrades, add-ons, monitoring, backups and access model. Separate production, staging and test clusters multiply that work.	Use fewer clusters with namespace isolation where tenancy rules allow it, and keep non-production environments as close to production as the budget allows.
Node count and size	More nodes add provisioning, bootstrap, patching and capacity testing work. Mixed hardware or instance types add variants to build and verify.	Standardize node pools on a small set of sizes and roles, and size from measured workload needs rather than peak guesses.
Control plane topology	Stacked etcd is the simpler build. External etcd adds a separate cluster to deploy, secure, back up and upgrade. High availability requires at least three control plane nodes, and production etcd is recommended at five members.	Confirm the topology early. Three control plane nodes and an odd etcd member count are fixed minimums for high availability, so the choice mainly changes how many separate systems the team operates.
Availability zones or failure domains	Spreading control plane and worker nodes across zones or racks requires network design, load balancer placement, storage that works across zones, and failure testing.	Set the failure domains the business actually needs and document which workloads must survive zone loss, instead of spreading everything by default.
Networking and storage choices	The CNI plugin, ingress design, load balancing and persistent storage each need selection, integration with existing network and storage teams, and performance validation.	Reuse what your organization already runs and supports, and limit storage classes to the ones that have a clear workload need.
Number of integrations	Identity provider sign-in, secrets stores, monitoring, logging and CI/CD pipelines each need configuration, testing and ongoing maintenance across upgrades.	Reuse existing identity infrastructure and standard monitoring stacks, and phase less critical integrations after the first production cluster is stable.
Compliance evidence requirements	Assessors often ask for configuration baselines, audit logs, access reviews, backup restore records and scan results. Collecting and retaining this evidence is ongoing work, not a one-time task.	Agree the evidence list at the start and build collection into the platform, such as scheduled scans and exported logs, rather than assembling it before each assessment.
Air-gapped operation	Without internet access, control plane images, add-ons, charts and packages must be mirrored to a private registry, and every upgrade needs a new mirroring cycle.	Decide early which artifacts are mirrored and how updates will reach the network, and keep the mirror process scripted so each upgrade repeats the same steps.
Distribution or edition chosen	Upstream kubeadm, certified vendor distributions and managed services differ in what the team installs, supports and patches. Each choice changes who carries the lifecycle and support work.	Compare the support lifecycle, the skills in house and the conformance status of each option before committing, and ask each vendor what is included in the quoted scope.

How a Kubernetes implementation moves through its phases

The sequence below turns a set of platform requirements into a cluster your team can run, with each phase producing a named output that the next phase depends on. Use it to compare what a partner would deliver at each step against what your own team would need to build.

Confirm discovery and sizing inputs
The partner and your architects gather workload profiles, required cluster count, expected node sizes, regions or sites, connectivity constraints, and the identity and compliance requirements that will shape later decisions. Sizing is worked from these inputs rather than from a default template. The output is a written discovery summary with a sizing worksheet and a list of open questions with owners. The phase is complete when the client signs off on the requirements and the open questions have named owners. Ask the partner for phase durations in the written scope, and confirm them against your own change windows and approval cycles.
Decide architecture and distribution
Based on the discovery summary, the team records the distribution choice, the number of clusters, the control plane topology (stacked etcd or external etcd), and the networking and storage approach. Options are checked against the Kubernetes version skew policy, the three supported minor releases, and your support obligations. The output is an architecture decision record and a logical diagram that your security and operations leads approve. Confirm with your distribution vendor, if one is chosen, which Kubernetes versions and add-ons it supports.
Prepare environments and registries
Cloud accounts, data center networks, DNS, certificate authorities, load balancers and any private image or package registries are provisioned. For offline or air-gapped sites, control plane and add-on images are mirrored to a private registry before any build starts, so kubeadm can pull from it through the image repository setting. The output is a documented environment with access paths, a registry inventory, and a connectivity test record. The phase closes when every node can reach the required endpoints or the mirrored registry.
Build the control plane
The control plane is built with the chosen topology, normally at least three control plane nodes behind a TCP load balancer in front of the API server on port 6443. Certificates, the API endpoint, and etcd membership are set up as the topology requires. The output is a healthy control plane with a verified API endpoint, etcd quorum, and a recorded join procedure. Acceptance means failover of a single control plane node has been tested and the API stays reachable.
Join nodes and configure networking
Worker nodes are joined and the pod network, service routing and ingress paths are configured. Node labels, taints and resource settings reflect the sizing worksheet. Connectivity between nodes and to external services is tested across each failure domain. The output is a node inventory with versions, labels and a network test report. The phase is complete when pods schedule across the intended nodes and cross-node traffic passes the agreed tests.
Set up storage and platform tooling
Storage classes, the container storage interface drivers, and core platform tooling such as monitoring, logging, ingress controller and certificate management are installed and configured. Each add-on is recorded with its version and its upgrade path, since add-on compatibility affects every future minor version upgrade. The output is a storage and tooling baseline with a test volume claim that binds and survives a pod restart. Confirm add-on support lifecycles with each vendor before committing.
Apply the identity and security baseline
Authentication is connected to your identity provider where the chosen method supports it, RBAC roles are defined for administrators and operators, and Pod Security Standards are enforced per namespace. Encryption at rest for Secrets is configured, since Secrets are stored unencrypted in etcd by default. The output is a security baseline record listing authentication methods, role bindings, enforced policy levels and the encryption configuration, ready for review by your security team. Map the results to your own control requirements, and do not treat them as an audit report.
Prove etcd backup and restore
Scheduled etcd snapshots are configured using the documented snapshot tool, stored off-cluster, and encrypted according to your policy. A restore is then rehearsed on a separate environment using the documented restore tool, with the result timed and written down. The output is a backup configuration, a restore test record, and a runbook for lost quorum. The phase is accepted only when a restore has completed successfully and the team has reviewed each step with the runbook in hand.
Run a pilot workload and hand over
A representative pilot workload is deployed against the agreed acceptance criteria, covering scheduling, service exposure, storage, scaling and a node drain. Once accepted, the partner delivers the as-built documentation, the runbooks, and training for your platform team. The output is a signed acceptance record, the handover package, and a list of post-handover support options. Ask the partner which handover items are covered by the fixed-scope fee and which move to a retainer, and confirm the schedule against your approval cycles.

Which parts of the build teams keep in-house and which they outsource

Most organizations keep the decisions that only they can make and hand the hands-on engineering of the cluster to a partner, or the reverse, depending on where their skills already sit. The useful split is not by team size but by task: business ownership, application onboarding, change approval and day-two operations usually stay inside the client, while architecture, cluster build, the hardening baseline, backup design with a restore test and the final handover are the parts a partner often carries. Deciding the split early tells you which roles to hire, which to train and which to contract, and it sets the scope you will put in writing.

Business ownership means someone accountable for what the platform is for, which teams may onboard, and how much risk the organization accepts. Application teams own their workloads, manifests, resource requests and release pipelines. Change approval stays with the client's existing governance, such as a change advisory board, because it reflects obligations the partner cannot take on. Day-two operations, meaning on-call response, capacity planning and routine upgrades, is where recurring cost sits. None of these tasks can be fully outsourced without a clear ongoing support agreement, so confirm early which of them the partner will perform and which your staff must perform.

The partner-led tasks need specific skills, and you should check them in the people who will do the work. Architecture and cluster build call for Linux and networking knowledge, including node sizing, the pod and service network ranges, and load balancing in front of the API server on port 6443. PKI and certificates cover the cluster certificate authority, kubelet and API server certificates, and rotation. etcd operations require understanding of quorum, snapshot saves with etcdctl and restores with etcdutl. Identity federation, policy and RBAC design, observability and release handling round out the list. Ask each candidate partner to name the person who holds each skill, not only the firm's general experience.

Whatever split you choose, plan the platform team that runs the cluster after handover as a recurring hire from the start, not as an afterthought. That team needs people who can patch nodes, rotate certificates, restore etcd, review admission and RBAC changes, and triage add-on failures. Ask the partner what knowledge transfer the handover includes, which runbooks and recovery drills they will rehearse with your staff, and how many of your people must be able to perform each task unaided before the engagement closes. Recruiting lead time for these skills is a planning risk, so start it during the build rather than after go-live.

For the quote, ask for a responsibility matrix that lists each task, the party performing it, the party approving it and whether the work recurs. Confirm which tasks are one-time, such as the initial build and hardening baseline, and which recur, such as upgrades, certificate rotation and restore tests. Ask what the handover includes, what skills it assumes in your team, and what support the partner provides if a gap appears in the first months of operation. A written split protects both sides and keeps the cost of the platform team visible in the plan.

What usually goes wrong in Kubernetes builds and how to prevent it

Most failed Kubernetes builds trace back to a few decisions made early and never revisited. Each card names a failure pattern, the prevention step and the artifact that shows the step happened. Use these artifacts as acceptance criteria in your written scope.

Distribution chosen before requirements

Teams often pick upstream kubeadm, a vendor distribution or a managed service before writing down conformance, support lifecycle and air-gap needs. Check each candidate against the CNCF Certified Kubernetes conformance program, its published support end dates and whether it provides an offline image set. Artifact: a signed requirements sheet and a conformance and support matrix for each shortlisted distribution, kept with the decision record.

Single control plane or even etcd members

A single control plane node is a single point of failure for the API server and scheduler. Kubernetes documentation says etcd should run with an odd number of members and recommends five in production, so an even count adds cost without adding fault tolerance. Use at least three control plane nodes behind a TCP load balancer on port 6443, in either stacked or external etcd topology. Artifact: a topology diagram and a node-loss test record showing the cluster keeps quorum.

etcd restore never rehearsed

Snapshots that nobody has restored do not show that the cluster can be recovered. Schedule etcdctl snapshot save, store copies off the cluster with encryption, and time a restore into an isolated environment using etcdutl. Record which snapshot was used, the steps run, who ran them and whether workloads came back. Artifact: a dated restore record signed off by the platform owner, repeated after each control plane change.

Secrets stored unencrypted in etcd

Kubernetes stores Secrets unencrypted in etcd by default. Configure encryption at rest through an EncryptionConfiguration backed by a key management service, then confirm that new Secrets are written encrypted and that existing ones are rewritten. Pair this with least-privilege RBAC on get, list and watch, and decide whether an external store through the Secrets Store CSI Driver fits your workloads. Artifact: the encryption configuration, a key rotation procedure and a verification record.

Shared admin kubeconfigs and unclear RBAC

Shared cluster-admin kubeconfigs remove individual accountability and make audit logs hard to use. Kubernetes authenticates users through certificates, OpenID Connect tokens, webhook authentication or an authenticating proxy, so map each person to an identity provider group and bind that group to a scoped role. Retire shared kubeconfigs only after break-glass accounts have been tested. Artifact: an RBAC review listing every cluster-admin binding, a named owner for each role and a dated access recertification.

No owner for upgrades and images after go-live

Version skew rules require kube-apiserver to move one minor version at a time, ahead of the controller manager, scheduler and kubelets, and kubelets may trail the API server by up to three minor versions. Air-gapped clusters also need control plane and add-on images mirrored again for each release, or upgrades stall. Name one accountable owner and plan the recurring work before go-live. Artifact: a skew matrix per cluster, a mirrored image manifest per release and a named responsibility matrix.

How the implementation changes by starting point and environment

A greenfield build starts with an empty cloud account, so the plan covers account structure, network layout and the first clusters before any workload exists. Nothing has to stay running during the change, so the sequence is simpler than a migration. Most decisions made at this stage are inherited by every later cluster.

Scope: account and network baseline, cluster count and sizes, node pools, API server load balancing, storage classes, identity and logging setup.
Sequence: choose the distribution and control plane topology first, build the control plane, add networking, storage and platform tooling, then verify the cluster before any team deploys to it.
People: the cloud platform owner, a security reviewer for the account baseline, and the team that will operate the cluster after handover.
Watch for: creating clusters before naming, tagging and account structure rules are agreed, which makes later audit scoping harder.

Check that the cloud team has approved the account structure and the high availability topology before the first cluster is created.

What your team must provide before a Kubernetes build can start

Before any Kubernetes build starts, your team needs to hand over a defined set of inputs. Most schedule slips on a cluster build come from these inputs arriving late or incomplete, not from the installation itself. Ask your delivery partner to confirm the full list below before you request a quote, because each item sets a dependency that the plan cannot work around. Start with infrastructure access. The build needs cloud accounts or hypervisor access, IP address ranges for nodes, pods and services, DNS zones for the API endpoint and ingress, load balancer capacity for the kube-apiserver on port 6443, and a storage backend for persistent volumes. If any one of these is missing, the control plane cannot be reached or tested, and every later phase waits.

Next, provide host and image standards. This covers the operating system baseline for nodes, kernel and container runtime settings your security team already requires, and the base image process used to build node images. Also provide a private container registry where your environment blocks public pulls. kubeadm can pull control plane images from a private registry through the --image-repository option, but the mirror has to exist and be populated before the first init. Confirm who owns image approval, since that owner will be asked to sign off on the image list.

Identity and decision inputs come next. For OpenID Connect sign-in, the build team needs your identity provider's issuer URL, client details, the claim that carries group membership, and the group names that will map to cluster roles. Decision owners must also be named in writing for four choices: the Kubernetes distribution, the cluster topology (stacked or external etcd, and the number of clusters), the security baseline (including which Pod Security Standard applies by default), and the storage and networking plugins. Each of these decisions changes the work plan, so an unnamed owner means the team cannot close the design phase.

Operational inputs are equally blocking. Name the change approval contacts and the approval window for production changes, because cluster creation, certificate changes and upgrades usually need a recorded approval. Also name the staff who will join the platform team during the build and take over afterwards, with their time commitment confirmed by their managers. Knowledge transfer depends on these people being available, and a team that is not yet staffed will inherit a cluster it cannot operate. Finally, ask your partner to confirm how each input will be tested before the build proceeds, and what happens if an input changes mid-build. A quote is only meaningful when it rests on these confirmed inputs, so treat the list as a gate, not a formality.

What the platform costs after go-live beyond the build

The build is a one-time project, but the cluster keeps costing money every month once it serves production traffic. The cards below cover the recurring cost lines and the release rhythm that sets how often that cost returns, so the quote can separate one-time build effort from ongoing operation. For the full side-by-side comparison, see the cost of ownership and editions page.

Infrastructure for control plane and workers

Control plane nodes and worker nodes bill every month whether or not workloads are busy. Three or more control plane nodes behind a load balancer are the baseline for high availability, and worker capacity usually grows with each new application team. Ask the quote to show node counts, the instance or hardware classes assumed, storage for etcd, and who pays for them in your own cloud account or data center.

Commercial distribution subscriptions

If you choose a certified vendor distribution rather than upstream kubeadm, the subscription is a recurring line that usually covers support, patches and lifecycle commitments. Check whether pricing scales with nodes, cores or clusters, and whether air-gapped or long-term support is included or priced separately. Upstream Kubernetes is open source under Apache 2.0, so this line may be zero, but support then moves to your team or a partner.

Platform team headcount

Someone must own cluster upgrades, add-on updates, access reviews, backup restore tests and on-call response. This is usually the largest recurring cost and is easy to leave out of a build estimate. Ask the quote to state the recurring effort in hours or roles per month, the skills assumed in house, and whether that effort is supplied by your staff, a retainer or both.

Support contracts and retainers

Support covers vendor response on incidents, security patches and help during upgrades, and it may be bought from the distribution vendor, a managed service provider or DeployOpen as a retainer. Compare response scope, which versions are covered and whether upgrades are included. Confirm which items are one-time project work and which fall under an ongoing support agreement.

Upgrade work on the release cycle

Kubernetes ships roughly three minor releases a year on a cycle of about 14 weeks, and the project maintains the three most recent minor releases with about one year of patch support each. Upgrades must move one minor version at a time, so each cycle creates recurring work on the cluster, add-ons and deprecated APIs. Ask the quote how many upgrade cycles it assumes per year and what each cycle includes in staging and production.

Separating build cost from running cost

Quotes often mix a one-time implementation fee with monthly operating costs, which hides the real annual total. Ask for two totals: the one-time build scope with its deliverables, and the recurring year-one cost covering infrastructure, subscriptions, support and upgrade effort. Confirm the renewal terms for each recurring line so the cost for year two and later is visible before you commit.

Questions buyers ask about the cost, time and effort of a Kubernetes implementation

How is the cost of a Kubernetes implementation calculated?

The cost is the written scope of work, the people who perform it, and the infrastructure and licenses you pay for separately. DeployOpen's quote follows from the agreed scope, and we do not publish a price list. Scope items usually include distribution selection, cluster design, networking and storage, identity integration, hardening, etcd backup, and handover documentation. Compute, storage, load balancers and any vendor subscription are paid to their providers, so ask the quote to state which infrastructure and licenses are included and which you buy directly. The build is one-time work, while upgrades, support and your internal platform team recur. Ask for a quote that separates one-time and recurring items and lists the assumptions it makes about your environment.

What makes a Kubernetes implementation take longer than planned?

The main drivers are the number of clusters and environments, how deeply the platform must integrate with existing systems, and how quickly your teams can review and approve decisions. Identity integration with your provider, storage and network design, and mirroring images for an air-gapped network each add work. High availability adds nodes: the kubeadm guidance calls for at least three control plane nodes behind a TCP load balancer, and five etcd members are recommended in production. Security evidence, change windows and approval cycles on your side often set the pace more than the build itself. Ask for a timeline tied to milestones, with each dependency on your team named and dated.

Can our own team build a Kubernetes cluster without outside help?

Yes, many teams build a cluster alone, especially with kubeadm or a distribution installer, provided they already have strong Linux, networking and certificate skills. The harder work usually comes after the first install. It includes etcd backup and restore drills, identity integration, Pod Security Standards, least-privilege RBAC, encrypted Secrets, and an upgrade routine that keeps pace with the three supported minor releases and a release cycle of about 14 weeks. Check whether two or more people on your team have restored etcd and performed a cluster upgrade in a test environment. If not, that gap is what to price, whether you close it with training, a partner, or both.

What does a Kubernetes implementation partner need from us?

The partner needs clear decisions, access and people. Typical inputs include access to your cloud accounts or data center hosts, network and IP plans, DNS and load balancer options, and identity provider details. You also need a named platform owner with decision authority, approvers for security and change control, and the workloads or test applications that will validate the cluster. Share your security policies, logging destinations and backup storage requirements early, since they shape the design. Ask for a written list of these inputs as part of the scope, so delays are visible early and each one is assigned to a named person on your side.

Is one large Kubernetes cluster cheaper than several smaller clusters?

It depends on your isolation needs and how much you are willing to share. One larger cluster shares control plane and operations overhead, but a fault or a bad upgrade affects more workloads, and teams share namespaces, quotas and policies. Several clusters add separation and allow upgrades to be staged per team, but each one needs its own control plane nodes (three at minimum for high availability), its own etcd backups, monitoring, certificates and upgrade work. Ask the quote to price both options under the same assumptions, including backup, identity and support for each cluster.

Does an air-gapped Kubernetes build change the implementation scope?

Yes, an air-gapped build adds scope. Control plane images, add-on images, charts, operating system packages and binaries must be mirrored into a private registry or repository before installation. kubeadm can list and pull the control plane images and accept a private registry through its image repository setting, but your team still handles certificates, time sources and package updates without internet access. Upgrades also change the scope, because each new release needs its images and artifacts staged before the change window. Ask whether the mirror process, transfer media and offline update routine are included in the quote.

What happens after a Kubernetes cluster is handed over?

Handover normally covers the working platform plus the documents and knowledge your team needs to run it. Expect architecture records, runbooks for common tasks, backup and restore procedures, a description of the access model, and a list of open items. After handover, your staff or a support retainer handles monitoring, patching, incidents and upgrades. Retainers are available for ongoing support, upgrades and continuous testing. Agree in writing what handover includes, how long any post-handover support period lasts, and how issues found after go-live are raised and prioritized.

Who owns Kubernetes upgrades once the cluster is live?

Your organization owns the cluster and decides when to change it, while DeployOpen can plan, rehearse and perform upgrades under an agreed scope or a retainer. Kubernetes maintains only the three most recent minor releases, so an upgrade plan is part of ownership from day one. Upgrade one minor version at a time, start with the API server, and keep kubelets within the version skew policy, which allows them to run up to three minor versions behind the API server. Ask the quote who performs each upgrade, who signs off on it, and how staging rehearsals are scheduled.

How DeployOpen scopes, builds and hands over a Kubernetes platform

DeployOpen plans, implements, hardens, documents and supports open-source platforms inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks. For a Kubernetes platform, we start from a written scope that sets distribution, cluster count, networking, storage and tooling, then build and hand the platform over with the documentation your platform team needs to run it.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope fixes distribution choice, cluster count and size, and the networking and storage approach.
Confirm with us which identity provider, registry and network constraints apply to your environment before quoting.

How we build

Control plane layout follows the agreed topology, such as stacked or external etcd with three or more control plane nodes.
Build includes identity integration, Pod Security Standards, encrypted Secrets and etcd snapshot backups as scoped.
Security testing and configuration checks run against the built cluster, with findings tracked to closure in the agreed scope.

How we hand over

You receive architecture, runbooks, configuration records and the upgrade plan written for your own team.
Handover includes a walkthrough of the etcd backup and restore procedure, with a restore exercise if it is in scope.
Evidence for compliance readiness is organized for your assessor, though auditors and certification bodies issue any formal opinion.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainer scope should state which supported minor releases are covered and how upgrades are rehearsed in staging.
Ask for the support boundary in writing, covering add-ons, certificates and version skew responsibilities.