K3s vs RKE2: when each distribution fits
K3s fits edge, small and general-purpose clusters that value a single binary and a light footprint, while RKE2 fits regulated or government-facing clusters that need CIS-oriented defaults and FIPS 140-2 builds. K3s is delivered as a single binary of less than 100 MB, and RKE2, also called RKE Government, is built around security and compliance requirements. Both give you a fully compliant Kubernetes API, so the choice is about defaults, operating model and evidence rather than whether the cluster works.
Four decisions settle most of the choice. First, the datastore and high availability plan: K3s uses an SQLite-based datastore by default, with etcd3, MySQL and PostgreSQL also available, so a multi-server design needs an explicit datastore decision before installation. Second, bundled ingress and CNI: K3s ships Traefik and Flannel by default, while RKE2 takes a more conservative default set, so confirm whether you want those components at all. Third, the compliance evidence you must produce, such as CIS benchmark results or a FIPS-validated cryptographic module, which should be mapped against the RKE2 documentation before you commit.
Fourth, who will perform upgrades and at what cadence. Kubernetes maintains only the three most recent minor releases, so whichever distribution you pick, plan a recurring upgrade path, not a one-time install. Ask the vendor or your integrator to document the upgrade procedure for each distribution in your environment, including how control plane nodes and agents are rolled, and estimate the internal staff time that will carry it. Those answers, more than feature lists, determine which distribution your team can run safely.
K3s vs RKE2 by scenario: edge, regulated and general clusters
This table maps common K3s and RKE2 scenarios to the better fit and the condition under which the other distribution could still be right. Read each row against your own hardware, compliance obligations and team experience, since the scenario rarely decides the question alone.
| Scenario | Better fit | Reason and the condition that changes the answer |
|---|---|---|
| Edge sites with limited hardware | K3s | K3s is documented as a single binary under 100 MB that uses about half the memory of upstream Kubernetes. RKE2 could still fit if the site has enough capacity and a policy requires its CIS-oriented defaults. |
| Federal or regulated estate with FIPS 140-2 requirements | RKE2 | RKE2 enables FIPS 140-2 compliance and scans components for CVEs in its build pipeline. K3s could still be considered if your assessor accepts compensating controls and you confirm FIPS support with Rancher before choosing it. |
| General internal platform on VMs | RKE2 for hardened estates, K3s for lean ones | RKE2 ships CIS-oriented defaults and static control plane pods, which suits a shared platform with audit exposure. K3s suits a platform where your team will add its own ingress, storage and security configuration deliberately. |
| Team new to Kubernetes | K3s | K3s bundles containerd, Flannel, CoreDNS, Traefik, ServiceLB and a local-path provisioner, so the first cluster has fewer decisions. RKE2 could be the better start if your team already plans to run a hardened, audited baseline from day one. |
| Cluster that must pass a CIS assessment | RKE2 | RKE2 ships defaults that help clusters pass the CIS Kubernetes Benchmark. Passing still depends on your node configuration, RBAC and workloads, so confirm the scope with your assessor. K3s could work if you apply and document the benchmark controls yourself. |
| Small cluster needing an external datastore | K3s | K3s uses SQLite by default and also supports etcd3, MySQL and PostgreSQL. Choose K3s when you need that datastore flexibility on modest hardware. RKE2 is the stronger choice when the datastore design must follow the upstream etcd model. |
| Cluster where default ingress and CNI must be replaced | Either, based on the team | Both can run with a different ingress controller or CNI, but K3s bundles Traefik and Flannel by default, so replacing them is a planned change. Confirm the replacement path and upgrade behavior with the vendor before you commit. |
How K3s and RKE2 are built and what that means for operations
K3s and RKE2 both descend from Rancher's Kubernetes work and both track upstream Kubernetes, but they make different packaging, datastore and hardening choices. Each card below names one of those choices and the operational work it creates, so you can price the replacements, additions and checks before you pick a distribution.
Single-binary delivery in K3s
K3s ships as one binary of less than 100 MB that bundles the control plane and node components, and the K3s documentation says it uses about half the memory of upstream Kubernetes. The practical consequence is a small install surface, but upgrades replace the whole binary, so your change process must cover every node at once. Check how your team will pin versions across a fleet and test the upgrade path on a staging cluster before production.
SQLite default and external datastores
K3s uses an SQLite-based datastore by default, with etcd3, MySQL and PostgreSQL also available. SQLite suits a single server with no high availability, while a multi-server control plane needs one of the external options. Decide the datastore before the first node joins, because moving a running cluster between datastores is a migration project. Ask your vendor or the K3s docs how backups and restores are performed for the datastore you choose.
Bundled Flannel, Traefik, ServiceLB and local-path
K3s bundles the Flannel CNI, CoreDNS, the Traefik ingress controller, the ServiceLB load balancer and the local-path persistent volume provisioner by default. Each bundled component is a choice you inherit unless you disable it. If your standard is Nginx ingress, Cilium or a CSI driver backed by Ceph or a SAN, you must disable the bundled piece and install and patch its replacement yourself. Local-path storage is node-bound, so plan for that in any stateful workload.
RKE2 static-pod control plane
RKE2 runs control plane components as static pods with an embedded containerd runtime and does not depend on Docker. Operators see the control plane through the same pod tooling used for workloads, which simplifies inspection but means control plane pods share node resources and rely on kubelet health. Confirm with your platform team whether they can inspect and restart static pods during an incident, and how node drains interact with control plane placement.
CIS-oriented defaults and FIPS 140-2
RKE2 ships defaults that help clusters pass the CIS Kubernetes Benchmark and enables FIPS 140-2 compliance. These defaults reduce the hardening work your team must do by hand, but they do not certify your cluster. Your auditors will test your configuration, so run the benchmark scan on your own nodes and ask your security team to confirm whether FIPS mode is required for the workloads you plan to host.
Trivy scanning in the build pipeline
RKE2 scans its components for CVEs with Trivy in its build pipeline, according to the RKE2 documentation. This narrows the gap between a release and known vulnerabilities in the distribution's own images, but it does not replace your own scanning of workloads or your patch schedule for nodes. Ask how often new RKE2 builds are published and which scan results you can request as evidence for your vulnerability management process.
Upstream alignment in both distributions
Both distributions track upstream Kubernetes, which is Apache 2.0 licensed and releases about three times per year. Kubernetes maintains the three most recent minor releases, so your distribution version must map to a supported upstream minor. Check the version skew rules before each upgrade, since the API server must move one minor version at a time and kubelets may lag by up to three minors. Confirm which upstream version each release you evaluate ships.
K3s vs RKE2 feature by feature
This table compares K3s and RKE2 on packaging, datastore, bundled networking and storage, hardening posture, runtime and upstream alignment. Read each row as a starting point for your own validation, since several rows depend on version and configuration choices that the current documentation for each distribution governs.
| Capability | K3s | RKE2 |
|---|---|---|
| Packaging | Single binary of less than 100 MB, per the K3s documentation | Enterprise-focused distribution from Rancher, also called RKE Government, per the RKE2 documentation |
| Default datastore | SQLite-based datastore, with etcd3, MySQL and PostgreSQL also available | Confirm the default datastore and multi-server layout in the current RKE2 documentation |
| Bundled ingress and CNI | Traefik ingress controller and Flannel CNI bundled by default | Confirm bundled ingress and CNI choices and how to disable or replace them in the current RKE2 documentation |
| Load balancer and storage defaults | ServiceLB load balancer and local-path persistent volume provisioner bundled by default | Confirm which load balancer and storage add-ons ship by default and how your cloud or bare metal layout will provide them |
| CIS Kubernetes Benchmark posture | Confirm the hardening profile and configuration needed for your target benchmark version | Ships defaults that help clusters pass the CIS Kubernetes Benchmark, per the RKE2 documentation; confirm the profile and version you audit against |
| FIPS 140-2 support | Confirm whether your K3s build and version meet your FIPS requirement before selecting it | Enables FIPS 140-2 compliance, per the RKE2 documentation; confirm the build and version your assessor accepts |
| CVE scanning in the build pipeline | Confirm the vulnerability scanning and release notes process in the K3s documentation | Scans components for CVEs with Trivy in its build pipeline, per the RKE2 documentation |
| Runtime and Docker dependency | Bundles containerd; confirm current runtime options in the K3s documentation | Does not depend on Docker; runs control plane components as static pods with an embedded containerd runtime |
| Upstream alignment | Fully compliant Kubernetes distribution, per the K3s documentation; confirm the conformance version for each release | Takes usability and deployment model from K3s and close alignment with upstream Kubernetes from RKE1, per the RKE2 documentation |
Licensing, editions and what is paid for each distribution
Kubernetes itself is open source and licensed under Apache 2.0, according to the kubernetes/kubernetes GitHub repository. That license covers the upstream project's source code, so there is no license fee for the upstream components. Both K3s and RKE2 are built on Kubernetes, which means the upstream license is the starting point for the cost model, not the endpoint. Costs that remain are the people who run the clusters, the hosts, the upgrades and any support contract you choose to buy.
- Upstream license is not the distribution license: Apache 2.0 applies to kubernetes/kubernetes. Confirm separately how each distribution's own code is licensed before assuming the same terms.
- Release cadence drives recurring effort: Kubernetes releases happen about three times per year on a cycle of about 14 weeks, so upgrade work recurs whichever distribution you choose.
- Patch windows set the upgrade budget: Kubernetes 1.19 and newer receive about one year of patch support, so plan for regular minor-version moves.
- Conformance is a technical check, not a contract: The CNCF Certified Kubernetes conformance program checks API support, and it does not tell you about licensing or support fees.
Confirm with Rancher which Kubernetes minor versions each distribution tracks and how long each one is patched.
K3s is the lightweight distribution in Rancher's lineup, delivered as a single binary of less than 100 MB, and it bundles containerd, Flannel, CoreDNS, Traefik, ServiceLB and a local-path provisioner by default, according to the K3s documentation. The supplied facts do not state the license under which K3s is distributed, nor whether a paid support tier exists for it. Those two answers decide whether the software cost is zero and whether you pay for vendor support, so verify them before budgeting.
- Software license: Confirm the license of the K3s source and binaries in the K3s documentation or with Rancher before you assume it is open source in your use case.
- Support tier: Ask Rancher whether K3s has paid support, what it covers and whether it is priced per node, per cluster or per organization.
- Bundled add-ons: Traefik, Flannel and the local-path provisioner are included, so ask whether you may replace them and whether support covers those replacements.
- Upgrade and patch support: Ask how long each K3s release line is maintained and whether security fixes reach older lines.
- Edge and small-footprint use: A single binary lowers host sizing but does not remove the need for an operations budget.
Ask for the license text, the support scope and the support price in writing before you compare totals with RKE2.
RKE2, also called RKE Government, is Rancher's Kubernetes distribution focused on security and compliance in the U.S. Federal Government sector, and it ships CIS-oriented defaults, FIPS 140-2 compliance and Trivy-based CVE scanning in its build pipeline, according to the RKE2 documentation. The supplied facts do not state the license of RKE2 or whether Rancher sells a tier that covers it. Those details determine whether the distribution itself costs anything and whether the compliance features come with a support obligation.
- Software license: Confirm the license terms for RKE2 in the RKE2 documentation or with Rancher, including any terms for government or FIPS builds.
- Support tier: Ask Rancher which support levels exist for RKE2, what each includes and whether CVE response times are part of the contract.
- Compliance features as a cost driver: FIPS and CIS-aligned defaults may be tied to specific support or build terms, so ask which features are included in the base offer.
- Ongoing evidence work: Benchmarks and FIPS posture still require your own configuration, testing and records, which are costs whatever the license says.
- Upgrade path: Ask how RKE2 upgrades are supported across minor Kubernetes versions and what the supported window is.
A written answer on the license, the support tiers and the scope of FIPS and CIS support is the key input to a quote.
Vendor support is the layer that changes the recurring cost model most. Whether it is paid, what it covers and how long it lasts are not stated in the supplied facts, so you cannot assume a price or an included SLA for either distribution. Support can be bought from the distribution vendor, from a third-party partner, or handled by your own staff, and each option moves a different part of the work to a different party. Ask for the terms in writing so the comparison reflects what you will pay, not what the marketing suggests.
- Who is paid for what: Vendor support covers vendor-written fixes and escalation. Installation, hardening, backups and day-two operations are separate costs, whoever provides them.
- One-time versus recurring: Support is usually recurring, while initial build, testing and documentation are one-time work.
- What drives cost up: Node or cluster counts, air-gapped operation, compliance evidence needs and response-time requirements typically raise the quote.
- What to request in a quote: Ask for the support tier names, included components, response targets, upgrade assistance and the term length.
- Ask about exit: Confirm whether support terms carry over if you later move between K3s and RKE2.
Confirm all of these points in writing with Rancher before comparing the two distributions on total cost.
Identity integration and secrets: the baseline both inherit
Kubernetes does not manage user accounts as API objects. It authenticates people and workloads through X.509 client certificates, bearer tokens (including OpenID Connect and JWT), webhook token authentication or an authenticating proxy, and then applies RBAC to what they can do. That means the identity decision sits outside the distribution you pick. Before you install either K3s or RKE2, decide which method your administrators and CI pipelines will use, whether an OIDC provider will issue tokens to kube-apiserver, and how break-glass access works if that provider is down. Confirm in each distribution's documentation at K3s documentation and RKE2 documentation which API server flags for OIDC or webhook authentication are exposed through its configuration file, and whether either one changes them during install.
Secrets are stored unencrypted in etcd by default. Neither distribution removes that exposure for you, so encryption at rest for Secret resources must be configured explicitly, and access to Secrets must be limited with least-privilege RBAC, especially list and watch verbs, because those can expose values across a namespace. Where Secrets must live outside the cluster, the Secrets Store CSI Driver is the upstream route to external stores. This matters more on K3s, which uses an SQLite datastore by default, because the file holding that data must also be protected, backed up and encrypted on the node. Ask each vendor whether encryption at rest is enabled by default, whether it can be turned on at install time, and how key rotation is handled. Treat any gap you find as a baseline control to fix before workloads land.
Pod Security Standards are the enforcement point to confirm. Verify, in the documentation for the exact version you plan to run, whether either distribution applies a default Pod Security admission level and which namespaces it exempts. RKE2 is built with hardening defaults aimed at the CIS Kubernetes Benchmark, so check how those defaults affect Pod Security admission and whether they match your workload profile. Then run a test: deploy a privileged pod in a scratch namespace on each distribution and confirm it is rejected or allowed as your policy requires. Record the results, the distribution version and the configuration file in your change records, since auditors and your own security team will ask how these baselines were verified.
What drives the running cost of each distribution
Running K3s or RKE2 costs more in people and upgrades than in licenses, since both are open source. The cards below separate the one-time build work from the recurring items that a written quote should spell out. Use them to compare how each distribution shifts effort between your team, your hardware and any paid support.
Infrastructure footprint
Nodes, memory and datastore hosts are a recurring cost tied to how many servers you keep running. K3s is delivered as a single binary under 100 MB and uses about half the memory of standard Kubernetes, according to the K3s documentation, but its default SQLite datastore is a single-node design, so high availability means choosing an external datastore. RKE2 runs control plane components as static pods, which shifts the host count toward three control plane nodes. Ask the vendor or partner to price each control plane and datastore host separately.
Staff skills and on-call load
Salaries and on-call rotations are the largest recurring cost for most self-hosted clusters, and they are paid by your organization to your own engineers or to a partner. RKE2 expects engineers who can work with CIS-aligned defaults, FIPS-enabled builds and CVE scan results, while K3s expects fewer moving parts but still needs staff who can run its datastore and bundled ingress. Ask any partner for the named roles, the hours covered by on-call and the escalation path for control plane incidents.
Support subscriptions to confirm
Both distributions are open source, but commercial support, long-term maintenance and enterprise features may come from Rancher or other vendors under separate agreements. Those terms are recurring and are priced by the vendor, not by DeployOpen. Confirm in writing which support tier covers each distribution, the response targets, the supported versions and whether FIPS-validated builds or CIS hardening guidance are included. Do not assume a subscription covers a partner's implementation work.
Upgrade cadence and support windows
Upstream Kubernetes ships about three minor releases per year on a cycle of about 14 weeks, and the project maintains the three most recent minors. Version 1.35 ends February 28, 2027, 1.36 ends June 28, 2027 and 1.37 ends October 28, 2027, according to kubernetes.io/releases. Each minor gets about one year of patch support, so plan a recurring upgrade every few months. Ask how each distribution tracks upstream releases, how long it backports fixes and who tests the upgrade path.
Compliance evidence work
Regulated teams carry a recurring cost to collect evidence that controls still hold after each upgrade. RKE2 documents defaults aimed at passing the CIS Kubernetes Benchmark and FIPS 140-2 support, which reduces the hardening work at build time. Evidence still has to be generated each cycle, and DeployOpen prepares that evidence but does not issue audit reports or certifications. Ask for the scan and benchmark outputs per release and who reviews them.
Replacing bundled add-ons
K3s bundles Traefik, Flannel, CoreDNS, ServiceLB and a local-path provisioner by default. If your standards require a different ingress, CNI or storage class, replacing those components is a one-time migration cost plus recurring testing for each upgrade. RKE2 ships a different default add-on set, so the replacement list differs. Ask for an inventory of bundled components, the steps to disable or swap each one and a test plan that covers both upgrades and rollback.
Moving from K3s to RKE2 or back: what transfers and what is rebuilt
This sequence separates the workload layer, which usually moves largely intact, from the cluster layer, which is rebuilt on the target distribution, so each wave can be validated before the source cluster is retired.
Inventory bundled components and workloads in use
The platform engineering team lists every workload, Helm release, and namespace on the source cluster, then records which bundled K3s components the cluster depends on: Traefik ingress resources and middleware, Flannel network assumptions, ServiceLB services, and local-path persistent volumes. Each item is tagged as carry over, replace, or confirm. The output is a written inventory signed off by the application owners, with every Traefik or local-path dependency named so it is not discovered during cutover.
Back up the datastore and Secrets material
The cluster operator takes a backup of the K3s datastore using the backup procedure in the K3s documentation, and exports manifests and Helm values for every release. Because Secrets are stored unencrypted in etcd unless encryption at rest is configured, the operator confirms where those values are kept and stores the backup under the same access controls as the source. The step is done when a restore from the backup has been tested in an isolated environment and the Secrets inventory is complete.
Stand up the target RKE2 cluster
The platform team builds the RKE2 cluster on the agreed hosts, then sets the CNI, ingress controller, and load balancing choices it intends to keep. Encryption at rest for Secrets is configured before any workload is deployed, and the CIS-related defaults are reviewed against the organization's own benchmark assessment. The output is a cluster that passes the team's admission, RBAC, and network policy checks with no application traffic yet.
Rebuild ingress, CNI, and add-on replacements
The team re-creates each K3s-bundled function that the target distribution handles differently: ingress rules are rewritten for the chosen controller, network policies are re-tested under the target CNI, and storage classes replace local-path claims. Each replacement is recorded with its owner and its test. The step closes when every item in the inventory marked replace has a working equivalent in staging and the team has confirmed the behavior change list with the distribution documentation.
Migrate workloads in waves
Workloads are moved by namespace or service group, starting with stateless, low-risk applications. Manifests and Helm charts are applied to the target cluster, container images are pulled from the same registry, and stateful data is moved with the method each application's owner has approved, often a copy with a planned write freeze. Each wave has a rollback path back to the source. The wave is complete when its health checks, logs, and owner sign-off are recorded.
Validate against the agreed acceptance criteria
After each wave, the team runs functional tests, confirms ingress and DNS routing, checks backup jobs and monitoring targets, and verifies that Secrets are readable only by the intended service accounts. Results are compared with the acceptance criteria written during planning. Validation is complete when every criterion is marked pass with evidence, and any failure has a documented fix and a retest.
Retire the source cluster and confirm the migration path
Once all waves pass validation and a retention period agreed with the business has elapsed, the source K3s cluster is shut down, its backups are kept under the retention policy, and its access is revoked. Before any work starts, the reader must confirm supported migration paths, version requirements, and any direction-specific limits, such as a move back from RKE2 to K3s, with the K3s and RKE2 documentation. The step is done when the decommission record and the confirmed migration notes are filed with the change records.
Implementing each distribution and where projects usually run long
Implementation effort for both distributions starts with the same decisions: host sizing, server count, datastore and how the control plane is laid out. A single K3s server is the fastest path to a working cluster, and its default SQLite datastore keeps that path short. A highly available K3s layout needs a supported external datastore such as etcd, MySQL or PostgreSQL, so the datastore choice has to be made before the first node is built. RKE2 runs its control plane components as static pods with an embedded containerd runtime, so host sizing and the number of server nodes drive the design more than the datastore does. For a stacked layout that mirrors the kubeadm high availability guidance, plan at least three control plane nodes behind a TCP load balancer that fronts the API server on port 6443, and confirm with Rancher's documentation at RKE2 documentation how each distribution expects its server and agent join tokens and load balancer address to be configured. Whichever distribution you choose, the work after the cluster is up is what decides the project's length: backup and restore drills for etcd or the chosen datastore (using the etcdctl snapshot save and etcdutl workflow the Kubernetes documentation describes), identity wiring against your OIDC provider, admission policy, monitoring and an upgrade runbook that respects the Kubernetes version skew policy.
Projects usually run long for three reasons. The first is unplanned replacement of bundled components. K3s ships Traefik, Flannel, CoreDNS, ServiceLB and the local-path provisioner by default, and teams that adopt those defaults and later swap Traefik or Flannel for another ingress or CNI discover the change touches manifests, network policy and monitoring. Decide early which bundled components you keep, and confirm with the K3s documentation at K3s documentation how each one is disabled or replaced. The second is a datastore decision made late. Moving a running K3s cluster from SQLite to an external datastore is a migration, not a setting, so the choice belongs in the written scope. The third is compliance evidence gathered after the build. RKE2 defaults are aimed at CIS Kubernetes Benchmark and FIPS 140-2 alignment, but DeployOpen prepares controls and evidence without issuing audit reports, so the evidence plan (configuration baselines, Secrets encryption at rest, least-privilege RBAC on Secrets) should be agreed before hardening starts. DeployOpen works on fixed scope agreed in writing before work starts, so ask for the component list, datastore, node count and evidence deliverables to appear in that document, with any retainer for upgrades and testing priced separately.
What buyers ask before choosing K3s or RKE2
How much effort does it take to run K3s compared with RKE2?
K3s usually needs less day-two effort because it ships as a single binary of less than 100 MB and bundles containerd, Flannel, CoreDNS, Traefik, ServiceLB and a local-path provisioner by default. RKE2 keeps its control plane components as static pods with an embedded containerd runtime and adds hardening defaults, so its footprint is heavier but its security baseline is stronger out of the box. Effort on either side grows with the number of clusters, the upgrade cadence and how many add-ons you replace. Confirm the expected upgrade process and monitoring tooling with the vendor documentation before you size the team.
Can an internal team run either distribution without outside help?
A team that already operates Linux, certificates, DNS, load balancers and Kubernetes objects can usually run either distribution, but the skills needed differ. K3s teams need to know which bundled components they keep and which they replace, such as Traefik or Flannel. RKE2 teams need to understand the CIS-aligned defaults, FIPS 140-2 mode if it applies, and how to verify them after each upgrade. Be honest about gaps in Kubernetes authentication, etcd backup and restore, and secrets encryption, because those failures surface in production rather than during installation.
How long does a first build take, and what sets that time?
No supplied fact gives a duration for a first K3s or RKE2 build, so treat any number you hear as unverified until it is written into a scope. The time is driven by the number of nodes, whether the datastore is embedded or external, how many bundled components you keep, the network and identity integration, backup design and the acceptance tests you require. A first build in a regulated environment also includes evidence collection for controls, which often takes longer than the installation itself. Ask for a milestone plan in the written scope.
Is RKE2 required for a CIS assessment or FIPS 140-2 scope?
No. RKE2 ships defaults that help clusters pass the CIS Kubernetes Benchmark and enables FIPS 140-2 compliance, but a CIS assessment or FIPS scope is determined by your assessor and your cluster configuration, not by the distribution name alone. K3s can be hardened to follow the CIS Kubernetes Benchmark, though that work falls to your team or your implementation partner. Confirm with the assessor which benchmark version and which FIPS validation status your scope requires, and whether a hardened K3s build would be accepted.
Can K3s run in production with an external datastore?
Yes. K3s uses an SQLite-based datastore by default, but the K3s documentation also lists etcd3, MySQL and PostgreSQL as available options. The choice affects high availability design, backup procedures and failure behavior, so pick the datastore against your recovery objectives rather than convenience. Whichever option you choose, confirm the supported topology, backup and restore steps and upgrade path in the K3s documentation before committing to it.
How does switching between K3s and RKE2 later affect workloads?
Workloads written to standard Kubernetes APIs generally move more easily than workloads tied to bundled components. The main switching costs are the ingress controller (Traefik in K3s), the CNI and network policy behavior, storage classes, the secrets encryption configuration and the operational runbooks. Plan a rebuild of the cluster rather than an in-place conversion, and test it in a non-production environment with a copy of your manifests and backups. Ask any implementation partner to quote the migration as a separate, written scope.
What does the work need from our staff?
Plan for named owners in four areas: Linux and virtualization or bare metal, Kubernetes administration, identity integration for cluster access, and security operations for benchmark checks, vulnerability scanning and secrets handling. Kubernetes authenticates users through certificates, OpenID Connect or other supported methods, so identity staff must be involved early. Someone also needs to own etcd backup and restore, because Kubernetes secrets are stored unencrypted in etcd unless encryption at rest is configured. Document who approves upgrades and who can roll them back.
What should we request in a written quote?
Ask for a quote that lists the target distribution and version, node counts and topology, datastore choice, which bundled components are kept or replaced, identity and network integration, backup and restore testing, hardening scope, documentation and handover, and any evidence the controls require. Fixed-scope engagements agree scope, deliverables and timelines in writing before work starts, so the quote should match that document. Ask which items are one-time and which recur, such as support retainers and upgrades, and what drives each cost. DeployOpen does not publish a price list, so a quote follows from the written scope.
How DeployOpen helps choose, implement or migrate
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including Kubernetes clusters on virtual machines and bare metal. For a K3s or RKE2 decision, the work starts with your environment and compliance obligations, then moves to a written scope before any cluster is built.
How we scope
- Review your hosts, network layout, air-gap requirements and the compliance baseline a K3s or RKE2 cluster must meet.
- Agree in writing which control plane and datastore layout, add-ons and upgrade path are in scope before work starts.
- Confirm with your team which bundled components, such as Traefik or Flannel, you keep or replace, since this changes the scope.
How we build
- Install the chosen distribution on your VMs or bare metal, with the datastore, CNI and ingress choices recorded in the scope.
- Apply hardening and configuration aligned with the CIS Kubernetes Benchmark where the chosen distribution supports it, and test the results.
- Run security testing against the cluster and its exposed services, then document any findings and their fixes.
How we hand over
- Deliver written documentation covering architecture, configuration, backup and etcd or datastore procedures, and upgrade steps.
- Provide compliance evidence and control mappings that your internal team or independent auditors can review, without us issuing any attestation.
- Walk your operators through runbooks for upgrades, node replacement and restores, and record the handover against the written scope.
How we support
- Offer ongoing support, distribution upgrades and continuous testing as a retainer, sized to your cluster and change rate.
- Plan Kubernetes minor version upgrades around your own support windows and the version skew rules for each cluster.
- Ask for the retainer terms, response expectations and upgrade scope in writing before you commit to any ongoing work.
