Skip to content
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.

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

added kb for recommendation on deployment of additional workloads on … #45

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
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
22 changes: 22 additions & 0 deletions kb/2023-10-10/deploy-additional-workload-on-harvester-host.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
---
title: Additional workload deployment on Harvester host cluster
description: Recommendation on the deployment of additional workloads on the Harvester cluster
slug: additional_workload_deployment_on_harvester
authors:
- name: Devendra Kulkarni
title: Technical Support Engineer
url: https://github.com/devenkulkarni
image_url: https://github.com/devenkulkarni.png
tags: [harvester, workloads, host, cluster, resources, WebUI]
hide_table_of_contents: false
---

While it is technically possible to deploy additional workloads on the Harvester host cluster, running other workloads or microservices in the same Kubernetes cluster where Harvester is deployed is not officially supported yet.

Moreover, the deployment of other microservices or workloads may invite the following risks:
1. They might not be well integrated and tested on Harvester. Additionally, users need to deploy and troubleshoot them on their own.
2. Potential conflict with existing features of Harvester. For instance, high system resource consumption can cause downtime.
3. No WebUI support, all operations can only be achieved via kubectl or other CLI tools.
4. During system upgrades, they would not be covered. For example, if your workload depends on the Kubernetes version, a Harvester upgrade could require a newer version of Kubernetes, which may break your custom workload.

Hence, the best practice is to deploy Harvester separately without any additional workloads. Although, we have an experimental feature allowing you to deploy additional workload on Harvester host cluster (bare metal) in Harvester v1.2.0 and for more information on it, please review the [blog](https://www.suse.com/c/rancher_blog/harvester-v1-2-0-release/) and our official documentation [Harvester baremetal container workload support](https://docs.harvesterhci.io/v1.2/rancher/index/#harvester-baremetal-container-workload-support-experimental).
Comment on lines +14 to +22
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
While it is technically possible to deploy additional workloads on the Harvester host cluster, running other workloads or microservices in the same Kubernetes cluster where Harvester is deployed is not officially supported yet.
Moreover, the deployment of other microservices or workloads may invite the following risks:
1. They might not be well integrated and tested on Harvester. Additionally, users need to deploy and troubleshoot them on their own.
2. Potential conflict with existing features of Harvester. For instance, high system resource consumption can cause downtime.
3. No WebUI support, all operations can only be achieved via kubectl or other CLI tools.
4. During system upgrades, they would not be covered. For example, if your workload depends on the Kubernetes version, a Harvester upgrade could require a newer version of Kubernetes, which may break your custom workload.
Hence, the best practice is to deploy Harvester separately without any additional workloads. Although, we have an experimental feature allowing you to deploy additional workload on Harvester host cluster (bare metal) in Harvester v1.2.0 and for more information on it, please review the [blog](https://www.suse.com/c/rancher_blog/harvester-v1-2-0-release/) and our official documentation [Harvester baremetal container workload support](https://docs.harvesterhci.io/v1.2/rancher/index/#harvester-baremetal-container-workload-support-experimental).
While it is technically possible to deploy additional workloads on a Harvester host cluster, running other workloads or microservices in the same Kubernetes cluster where you deploy Harvester is not officially supported.
Moreover, the deployment of other microservices or workloads may invite the following risks:
- Your workloads might not be well integrated and tested on Harvester, and you would need to deploy and troubleshoot them on your own.
- Potential conflict with existing features of Harvester. For instance, high system resource consumption can cause downtime.
- No Harvester WebUI support. You can only perform all of the operations via kubectl or other CLI tools.
- During system upgrades, covering your workload may not be possible. For example, if your workload depends on a specific version of Kubernetes, a Harvester upgrade could require a newer version of Kubernetes, which may break your custom workload.
The best practice is to deploy Harvester separately without any additional workloads. However, Harvester v1.2.0 introduces an experimental feature allowing you to deploy additional workloads on a Harvester host cluster (bare metal). For more information, please review the [Announcing the Harvester v1.2.0 Release](https://www.suse.com/c/rancher_blog/harvester-v1-2-0-release/#:~:text=BareMetal%20Cloud%20Native%20Workload%20Support%20(Experimental)) blog and our official documentation [Harvester baremetal container workload support (experimental)](https://docs.harvesterhci.io/v1.2/rancher/index/#harvester-baremetal-container-workload-support-experimental).