Kafka on Kubernetes with Strimzi or VMs: which fits your team
Choose Strimzi on Kubernetes when your team already operates Kubernetes well and wants Kafka lifecycle automation to run inside the same platform. Strimzi moves Kafka lifecycle automation onto Kubernetes, so the Cluster Operator deploys and manages Kafka, Kafka Connect, MirrorMaker and the HTTP Bridge, while virtual machines keep every operational decision with your team. Both paths run the same Apache-2.0 Kafka, and the Apache Software Foundation project offers no paid edition, so the difference is who builds and maintains the operational layer, not which Kafka you get.
Kubernetes favors Strimzi when you have cluster admins who already handle upgrades, storage classes, network policy and RBAC, and when you want Kafka topics and users declared as KafkaTopic and KafkaUser resources in version control. Node pools defined by KafkaNodePool resources let you separate broker and controller roles, and the Strimzi overview recommends a dedicated pool of three or more controllers in production. Strimzi's operators also automate rolling upgrades and recovery, which reduces manual work and downtime. Confirm with your platform team that they can staff the Kubernetes control plane, etcd backups and Kubernetes upgrade cadence alongside Kafka, because those obligations do not go away.
Virtual machines fit teams that already run mature configuration management, have no Kubernetes footprint in the regulated zone, or need to control every KRaft role, controller quorum and listener setting directly. Kafka's own KRaft operations documentation covers those decisions, and it recommends against combined broker and controller servers in critical environments. Expect your team to own rolling restarts, certificate rotation and recovery steps in full. Before you choose, ask your auditors and security team which control plane they can evidence more easily, and confirm how your organization handles the Kubernetes version skew and etcd backup duties that Strimzi would add to your scope.
How the fit changes by team and environment
Teams that already run production Kubernetes with a platform group, GitOps delivery and cluster-wide monitoring usually find that Strimzi matches existing habits. The operators reconcile Kafka resources the same way the team manages other workloads, so brokers, topics and users become declarative objects in the cluster. This tab points toward Strimzi. The choice reverses if the Kubernetes cluster is shared with teams that cannot agree on upgrade windows, or if the platform group cannot keep the cluster on a supported minor version.
- Operator-managed components: The Cluster Operator deploys Kafka, Kafka Connect, MirrorMaker and the HTTP Bridge, and the Entity Operator runs the Topic and User Operators through
KafkaTopicandKafkaUserresources. - Node pools:
KafkaNodePoolresources separate broker and controller roles, and the Strimzi overview recommends a dedicated pool of three or more controllers in production. - Version cadence: Kubernetes maintains the three most recent minor releases, which were 1.37, 1.36 and 1.35 as of September 2026, so the platform group must schedule cluster upgrades on that cadence alongside Kafka upgrades.
- Rolling upgrades: Strimzi operators automate rolling upgrades and recovery, which reduces manual steps, but the team still validates each Kafka version step against its clients.
Confirm which Strimzi release supports the Kubernetes and Kafka versions you plan to run, and ask the vendor for the supported combinations before you commit.
Teams with configuration management, VM snapshots and monitoring for virtual machines, but no cluster platform, can run Kafka as a managed process on hosts they already control. Existing tooling carries over, and the team keeps direct control of the KRaft configuration. This tab points toward VMs. The choice reverses if the team cannot staff the scripted upgrades and controller replacements described below, or if a Kubernetes platform is planned within the same period, since adopting Strimzi later means migrating running clusters.
- Existing tooling: Configuration management, host hardening and alerting extend to Kafka hosts without a new control plane to learn.
- Controller quorum: The team sets controller roles and quorum membership itself, following the KRaft operations guide, and must rehearse replacing a failed controller.
- Dedicated controllers: The Kafka documentation recommends against combined broker and controller servers in critical environments, so plan separate controller hosts from the start.
- Upgrade runbooks: Rolling upgrades are supported from the last three releases to the latest, and the team must script, test and time each step.
- Provisioning: Topics, users and ACLs are created through your own pipeline rather than through declarative resources that reconcile automatically.
Ask who owns each of these runbooks, how often they are rehearsed, and whether the same people can perform them during an incident.
Organizations under banking, healthcare or public sector obligations need evidence for access control, encryption, change history and backup. Both options can produce that evidence, but the sources differ. An operator model records changes as declarative objects that can be versioned and reviewed, while a VM model relies on change tickets and configuration management records. The tab does not pick a winner for regulated teams. It shows where the controls sit in each model and where the team must add its own.
- Authentication: Kafka supports SSL and SASL, including SCRAM-SHA-512, OAUTHBEARER and GSSAPI, and Kubernetes supports OpenID Connect for human users, so confirm which mechanism your identity provider supports for each path.
- Authorization: In KRaft clusters the StandardAuthorizer stores ACLs in the metadata log, and resources without ACLs are restricted to super users unless
allow.everyone.if.no.acl.foundis set to true. Test default-deny behavior in either model. - Secrets: Kubernetes Secrets are stored unencrypted in etcd by default, so configure encryption at rest and restrict list and watch access, or use an external store. VM deployments keep credentials in files that need their own controls.
- Scope: A Kubernetes control plane may bring additional systems into the assessment boundary, which can increase evidence work.
DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports, so confirm with your assessor which evidence format they accept before you choose a path.
In an air-gapped network, every image, package and bundle must be transferred in through an approved process, and every update repeats that transfer. An enclave that already hosts a Kubernetes cluster with an internal registry starts closer to Strimzi. An enclave with only VMs and an internal package mirror starts closer to a VM deployment. The condition that reverses the Strimzi choice is a control plane the enclave cannot keep highly available and backed up.
- Artifact mirroring: Operator images, Kafka binaries and Java 17 must all be brought in, and you should confirm the exact artifacts each Strimzi and Kafka release requires.
- Control plane availability: The kubeadm high availability guide describes a stacked topology with at least three control plane nodes and a TCP load balancer on port 6443, or an external etcd cluster.
- etcd operations: Run an odd number of members, five is the recommended production size, and back up with
etcdctl snapshot save, restoring withetcdutl. - Release bundles: Kubernetes version skew rules and Kafka rolling upgrades both require staged bundles, so transfer each release set before its upgrade window opens.
- Dependencies: Confirm whether your enclave allows the Kubernetes and Kafka runtime dependencies you plan to use, including Java.
Write down how each bundle reaches the enclave and who verifies it before any upgrade is scheduled.
Strimzi on Kubernetes against VM deployments, factor by factor
This table compares running Apache Kafka with the Strimzi operators on Kubernetes against running it on virtual machines under your own tooling, one factor per row. Read each row for the condition under which that factor should decide the choice, since most advantages depend on whether your team already runs Kubernetes well. The main takeaway is that Strimzi shifts work into the Kubernetes layer you must operate, while VMs keep that work in tooling you must build and maintain yourself.
| Factor | Strimzi on Kubernetes | Kafka on virtual machines |
|---|---|---|
| License | Strimzi and Kafka are both open source. Kubernetes is Apache 2.0. Costs come from the platform team and infrastructure, not from licenses, so this factor rarely decides the choice. | Kafka is Apache-2.0 with no paid edition from the project. Licensing is neutral, so the decision turns on operating effort and existing platform skills. |
| What the operator automates | The Cluster Operator deploys Kafka, Connect, MirrorMaker and the HTTP Bridge. Topic and User Operators manage KafkaTopic and KafkaUser resources. Matters most when you want topics and users declared as code. | Your team writes and maintains the provisioning, topic creation, user management and configuration for each broker and controller. Matters when you already have mature configuration management for VMs. |
| KRaft node pools and controller layout | KafkaNodePool resources separate broker and controller roles. The Strimzi overview recommends a dedicated pool of three or more controllers in production. Matters when you want that layout enforced by declarative resources. | Kafka's KRaft documentation covers the roles and controller quorum you configure yourself. It recommends against combined broker and controller servers in critical environments. Matters when you need full control over host placement. |
| Rolling upgrades | Strimzi operators automate rolling upgrades and recovery of Kafka components, reducing manual work and downtime. Confirm the supported upgrade path for your target version in the Strimzi documentation. | Your runbook must sequence restarts, check under-replicated partitions and handle rollback. Kafka's time-based release plan supports rolling upgrades from the last three releases to the latest, which applies on either platform. |
| Control plane and etcd dependencies | You must run a highly available Kubernetes control plane, which Kubernetes documents with at least three control plane nodes and etcd with an odd member count, five in production. Matters if the cluster already exists and is operated by a skilled team. | No Kubernetes control plane is required, so the Kafka estate has fewer moving parts. Your team still owns host patching, network layout and load balancing for every node. |
| Authentication and secrets | Kafka users are declared through KafkaUser resources. Kubernetes Secrets are stored unencrypted in etcd by default, so you must configure encryption at rest and restrict list and watch access with RBAC, or use an external store. Confirm this before storing Kafka credentials there. | Kafka supports SSL and SASL mechanisms such as SCRAM-SHA-512 and OAUTHBEARER on any host. Your team chooses the secret store, such as a vault, and manages rotation outside Kubernetes. |
| Skills required | Platform engineers need Kubernetes operations, RBAC, storage classes and etcd care alongside Kafka knowledge. Matters if your organization already runs Kubernetes in production. | Linux administration, Kafka configuration and automation tooling are the core skills. Matters if your team is strong on VMs and has no Kubernetes practice yet. |
How Cluster, Topic and User Operators and KafkaNodePool resources divide the work
On Kubernetes, Strimzi splits Kafka operations across a Cluster Operator, an Entity Operator and KafkaNodePool resources. On virtual machines, your team owns the same decisions directly. Each card below marks one piece of that split and what to verify before choosing a layout.
Cluster Operator and managed components
The Cluster Operator deploys and manages Kafka, Kafka Connect, MirrorMaker and the HTTP Bridge from custom resources. It is the component that carries out rolling changes to running clusters. Check which of these components your design needs, since each one adds pods to size, patch and monitor. Ask your team which upgrade steps still need a human decision, such as pausing between broker restarts.
Entity Operator with Topic and User Operators
The Entity Operator runs the Topic Operator and User Operator, which reconcile KafkaTopic and KafkaUser resources into live topics and credentials. Topics and users then live in Git as code instead of in ad hoc broker commands. The risk is drift: anyone who changes a topic directly on the cluster may see that change overwritten. Confirm how your change process handles emergency topic edits.
KafkaNodePool groupings for roles
KafkaNodePool resources group nodes by KRaft role, so broker pools and controller pools can have different storage, resources and scheduling rules. This keeps role changes visible in version control. On virtual machines, the same grouping is a naming and inventory convention your team must maintain by hand. Check that node pool storage classes and zones match your failure-domain plan before the first deployment.
Dedicated controller pool in production
The Strimzi overview recommends a dedicated pool of three or more controllers for production. Controllers hold cluster metadata, so a dedicated pool keeps that quorum separate from broker load and restarts. Ask whether your availability target and budget allow three controllers in separate failure domains, and what happens to the quorum during a node drain.
Rolling upgrades and recovery
Strimzi operators automate rolling upgrades and recovery of Kafka components, which reduces manual steps and downtime. Kafka's own time-based release plan still limits which versions can be rolled to the latest release. Confirm the supported upgrade path for your current version before scheduling a change window, whichever way you deploy.
KRaft roles and quorum on virtual machines
On virtual machines, your team writes the KRaft process roles and controller quorum settings itself and keeps them consistent across hosts. Kafka's operations guidance recommends against combining broker and controller roles on the same servers in critical environments. Plan for quorum configuration, certificate rotation and recovery runbooks that the operator would otherwise handle, and budget that ownership in the quote.
Rolling upgrades and recovery: what the operator does and what remains yours
On Strimzi, the Cluster Operator automates rolling upgrades and recovery of Kafka components, which the Strimzi overview describes as reducing manual work and downtime. On virtual machines, your team owns that sequence. Someone has to decide the order in which brokers and controllers restart, confirm the controller quorum is healthy before and after each step, and keep the change log that proves it. The decision to make before you choose a model is who carries that runbook at 2 a.m., and whether your team has rehearsed it on a non-production cluster.
Version planning is the same work under either model, but the operator changes who executes it. Apache Kafka's supported releases are 4.3.1 (June 25, 2026), 4.2.2 (September 29, 2026) and 4.1.2 (March 17, 2026), and the time-based release plan supports rolling upgrades from each release in the past year to the latest version. Kafka 4.0 removed ZooKeeper, so any ZooKeeper-based cluster must migrate to KRaft first, and clusters older than 3.3.x should move to 3.9.x before 4.x. Brokers, Kafka Connect and tools require Java 17 from 4.0 onward, so check JVM versions on every VM image or container base before you start. Confirm with your Strimzi release notes which Kafka versions your operator build supports, because the operator and Kafka versions must match.
Kubernetes adds a second upgrade track that you cannot skip. The version skew policy requires kube-apiserver to move one minor version at a time, before kube-controller-manager, kube-scheduler and kubelets, and allows kubelets up to three minor versions older than the API server. The Kubernetes project maintains only the three most recent minor releases, so 1.37, 1.36 and 1.35 were the supported lines as of September 2026. Plan Kubernetes upgrades and Strimzi upgrades as separate changes, and check the operator's compatibility notes before each. Ask your platform vendor or distribution how node upgrades interact with Kafka pod disruption budgets, because a node drain can stall a broker restart.
Choosing a deployment model in four decisions
This sequence takes you from your current Kubernetes skills to a deployment model you can staff, upgrade and secure, so each choice rests on a condition you have checked rather than a preference. Work through it with your platform, operations and security leads before any architecture is approved.
Confirm existing Kubernetes operations skill
Start by checking whether your team already runs Kubernetes in production, including cluster upgrades, etcd backups, RBAC, network policy and node maintenance. Strimzi automates Kafka components on top of the cluster, but it does not replace the cluster itself, so someone must own the Kubernetes layer. If that skill sits with a single person or does not exist, a VM deployment with your own tooling may be the safer starting point. The output is a named owner for the cluster and a short list of the Kubernetes tasks that owner already performs without outside help.
Decide controller layout and quorum size
Next, decide how Kafka nodes split into broker and controller roles. Strimzi groups KRaft nodes into node pools defined by KafkaNodePool resources, and its overview recommends a dedicated pool of three or more controllers in production. On virtual machines, your team defines the controller quorum itself, and Kafka's KRaft operations documentation recommends against combined broker and controller servers in critical environments. Record the layout you intend, the number of controllers, and the failure domains they span. The check that closes this step is a written diagram showing which nodes hold each role and where they run.
Assign ownership of upgrades and recovery
Decide who performs Kafka version upgrades, Kubernetes minor upgrades and recovery work, and which tasks the operator handles for you. Strimzi operators automate rolling upgrades and recovery of Kafka components, which reduces manual work and downtime, but the platform team still owns the Kubernetes version path. Kafka supports rolling upgrades from each release in the past year to the latest version, and Kubernetes requires control plane components to move one minor version at a time. On virtual machines, every rolling restart, configuration change and recovery step is a runbook your team writes and rehearses. Close this step with a responsibility matrix that names an owner for each upgrade path and a rehearsed restore procedure.
Confirm backup scope for each layer
Map backups across the layers that matter: Kafka topic data, controller metadata, Kubernetes state and etcd. On Kubernetes, the etcd data needs its own backup plan, and Kubernetes documentation covers snapshot saves with etcdctl and restores with etcdutl. Ask your Strimzi and Kafka vendor or consultant to confirm how topic data and controller metadata are recovered in your chosen topology, and test that recovery in a non-production environment. The output is a documented backup schedule per layer and a restore test with recorded results.
Check secrets storage and encryption
Review where Kafka credentials, TLS keys and Kubernetes Secrets will live. Kubernetes stores Secrets unencrypted in etcd by default, so configure encryption at rest, restrict list and watch access with least-privilege RBAC, or use an external store through the Secrets Store CSI Driver. On virtual machines, the equivalent question is which secret manager holds keystores and SASL credentials, and how file permissions and rotation are enforced. Confirm with your security team which approach meets your internal standard. The check that closes this step is a secrets inventory with a storage location and an access owner for each entry.
Validate client authentication and authorization
Choose the authentication mechanism for clients, brokers and tools. Kafka supports SSL and SASL, including GSSAPI (Kerberos), PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 and OAUTHBEARER, and Strimzi's User Operator manages KafkaUser resources and their credentials. In KRaft clusters, the StandardAuthorizer stores ACLs in the metadata log, and resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true. Confirm that your identity provider can issue the tokens your chosen mechanism needs, and that no listener is left unsecured. The output is a tested list of users, mechanisms and ACLs, with a note on which identity integrations need your identity team's sign-off.
Questions teams ask before running Kafka on Kubernetes or VMs
What drives the cost and effort of running Kafka on Kubernetes with Strimzi?
The main costs are the Kubernetes platform the cluster runs on, the engineering time to operate it, and the people who build and maintain the Strimzi configuration. Strimzi itself is open source under Apache 2.0, so the license is not the cost driver. Effort rises with the number of clusters, the number of topics and users managed through custom resources, and how much of the Kubernetes control plane your team must run, patch and back up. Ask any implementation partner for a quote built from a written scope that lists clusters, environments, authentication and upgrade expectations.
What drives the cost and effort of running Kafka on virtual machines?
On virtual machines, the cost is mostly the operations work your team owns: provisioning servers, configuring KRaft roles and the controller quorum, writing and testing upgrade runbooks, and building your own tooling for topics, users and recovery. Kafka's own documentation recommends against combined broker and controller servers in critical environments, so plan for separate controller nodes from the start. Effort rises with fleet size, the number of manual steps in each rolling upgrade, and how many automation scripts you must keep working as Kafka releases change. Infrastructure costs are one-time setup plus recurring hosting, and the recurring operations hours usually dominate.
Can a team run Strimzi without prior Kubernetes experience?
Not comfortably in production. Strimzi runs Kafka inside a Kubernetes cluster, so the team must understand pods, persistent volumes, networking, RBAC and upgrades of the cluster itself, along with Kafka's KRaft roles. Someone must also own the Kubernetes control plane, which the kubeadm high availability guide describes as at least three control plane nodes behind a TCP load balancer on port 6443. Teams without this skill set should either build it through training or bring in outside help for the first deployment. Confirm your staff's experience against the scope you plan to run before you commit.
How long does a migration between Kubernetes and virtual machines take?
No supplied figure exists for this, so treat any duration as something to confirm in scope. The time depends on the number of clusters, the volume of data that must be moved or mirrored, the number of topics, users and client applications that must reconnect, and the authentication and authorization model in use. Migrations usually need a parallel run, a cutover plan and rollback steps. Ask for the migration approach, the cutover sequence and the testing evidence to be written into the scope before work starts, and confirm how Kafka client compatibility and rolling upgrade paths apply to your versions.
What does the work need from the team on each path?
On Strimzi, the team needs Kubernetes operations skills, GitOps or equivalent change control for custom resources such as KafkaNodePool, KafkaTopic and KafkaUser, and a process to review operator upgrades. On virtual machines, the team needs Linux administration, Kafka KRaft configuration expertise, TLS and SASL setup, and tested scripts for every upgrade step. Both paths need monitoring, backup planning and a clear owner for incidents. The Kafka upgrade notes require ZooKeeper-based clusters to move to KRaft before upgrading to 4.x, so confirm your current state before choosing a path.
Can DeployOpen plan, implement and support either path?
Yes. DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, which covers both a Strimzi deployment on Kubernetes and a KRaft deployment on virtual machines. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support, upgrades and testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask for the scope to state which path you chose, how upgrades will be handled and who owns each component afterward.
What security work sits with the team on Kubernetes that does not on VMs?
Kubernetes adds controls that your team must configure. Secrets are stored unencrypted in etcd by default, so you should enable encryption at rest, restrict list and watch access with least-privilege RBAC, or use an external store through the Secrets Store CSI Driver. The etcd cluster needs an odd number of members, a five-member cluster is recommended in production, and it needs a tested backup plan using etcdctl snapshot save and etcdutl for restores. Pod Security Standards and the CIS Kubernetes Benchmark are useful references for hardening. On virtual machines, the same Kafka controls apply, but your team also owns OS hardening and host access. Confirm how each control maps to your own compliance obligations with your auditor.
What drives the cost of each deployment model
Neither path carries a license fee for the core software: Apache Kafka is Apache-2.0 licensed with no paid edition from the project, and Strimzi is also open source. So the cost of running Kafka on Kubernetes or on virtual machines comes from infrastructure, platform operations, staff time, upgrades and security work. The one-time work is the initial build: sizing the broker and controller nodes, designing the Kubernetes or VM baseline, setting up TLS and SASL listeners, configuring authorization, and wiring monitoring and backups. The recurring work is what keeps the cluster healthy after go-live, and it is where the two models diverge most.
On Kubernetes, the Strimzi Cluster, Topic and User Operators absorb much of the routine Kafka administration, such as creating KafkaTopic and KafkaUser resources and performing rolling upgrades. But the platform underneath is not free to run. You still pay for the Kubernetes control plane, which carries its own upgrade cadence (Kubernetes ships about three minor releases a year and maintains the three most recent minors), its etcd backups and its Secrets encryption at rest. On virtual machines, the operations team owns the KRaft role layout, controller quorum, certificate rotation and rolling restarts by hand, so recurring staff time is usually the larger line item. Ask any party quoting either model to separate platform labor from Kafka labor.
When requesting a written scope or quote, ask for each of these: the number of broker and dedicated controller nodes and their pool layout; who performs each Kafka upgrade and how many upgrade windows per year are assumed; whether Kubernetes version upgrades, etcd backup testing and CIS-aligned hardening are included; how Kafka Java 17 runtime and OS patching are handled; and which security evidence (access reviews, ACL exports, key rotation records) is delivered. Confirm current support windows directly with the Kubernetes releases page and the Kafka downloads page before you size the upgrade calendar, because those dates drive how often recurring work occurs.
How DeployOpen scopes and delivers Kafka deployments
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, so the Kafka layout is built where your data and controls already live. Whichever runtime you choose, the work starts with a written scope that states what the cluster must do and who operates it afterwards.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope names the Kafka version, the runtime (Strimzi on Kubernetes or VMs), and which node pools or controller roles are included.
- Scope also records who owns Kubernetes or VM operations, upgrades and on-call response after handover.
How we build
- Build covers KRaft node pools or controller quorum layout, listener security with SSL or SASL, and topic and user provisioning.
- Work includes configuring the Strimzi operators or your VM tooling so rolling upgrades and restarts follow a documented procedure.
- Testing covers failover of a broker or controller, and backup and restore of the configuration and etcd or metadata state where applicable.
How we hand over
- Handover documents the topology, runbooks for upgrades and recovery, and how the Topic and User Operators are used day to day.
- Deliverables include configuration as code and a record of the controls and evidence your compliance assessor may ask to see.
- Your team receives walkthroughs so operators can run the platform without depending on DeployOpen for routine changes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the initial build.
- Upgrade planning checks the Kafka release line and the Kubernetes or OS version in use before each change.
- Ask any provider for the support hours, response commitments and upgrade responsibilities in writing before signing.
