Preparing a K3s environment for Workbench
Determining the resource requirements for a Kubernetes cluster depends on a number of different factors, including what type of applications you will be running, the number of users that are active at once, and the workloads you will be managing within the cluster. Data Science & AI Workbench’s performance is tightly coupled with the health of your Kubernetes stack, so it is important to allocate enough resources to manage your users’ workloads. Generally speaking, your system should contain at least 1 CPU, 1GB of RAM, and 5GB of disk space for each project session or deployment.
Hardware requirements
Anaconda’s hardware recommendations ensure a reliable and performant Kubernetes cluster.
The following are minimum specifications for the control plane and worker nodes, as well as the entire cluster.
Control plane node | Minimum |
---|---|
CPU | 16 cores |
RAM | 64GB |
Disk space in /opt/anaconda | 500GB |
Disk space in /var/lib/rancher | 300GB |
Disk space in /tmp or $TMPDIR | 50GB |
- Disk space reserved for
/var/lib/rancher
is utilized as additional space to accommodate upgrades. Anaconda recommends having this available during installation. - The
/var/lib/rancher
volume must be mounted on local storage. Core components of Kubernetes run from this directory, some of which are extremely intolerant of disk latency. Therefore, Network-Attached Storage (NAS) and Storage Area Network (SAN) solutions are not supported for this volume. - Anaconda recommends that you set up the
/opt/anaconda
and/var/lib/rancher
partitions using Logical Volume Management (LVM) to provide the flexibility needed to accommodate future expansion. - Disk space reserved for
/opt/anaconda
is utilized for project and package storage (including mirrored packages).
Worker node | Minimum |
---|---|
CPU | 16 cores |
RAM | 64GB |
Disk space in /var/lib/rancher | 300GB |
Disk space in /tmp or $TMPDIR | 50GB |
Multi-node synchronization
When installing Workbench on a system with multiple nodes, verify that the clock of each node is in sync with the others prior to installation. Anaconda recommends using the Network Time Protocol (NTP) to synchronize computer system clocks automatically over a network. For step-by-step instructions, see How to Synchronize Time with Chrony NTP in Linux.
Disk IOPS requirements
Nodes require a minimum of 3000 concurrent Input/Output operations Per Second (IOPS).
Solid state disks are strongly recommended for optimal performance.
Cloud performance requirements
Requirements for running Workbench in the cloud relate to compute power and disk performance.
Minimum specifications:
- CPU: 8 vCPU
- Memory: 32GB RAM
Recommended specifications:
- CPU: 16 vCPU
- Memory: 64GB RAM
Operating system requirements
Please see the official K3s documentation for information on supported operating systems.
You must remove Docker or Podman from the server, if present.
Security requirements
-
If your Linux system utilizes an antivirus scanner, ensure that the scanner excludes the
/var/lib/rancher
volume from its security scans. -
Installation requires that you have
sudo
access. -
RHEL instances must disable
nm-cloud-setup
. -
Nodes running CentOS or RHEL must ensure that Security Enhanced Linux (SELinux) is set to either
disabled
orpermissive
mode in the/etc/selinux/config
file.Check the status of SELinux by running the following command:
Network requirements
Please see the official K3s documentation regarding network requirements.
Firewall Requirements
It is recommended to remove OS-level firewalls altogether. If that is not possible, review the K3s requirements on how to configure the firewall for your OS.
TLS/SSL certificate requirements
Workbench uses certificates to provide transport layer security for the cluster. Self-signed certificates are generated during the initial installation. Once installation is complete, you can configure the platform to use your organizational TLS/SSL certificates.
You can purchase certificates commercially or generate them using your organization’s internal public key infrastructure (PKI) system. When using an internal PKI-signed setup, the CA certificate is inserted into the Kubernetes secret.
In either case, the configuration will include the following:
- A certificate for the root certificate authority (CA)
- An intermediate certificate chain
- A server certificate
- A certificate private key
For more information about TLS/SSL certificates, see Updating TLS/SSL certificates.
DNS requirements
Workbench assigns unique URL addresses to deployments by combining a dynamically generated universally unique identifier (UUID) with your organization’s domain name, like this: https://uuid001.anaconda.yourdomain.com
.
This requires the use of wildcard DNS entries that apply to a set of domain names such as *.anaconda.yourdomain.com
.
For example, if you are using the domain name anaconda.yourdomain.com
with a control plane node IP address of 12.34.56.78
, the DNS entries would be as follows:
The wildcard subdomain’s DNS entry points to the Workbench control plane node.
The control plane node’s hostname and the wildcard domains must be resolvable with DNS from the control plane node, worker nodes, and the end user’s machines. To ensure the control plane node can resolve its own hostname, distribute any /etc/hosts
entries to the K3s environment.
If dnsmasq
is installed on the control plane node or any worker nodes, you’ll need to remove it from all nodes prior to installing Workbench.
Verify dnsmasq
is disabled by running the following command:
If necessary, stop and disable dnsmasq
by running the following commands:
Helm chart
Helm is a tool used by Workbench to streamline the creation, packaging, configuration, and deployment of the application’s configurations. It combines all of the config map objects into a single reusable package called a Helm chart. This chart contains all the necessary resources to deploy the application within your cluster. These resources include .yaml
configuration files, services, secrets, and config maps.
For K3s, Workbench includes a values.k3s.yaml
file that overrides the default values in the top-level Helm chart. Make additions and modifications to this file with your current cluster configurations at this time.
These default configurations are meant for a single-tenant cluster. If you are utilizing a multi-tenant cluster, modify the rbac
parameters where present to scope to the namespace
only.
Pre-installation checklist
Anaconda has created this pre-installation checklist to help you verify that you have properly prepared your environment prior to installation.
Was this page helpful?