RKE2 vs Kubespray vs Kubeadm: Deploying MariaDB on Kubernetes
Explore three approaches to setting up Kubernetes clusters—RKE2, Kubespray, and Kubeadm—through a practical MariaDB deployment scenario. Learn their architectural differences, deployment workflows, storage requirements, security considerations, and best-fit use cases.
Introduction
Kubernetes has become a popular platform for deploying and managing containerized applications, including databases. However, before deploying a database such as MariaDB, we need a Kubernetes cluster that is configured, secured, and ready to run workloads.
There are multiple ways to build a Kubernetes cluster. Three commonly discussed options are RKE2, Kubespray, and Kubeadm.
Although these tools can be used to establish a Kubernetes environment, they differ in their approach, level of automation, operational complexity, and intended use cases.
In this article, we will compare these three approaches and explore how each fits into a practical MariaDB deployment scenario.
1. Understanding the Three Approaches
What is Kubeadm?
Kubeadm is an official Kubernetes tool designed to bootstrap a Kubernetes cluster using established best practices. It helps initialize the control plane, join worker nodes, and manage certain cluster lifecycle operations.
Kubeadm does not provision the underlying servers or automatically configure every additional component required for a complete production environment. Administrators must handle prerequisites, networking, storage integrations, and other operational requirements.
Key characteristics:
- Provides direct control over cluster initialization.
- Helps build a Kubernetes cluster with standard Kubernetes components.
- Supports learning, experimentation, and customized automation.
- Requires additional configuration and operational knowledge.
Kubeadm is a good starting point for understanding how Kubernetes components work together.
Official documentation: https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/
What is Kubespray?
Kubespray is an automation project that uses Ansible playbooks, inventory files, and configuration variables to deploy and manage Kubernetes clusters.
Instead of manually configuring each server, administrators define the cluster inventory and desired configuration. Kubespray automates many installation and configuration steps across the specified machines.
Key characteristics:
- Uses Ansible for automation.
- Supports multi-node and highly available cluster deployments.
- Provides configurable networking and cluster settings.
- Helps standardize cluster provisioning and repeatable deployments.
Kubespray is particularly useful when teams need consistent Kubernetes environments across multiple servers.
Official documentation: https://kubespray.io/
What is RKE2?
RKE2, also known as Rancher Kubernetes Engine 2, is a Kubernetes distribution maintained by the Rancher/SUSE ecosystem. It focuses on secure, production-oriented Kubernetes deployments.
RKE2 provides an integrated installation and operational model, including Kubernetes components, containerd, and distribution-specific configuration and security features.
Key characteristics:
- Offers an integrated Kubernetes distribution.
- Uses containerd as its container runtime.
- Provides security-focused configuration and hardening capabilities.
- Supports standalone operation and integration with Rancher.
RKE2 is a useful choice for organizations looking for a Kubernetes distribution with an opinionated installation and security-oriented operational approach.
Official documentation: https://docs.rke2.io/
2. RKE2 vs Kubespray vs Kubeadm
The most important difference is how each approach helps establish and operate the Kubernetes cluster.
| Comparison | Kubeadm | Kubespray | RKE2 |
|---|---|---|---|
| Type | Cluster bootstrap tool | Ansible-based deployment automation | Kubernetes distribution |
| Main approach | Initialize and join nodes | Automate installation across hosts | Install and operate RKE2 services |
| Automation | Requires additional automation for broader tasks | Extensive Ansible-based automation | Integrated installation and service management |
| Configuration flexibility | High, with more manual work | High, through inventory and variables | Configuration follows RKE2's supported options |
| Operational complexity | More hands-on | Requires Ansible and inventory management | Requires familiarity with RKE2 operations |
| High availability | Supported with additional configuration | Supported through cluster configuration | Supported through RKE2's server and datastore architecture |
| Best suited for | Learning Kubernetes internals and customized setups | Repeatable, automated multi-node deployments | Security-focused Kubernetes environments |
These are different tools rather than three interchangeable installation commands. Kubespray can use Kubernetes components and tools such as kubeadm as part of its automation, whereas RKE2 provides its own integrated Kubernetes distribution.
3. Understanding the MariaDB Deployment Scenario
Consider a scenario in which a development team wants to deploy MariaDB on Kubernetes for application testing.
The database must:
- Run as a containerized workload.
- Store database files persistently.
- Be accessible to applications inside the cluster.
- Recover from container or Pod failures.
- Keep database credentials out of application manifests.
- Support backup and restore procedures.
The deployment has two separate layers:
Layer 1 — Kubernetes infrastructure: Build and configure the cluster using Kubeadm, Kubespray, or RKE2.
Layer 2 — Database workload: Deploy MariaDB using Kubernetes resources such as StatefulSets, PersistentVolumeClaims, Services, and Secrets, or use a MariaDB operator.
Choosing a different Kubernetes installation method does not fundamentally change how a standard MariaDB workload is deployed. However, the cluster's networking, storage configuration, security policies, and operational tooling can affect the database deployment.
4. High-Level Deployment Workflow
A typical workflow looks like this:
- Prepare Linux servers or virtual machines.
- Choose and install the Kubernetes distribution or deployment tooling.
- Configure the control plane, worker nodes, and Pod networking.
- Verify that all nodes are Ready.
- Configure persistent storage.
- Create a namespace and database credentials.
- Deploy MariaDB.
- Verify database connectivity and persistent data.
- Test recovery, backup, and restore procedures.
For example, after the cluster is ready, the following commands can help verify its status:
1
2
3
kubectl get nodes
kubectl get pods -A
kubectl get storageclassThe first command checks node readiness, the second checks system workloads, and the third lists available storage classes.
Before deploying MariaDB, confirm that an appropriate StorageClass exists or configure a suitable persistent storage solution.
5. Deploying MariaDB: What Changes Between the Approaches?
With Kubeadm
First, prepare the Linux hosts and install the required container runtime and Kubernetes packages. Initialize the control plane with
kubeadm init, configure kubectl, install a compatible Pod network, and join the worker nodes.Once the cluster is ready, deploy MariaDB using Kubernetes manifests or a database operator.
This approach is useful when you want to understand cluster setup and troubleshoot each component yourself.
With Kubespray
Prepare the target hosts and an Ansible control environment. Define the nodes in the Kubespray inventory, configure the required cluster variables, and execute the deployment playbooks.
After Kubespray finishes configuring the cluster, validate node readiness and storage support before deploying MariaDB.
This approach is useful when you want repeatable deployments and hands-on experience with infrastructure automation.
With RKE2
Install RKE2 on the designated server nodes, configure the cluster's networking and datastore requirements, and register worker nodes using the appropriate RKE2 agent configuration.
Once the cluster is healthy, configure storage and deploy MariaDB through standard Kubernetes resources or an operator.
This approach is useful when you want to learn an integrated Kubernetes distribution with security-focused defaults and operational tooling.
6. Important Considerations for MariaDB on Kubernetes
Persistent storage
Databases require persistent storage. A container filesystem alone is not suitable for retaining database files across Pod replacement.
Use a PersistentVolumeClaim backed by an appropriate storage system. On AWS, options may include Amazon EBS through the EBS CSI driver or Amazon EFS where shared file storage is appropriate.
For a typical single-instance MariaDB deployment, block storage is often a suitable starting point. Verify the access mode, volume topology, and recovery requirements.
Database credentials
Avoid hardcoding database passwords in application manifests or source control.
Kubernetes Secrets can be used to provide credentials to workloads, but production environments also need appropriate access controls, encryption, and secret-management practices.
High availability
Running multiple MariaDB Pods does not automatically provide database high availability.
A highly available database requires a deliberate replication or clustering design, health checks, failover behavior, backup procedures, and testing. Kubernetes node redundancy and database redundancy solve different problems.
Backups and recovery
Persistent storage protects data from some Pod-level failures, but it is not a replacement for backups.
Create a backup strategy, store backups independently of the database's primary storage, and regularly test restoration.
Security
Use appropriate network restrictions, least-privilege access, supported software versions, and regular security updates. Database access should be limited to authorized applications and administrators.
7. Which Approach Should You Choose?
The right choice depends on your learning goals and operational requirements.
Choose Kubeadm if:
- You want to understand Kubernetes architecture.
- You prefer manual control over cluster configuration.
- You want to learn node initialization, joining, networking, and upgrades.
Choose Kubespray if:
- You want to automate infrastructure provisioning.
- You manage several Linux hosts.
- You want to learn Ansible-based cluster deployment and repeatability.
Choose RKE2 if:
- You want to explore a security-focused Kubernetes distribution.
- You prefer an integrated installation and service-management approach.
- You are interested in RKE2 and Rancher-based operations.
For hands-on learning, Kubeadm is a good way to understand the underlying components, Kubespray is an excellent next step for automation, and RKE2 introduces an alternative distribution and its operational model.
8. Conclusion
Kubeadm, Kubespray, and RKE2 can all provide a foundation for running MariaDB on Kubernetes, but they approach cluster installation and management differently.
Kubeadm emphasizes cluster bootstrapping and control, Kubespray emphasizes automation across hosts, and RKE2 provides an integrated Kubernetes distribution with a focus on security and operational simplicity.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article