mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
101 lines
5.1 KiB
Plaintext
101 lines
5.1 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * virt/install/virt-specifying-nodes-for-virtualization-components.adoc
|
|
|
|
:_mod-docs-content-type: CONCEPT
|
|
[id="virt-about-node-placement-virtualization-components_{context}"]
|
|
= About node placement for virtualization components
|
|
|
|
[role="_abstract"]
|
|
You can customize where {VirtProductName} deploys its components by applying node placement rules.
|
|
|
|
You might want to customize where {VirtProductName} deploys its components to ensure that:
|
|
|
|
* Virtual machines only deploy on nodes that are intended for virtualization workloads.
|
|
* Operators only deploy on infrastructure nodes.
|
|
* Certain nodes are unaffected by {VirtProductName}. For example, you have workloads unrelated to virtualization running on your cluster, and you want those workloads to be isolated from {VirtProductName}.
|
|
|
|
[id="how-to-apply-node-placement-rules-virt-components"]
|
|
== How to apply node placement rules to virtualization components
|
|
|
|
You can specify node placement rules for a component by editing the corresponding object directly or by using the web console.
|
|
|
|
* For the {VirtProductName} Operators that Operator Lifecycle Manager (OLM) deploys, edit the OLM `Subscription` object directly. Currently, you cannot configure node placement rules for the `Subscription` object by using the web console.
|
|
* For components that the {VirtProductName} Operators deploy, edit the `HyperConverged` object directly or configure it by using the web console during {VirtProductName} installation.
|
|
* For the hostpath provisioner, edit the `HostPathProvisioner` object directly or configure it by using the web console.
|
|
+
|
|
[WARNING]
|
|
====
|
|
You must schedule the hostpath provisioner and the virtualization components on the same nodes. Otherwise, virtualization pods that use the hostpath provisioner cannot run.
|
|
====
|
|
|
|
Depending on the object, you can use one or more of the following rule types:
|
|
|
|
`nodeSelector`:: Allows pods to be scheduled on nodes that are labeled with the key-value pair or pairs that you specify in this field. The node must have labels that exactly match all listed pairs.
|
|
`affinity`:: Enables you to use more expressive syntax to set rules that match nodes with pods. Affinity also allows for more nuance in how the rules are applied. For example, you can specify that a rule is a preference, rather than a hard requirement, so that pods are still scheduled if the rule is not satisfied.
|
|
`tolerations`:: Allows pods to be scheduled on nodes that have matching taints. If a taint is applied to a node, that node only accepts pods that tolerate the taint.
|
|
|
|
[id="node-placement-olm-subscription_{context}"]
|
|
== Node placement in the OLM Subscription object
|
|
|
|
To specify the nodes where OLM deploys the {VirtProductName} Operators, edit the `Subscription` object during {VirtProductName} installation. You can include node placement rules in the `spec.config` field, as shown in the following example:
|
|
|
|
[source,yaml,subs="attributes+"]
|
|
----
|
|
apiVersion: operators.coreos.com/v1alpha1
|
|
kind: Subscription
|
|
metadata:
|
|
name: hco-operatorhub
|
|
namespace: {CNVNamespace}
|
|
spec:
|
|
source: {CNVSubscriptionSpecSource}
|
|
sourceNamespace: openshift-marketplace
|
|
name: {CNVSubscriptionSpecName}
|
|
startingCSV: kubevirt-hyperconverged-operator.v{HCOVersion}
|
|
channel: "stable"
|
|
config: <1>
|
|
----
|
|
<1> The `config` field supports `nodeSelector` and `tolerations`, but it does not support `affinity`.
|
|
|
|
[id="node-placement-hco_{context}"]
|
|
== Node placement in the HyperConverged object
|
|
|
|
To specify the nodes where {VirtProductName} deploys its components, you can include the `nodePlacement` object in the HyperConverged Cluster custom resource (CR) file that you create during {VirtProductName} installation. You can include `nodePlacement` under the `spec.infra` and `spec.workloads` fields, as shown in the following example:
|
|
|
|
[source,yaml,subs="attributes+"]
|
|
----
|
|
apiVersion: hco.kubevirt.io/v1beta1
|
|
kind: HyperConverged
|
|
metadata:
|
|
name: kubevirt-hyperconverged
|
|
namespace: {CNVNamespace}
|
|
spec:
|
|
infra:
|
|
nodePlacement: <1>
|
|
...
|
|
workloads:
|
|
nodePlacement:
|
|
...
|
|
----
|
|
<1> The `nodePlacement` fields support `nodeSelector`, `affinity`, and `tolerations` fields.
|
|
|
|
[id="node-placement-hpp_{context}"]
|
|
== Node placement in the HostPathProvisioner object
|
|
|
|
You can configure node placement rules by specifying `nodeSelector`, `affinity`, or `tolerations` for the `spec.workload` field of the `HostPathProvisioner` object that you create when you install the hostpath provisioner. If after you create the `HostPathProvisioner` you delete the `HostPathProvisioner` pod and then want to delete the virtual machine (VM), you must first update the `spec.workload` field to another value and then wait for the `HostPathProvisioner` pod to restart. You can then delete the VM from the node.
|
|
|
|
[source,yaml]
|
|
----
|
|
apiVersion: hostpathprovisioner.kubevirt.io/v1beta1
|
|
kind: HostPathProvisioner
|
|
metadata:
|
|
name: hostpath-provisioner
|
|
spec:
|
|
imagePullPolicy: IfNotPresent
|
|
pathConfig:
|
|
path: "</path/to/backing/directory>"
|
|
useNamingPrefix: false
|
|
workload: <1>
|
|
----
|
|
<1> The `workload` field supports `nodeSelector`, `affinity`, and `tolerations` fields.
|