diff --git a/static/img/v1.2/networking-hv/config-uplink.png b/static/img/v1.2/networking-hv/config-uplink.png new file mode 100644 index 00000000..4b55e713 Binary files /dev/null and b/static/img/v1.2/networking-hv/config-uplink.png differ diff --git a/static/img/v1.2/networking-hv/create-clusternetwork.png b/static/img/v1.2/networking-hv/create-clusternetwork.png new file mode 100644 index 00000000..885377d2 Binary files /dev/null and b/static/img/v1.2/networking-hv/create-clusternetwork.png differ diff --git a/static/img/v1.2/networking-hv/create-ippool-from-rancher-manager.png b/static/img/v1.2/networking-hv/create-ippool-from-rancher-manager.png new file mode 100644 index 00000000..ad984882 Binary files /dev/null and b/static/img/v1.2/networking-hv/create-ippool-from-rancher-manager.png differ diff --git a/static/img/v1.2/networking-hv/create-lb-01.png b/static/img/v1.2/networking-hv/create-lb-01.png new file mode 100644 index 00000000..b6304792 Binary files /dev/null and b/static/img/v1.2/networking-hv/create-lb-01.png differ diff --git a/static/img/v1.2/networking-hv/create-lb-02.png b/static/img/v1.2/networking-hv/create-lb-02.png new file mode 100644 index 00000000..918213a9 Binary files /dev/null and b/static/img/v1.2/networking-hv/create-lb-02.png differ diff --git a/static/img/v1.2/networking-hv/create-lb-03.png b/static/img/v1.2/networking-hv/create-lb-03.png new file mode 100644 index 00000000..033a9474 Binary files /dev/null and b/static/img/v1.2/networking-hv/create-lb-03.png differ diff --git a/static/img/v1.2/networking-hv/create-lb-04.png b/static/img/v1.2/networking-hv/create-lb-04.png new file mode 100644 index 00000000..1e67ae79 Binary files /dev/null and b/static/img/v1.2/networking-hv/create-lb-04.png differ diff --git a/static/img/v1.2/networking-hv/create-network-auto.png b/static/img/v1.2/networking-hv/create-network-auto.png new file mode 100644 index 00000000..fd933619 Binary files /dev/null and b/static/img/v1.2/networking-hv/create-network-auto.png differ diff --git a/static/img/v1.2/networking-hv/create-network-config-button.png b/static/img/v1.2/networking-hv/create-network-config-button.png new file mode 100644 index 00000000..22e53b4b Binary files /dev/null and b/static/img/v1.2/networking-hv/create-network-config-button.png differ diff --git a/static/img/v1.2/networking-hv/create-network-manual.png b/static/img/v1.2/networking-hv/create-network-manual.png new file mode 100644 index 00000000..83acd9ce Binary files /dev/null and b/static/img/v1.2/networking-hv/create-network-manual.png differ diff --git a/static/img/v1.2/networking-hv/create-untagged-network.png b/static/img/v1.2/networking-hv/create-untagged-network.png new file mode 100644 index 00000000..0b89563e Binary files /dev/null and b/static/img/v1.2/networking-hv/create-untagged-network.png differ diff --git a/static/img/v1.2/networking-hv/create-vlan-network.png b/static/img/v1.2/networking-hv/create-vlan-network.png new file mode 100644 index 00000000..8f19af04 Binary files /dev/null and b/static/img/v1.2/networking-hv/create-vlan-network.png differ diff --git a/static/img/v1.2/networking-hv/create_vm_networks.png b/static/img/v1.2/networking-hv/create_vm_networks.png new file mode 100644 index 00000000..98b16ea8 Binary files /dev/null and b/static/img/v1.2/networking-hv/create_vm_networks.png differ diff --git a/static/img/v1.2/networking-hv/guest-kubernetes-cluster-lb.png b/static/img/v1.2/networking-hv/guest-kubernetes-cluster-lb.png new file mode 100644 index 00000000..43bc16d5 Binary files /dev/null and b/static/img/v1.2/networking-hv/guest-kubernetes-cluster-lb.png differ diff --git a/static/img/v1.2/networking-hv/health-check.png b/static/img/v1.2/networking-hv/health-check.png new file mode 100644 index 00000000..c30ac9a4 Binary files /dev/null and b/static/img/v1.2/networking-hv/health-check.png differ diff --git a/static/img/v1.2/networking-hv/ippool-scope.png b/static/img/v1.2/networking-hv/ippool-scope.png new file mode 100644 index 00000000..2a27bf68 Binary files /dev/null and b/static/img/v1.2/networking-hv/ippool-scope.png differ diff --git a/static/img/v1.2/networking-hv/kubeovn-harvester-topology.svg b/static/img/v1.2/networking-hv/kubeovn-harvester-topology.svg new file mode 100644 index 00000000..134c55dd --- /dev/null +++ b/static/img/v1.2/networking-hv/kubeovn-harvester-topology.svg @@ -0,0 +1,109 @@ + + + + + + + + + + + Hypervisor + Kube-OVN Integration Architecture (Multi-VPC, Text-Based) + + + + + + + + Kube-OVN (SDN Controller / IPAM) + + + + VPC: vpc-1 + + + + vswitch1subnet + + vswitch2subnet + + vswitch3subnet + + + + + VPC: vpc-2 + + + + vswitch4subnet + + vswitch5subnet + + vswitch6subnet + + + + + Hypervisor Overlay + + + + + + HypervisorOverlay vswitch1 + + + HypervisorOverlay vswitch2 + + + HypervisorOverlay vswitch3 + + + HypervisorOverlay vswitch4 + + + HypervisorOverlay vswitch5 + + + HypervisorOverlay vswitch6 + + + + + VM1 vswitch1 + VM1 vswitch2 + VM1 vpcpeer1 + VM2 vswitch3 + VM external + VM2 vpcpeer2 + + + + + + + + + + + + + + + + + + + + VM launched and managed by Hypervisor + NatOutgoing: true + Connected (VPC peering) + diff --git a/static/img/v1.2/networking-hv/kubeovn-hypervisor-topology.svg b/static/img/v1.2/networking-hv/kubeovn-hypervisor-topology.svg new file mode 100644 index 00000000..134c55dd --- /dev/null +++ b/static/img/v1.2/networking-hv/kubeovn-hypervisor-topology.svg @@ -0,0 +1,109 @@ + + + + + + + + + + + Hypervisor + Kube-OVN Integration Architecture (Multi-VPC, Text-Based) + + + + + + + + Kube-OVN (SDN Controller / IPAM) + + + + VPC: vpc-1 + + + + vswitch1subnet + + vswitch2subnet + + vswitch3subnet + + + + + VPC: vpc-2 + + + + vswitch4subnet + + vswitch5subnet + + vswitch6subnet + + + + + Hypervisor Overlay + + + + + + HypervisorOverlay vswitch1 + + + HypervisorOverlay vswitch2 + + + HypervisorOverlay vswitch3 + + + HypervisorOverlay vswitch4 + + + HypervisorOverlay vswitch5 + + + HypervisorOverlay vswitch6 + + + + + VM1 vswitch1 + VM1 vswitch2 + VM1 vpcpeer1 + VM2 vswitch3 + VM external + VM2 vpcpeer2 + + + + + + + + + + + + + + + + + + + + VM launched and managed by Hypervisor + NatOutgoing: true + Connected (VPC peering) + diff --git a/static/img/v1.2/networking-hv/management-network-mtu.png b/static/img/v1.2/networking-hv/management-network-mtu.png new file mode 100644 index 00000000..5f266301 Binary files /dev/null and b/static/img/v1.2/networking-hv/management-network-mtu.png differ diff --git a/static/img/v1.2/networking-hv/management-network.png b/static/img/v1.2/networking-hv/management-network.png new file mode 100644 index 00000000..398c852a Binary files /dev/null and b/static/img/v1.2/networking-hv/management-network.png differ diff --git a/static/img/v1.2/networking-hv/multiple-ranges.png b/static/img/v1.2/networking-hv/multiple-ranges.png new file mode 100644 index 00000000..7106b1e1 Binary files /dev/null and b/static/img/v1.2/networking-hv/multiple-ranges.png differ diff --git a/static/img/v1.2/networking-hv/network-configuration-1.png b/static/img/v1.2/networking-hv/network-configuration-1.png new file mode 100644 index 00000000..13b20c71 Binary files /dev/null and b/static/img/v1.2/networking-hv/network-configuration-1.png differ diff --git a/static/img/v1.2/networking-hv/network-configuration-2.png b/static/img/v1.2/networking-hv/network-configuration-2.png new file mode 100644 index 00000000..0c6df380 Binary files /dev/null and b/static/img/v1.2/networking-hv/network-configuration-2.png differ diff --git a/static/img/v1.2/networking-hv/network-configuration-3.png b/static/img/v1.2/networking-hv/network-configuration-3.png new file mode 100644 index 00000000..25ff0a83 Binary files /dev/null and b/static/img/v1.2/networking-hv/network-configuration-3.png differ diff --git a/static/img/v1.2/networking-hv/relation.png b/static/img/v1.2/networking-hv/relation.png new file mode 100644 index 00000000..2d542e6c Binary files /dev/null and b/static/img/v1.2/networking-hv/relation.png differ diff --git a/static/img/v1.2/networking-hv/select-node.png b/static/img/v1.2/networking-hv/select-node.png new file mode 100644 index 00000000..9a00caf8 Binary files /dev/null and b/static/img/v1.2/networking-hv/select-node.png differ diff --git a/static/img/v1.2/networking-hv/select-nodes.png b/static/img/v1.2/networking-hv/select-nodes.png new file mode 100644 index 00000000..89d78d42 Binary files /dev/null and b/static/img/v1.2/networking-hv/select-nodes.png differ diff --git a/static/img/v1.2/networking-hv/set-a-new-mtu-value.svg b/static/img/v1.2/networking-hv/set-a-new-mtu-value.svg new file mode 100644 index 00000000..efe243e4 --- /dev/null +++ b/static/img/v1.2/networking-hv/set-a-new-mtu-value.svg @@ -0,0 +1,65 @@ + + + + + In this example, applying a new MTU value 9000 needs to touch: + (1) All the related ports in the external Switch/Router + (2) All the related uplinks of Hypervisor nodes which join this clusternetwork cn-data + + + + + + + Network Configuration: 1 + Uplink + linkAttributes + Mtu:1500 + (selects node1) + + + + Network Configuration: 2 + Uplink + linkAttributes + Mtu:1500 + (selects node2) + + + Hypervisor ClusterNetwork: cn-data + + + + external Switch1 + + + external Switch2 + + + + external Router1 + + + + + + + + + mtu:1500 + mtu:1500 + mtu:1500 + port mtu:1500 + mtu:1500 + mtu:1500 + mtu:1500 + mtu:1500 + diff --git a/static/img/v1.2/networking-hv/topology.png b/static/img/v1.2/networking-hv/topology.png new file mode 100644 index 00000000..4d124cf9 Binary files /dev/null and b/static/img/v1.2/networking-hv/topology.png differ diff --git a/static/img/v1.2/networking-hv/traffic-isolation.png b/static/img/v1.2/networking-hv/traffic-isolation.png new file mode 100644 index 00000000..e2eb9d64 Binary files /dev/null and b/static/img/v1.2/networking-hv/traffic-isolation.png differ diff --git a/versioned_docs/version-v1.6/networking/best-practice.md b/versioned_docs/version-v1.6/networking/best-practice.md index 538f2acf..f8ffa5d5 100644 --- a/versioned_docs/version-v1.6/networking/best-practice.md +++ b/versioned_docs/version-v1.6/networking/best-practice.md @@ -1,9 +1,9 @@ --- sidebar_position: 6 -sidebar_label: Harvester Network Best Practice -title: "Harvester Network Best Practice" +sidebar_label: Hypervisor Network Best Practice +title: "Hypervisor Network Best Practice" keywords: -- Harvester +- Hypervisor - Networking - Best Practice --- @@ -14,7 +14,7 @@ keywords: ## Replace Ethernet NICs -You may want to replace the Ethernet NICs of a bare-metal node in a Harvester cluster for various reasons, including the following: +You may want to replace the Ethernet NICs of a bare-metal node in a Hypervisor cluster for various reasons, including the following: - Malfunction or damage @@ -26,21 +26,21 @@ You can follow the steps below and run them in each node step by step. ### Pre-Replacement Checks -1. Verify that the installed Harvester version supports the new NICs. +1. Verify that the installed Hypervisor version supports the new NICs. 1. Test the new NICs in non-production environment. -1. On the [**Virtual Machines** screen of the Harvester UI](../vm/access-to-the-vm.md#access-with-the-harvester-ui), verify that the status of all VMs is either *Running* or *Stopped*. +1. On the [**Virtual Machines** screen of the Hypervisor UI](../vm/access-to-the-vm.md#access-with-the-harvester-ui), verify that the status of all VMs is either *Running* or *Stopped*. 1. On the [embedded Longhorn dashboard](../troubleshooting/harvester.md#access-embedded-rancher-and-longhorn-dashboards), verify that the status of all Longhorn volumes is *Healthy*. -1. (Optional) On the **Harvester Support** screen, generate a [support bundle](../troubleshooting/harvester.md#generate-a-support-bundle) for comparison purposes. +1. (Optional) On the **Hypervisor Support** screen, generate a [support bundle](../troubleshooting/harvester.md#generate-a-support-bundle) for comparison purposes. ### Collect Information Before any action is taken, it is important to collect the current network information and status. -- Harvester network configuration: By default, Harvester creates a bond interface named `mgmt-bo` for the management network and one new bond interface for each cluster network. Harvester saves network configuration details in the file `/oem/90_custom.yaml`. +- Hypervisor network configuration: By default, Hypervisor creates a bond interface named `mgmt-bo` for the management network and one new bond interface for each cluster network. Hypervisor saves network configuration details in the file `/oem/90_custom.yaml`. Example: A NIC named `ens3` was added to the `mgmt-bo` bond interface. @@ -113,7 +113,7 @@ Before any action is taken, it is important to collect the current network infor - Linux kernel log: You can use the command `dmesg` to display kernel messages, which include most of the required information. If you save the messages to `kernel.log`, you can check the driver and link status. - Harvester places sub-NICs into the bond interfaces. In the following example, an additional bond interface named `data-bo` is created in the cluster. + Hypervisor places sub-NICs into the bond interfaces. In the following example, an additional bond interface named `data-bo` is created in the cluster. ``` $ grep "(slave" kernel.log (or: dmesg | grep "(slave") @@ -121,7 +121,7 @@ Before any action is taken, it is important to collect the current network infor Jan 08 00:35:00 localhost kernel: mgmt-bo: (slave eno5): Enslaving as a backup interface with an up link Jan 08 00:35:00 localhost kernel: mgmt-bo: (slave ens4f0): Enslaving as a backup interface with an up link Jan 08 00:37:34 localhost kernel: data-bo: (slave eno6): Enslaving as a backup interface with an up link - Jan 08 00:37:35 localhost kernel: data-bo: (slave ens4f1): Enslaving as a backup interface with an up link + Jan 08 00:37:35 localhost kernel: data-bo: (slave ens4f1): Enslaving as a backup interface with anypervisor ``` The NICs are renamed. @@ -179,7 +179,7 @@ Before any action is taken, it is important to collect the current network infor ### (Optional) Update the Network Config -There are one or more [Network Config](./clusternetwork.md#create-a-new-cluster-network) under every [Cluster Network](./clusternetwork.md#cluster-network) on Harvester. Each `Network Config` is backed by a `VlanConfig` CRD object. +There are one or more [Network Config](./clusternetwork.md#create-a-new-cluster-network) under every [Cluster Network](./clusternetwork.md#cluster-network) on Hypervisor. Each `Network Config` is backed by a `VlanConfig` CRD object. :::info important @@ -189,7 +189,7 @@ Updating the `Network Config` is **required** if the new NICs will be placed in 1. Check the node. - When a Harvester cluster node belongs to a `Network Config`, the `Node` object has a label with the key `network.harvesterhci.io/vlanconfig`. + When a Hypervisor cluster node belongs to a `Network Config`, the `Node` object has a label with the key `network.harvesterhci.io/vlanconfig`. Example: @@ -262,13 +262,13 @@ Updating the `Network Config` is **required** if the new NICs will be placed in You may find that some Longhorn replicas remain active on the node even after completing the previously outlined procedures. -1. Drain the node. (This is optional in Harvester.) +1. Drain the node. (This is optional in Hypervisor.) - Scenario 1: The `numReplicas` value of all volumes is `3`, which means that each Longhorn volume has three active replicas. The Longhorn Engine recognizes that it can no longer communicate with the replica on the drained node, and then marks that replica as failed. None of the replicas hold any special significance to Longhorn so it functions as long as it can communicate with at least one replica. - - Scenario 2: Some Longhorn volumes have *fewer* than three active replicas, or you manually attached volumes using the Harvester UI or Longhorn UI. + - Scenario 2: Some Longhorn volumes have *fewer* than three active replicas, or you manually attached volumes using the Hypervisor UI or Longhorn UI. You must manually detach the replicas or move them to other nodes, and then [drain the node](https://longhorn.io/docs/1.4.3/volumes-and-nodes/maintenance/#updating-the-node-os-or-container-runtime) using the command `kubectl drain --ignore-daemonsets `. The option `--ignore-daemonsets` is required because Longhorn deploys daemonsets such as Longhorn Manager, Longhorn CSI plugin, and Longhorn Engine image. @@ -280,7 +280,7 @@ You may find that some Longhorn replicas remain active on the node even after co During system maintenance, you can modify the [`replica-replenishment-wait-interval`](https://longhorn.io/docs/1.4.3/references/settings/#replica-replenishment-wait-interval) value using the [embedded Longhorn UI](../troubleshooting/harvester.md#access-embedded-rancher-and-longhorn-dashboards) to enable faster replica rebuilding. - Harvester v1.3.0 uses Longhorn v1.6.0, while Harvester v1.2.1 uses Longhorn v1.4.3. + Hypervisor v1.3.0 uses Longhorn v1.6.0, while Hypervisor v1.2.1 uses Longhorn v1.4.3. ### Replace the Nics @@ -326,7 +326,7 @@ Updating the `Network Config` is **required** if the new NICs will be placed in ### Troubleshooting -Harvester uses multiple network-related pods and CRDs. When troubleshooting, check the pod logs and the status of CRD objects. +Hypervisor uses multiple network-related pods and CRDs. When troubleshooting, check the pod logs and the status of CRD objects. Pods: diff --git a/versioned_docs/version-v1.6/networking/clusternetwork.md b/versioned_docs/version-v1.6/networking/clusternetwork.md index d995d3b0..f5886f42 100644 --- a/versioned_docs/version-v1.6/networking/clusternetwork.md +++ b/versioned_docs/version-v1.6/networking/clusternetwork.md @@ -4,7 +4,7 @@ sidebar_position: 1 sidebar_label: Cluster Network title: "Cluster Network" keywords: -- Harvester +- Hypervisor - Networking - ClusterNetwork - NetworkConfig @@ -20,19 +20,19 @@ keywords: ### Cluster Network _Available as of v1.1.0_ -In Harvester v1.1.0, we introduced a new concept called cluster network for traffic isolation. +In Hypervisor v1.1.0, we introduced a new concept called cluster network for traffic isolation. The following diagram describes a typical network architecture that separates data-center (DC) traffic from out-of-band (OOB) traffic. -![](/img/v1.2/networking/traffic-isolation.png) +![](/img/v1.2/networking-hv/traffic-isolation.png) -We abstract the sum of devices, links, and configurations on a traffic-isolated forwarding path on Harvester as a cluster network. +We abstract the sum of devices, links, and configurations on a traffic-isolated forwarding path on Hypervisor as a cluster network. In the above case, there will be two cluster networks corresponding to two traffic-isolated forwarding paths. ### Network Configuration -Specifications including network devices of the Harvester hosts can be different. To be compatible with such a heterogeneous cluster, we designed the network configuration. +Specifications including network devices of the Hypervisor hosts can be different. To be compatible with such a heterogeneous cluster, we designed the network configuration. Network configuration only works under a certain cluster network. Each network configuration corresponds to a set of hosts with uniform network specifications. Therefore, multiple network configurations are required for a cluster network on non-uniform hosts. @@ -40,14 +40,14 @@ Network configuration only works under a certain cluster network. Each network c A VM network is an interface in a virtual machine that connects to the host network. As with a network configuration, every network except the built-in [management network](./harvester-network.md#management-network) must be under a cluster network. -Harvester supports adding multiple networks to one VM. If a network's cluster network is not enabled on some hosts, the VM that owns this network will not be scheduled to those hosts. +Hypervisor supports adding multiple networks to one VM. If a network's cluster network is not enabled on some hosts, the VM that owns this network will not be scheduled to those hosts. Please refer to [network part](./harvester-network.md) for more details about networks. ### Relationship Between Cluster Network, Network Config, VM Network The following diagram shows the relationship between a cluster network, a network config, and a VM network. -![](/img/v1.2/networking/relation.png) +![](/img/v1.2/networking-hv/relation.png) All `Network Configs` and `VM Networks` are grouped under a cluster network. @@ -70,19 +70,19 @@ Overall, this diagram provides a clear visualization of the relationship between ## Cluster Network Details -Cluster networks are traffic-isolated forwarding paths for transmission of network traffic within a Harvester cluster. +Cluster networks are traffic-isolated forwarding paths for transmission of network traffic within a Hypervisor cluster. -A cluster network called `mgmt` is automatically created when a Harvester cluster is deployed. You can also create custom cluster networks that can be dedicated to virtual machine traffic. +A cluster network called `mgmt` is automatically created when a Hypervisor cluster is deployed. You can also create custom cluster networks that can be dedicated to virtual machine traffic. ### Built-in Cluster Network -When a Harvester cluster is deployed, a cluster network named `mgmt` is automatically created for intra-cluster communications. `mgmt` consists of the same bridge, bond, and NICs as the external infrastructure network to which each Harvester host attaches with management NICs. Because of this design, `mgmt` also allows virtual machines to be accessed from the external infrastructure network for cluster management purposes. +When a Hypervisor cluster is deployed, a cluster network named `mgmt` is automatically created for intra-cluster communications. `mgmt` consists of the same bridge, bond, and NICs as the external infrastructure network to which each Hypervisor host attaches with management NICs. Because of this design, `mgmt` also allows virtual machines to be accessed from the external infrastructure network for cluster management purposes. `mgmt` does not require a network configuration and is always enabled on all hosts. You cannot disable and delete `mgmt`. :::note -In Harvester v1.5.x and earlier versions, the entire VLAN ID range (2 to 4094) was assigned to the `mgmt` interfaces. However, this exceeded the upper limit of supported VLANs on certain network cards, so hardware VLAN offloading stopped working correctly. +In Hypervisor v1.5.x and earlier versions, the entire VLAN ID range (2 to 4094) was assigned to the `mgmt` interfaces. However, this exceeded the upper limit of supported VLANs on certain network cards, so hardware VLAN offloading stopped working correctly. For more information, see [issue #7650](https://github.com/harvester/harvester/issues/7650). @@ -94,9 +94,9 @@ During installation of the first cluster node, you can configure the MTU value f :::caution -- Certain [ARP settings](https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt) can break cluster communications. With `arp_ignore=2`, for example, replies are sent only if the sender IP address is in the same subnet as the target IP address for which the MAC address is requested. This is not the case in a Harvester cluster, so using `arp_ignore=2` on all interfaces results in failed connectivity checks and prevents Longhorn pods (specifically, `backing-image` and `instance-manager`) from transitioning to the `Ready` state. Volumes cannot be attached to virtual machines if these Longhorn pods are not ready. +- Certain [ARP settings](https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt) can break cluster communications. With `arp_ignore=2`, for example, replies are sent only if the sender IP address is in the same subnet as the target IP address for which the MAC address is requested. This is not the case in a Hypervisor cluster, so using `arp_ignore=2` on all interfaces results in failed connectivity checks and prevents Longhorn pods (specifically, `backing-image` and `instance-manager`) from transitioning to the `Ready` state. Volumes cannot be attached to virtual machines if these Longhorn pods are not ready. -- All nodes in a Harvester cluster must use the same MTU value. Because Harvester does not automatically detect discrepancies when nodes join, you must manually ensure that the values are identical to prevent unexpected system behavior. +- All nodes in a Hypervisor cluster must use the same MTU value. Because Hypervisor does not automatically detect discrepancies when nodes join, you must manually ensure that the values are identical to prevent unexpected system behavior. ::: @@ -248,11 +248,11 @@ To simplify cluster maintenance, create one network configuration for each node 1. Specify a name for the cluster network. - ![](/img/v1.2/networking/create-clusternetwork.png) + ![](/img/v1.2/networking-hv/create-clusternetwork.png) 1. On the **ClusterNetworks/Configs** screen, click the **Create Network Config** button of the cluster network you created. - ![](/img/v1.2/networking/create-network-config-button.png) + ![](/img/v1.2/networking-hv/create-network-config-button.png) 1. On the **Network Config:Create** screen, specify a name for the configuration. @@ -271,15 +271,15 @@ To simplify cluster maintenance, create one network configuration for each node - **NICs**: The list contains NICs that are common to all selected nodes. NICs that cannot be selected are unavailable on one or more nodes and must be configured. Once troubleshooting is completed, refresh the screen and verify that the NICs can be selected. - **Bond Options**: The default bonding mode is **active-backup**. - - **Attributes**: You must use the same MTU across all network configurations of a custom cluster network. If you do not specify an MTU, the default value **1500** is used. The Harvester webhook rejects a new network configuration if its MTU does not match the MTU of existing network configurations. + - **Attributes**: You must use the same MTU across all network configurations of a custom cluster network. If you do not specify an MTU, the default value **1500** is used. The Hypervisor webhook rejects a new network configuration if its MTU does not match the MTU of existing network configurations. - ![](/img/v1.2/networking/config-uplink.png) + ![](/img/v1.2/networking-hv/config-uplink.png) 1. Click **Save**. ### Change a Network Configuration -Changes to existing network configurations may affect Harvester virtual machines and workloads, and external devices such as switches and routers. For more information, see [Network Topology](./deep-dive.md#network-topology). +Changes to existing network configurations may affect Hypervisor virtual machines and workloads, and external devices such as switches and routers. For more information, see [Network Topology](./deep-dive.md#network-topology). :::info important @@ -293,17 +293,17 @@ You must stop all affected virtual machines before changing a network configurat In the following example, the cluster network is `cn-data` and the network configuration is `nc-1`. - ![](/img/v1.4/networking/network-configuration-1.png) + ![](/img/v1.2/networking-hv/network-configuration-1.png) 1. Select **⋮ > Edit Config**, and then change the relevant fields. - **Node Selector** tab: - ![](/img/v1.4/networking/network-configuration-2.png) + ![](/img/v1.2/networking-hv/network-configuration-2.png) - **Uplink** tab: - ![](/img/v1.4/networking/network-configuration-3.png) + ![](/img/v1.2/networking-hv/network-configuration-3.png) :::info important @@ -315,7 +315,7 @@ You must stop all affected virtual machines before changing a network configurat The following sections outline the steps you must perform to change the MTU of a network configuration. The sample cluster network used in these sections has `cn-data` that was built with a MTU value `1500` and is intended to be changed with value `9000`. -![](/img/v1.4/networking/set-a-new-mtu-value.png) +![](/img/v1.2/networking-hv/set-a-new-mtu-value.svg) #### Change the MTU of a Network Configuration with No Attached Storage Network @@ -323,7 +323,7 @@ In this scenario, the [storage network](../advanced/storagenetwork.md#storage-ne :::caution -- The MTU affects Harvester nodes and networking devices such as switches and routers. Careful planning and testing are required to ensure that changing the MTU does not adversely affect the system. For more information, see [Network Topology](./deep-dive.md#network-topology). +- The MTU affects Hypervisor nodes and networking devices such as switches and routers. Careful planning and testing are required to ensure that changing the MTU does not adversely affect the system. For more information, see [Network Topology](./deep-dive.md#network-topology). - You must use the same MTU across all network configurations of a custom cluster network. - Cluster operations are interrupted during the configuration change. - The information in this section does not apply to the built-in `mgmt` cluster network. @@ -334,7 +334,7 @@ If you must change the MTU, perform the following steps: 1. Stop all virtual machines that are attached to the target cluster network. - You can check this using the [VM network](./harvester-network.md#create-a-vm-network) and any [secondary networks](../vm/create-vm.md#secondary-network) you may have used. Harvester does not allow you to change the MTU when any of the connected virtual machines are still running. + You can check this using the [VM network](./harvester-network.md#create-a-vm-network) and any [secondary networks](../vm/create-vm.md#secondary-network) you may have used. Hypervisor does not allow you to change the MTU when any of the connected virtual machines are still running. 1. Check the network configurations of the target cluster network. @@ -348,12 +348,12 @@ If you must change the MTU, perform the following steps: ::: -1. Verify that the MTU was changed using the Linux `ip link` command. If the network configuration selects multiple Harvester nodes, run the command on each node. +1. Verify that the MTU was changed using the Linux `ip link` command. If the network configuration selects multiple Hypervisor nodes, run the command on each node. The output must show the new MTU of the related `*-br` device and the state `UP`. In the following example, the device is `cn-data-br` and the new MTU is `9000`. ``` - Harvester node $ ip link show dev cn-data-br + Hypervisor node $ ip link show dev cn-data-br |new MTU| |state UP| 3: cn-data-br: mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000 @@ -362,11 +362,11 @@ If you must change the MTU, perform the following steps: :::note - When the state is `UNKNOWN`, it is likely that the MTU values on Harvester and the external switch or router do not match. + When the state is `UNKNOWN`, it is likely that the MTU values on Hypervisor and the external switch or router do not match. ::: -1. Test the new MTU on Harvester nodes using commands such as `ping`. You must send the messages to a Harvester node with the new MTU or a node with an external IP. +1. Test the new MTU on Hypervisor nodes using commands such as `ping`. You must send the messages to a Hypervisor node with the new MTU or a node with an external IP. In the following example, the network is `cn-data`, the CIDR is `192.168.100.0/24`, and the gateway is `192.168.100.1`. @@ -418,7 +418,7 @@ If you must change the MTU, perform the following steps: :::info important - You must change the MTU in each one, and verify that the new MTU was applied. The Harvester webhook rejects a new network configuration if its MTU does not match the MTU of existing network configurations. + You must change the MTU in each one, and verify that the new MTU was applied. The Hypervisor webhook rejects a new network configuration if its MTU does not match the MTU of existing network configurations. ::: @@ -459,7 +459,7 @@ If you must change the MTU, perform the following steps: :::info important -Harvester cannot be held responsible for any damage or loss of data that may occur when the MTU value is changed. +Hypervisor cannot be held responsible for any damage or loss of data that may occur when the MTU value is changed. ::: @@ -467,11 +467,11 @@ Harvester cannot be held responsible for any damage or loss of data that may occ In this scenario, the [storage network](../advanced/storagenetwork.md#storage-network-setting) is enabled and attached to the target cluster network. -The storage network is used by `driver.longhorn.io`, which is Harvester's default CSI driver. Longhorn is responsible for provisioning [root volumes](../vm/create-vm.md#volumes), so changing the MTU affects all virtual machines. +The storage network is used by `driver.longhorn.io`, which is Hypervisor's default CSI driver. Longhorn is responsible for provisioning [root volumes](../vm/create-vm.md#volumes), so changing the MTU affects all virtual machines. :::caution -- The MTU affects Harvester nodes and networking devices such as switches and routers. Careful planning and testing are required to ensure that changing the MTU does not adversely affect the system. For more information, see [Network Topology](./deep-dive.md#network-topology). +- The MTU affects Hypervisor nodes and networking devices such as switches and routers. Careful planning and testing are required to ensure that changing the MTU does not adversely affect the system. For more information, see [Network Topology](./deep-dive.md#network-topology). - You must use the same MTU across all network configurations of a custom cluster network. - All cluster operations are interrupted during the configuration change. - The information in this section does not apply to the built-in `mgmt` cluster network. @@ -500,12 +500,12 @@ If you must change the MTU, perform the following steps: 1. Verify that the MTU was changed using the Linux `ip link` command. - If the network configuration selects multiple Harvester nodes, run the command on each node. + If the network configuration selects multiple Hypervisor nodes, run the command on each node. The output must show the new MTU of the related `*-br` device and the state `UP`. In the following example, the device is `cn-data-br` and the new MTU is `9000`. ``` - Harvester node $ ip link show dev cn-data-br + Hypervisor node $ ip link show dev cn-data-br |new MTU| |state UP| 3: cn-data-br: mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000 @@ -514,11 +514,11 @@ If you must change the MTU, perform the following steps: :::note - When the state is `UNKNOWN`, it is likely that the MTU values on Harvester and the external switch or router do not match. + When the state is `UNKNOWN`, it is likely that the MTU values on Hypervisor and the external switch or router do not match. ::: -1. Test the new MTU on Harvester nodes using commands such as `ping`. You must send the messages to a Harvester node with the new MTU or to a node with an external IP. +1. Test the new MTU on Hypervisor nodes using commands such as `ping`. You must send the messages to a Hypervisor node with the new MTU or to a node with an external IP. In the following example, the network is `cn-data`, the CIDR is `192.168.100.0/24`, and the gateway is `192.168.100.1`. @@ -570,11 +570,11 @@ If you must change the MTU, perform the following steps: :::info important - You must change the MTU in each one, and verify that the new MTU was applied. The Harvester webhook rejects a new network configuration if its MTU does not match the MTU of existing network configurations. + You must change the MTU in each one, and verify that the new MTU was applied. The Hypervisor webhook rejects a new network configuration if its MTU does not match the MTU of existing network configurations. ::: -1. Enable and configure the Harvester [storage network setting](../advanced/storagenetwork.md#enable-the-storage-network), ensuring that the [prerequisites](../advanced/storagenetwork.md#prerequisites) are met. +1. Enable and configure the Hypervisor [storage network setting](../advanced/storagenetwork.md#enable-the-storage-network), ensuring that the [prerequisites](../advanced/storagenetwork.md#prerequisites) are met. 1. Allow some time for the setting to be enabled, and then [verify that the change was applied](../advanced/storagenetwork.md#post-configuration-steps). The `storagenetwork` runs with the new MTU value. @@ -615,6 +615,6 @@ If you must change the MTU, perform the following steps: :::info important -Harvester cannot be held responsible for any damage or loss of data that may occur when the MTU value is changed. +Hypervisor cannot be held responsible for any damage or loss of data that may occur when the MTU value is changed. ::: diff --git a/versioned_docs/version-v1.6/networking/deep-dive.md b/versioned_docs/version-v1.6/networking/deep-dive.md index 705c98a8..b28acb8e 100644 --- a/versioned_docs/version-v1.6/networking/deep-dive.md +++ b/versioned_docs/version-v1.6/networking/deep-dive.md @@ -1,9 +1,9 @@ --- sidebar_position: 3 -sidebar_label: Harvester Network Deep Dive -title: "Harvester Network Deep Dive" +sidebar_label: Hypervisor Network Deep Dive +title: "Hypervisor Network Deep Dive" keywords: -- Harvester +- Hypervisor - Networking - Topology --- @@ -14,19 +14,19 @@ keywords: ## Network Topology -The network topology below reveals how we implement the Harvester network. +The network topology below reveals how we implement the Hypervisor network. -![](/img/v1.2/networking/topology.png) +![](/img/v1.2/networking-hv/topology.png) The diagram contains [the built-in cluster network mgmt](./clusternetwork.md#built-in-cluster-network) and a [custom cluster network](./clusternetwork.md#custom-cluster-network) called `oob`. -As shown above, the Harvester network primarily focuses on OSI model layer 2. We leverage Linux network devices and protocols to construct traffic paths for the communication between VM to VM, VM to host, and VM to external network devices. +As shown above, the Hypervisor network primarily focuses on OSI model layer 2. We leverage Linux network devices and protocols to construct traffic paths for the communication between VM to VM, VM to host, and VM to external network devices. -The Harvester network is composed of three layers, including: +The Hypervisor network is composed of three layers, including: - KubeVirt networking layer -- Harvester networking layer +- Hypervisor networking layer - External networking layer @@ -35,9 +35,9 @@ The Harvester network is composed of three layers, including: The general purpose of KubeVirt is to run VM inside the Kubernetes pod. The KubeVirt network builds the network path between the pod and VM. Please refer to the [KubeVirt official document](https://kubevirt.io/2018/KubeVirt-Network-Deep-Dive.html) for more details. -## Harvester Networking +## Hypervisor Networking -Harvester networking is designed to build the network path between pods and the host network. It implements a management network, VLAN networks and untagged networks. We can refer to the last two networks as **bridge networks**, because bridge plays a vital role in their implementation. +Hypervisor networking is designed to build the network path between pods and the host network. It implements a management network, VLAN networks and untagged networks. We can refer to the last two networks as **bridge networks**, because bridge plays a vital role in their implementation. ### Bridge Network @@ -89,7 +89,7 @@ We leverage [multus CNI](https://github.com/k8snetworkplumbingwg/multus-cni) and The management network is based on [Canal](https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel). -It is worth mentioning that the Canal interface where the Harvester configures the node IP is the bridge `mgmt-br` or a VLAN sub-interface of `mgmt-br`. This design has two benefits: +It is worth mentioning that the Canal interface where the Hypervisor configures the node IP is the bridge `mgmt-br` or a VLAN sub-interface of `mgmt-br`. This design has two benefits: - The built-in `mgmt` cluster network supports both the management network and bridge network. - With the VLAN network interface, we can assign a VLAN ID to the management network. diff --git a/versioned_docs/version-v1.6/networking/harvester-network.md b/versioned_docs/version-v1.6/networking/harvester-network.md index 61cfa49c..f1fb30a0 100644 --- a/versioned_docs/version-v1.6/networking/harvester-network.md +++ b/versioned_docs/version-v1.6/networking/harvester-network.md @@ -3,7 +3,7 @@ sidebar_position: 2 sidebar_label: VM Network title: "VM Network" keywords: -- Harvester +- Hypervisor - Network --- @@ -11,7 +11,7 @@ keywords: -Harvester provides three types of networks for virtual machines (VMs), including: +Hypervisor provides three types of networks for virtual machines (VMs), including: - Management Network - VLAN Network @@ -21,12 +21,12 @@ The management network is usually used for VMs whose traffic only flows inside t _Available as of v1.0.1_ -Harvester also introduced storage networking to separate the storage traffic from other cluster-wide workloads. Please refer to [the storage network document](../advanced/storagenetwork.md) for more details. +Hypervisor also introduced storage networking to separate the storage traffic from other cluster-wide workloads. Please refer to [the storage network document](../advanced/storagenetwork.md) for more details. ## Management Network -Harvester uses [Canal](https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel) as its default management network. It is a built-in network that can be used directly from the cluster. +Hypervisor uses [Canal](https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel) as its default management network. It is a built-in network that can be used directly from the cluster. By default, the management network IP of a VM can only be accessed within the cluster nodes, and the management network IP will change after the VM reboot. This is non-typical behaviour that needs to be taken note of since VM IPs are expected to remain unchanged after a reboot. @@ -36,13 +36,13 @@ However, you can leverage the Kubernetes [service object](https://kubevirt.io/us Since the management network is built-in and doesn't require extra operations, you can add it directly when configuring the VM network. -![](/img/v1.2/networking/management-network.png) +![](/img/v1.2/networking-hv/management-network.png) :::info important -`mgmt` uses the default MTU value `1500` if you do not specify a value other than `0` or `1500` in the [`install.management_interface`](../install/harvester-configuration.md#installmanagement_interface) setting during installation. However, the network interfaces of virtual machines connected to `mgmt` have an MTU value of [`1450`](https://docs.tigera.io/calico/latest/networking/configuring/mtu#determine-mtu-size). This is because Harvester uses the **Calico and Flannel CNI**, which has an overhead of 50 bytes per packet, to carry the in-cluster overlay network. +`mgmt` uses the default MTU value `1500` if you do not specify a value other than `0` or `1500` in the [`install.management_interface`](../install/harvester-configuration.md#installmanagement_interface) setting during installation. However, the network interfaces of virtual machines connected to `mgmt` have an MTU value of [`1450`](https://docs.tigera.io/calico/latest/networking/configuring/mtu#determine-mtu-size). This is because Hypervisor uses the **Calico and Flannel CNI**, which has an overhead of 50 bytes per packet, to carry the in-cluster overlay network. -![](/img/v1.3/networking/management-network-mtu.png) +![](/img/v1.2/networking-hv/management-network-mtu.png) If any of your workloads involve transmission of network traffic, you must specify the appropriate MTU value for the affected VM network interfaces and bridges. @@ -50,7 +50,7 @@ If any of your workloads involve transmission of network traffic, you must speci ## VLAN Network -The [Harvester network-controller](https://github.com/harvester/harvester-network-controller) leverages the [multus](https://github.com/k8snetworkplumbingwg/multus-cni) and [bridge](https://www.cni.dev/plugins/current/main/bridge/) CNI plugins to implement its customized L2 bridge VLAN network. It helps to connect your VMs to the host network interface and can be accessed from internal and external networks using the physical switch. +The [Hypervisor network-controller](https://github.com/harvester/harvester-network-controller) leverages the [multus](https://github.com/k8snetworkplumbingwg/multus-cni) and [bridge](https://www.cni.dev/plugins/current/main/bridge/) CNI plugins to implement its customized L2 bridge VLAN network. It helps to connect your VMs to the host network interface and can be accessed from internal and external networks using the physical switch. ### Create a VM Network @@ -70,7 +70,7 @@ The [Harvester network-controller](https://github.com/harvester/harvester-networ - Vlan ID - Cluster Network - ![](/img/v1.2/networking/create-vlan-network.png) +![](/img/v1.2/networking-hv/create-vlan-network.png) :::note @@ -78,22 +78,22 @@ The [Harvester network-controller](https://github.com/harvester/harvester-networ When you change the MTU on the physical NICs of cluster network uplink, the newly created virtual machine networks automatically inherit the new MTU. The existing virtual machine networks are also updated automatically. For more information, see [Change the MTU of a Network Configuration with an Attached Storage Network](./clusternetwork.md#change-the-mtu-of-a-network-configuration-with-an-attached-storage-network) and [Change the MTU of a Network Configuration with No Attached Storage Network](./clusternetwork.md#change-the-mtu-of-a-network-configuration-with-no-attached-storage-network). - The Harvester webhook does not allow you to directly change the MTU on VM networks. + The Hypervisor webhook does not allow you to directly change the MTU on VM networks. ::: 1. On the Route tab, select an option and then specify the related IPv4 addresses. - - Auto(DHCP): The Harvester network controller retrieves the CIDR and gateway addresses from the DHCP server. You can specify the DHCP server address. + - Auto(DHCP): The Hypervisor network controller retrieves the CIDR and gateway addresses from the DHCP server. You can specify the DHCP server address. - ![](/img/v1.2/networking/create-network-auto.png) +![](/img/v1.2/networking-hv/create-network-auto.png) - Manual: Specify the CIDR and gateway addresses. - ![](/img/v1.2/networking/create-network-manual.png) +![](/img/v1.2/networking-hv/create-network-manual.png) :::info important - Harvester uses the information to verify that all nodes can access the VM network you are creating. If that is the case, the *Network connectivity* column on the **VM Networks** screen indicates that the network is active. Otherwise, the screen indicates that an error has occurred. + Hypervisor uses the information to verify that all nodes can access the VM network you are creating. If that is the case, the *Network connectivity* column on the **VM Networks** screen indicates that the network is active. Otherwise, the screen indicates that an error has occurred. ::: ### Create a VM with VLAN Network @@ -112,11 +112,11 @@ The usage of untagged network is similar to [the VLAN network](#vlan-network). To create a new untagged network, go to the **Networks > VM Networks** page and click the **Create** button. You have to specify the name, select the type `Untagged Network` and choose the cluster network. -![](/img/v1.2/networking/create-untagged-network.png) +![](/img/v1.2/networking-hv/create-untagged-network.png) :::note -Starting from Harvester v1.1.2, Harvester supports updating and deleting VM networks. Make sure to stop all affected VMs before updating or deleting VM networks. +Starting from Hypervisor v1.1.2, Hypervisor supports updating and deleting VM networks. Make sure to stop all affected VMs before updating or deleting VM networks. ::: @@ -124,17 +124,17 @@ Starting from Harvester v1.1.2, Harvester supports updating and deleting VM netw _Available as of v1.6.0_ -The [Harvester network-controller](https://github.com/harvester/harvester-network-controller) leverages [Kube-OVN](https://github.com/kubeovn/kube-ovn) to create an OVN-based virtualized network that supports advanced SDN capabilities such as [virtual private clouds (VPCs) and subnets](./kubeovn-vpc.md) for virtual machine workloads. +The [Hypervisor network-controller](https://github.com/harvester/harvester-network-controller) leverages [Kube-OVN](https://github.com/kubeovn/kube-ovn) to create an OVN-based virtualized network that supports advanced SDN capabilities such as [virtual private clouds (VPCs) and subnets](./kubeovn-vpc.md) for virtual machine workloads. An overlay network represents a virtual layer 2 switch that encapsulates and forwards traffic between virtual machines. This network can be linked to the subnet created in the VPC so that virtual machines can access the internal virtualized network and also reach the external network. However, the same virtual machines cannot be accessed by external networks such as VLANs and untagged networks because of current VPC limitations. -![](/img/kubeovn-harvester-topology.png) +![](/img/v1.2/networking-hv/kubeovn-harvester-topology.svg) ### Create an Overlay Network 1. Go to **Networks > Virtual Machine Networks**, and then click **Create**. - ![](/img/create_vm_networks.png) +![](/img/v1.2/networking-hv/create_vm_networks.png) 1. On the **Virtual Machine Network:Create** screen, specify a name for the network. @@ -144,7 +144,7 @@ An overlay network represents a virtual layer 2 switch that encapsulates and for ### Limitations -The overlay network implementation in Harvester v1.6 has the following limitations: +The overlay network implementation in Hypervisor v1.6 has the following limitations: - Overlay networks that are backed by Kube-OVN can only be created on `mgmt` (the built-in management network). @@ -174,15 +174,15 @@ The overlay network implementation in Harvester v1.6 has the following limitatio - Peering only works between custom VPCs. Attempts to establish a peering connection between the default VPC and a custom VPC will fail. -- Virtual machine load balancers, which are provided by the Harvester Load Balancer, are not compatible with Kube-OVN overlay networks. You can only use these load balancers with VLAN networks. +- Virtual machine load balancers, which are provided by the Hypervisor Load Balancer, are not compatible with Kube-OVN overlay networks. You can only use these load balancers with VLAN networks. -- Cluster load balancers, which are provided by the Harvester Cloud Provider and the Harvester Load Balancer, do not function properly with guest clusters on Kube-OVN overlay networks. The compatibility issues are caused by the following: +- Cluster load balancers, which are provided by the Hypervisor Cloud Provider and the Hypervisor Load Balancer, do not function properly with guest clusters on Kube-OVN overlay networks. The compatibility issues are caused by the following: - - `Pool` IPAM: Kube-OVN is unaware that the load balancer's front-end IP addresses are allocated from pools managed by the Harvester Load Balancer. This can lead to IP address conflicts. + - `Pool` IPAM: Kube-OVN is unaware that the load balancer's front-end IP addresses are allocated from pools managed by the Hypervisor Load Balancer. This can lead to IP address conflicts. - `DHCP` IPAM: Dynamic IP address allocation does not work even when the DHCP service is enabled for the Kube-OVN subnet. The lease record is managed on the control plane by Kube-OVN. Integration enhancements are required to allow the affected components to function properly together. -- Rancher integration (specifically, downstream cluster creation using the Harvester Node Driver) only works on Kube-OVN overlay networks within the default VPC. To ensure successful cluster creation, you must perform the following actions: +- Rancher integration (specifically, downstream cluster creation using the Hypervisor Node Driver) only works on Kube-OVN overlay networks within the default VPC. To ensure successful cluster creation, you must perform the following actions: - Enable the DHCP service for the overlay network. You must set a valid default gateway. diff --git a/versioned_docs/version-v1.6/networking/ippool.md b/versioned_docs/version-v1.6/networking/ippool.md index d06af703..2afc5737 100644 --- a/versioned_docs/version-v1.6/networking/ippool.md +++ b/versioned_docs/version-v1.6/networking/ippool.md @@ -12,7 +12,7 @@ keywords: _Available as of v1.2.0_ -Harvester IP Pool is a built-in IP address management (IPAM) solution exclusively available to Harvester load balancers (LBs). +Hypervisor IP Pool is a built-in IP address management (IPAM) solution exclusively available to Hypervisor load balancers (LBs). ## Features - **Multiple IP ranges:** Each IP pool can contain multiple IP ranges or CIDRs. @@ -30,17 +30,17 @@ To create a new IP pool: 1. Go to the **Networks** > **IP Pools** page and select **Create**. 1. Specify the **Name** of the IP pool. 1. Go to the **Range** tab to specify the **IP ranges** for the IP pool. You can add multiple IP ranges. - ![](/img/v1.2/networking/multiple-ranges.png) +![](/img/v1.2/networking-hv/multiple-ranges.png) 1. Go to the **Selector** tab to specify the **Scope** and **Priority** of the IP pool. - ![](/img/v1.2/networking/ippool-scope.png) +![](/img/v1.2/networking-hv/ippool-scope.png) -When you operate from the Harvester UI, the `Scope` only includes `Namespace`. Click `Add Scope` to add new items. +When you operate from the Hypervisor UI, the `Scope` only includes `Namespace`. Click `Add Scope` to add new items. ### Create IP Pool from Rancher Manager UI -If the Harvester cluster is imported to `Rancher Manager` from `Rancher Manager UI > Virtualization Management`, the `Network` tab in the IP Pools section looks different. +If the Hypervisor cluster is imported to `Rancher Manager` from `Rancher Manager UI > Virtualization Management`, the `Network` tab in the IP Pools section looks different. -![](/img/v1.6/networking/create-ippool-from-rancher-manager.png) +![](/img/v1.2/networking-hv/create-ippool-from-rancher-manager.png) The `Scope` includes `Project`, `Namespace` and `Guest Kubernetes Cluster`. For more information, see [Multi-Tenancy Example](../rancher/virtualization-management.md#multi-tenancy-example) and [Projects and Kubernetes Namespaces with Rancher](https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/manage-clusters/projects-and-namespaces#about-projects). @@ -139,7 +139,7 @@ Each IP pool will have a specific range, and you can specify the corresponding r ### IPPool for VM type Loadbalancer -1. It is better to [Create IP Pool from Harvester UI directly](#how-to-create), which leaves the seletor scope `Project` and `Guest Kubernetes Cluster` blank. +1. It is better to [Create IP Pool from Hypervisor UI directly](#how-to-create), which leaves the seletor scope `Project` and `Guest Kubernetes Cluster` blank. 1. If you can only [Create IP Pool from Rancher Managery UI](#create-ip-pool-from-rancher-manager-ui), set the scope `Project` and `Guest Kubernetes Cluster` to be `All` or `None`. diff --git a/versioned_docs/version-v1.6/networking/kubeovn-vm-isolation.md b/versioned_docs/version-v1.6/networking/kubeovn-vm-isolation.md index e6058de9..c3b2222a 100644 --- a/versioned_docs/version-v1.6/networking/kubeovn-vm-isolation.md +++ b/versioned_docs/version-v1.6/networking/kubeovn-vm-isolation.md @@ -3,7 +3,7 @@ sidebar_position: 8 sidebar_label: Kube-OVN Virtual Machine Isolation title: "Kube-OVN Virtual Machine Isolation" keywords: -- Harvester +- Hypervisor - networking - Kube-OVN - access control list diff --git a/versioned_docs/version-v1.6/networking/kubeovn-vpc.md b/versioned_docs/version-v1.6/networking/kubeovn-vpc.md index b0d23cf6..2d085c2f 100644 --- a/versioned_docs/version-v1.6/networking/kubeovn-vpc.md +++ b/versioned_docs/version-v1.6/networking/kubeovn-vpc.md @@ -3,13 +3,14 @@ sidebar_position: 7 sidebar_label: Virtual Private Cloud (VPC) title: "Virtual Private Cloud (VPC)" keywords: -- Harvester +- Hypervisor - networking - Kube-OVN - overlay network - subnet - virtual private cloud - VPC +draft: true --- @@ -30,9 +31,9 @@ The following table outlines the key components of a VPC: | security group | Virtual firewall that controls inbound and outbound traffic per instance | | VPC peering | Optional peering or hybrid connections between different VPCs or on-premises networks | -## Harvester + Kube-OVN Integration Architecture +## Hypervisor + Kube-OVN Integration Architecture -The following diagram illustrates how VPCs, subnets, overlay networks, and virtual machines are logically connected in Harvester with Kube-OVN. This architecture includes public and private subnets, allowing separation of internet-facing traffic from internal resources. Moreover, this architecture enables scalable, isolated L3 and L2 network structures across the cluster. +The following diagram illustrates how VPCs, subnets, overlay networks, and virtual machines are logically connected in Hypervisor with Kube-OVN. This architecture includes public and private subnets, allowing separation of internet-facing traffic from internal resources. Moreover, this architecture enables scalable, isolated L3 and L2 network structures across the cluster. ``` [ VPC: vpc-1 ] @@ -56,8 +57,8 @@ IP: 172.20.10.X IP: 172.20.10.Y IP: 172.20.20.Z | --- | --- | --- | | [VPC](#vpc-settings) | Kube-OVN | Top-level L3 domain, manages subnet groupings | | [subnet](#subnet-settings) | Kube-OVN | CIDR assignment, routing, gateway, firewall rules | -| [overlay network](./harvester-network.md#overlay-network-experimental) | Harvester | L2 virtual switch (OVS bridge), mapped to subnet | -| virtual machine | Harvester | Runs compute workloads, connected to overlay network | +| [overlay network](./harvester-network.md#overlay-network-experimental) | Hypervisor | L2 virtual switch (OVS bridge), mapped to subnet | +| virtual machine | Hypervisor | Runs compute workloads, connected to overlay network | This architecture has the following key characteristics: @@ -65,22 +66,22 @@ This architecture has the following key characteristics: Each subnet includes a CIDR and gateway IP, and binds to an overlay network (as provider). Kube-OVN enforces a one-to-one mapping between the subnet and the overlay network to avoid ambiguous routing, traffic collisions, and isolation issues. -- Harvester defines the overlay networks (type: `OverlayNetwork`). +- Hypervisor defines the overlay networks (type: `OverlayNetwork`). - Each overlay network is considered a provider in Kube-OVN. When you create a subnet on the Harvester UI, you can select these overlay networks in the **Provider** list on the **Subnet:Create** screen. + Each overlay network is considered a provider in Kube-OVN. When you create a subnet on the Hypervisor UI, you can select these overlay networks in the **Provider** list on the **Subnet:Create** screen. -- Harvester provisions virtual machines that are connected to an overlay network. +- Hypervisor provisions virtual machines that are connected to an overlay network. Each virtual machine uses the Kube-OVN IPAM to request an IP address after booting. The virtual machine receives its IP address, gateway, and routing information from the associated subnet. - Kube-OVN handles all L3 logic (routing, NAT, VPC peering, and isolation). - Harvester focuses purely on compute and network attachment. Network policy enforcement, private subnets, and NAT egress are managed by Kube-OVN. + Hypervisor focuses purely on compute and network attachment. Network policy enforcement, private subnets, and NAT egress are managed by Kube-OVN. This architecture has the following benefits: -- Clear separation of concerns: Harvester handles virtualization; Kube-OVN handles SDN -- Scalability: New VPCs, subnets, and peering don’t require changes in Harvester core +- Clear separation of concerns: Hypervisor handles virtualization; Kube-OVN handles SDN +- Scalability: New VPCs, subnets, and peering don’t require changes in Hypervisor core - Kubernetes-native networking: Kube-OVN integrates tightly with Kubernetes, supporting CRDs, policies, etc. - Isolation and observability: Centralized control over IPs, ACLs, and routing through Kube-OVN @@ -88,9 +89,9 @@ This architecture has the following benefits: ### VPC Settings -In Harvester, a virtual private cloud (VPC) is a logical network container that helps manage and isolate subnets and traffic. It defines routing, NAT, and network segmentation. +In Hypervisor, a virtual private cloud (VPC) is a logical network container that helps manage and isolate subnets and traffic. It defines routing, NAT, and network segmentation. -Harvester provides a default VPC named `ovn-cluster`, and two associated subnets named `ovn-default` and `join` for internal Kube-OVN operations. You can create additional VPCs by clicking **Create** on the **Virtual Private Cloud** screen. +Hypervisor provides a default VPC named `ovn-cluster`, and two associated subnets named `ovn-default` and `join` for internal Kube-OVN operations. You can create additional VPCs by clicking **Create** on the **Virtual Private Cloud** screen. ![](/img/default_vpc_and_subnet.png) @@ -109,7 +110,7 @@ When creating custom VPCs, you must configure settings related to the routes def ### Subnet Settings -Each subnet defines a CIDR block and gateway, and is mapped to a Harvester [overlay network](./harvester-network.md#overlay-network-experimental) (virtual switch). It also includes controls for NAT and [access rules](./kubeovn-vm-isolation.md#subnet-acls). +Each subnet defines a CIDR block and gateway, and is mapped to a Hypervisor [overlay network](./harvester-network.md#overlay-network-experimental) (virtual switch). It also includes controls for NAT and [access rules](./kubeovn-vm-isolation.md#subnet-acls). When creating subnets, you must configure settings that are relevant to your use case. In most cases, you can get started by just configuring the **CIDR Block**, **Gateway**, and **Provider**. The following table outlines the settings on the **Subnet** details screen: @@ -148,7 +149,7 @@ Perform the following steps to create and configure a VPC. 1. Enable [kubeovn-operator](../advanced/addons/kubeovn-operator.md). - The kubeovn-operator add-on deploys Kube-OVN to the Harvester cluster. + The kubeovn-operator add-on deploys Kube-OVN to the Hypervisor cluster. ![](/img/kubeovn-operator.png) @@ -174,7 +175,7 @@ Perform the following steps to create and configure a VPC. :::note - You must link each subnet to a dedicated overlay network. In the **Provider** field, the Harvester UI only shows overlay networks that are not linked to other subnets, automatically enforcing the one-to-one mapping. + You must link each subnet to a dedicated overlay network. In the **Provider** field, the Hypervisor UI only shows overlay networks that are not linked to other subnets, automatically enforcing the one-to-one mapping. ::: @@ -385,7 +386,7 @@ The `natOutgoing` setting enables network address translation (NAT) for traffic VPC peering is a networking connection that enables virtual machines in different VPCs to communicate using *private IP addresses*. -Each VPC is a separate network namespace with its own CIDR block, routing table, and isolation boundary. Without VPC peering, virtual machines are isolated even when they are hosted within the same Harvester cluster. Once a peering connection is established, routing rules are automatically updated to allow virtual machines to communicate privately. +Each VPC is a separate network namespace with its own CIDR block, routing table, and isolation boundary. Without VPC peering, virtual machines are isolated even when they are hosted within the same Hypervisor cluster. Once a peering connection is established, routing rules are automatically updated to allow virtual machines to communicate privately. VPC peering offers the following key benefits: @@ -395,7 +396,7 @@ VPC peering offers the following key benefits: - Keeping traffic within the internal cloud network not only improves performance but also lowers costs, providing a significant advantage over using the public internet or VPNs. -The following diagram shows how VPCs and subnets in Kube-OVN map to overlay networks and virtual machines in Harvester. This architecture enables you to create scalable and isolated L3 and L2 network structures across the cluster. +The following diagram shows how VPCs and subnets in Kube-OVN map to overlay networks and virtual machines in Hypervisor. This architecture enables you to create scalable and isolated L3 and L2 network structures across the cluster. ``` @@ -419,7 +420,7 @@ The following diagram shows how VPCs and subnets in Kube-OVN map to overlay netw │ (1:1 mapping - Provider binding) │ │ ▼ ▼ ▼ ┌──────────────────────────────┐ ┌──────────────────────────────┐ ┌──────────────────────────────┐ -│ Harvester Overlay: vswitch1 │ │ Harvester Overlay: vswitch3 │ │ Harvester Overlay: vswitch4 │ +│ Hypervisor Overlay: vswitch1 │ │ Hypervisor Overlay: vswitch3 │ │ Hypervisor Overlay: vswitch4 │ │ Type: OverlayNetwork │ │ Type: OverlayNetwork │ │ Type: OverlayNetwork │ └──────────────────────────────┘ └──────────────────────────────┘ └──────────────────────────────┘ │ │ │ @@ -430,7 +431,7 @@ The following diagram shows how VPCs and subnets in Kube-OVN map to overlay netw └──────────────────────┘ └──────────────────────┘ vswitch (overlay) └──────────────────────┘ ▲ │ -VM launched and managed by Harvester +VM launched and managed by Hypervisor ``` @@ -476,7 +477,7 @@ For more information about VPC peering prerequisites and configuration, see [VPC 1. Create two VPCs named `vpcpeer-1` and `vpcpeer-2`. - Harvester creates two isolated network spaces that are ready for subnet creation. + Hypervisor creates two isolated network spaces that are ready for subnet creation. 1. Create one subnet in each VPC with the following settings: diff --git a/versioned_docs/version-v1.6/networking/loadbalancer.md b/versioned_docs/version-v1.6/networking/loadbalancer.md index 4e8a2d65..89226266 100644 --- a/versioned_docs/version-v1.6/networking/loadbalancer.md +++ b/versioned_docs/version-v1.6/networking/loadbalancer.md @@ -12,12 +12,12 @@ keywords: _Available as of v1.2.0_ -The Harvester load balancer (LB) is a built-in Layer 4 load balancer that distributes incoming traffic across workloads deployed on Harvester virtual machines (VMs) or guest Kubernetes clusters. +The Hypervisor load balancer (LB) is a built-in Layer 4 load balancer that distributes incoming traffic across workloads deployed on Hypervisor virtual machines (VMs) or guest Kubernetes clusters. ## VM load balancer ### Features -Harvester VM load balancer supports the following features: +Hypervisor VM load balancer supports the following features: - **Address assignment:** Get the LB IP address from a DHCP server or a pre-defined IP pool. - **Protocol support:** Supports both TCP and UDP protocols for load balancing. @@ -26,37 +26,37 @@ Harvester VM load balancer supports the following features: - **Health check:** Only send traffic to healthy backend instances. ### Limitations -Harvester VM load balancer has the following limitations: +Hypervisor VM load balancer has the following limitations: - **Namespace restriction:** This restriction facilitates permission management and ensures the LB only uses VMs in the same namespace as the backend servers. - **IPv4-only:** The LB is only compatible with IPv4 addresses for VMs. - **Guest agent installation:** Installing the guest agent on each backend VM is required to obtain IP addresses. -- **Connectivity Requirement:** Network connectivity must be established between backend VMs and Harvester hosts. When a VM has multiple IP addresses, the LB will select the first one as the backend address. -- **Access Restriction:** The VM LB address is exposed only within the same network as the Harvester hosts. To access the LB from outside the network, you must provide a route from outside to the LB address. +- **Connectivity Requirement:** Network connectivity must be established between backend VMs and Hypervisor hosts. When a VM has multiple IP addresses, the LB will select the first one as the backend address. +- **Access Restriction:** The VM LB address is exposed only within the same network as the Hypervisor hosts. To access the LB from outside the network, you must provide a route from outside to the LB address. :::note -Harvester VM load balancer doesn't support Windows VMs because the guest agent is not available for Windows VMs. +Hypervisor VM load balancer doesn't support Windows VMs because the guest agent is not available for Windows VMs. ::: ### How to create -To create a new Harvester VM load balancer: +To create a new Hypervisor VM load balancer: 1. Go to the **Networks > Load Balancers** page and select **Create**. 1. Select the **Namespace** and specify the **Name**. 1. Go to the **Basic** tab to choose the IPAM mode, which can be **DHCP** or **IP Pool**. If you select **IP Pool**, prepare an IP pool first, specify the IP pool name, or choose **auto**. If you choose **auto**, the LB automatically selects an IP pool according to [the IP pool selection policy](/networking/ippool.md/#selection-policy). - ![](/img/v1.2/networking/create-lb-01.png) +![](/img/v1.2/networking-hv/create-lb-01.png) 1. Go to the **Listeners** tab to add listeners. You must specify the **Port**, **Protocol**, and **Backend Port** for each listener. - ![](/img/v1.2/networking/create-lb-02.png) +![](/img/v1.2/networking-hv/create-lb-02.png) 1. Go to the **Backend Server Selector** tab to add label selectors. To add the VM to the LB, go to the **Virtual Machine > Instance Labels** tab to add the corresponding labels to the VM. - ![](/img/v1.2/networking/create-lb-03.png) +![](/img/v1.2/networking-hv/create-lb-03.png) 1. Go to the **Health Check** tab to enable health check and specify the parameters, including the **Port**, **Success Threshold**, **Failure Threshold**, **Interval**, and **Timeout** if the backend service supports health check. Refer to [Health Checks](#health-checks) for more details. - ![](/img/v1.2/networking/create-lb-04.png) +![](/img/v1.2/networking-hv/create-lb-04.png) ### Health Checks -The Harvester load balancer supports TCP health checks. You can specify the parameters in the Harvester UI if you've enabled the `Health Check` option. +The Hypervisor load balancer supports TCP health checks. You can specify the parameters in the Hypervisor UI if you've enabled the `Health Check` option. -![](/img/v1.2/networking/health-check.png) +![](/img/v1.2/networking-hv/health-check.png) | Name | Value Type | Required | Default | Description | |:-------------------------------|:-----------|:---|:--------|:---| @@ -67,8 +67,8 @@ The Harvester load balancer supports TCP health checks. You can specify the para | Health Check Timeout | int | false | 3 | Specifies the timeout of every health check in seconds. Disabled by default. ## Guest Kubernetes cluster load balancer -In conjunction with Harvester Cloud Provider, the Harvester load balancer provides load balancing for LB services in the guest cluster. - ![](/img/v1.2/networking/guest-kubernetes-cluster-lb.png) -When you create, update, or delete an LB service on a guest cluster with Harvester Cloud Provider, the Harvester Cloud Provider will create a Harvester LB automatically. +In conjunction with Hypervisor Cloud Provider, the Hypervisor load balancer provides load balancing for LB services in the guest cluster. + ![](/img/v1.2/networking-hv/guest-kubernetes-cluster-lb.png) +When you create, update, or delete an LB service on a guest cluster with Hypervisor Cloud Provider, the Hypervisor Cloud Provider will create a Hypervisor LB automatically. -For more details, refer to [Harvester Cloud Provider](/rancher/cloud-provider.md). +For more details, refer to [Hypervisor Cloud Provider](/rancher/cloud-provider.md).