Skip to content

Add ADR on virtualisation #18

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Jul 8, 2025
Merged

Add ADR on virtualisation #18

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
5636f1f
added adr for virtualisation, and moved previous stuff from main guid…
housa Mar 17, 2025
2f64461
remove adr file to do clean up pr first
housa Jul 8, 2025
100f9b1
Update docs/hardware_ready/_index.md
housa Jul 8, 2025
90b1cb3
remove duplicate blank line
housa Jul 8, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 1 addition & 10 deletions docs/hardware_ready/_index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,16 +1,6 @@
---
title: Getting your hardware ready
---
## Virtualisation or bare metal

One important aspect is to determine whether the clusters should run on an OS directly on the machines, or if it makes sense to add a virtualisation layer.

Running directly on the hardware gives you a 1-1 relationship between the machines and the nodes. This is not always advised if the machines are particularly beefy. Running directly on the hardware will of course have lower latency than when adding a virtualisation layer.

A virtualisation layer can benefit via abstracting the actual hardware, and enable simple zero downtime hardware maintenance.

In case virtualisation is chosen, the below recommendations are what you would run in your VM. For setting up your VM’s we recommend Talos with KubeVirt.

## Decision Matrix

| Problem domain | Description | Reason for importance | Tool recommendation |
Expand All @@ -19,3 +9,4 @@ In case virtualisation is chosen, the below recommendations are what you would r
| Storage solution | The underlying storage capabilities which Kubernetes will leverage to provide persistence for stateful workloads | Choosing the right storage solution for your clusters needs is important as there is a lot of balance tradeoffs associated with it, e.g redundancy vs. complexity | [Longhorn](Longhorn_as_storage_solution.md) |
| Container Runtime (CRI) | The software that is responsible for running containers | You need a working container runtime on each node in your cluster, so that the kubelet can launch pods and their containers | |
| Network plugin (CNI) | Plugin used for cluster networking | A CNI plugin is required to implement the Kubernetes network model | [Cilium](Cilium_as_network_plugin.md) |
| Virtualisation | An optional layer between your hardware and your Kubernetes tech stack | In some scenarioes it might be benefitial to abstract the underlying hardeware away, and have everything running in virtual machines | |