When we started building Lattice, we weren't trying to create another Kubernetes distribution. We were trying to solve a specific problem: deploying production-ready clusters in environments where the usual approaches don't work.
Along the way, people have asked how Lattice compares to other options. It's a fair question since the Kubernetes ecosystem is crowded, and understanding where different tools fit helps make informed decisions.
This post maps out the landscape and explains where Lattice sits within it.
The Spectrum of Kubernetes Deployments
Kubernetes deployment options range from "raw upstream" to "fully managed platform":
Upstream Kubernetes - You build everything yourself. Maximum flexibility, maximum effort. Suitable if you have specific requirements that nothing else meets and the engineering capacity to maintain it.
Lightweight distributions - K3s, k0s, MicroK8s. Simplified installation, reduced resource requirements, but you're still assembling the rest of the stack yourself.
Installer frameworks - Kubespray, kubeadm-based tooling. Automate the deployment of upstream or lightweight distributions, with varying degrees of opinion about what else gets installed.
Opinionated platforms - Rancher, OpenShift, Tanzu. Complete platforms with integrated components, management interfaces, and commercial support. More decisions made for you, less flexibility.
Managed services - EKS, GKE, AKS. Someone else operates the control plane. Great when you can use them, but not an option for air-gapped or on-premises requirements.
Lattice sits in the "installer framework" space but leans toward "opinionated platform" - it deploys a specific set of components that work well together, rather than leaving every choice to you.
Kubespray: The Closest Comparison
Kubespray is the project Lattice most resembles architecturally. Both use Ansible to deploy Kubernetes clusters, both support air-gapped installation, and both aim for production-ready deployments.
Where they align:
- Ansible-driven deployment
- Support for air-gapped environments
- Configurable component selection
- Focus on bare-metal and VM deployments
Where they differ:
Kubespray deploys upstream Kubernetes via kubeadm. This means full compatibility with the Kubernetes ecosystem, but also the resource overhead that comes with it. Lattice uses K3s, which is lighter and simpler while remaining fully conformant.
Kubespray is deliberately unopinionated about add-ons. You choose your CNI, your storage solution, your monitoring stack. This flexibility is powerful but means more decisions and more integration work. Lattice makes these choices for you - Longhorn for storage, Istio for service mesh, the Prometheus/Grafana/Loki stack for observability. You can disable components you don't need, but the defaults form a coherent, tested whole.
Kubespray is a community project without commercial backing. This is fine for many use cases, but it means support comes from community goodwill. Lattice is developed by a team that deploys and operates these clusters professionally.
K3s and k0s: The Lightweight Distributions
Lattice builds on K3s, so the comparison here is less "versus" and more "what Lattice adds on top."
K3s gives you a working Kubernetes cluster in minutes. It's remarkable engineering - a single binary that includes everything needed to run Kubernetes, with embedded container runtime and optional components like Traefik and a local storage provider.
What K3s doesn't give you is a production platform. You still need:
- Distributed storage that survives node failures
- Monitoring, logging, and alerting
- Service mesh (if you need it)
- Security hardening beyond defaults
- Tested deployment automation
Lattice packages K3s with these additional components, configured to work together and tested as a unit.
The K3s Ecosystem
One advantage of building on K3s is the ecosystem that's grown around it:
k3d wraps K3s in Docker, letting you spin up multi-node clusters on a single machine in seconds. This is invaluable for development and testing - you can validate Lattice configurations locally before deploying to real infrastructure. CI pipelines can run integration tests against disposable clusters without dedicated hardware.
k3sup simplifies K3s installation over SSH, useful for quick bootstrapping and experimentation.
AutoK3s provides a UI and API for provisioning K3s clusters across various providers.
System Upgrade Controller handles automated, rolling upgrades of K3s nodes - originally built for K3s but now usable with other distributions too.
This ecosystem means development workflows are smoother. Engineers can run realistic clusters locally, test changes quickly, and have confidence that what works in k3d will work in production K3s. The gap between development and production environments shrinks.
Why Ansible Over k3sup or AutoK3s
Given these ecosystem tools exist, why does Lattice use Ansible instead?
Strict version control - Ansible playbooks are declarative files that live in Git. Every change is tracked, reviewed, and auditable. You can diff exactly what changed between deployments, roll back to a known state, and prove to auditors precisely what was deployed. k3sup is imperative; you run commands that change state, but there's no single source of truth for what the cluster should look like.
Configuration as code - Lattice doesn't just install K3s; it configures the entire stack. Ansible's role-based structure handles the complexity of coordinating K3s installation, storage provisioning, service mesh configuration, monitoring deployment, and security hardening in a defined order with proper dependencies. k3sup and AutoK3s focus on K3s itself, leaving the rest to you.
Idempotency - Ansible playbooks can be run repeatedly, converging to the desired state without side effects. This enables both initial deployment and ongoing configuration management with the same tooling. Drift correction becomes "run the playbook again."
Organisational fit - Many organisations already use Ansible for infrastructure automation. Lattice fits into existing workflows, CI/CD pipelines, and team expertise rather than introducing another tool. In regulated environments, using approved tooling simplifies compliance.
Air-gap simplicity - Ansible needs only SSH access to target nodes. No agents to install, no control plane to run, no external dependencies during execution. In air-gapped environments where minimising moving parts matters, this is a significant advantage.
k0s from Mirantis occupies similar space to K3s — lightweight, single-binary distribution. It's technically capable, but K3s has broader adoption, a larger community, and more ecosystem tooling. Both would work as a Lattice foundation; K3s was chosen for its maturity and the practical benefits of that ecosystem.
Rancher: Fleet Management
Rancher is often mentioned alongside K3s (both from SUSE/Rancher Labs), but they solve different problems.
Rancher is a multi-cluster management platform. It excels at managing fleets of clusters - deploying them, upgrading them, providing unified access control and visibility. If you're running dozens or hundreds of clusters, Rancher adds significant value.
For single clusters or small numbers of clusters, Rancher adds complexity without proportionate benefit. The management overhead of running Rancher itself - it's a substantial application - may exceed the value it provides.
Lattice doesn't compete with Rancher; it could be managed by Rancher. But for environments with a handful of clusters, Lattice's direct Ansible deployment is simpler than introducing a management layer.
RKE2: The Hardened Alternative
RKE2, also from Rancher/SUSE, deserves specific mention. It's positioned as "a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government sector."
What RKE2 offers:
- CIS hardening enabled by default
- DISA STIG compliance out of the box
- FIPS 140-2 compliant builds available
- Secrets Encryption enabled by default
- Pod Security is restricted by default
For environments where compliance frameworks explicitly require these certifications, RKE2 is compelling. Rancher Federal specifically supports government deployments, and RKE2 is their recommended distribution for classified environments.
Why Lattice uses K3s instead:
K3s is lighter, simpler, and faster to deploy. The hardening that RKE2 provides by default can be applied to K3s - it's configuration rather than architecture. For many environments, K3s with appropriate hardening meets requirements without RKE2's additional complexity and resource overhead.
That said, the architectural difference is smaller than it appears. Both use containerd, both are fully conformant Kubernetes, and both come from the same engineering organisation.
Future compatibility:
Lattice's Ansible-driven approach isn't fundamentally tied to K3s. The modular architecture could support RKE2 as an alternative base distribution for environments that mandate it. This isn't on the immediate roadmap, but the design doesn't preclude it - and for organisations required to use RKE2 specifically, it's a path that could be explored.
OpenShift: The Enterprise Platform
Red Hat OpenShift is the most fully-featured comparison. It's a complete platform that includes:
- Kubernetes (with Red Hat's modifications)
- Container registry
- CI/CD pipelines
- Monitoring and logging
- Service mesh
- Developer console
- Operator framework
OpenShift is impressive in scope. For organisations committed to the Red Hat ecosystem with budget for licensing and full time management, it's a defensible choice.
The trade-offs:
Cost - OpenShift licensing is substantial. For smaller deployments or cost-sensitive environments, the licensing cost may exceed infrastructure costs.
Complexity - OpenShift is a large, complex platform. Operating it requires significant and dedicated expertise. The learning curve is steep, and troubleshooting often requires Red Hat support.
Flexibility - OpenShift makes many decisions for you. This is efficient when those decisions align with your needs and frustrating when they don't. Customisation is possible but sometimes fights the platform.
Resource requirements - OpenShift has significant infrastructure requirements. The control plane alone needs substantial resources before you deploy any workloads.
Lattice aims for "OpenShift-lite" outcomes - a production-ready platform with enterprise components - without the licensing cost, vendor lock-in, or operational complexity. The trade-off is less out-of-the-box functionality and no big vendor backed commercial support contract.
Talos Linux: A Different Philosophy
Talos takes a radically different approach: an immutable, API-driven operating system purpose-built for Kubernetes. There's no SSH, no shell, no package manager. Everything is managed through the Talos API.
This has genuine security benefits. The attack surface is minimal. There's nothing to misconfigure because there's nothing to configure at the OS level. Drift is impossible because the OS is immutable.
The trade-off is operational familiarity. Teams accustomed to SSH access for debugging and troubleshooting need to learn new approaches. The API-driven model is powerful but unfamiliar.
Lattice takes the opposite approach: standard Linux distributions (typically RHEL-family or Ubuntu), standard tools (Ansible, kubectl), standard access patterns (SSH when needed). This is less innovative but more accessible to teams with traditional operations backgrounds.
For environments prioritising maximum security with teams ready to adapt their operational model, Talos deserves consideration. For environments prioritising operational familiarity, Lattice's approach may be more practical.
Charmed Kubernetes: The Canonical Option
Canonical's Charmed Kubernetes uses Juju for deployment and management. It integrates well with Ubuntu and Canonical's broader ecosystem (MAAS for bare-metal provisioning, LXD for containers).
If you're already invested in the Canonical ecosystem, Charmed Kubernetes fits naturally. If you're not, Juju's model-driven operations approach has a learning curve, and the Ubuntu dependency may not align with organisational standards.
In government and defence contexts, RHEL-family distributions are more common than Ubuntu, making Charmed Kubernetes less natural a fit than it might be elsewhere.
What Lattice Prioritises
Given the landscape, Lattice makes deliberate choices:
Simplicity over features - A coherent set of components that work together, rather than every possible option. Less to configure, less to break, less to understand.
Ansible over proprietary tooling - Standard automation that teams likely already know. No new orchestration framework to learn.
K3s over upstream Kubernetes - Lighter resource requirements, simpler operation, faster deployment. Full conformance means applications don't know the difference.
Integrated stack over DIY assembly - Storage, networking, observability, and security components selected and tested together. You can deploy a production-ready platform, not just a Kubernetes API endpoint.
Air-gap capability from the start - Not an afterthought or add-on, but a core design consideration throughout.
Testing built in - Confidence that deployments work correctly, not just that they complete.
When to Choose What
Choose managed Kubernetes (EKS, GKE, AKS) when you want someone else to look after your Kubernetes infrastructure. If cloud deployment is permitted and the managed services meet your requirements, they're hard to beat for operational simplicity.
Choose OpenShift when you need the full platform, have the budget for licensing and FT management staffing, and want commercial support. It's expensive but comprehensive.
Choose Rancher when you're managing multiple clusters and need unified control plane visibility and management.
Choose Kubespray when you need maximum flexibility, want upstream Kubernetes specifically, and have the expertise to integrate your own component stack.
Choose Talos when security is paramount and you're ready to adapt operational practices to an API-driven, immutable model.
Choose Lattice when you need a production-ready platform for air-gapped or secure environments, want sensible defaults without long setup time, commercial licensing costs, and prefer familiar operational patterns (Linux, Ansible, standard Kubernetes tooling).
Conclusion
There's no universally correct choice in this landscape. Different tools optimise for different constraints - cost, complexity, security, flexibility, support.
Lattice exists because we needed something that wasn't quite available: an opinionated, production-ready platform that deploys cleanly to air-gapped environments using familiar tools, without commercial licensing overhead. We built it for our own use and made it available because others face similar challenges.
Understanding where it fits helps you decide whether it fits your needs. Get in touch if you would like to try it out.
What's Next
The next post in this series will cover infrastructure testing — validating that deployments actually work as intended, not just that they complete without errors. We'll look at why testing infrastructure matters and how Lattice's built-in test suites provide confidence in every deployment.
Lattice is a project developed by Digital Native Group.