Container environment requirements
Supported CLM cluster environments
A CLM cluster must be deployed in a Nokia provided container environment.
Nokia supports and recommends installing CLM on VMs using VMware ESXi or RHEL KVM, including OpenStack. The guest OS must be a supported RHEL version.
Supported container software versions
The CLM is validated against a container environment that uses the following software versions:
Table 2-1: Supported container software versions
|
Containerization element |
Supported version |
|---|---|
|
Kubernetes core |
v1.29.5 |
|
calico |
v3.27.3 |
|
cni |
v1.3.0 |
|
containerd |
v1.7.16 |
|
etcd |
v3.5.12 |
|
Helm |
v3.14.2 |
|
coredns |
v1.11.1 |
|
kubespray |
2.25.0 |
|
k9s |
v0.32.5 |
|
metallb |
v0.13.9 |
|
harbor app |
v2.11.1 |
|
nerdctl |
v1.7.4 |
KVM virtualization
The CLM supports using RHEL 6, RHEL 7, and RHEL 8 based KVM on x86 based servers natively supported by KVM. See the Host Environment Compatibility Reference for NSP and CLM for the current KVM compatibility level, requirements, and restrictions. See the RHEL Hardware Compatibility List (HCL) for information about specific hardware support.
Not all features offered by KVM are supported when using the CLM. For example Snapshots, Live Migration and HA are not supported. Contact Nokia to determine if a specific KVM feature is supported with an installation of CLM.
KVM CPU and Memory
The required memory resources must be reserved and dedicated to each guest OS, and cannot be shared or oversubscribed. In a medium development type, CPU resources may be oversubscribed with a KVM cpu_allocation_ratio of 1.25.
Note: CPU oversubscription is only supported on CLM clusters with three or more nodes. Smaller CLM deployments must have reserved and dedicated CPU resources for each node.
KVM configuration
When you configure the KVM, set the parameters listed in the following table to the required values.
Table 2-2: KVM configuration parameters
|
Parameter |
Value |
|---|---|
|
Disk Controller type |
virtio |
|
Storage format |
raw |
|
Cache mode |
none |
|
I/O mode |
native |
|
NIC device model |
virtio |
|
Hypervisor type |
kvm |
CPU pinning may be used for CLM virtual machines (deployer and cluster nodes) but may restrict other KVM functions. Please consult KVM documentation for more information.
OpenStack virtualization
The CLM is tested in an open-source OpenStack environment. Nokia supports CLM deployment on VMs provided in any OpenStack distribution that is based on the tested version. Any product issues deemed related to a specific distribution must be pursued by the customer and OpenStack vendor. The supported OpenStack versions include Newton, Queens and Train.
To ensure CLM compatibility with an OpenStack environment, you must follow the requirements in the following topics.
Hypervisor
KVM is the only supported hypervisor for an OpenStack environment. For information about the supported KVM hypervisor versions, see KVM virtualization.
CPU and memory resources
The required memory resources must be reserved and dedicated to each guest OS, and cannot be shared or oversubscribed. You must set the ram_allocation_ratio parameter to 1.0 in the OpenStack Nova configuration on the control NE, or on each individual compute node that may host a CLM VM. CPU resources may be oversubscribed using the guidelines for KVM CPU oversubscription in Table 2-2, KVM configuration parameters.
Simultaneous Multi-threading (SMT)
The usage of CPUs with enabled SMT must be consistent across all compute nodes. If the CPUs do not support SMT, you must disable SMT at the hardware level on each compute node that may host a CLM VM.
CPU pinning
CPU pinning is supported, but may restrict some OpenStack functions such as migration.
Availability zones/affinity/placement
Nokia does not provide recommendations for configuring VM placement in OpenStack.
Migration
The OpenStack environment supports only regular migration; live migration is not supported.
Networking
Basic Neutron functions using Open vSwitch with the ML2 plugin are supported in an NSP deployment, as is the use of OpenStack floating IP addresses.
Storage
All storage must meet the throughput and latency performance criteria in Table 4-1, Live partitioning scheme, CLM deployer host
VM storage
The VM storage must be persistent block (Cinder) storage, and not ephemeral. In order to deploy each VM, you must create a bootable Cinder volume. The volume size is indicated in Table 4-1, Live partitioning scheme, CLM deployer host
Firewalls
You can enable firewalls using OpenStack Security Groups, or on the VMs using the firewalld service, except as noted. If firewalld is enabled, an OpenStack Security Group that allows all incoming and outgoing traffic must be used.
ARP spoofing
OpenStack ARP spoofing protection must be disabled. MetalLB load balancer looks like an ARP spoofing attempt to OpenStack.
VMware virtualization
The CLM supports using VMware vSphere ESXi 6.5, 6.7, 7.0 and 8.0 only, on x86 based servers natively supported by ESXi. See the Host Environment Compatibility Reference for NSP and CLM for the current VMware compatibility level, requirements, and restrictions. See the VMware Hardware Compatibility List (HCL) to determine specific hardware support.
Not all features offered by ESXi are supported when using the CLM. For example, Fault Tolerant, High Availability (HA), Memory Compression, Distributed Resource Scheduler (DRS), and vMotion features are not supported. VM snapshots are not supported when using CLM. Contact Nokia to determine if a specific ESXi feature is supported with a CLM installation.
CPU pinning is supported on CLM virtual machines (deployer and cluster nodes) but may restrict some VMware functions. Please consult VMware documentation for more information.
Note: The system clocks of the CLM must always be closely synchronized. The RHEL chronyd service is the mandatory time-synchronization mechanism that you must engage on CLM during deployment.
Caution: Some entities - members of an etcd cluster, for example - will not trust the integrity of data if a time difference is detected. As such, failure to closely synchronize system clocks can complicate debugging and cause outages or other unexpected behavior.
Only one time-synchronization mechanism can be active in a CLM system. Before you enable a service such as chronyd on CLM , you must ensure that no other time-synchronization mechanism, for example, the VMware Tools synchronization utility, is enabled.
Virtual Machine Version 11 or above must be used.
See the following table for additional Virtual Machine setting requirements:
Table 2-3: Additional Virtual Machine setting requirements
|
Resource type |
Parameter |
Setting |
|---|---|---|
|
CPU |
Shares |
Set to High |
|
Reservation |
See VMWare CPU Reservation below | |
|
Limit |
Check box checked for unlimited | |
|
Memory |
Shares |
Set to High |
|
Reservation |
Reserve all guest memory | |
|
Limit |
Check box checked for unlimited | |
|
Disk |
Shares |
Set to High |
|
Limit - IOPs |
set to Unlimited | |
|
Type |
Thick Provision Eager Zeroed | |
|
SCSI controller |
Type |
VMware Paravirtual |
|
Network Adapter |
Type |
VMXNET 3 |
VMWare CPU Reservation
CPU resources may be oversubscribed when CLM is deployed on VMWare. The CPU Reservation is determined by: factor X * the number of CPUs * the CPU frequency. For example, with a factor of 0.5 on a 2.4 GHz 8 vCPU configuration, the reservation must be set to (0.5 * 8 * 2400) = 9600 MHz. For a medium deployment type, the VMWare factor X is 0.4.
Note: CPU oversubscription is only supported on CLM clusters with three or more nodes. Smaller CLM deployments must have reserved and dedicated CPU resources for each node.