From 5636f1f9c1c16f3c5a28658cb2a73d435580c4c9 Mon Sep 17 00:00:00 2001 From: Alexandra Aldershaab Date: Mon, 17 Mar 2025 10:21:06 +0100 Subject: [PATCH 1/4] added adr for virtualisation, and moved previous stuff from main guide page --- docs/hardware_ready/ADRs/virtualisation.md | 37 ++++++++++++++++++++++ docs/hardware_ready/_index.md | 11 +------ 2 files changed, 38 insertions(+), 10 deletions(-) create mode 100644 docs/hardware_ready/ADRs/virtualisation.md diff --git a/docs/hardware_ready/ADRs/virtualisation.md b/docs/hardware_ready/ADRs/virtualisation.md new file mode 100644 index 0000000..5ab3f4b --- /dev/null +++ b/docs/hardware_ready/ADRs/virtualisation.md @@ -0,0 +1,37 @@ +--- +title: "Virtualisation" +date: "2025-03-17" +--- + + +| status: | date: | decision-makers: | +| --- | --- | --- | +| proposed | 2025-03-17 | Alexandra Aldershaab | + + +## Context and Problem Statement + +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. + +For larger companies, it is usually possible to provision VM's from the IT department, and in that case the clear recommendation would alway be to just use what is available. + +## Considered Options + +* KubeVirt +* Incus +* Proxmox + +## Decision Outcome + +Chosen option: "{title of option 1}", because {justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force {force} | … | comes out best (see below)}. + + +### Consequences + +* Good, because {positive consequence, e.g., improvement of one or more desired qualities, …} +* Bad, because {negative consequence, e.g., compromising one or more desired qualities, …} +* … \ No newline at end of file diff --git a/docs/hardware_ready/_index.md b/docs/hardware_ready/_index.md index e856242..1fedc32 100644 --- a/docs/hardware_ready/_index.md +++ b/docs/hardware_ready/_index.md @@ -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 | @@ -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 | [KubeVirt??](virtualisation.md) | From 2f64461a60c498f956b99c0bab8b916b21b5a155 Mon Sep 17 00:00:00 2001 From: Alexandra Aldershaab Date: Tue, 8 Jul 2025 14:00:22 +0200 Subject: [PATCH 2/4] remove adr file to do clean up pr first --- docs/hardware_ready/ADRs/virtualisation.md | 37 ---------------------- 1 file changed, 37 deletions(-) delete mode 100644 docs/hardware_ready/ADRs/virtualisation.md diff --git a/docs/hardware_ready/ADRs/virtualisation.md b/docs/hardware_ready/ADRs/virtualisation.md deleted file mode 100644 index 5ab3f4b..0000000 --- a/docs/hardware_ready/ADRs/virtualisation.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: "Virtualisation" -date: "2025-03-17" ---- - - -| status: | date: | decision-makers: | -| --- | --- | --- | -| proposed | 2025-03-17 | Alexandra Aldershaab | - - -## Context and Problem Statement - -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. - -For larger companies, it is usually possible to provision VM's from the IT department, and in that case the clear recommendation would alway be to just use what is available. - -## Considered Options - -* KubeVirt -* Incus -* Proxmox - -## Decision Outcome - -Chosen option: "{title of option 1}", because {justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force {force} | … | comes out best (see below)}. - - -### Consequences - -* Good, because {positive consequence, e.g., improvement of one or more desired qualities, …} -* Bad, because {negative consequence, e.g., compromising one or more desired qualities, …} -* … \ No newline at end of file From 100f9b1f1d8bbf4c7ac477ef3cd56483aebd3d33 Mon Sep 17 00:00:00 2001 From: Alexandra Date: Tue, 8 Jul 2025 14:13:33 +0200 Subject: [PATCH 3/4] Update docs/hardware_ready/_index.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Kasper Møller <83021349+moller2866@users.noreply.github.com> --- docs/hardware_ready/_index.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/hardware_ready/_index.md b/docs/hardware_ready/_index.md index 1fedc32..0d15d96 100644 --- a/docs/hardware_ready/_index.md +++ b/docs/hardware_ready/_index.md @@ -9,4 +9,5 @@ title: Getting your hardware ready | 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 | [KubeVirt??](virtualisation.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 | | + From 90b1cb33da3f2f5af1fcd7d4acb21e7313415539 Mon Sep 17 00:00:00 2001 From: Alexandra Aldershaab Date: Tue, 8 Jul 2025 14:14:41 +0200 Subject: [PATCH 4/4] remove duplicate blank line --- docs/hardware_ready/_index.md | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/hardware_ready/_index.md b/docs/hardware_ready/_index.md index 0d15d96..8f0ba49 100644 --- a/docs/hardware_ready/_index.md +++ b/docs/hardware_ready/_index.md @@ -10,4 +10,3 @@ title: Getting your hardware ready | 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 | | -