System Requirements for an Existing Cluster Install
Here are the system requirements for installing Turbine on an existing Kubernetes cluster:
- A Kubernetes 1.27.x, 1.28.x, 1.29.x, 1.30.x, 1.31.x or 1.32.x compliant cluster.
- A persistent and reliable StorageClass to use for the MongoDB and RabbitMQ pods persistent volumes.
- The required filesystem for the MongoDB StorageClass is XFS.
- 3+ node cluster for production environments to provide redundancy and high availability (HA).
- Ensure all nodes are in the same cloud provider region or physical data center network. Nodes behind different WAN links in the same cluster are not supported.
- CPU architecture must be compatible with MongoDB, unless an external Mongo solution is used.
- See the MongoDB Platform Support Matrix for more information.
- Production environments should have snapshots set up and stored externally from the cluster to ensure that they can be retrieved in the event of a total cluster loss.
- See Backup and Restore on an Existing Cluster with SnapshotsBackup and Restore on an Existing Cluster with Snapshots for more information on how to set up snapshots and compatible providers.
- A load balancer or ingress controller to load balance to the Turbine platform UI.
- Must be configured for TLS communication to the backend.
- If your load balancer or ingress controller requires explicit trust with the certificate presented by the backend service then you must upload a trusted certificate for the Swimlame Web backend.
- The Turbine platform UI must be accessed externally via port 443. Accessing Turbine over any other port is not supported.
- Must support websockets.
- Velero 1.9.0 installed in the cluster to handle backup and restores with snapshots.
- See Backup and Restore on an Existing Cluster with SnapshotsBackup and Restore on an Existing Cluster with Snapshots for instructions to install Velero into your cluster.
Limitations
- Changing annotations, labels, resources, node selector, tolerations, or affinity settings for the Turbine Platform Installer pods is not currently supported. These settings can, however, be set for the Turbine platform pods on the config page.
- The StorageClass for the Turbine Platform Installer pods is required to be default and cannot currently be changed.
- Multiple TPI installs into the same cluster is not currently supported.
Optional: Swimlane does not provide native, application-level encryption for data at rest. Instead it is recommended using disk-level encryption to secure stored data. Most cloud providers and Kubernetes service providers offer options to create encrypted disks or storage classes. For on-premise environments, disk encryption can be configured using standard tools such as dm-crypt.
Note that the configuration and management of disk encryption technologies (for example, dm-crypt) are outside the scope of Swimlane documentation and support.
Backup Requirements
Taking a snapshot requires enough free disk space for a compressed archive of the Swimlane database to be saved in ephemeral storage before it is uploaded to the snapshot destination. Free disk space on the cluster at /var/lib/kubelet should be greater than or equal to the size of the uncompressed database to ensure there is no disk pressure during the snapshot process.
Additional Offline Install Requirements
In addition to the requirements above, installs into an offline (airgapped) Kubernetes cluster have the following additional requirements:
- A private docker image registry accessible by the Kubernetes cluster and jumpbox is required for installation and ongoing operation.
- The registry needs to be trusted by your Kubernetes cluster in order to be be able to pull images. See the Kubernetes documentation for more information.
- A jumpbox that has access to the internet, access to the airgapped kubernetes cluster, and a browser from which you can access the Turbine Platform Installer.
Critical Prerequisites for Airgapped Network Installations
For access to these optional services, ensure you have these things within the airgapped network:
- LDAP login functionality requires an LDAP server inside of the airgapped subnet, or access to outside subnets or the IP or Domain where the LDAP server resides. In order to open these ports, non-secure LDAP uses port 389, but LDAPS (Secure LDAP) uses port 636 and is preferred.
- SSO login functionality requires the service to be able to reach inside the airgapped network (where the Turbine instance resides).
- Email functionality requires the Turbine instance to use a functioning mail proxy that resides within the airgapped subnet, access to outside subnets where an email server resides, or to your chosen email server on the internet. In order to open these ports, non-secure SMTP uses port 25, but the Secure SMTP uses port 587 and is preferred.
- In order to provide threat intelligence enrichment, the SOC Solution requires access to the following Threat Intelligence URLs:
- VirusTotal - https://virustotal.com and subdomains
- URL Haus - URLhaus - Malware URL exchange - and subdomains
- Recorded Future - Recorded Future: Securing Our World With Intelligence and subdomains
- IPQualityScore - Fraud Prevention | Bot Detection | Bot Protection | Prevent Fraud with IPQS and subdomains
- Each of these requires TCP port 443 access and TCP port 80 access.
Cluster Resources
Your cluster needs the following resources available to meet the usage thresholds for the given deployment sizes:
Components | Single Node (Dev/Test) | Small | Medium | Large |
|---|---|---|---|---|
CPU | 8 CPU cores | 24 CPU cores | 48 CPU cores | 96 CPU cores |
CPU Instruction Set | AVX required | AVX required | AVX required | AVX required |
MEMORY | 32 GB RAM | 96 GB RAM | 192 GB RAM | 384 GB RAM |
STORAGE | 600 GB SSD / 3000 IOPS per MongoDB pod persistent volume | 600 GB SSD / 3000 IOPS per MongoDB pod persistent volume | 1 TB SSD / 3000 IOPS per MongoDB pod persistent volume | 1 TB SSD / 3000 IOPS per MongoDB pod persistent volume |
Record Creation Boundaries + Active Users | Records created in a day: 250,000Total records: 5 millionActive users: 10 | Records created in a day: 500,000Total records: 20 millionActive users: 30 | Records created in a day: 1 millionTotal records: 20 millionActive users: 50 | Records created in a day: 1 millionTotal records: 20 millionActive users: 200 |
Integration Calculations | Integrations in use < 20 averageIntegration actions/day < 250,000 | Integrations in use < 20 averageIntegration actions/day < 500,000 | Integrations in use < 20 averageIntegration actions/day < 1 million | Integrations in use > 20 averageIntegration actions/day < 1 million |
Pods | API: 1Tasks: 1Web: 1Reports: 1MongoDB: 1 | API: 3Tasks: 3Web: 3Reports: 3MongoDB: 3 | API: 3Tasks: 3Web: 3Reports: 3MongoDB: 3 | API: 6Tasks: 9Web: 3Reports: 3MongoDB: 3 |
External MongoDB Resource Recommendations
The following table illustrates the resource recommendations (per node) for a standalone mongo deployment. All of these values can be subtracted from the Cluster Resources above when allocating resources for the remainder of the Turbine pods. For more information about deploying on an External MongoDB cluster, see Deploy Turbine with an External MongoDB ClusterDeploy Turbine with an External MongoDB Cluster.
Components | Single Node | Small | Medium | Large |
|---|---|---|---|---|
CPU | 4 CPU Cores | 4 CPU Cores | 8 CPU Cores | 8 CPU Cores |
Ram | 16 GB RAM | 16 GB RAM | 16 GB RAM | 32 GB RAM |
Storage | 300 GB SSD / 3000 IOPS per MongoDB pod persistent volume | 300 GB SSD / 3000 IOPS per MongoDB pod persistent volume | 700 GB SSD / 3000 IOPS per MongoDB pod persistent volume | 700 GB SSD / 3000 IOPS per MongoDB pod persistent volume |
Remaining Turbine Cluster Resources
This table illustrates the resources necessary for the remainder of Turbine if you are using external MongoDB resources:
Components | Single Node | Small | Medium | Large |
|---|---|---|---|---|
CPU | 4 CPU Cores | 12 CPU Cores | 24 CPU Cores | 72 CPU Cores |
Ram | 16 GB RAM | 48 GB RAM | 144 GB RAM | 288 GB RAM |
Storage | 300 GB SSD / 3000 IOPS per node | 300 GB SSD / 3000 IOPS per node | 300 GB SSD / 3000 IOPS per node | 300 GB SSD / 3000 IOPS per node |
Optional Pods
If you require the use of these optional pods you will need the following additional resources available:
Pod | Small | Medium | Large |
|---|---|---|---|
Turbine Logger | .1 CPU core1 GB RAM | .4 CPU core1 GB RAM | .5 CPU core2 GB RAM |
See Pod Requests and LimitsPod Requests and Limits for a breakdown of resources for each pod type including optional pods not included in the table above.
Critical CPU Architecture Prerequisites
CPU architecture must be compatible with MongoDB, unless an external MongoDB solution is used. See the MongoDB Platform Support Matrix for more information.
⚠️ Warning: The AVX CPU instruction set is required for all Turbine deployments using the bundled MongoDB (v5.0+). If AVX is not supported by your CPU or VM configuration, MongoDB will fail to start with an Illegal instruction (core dumped) error and the mongo-0 pod will be stuck in Init:2/3 state. Deployment will not complete.
This requirement does not apply if you are using an external MongoDB solution.
Key requirements:
- AVX (Advanced Vector Extensions) CPU instruction set is required to run MongoDB.
- NUMA (non-uniform memory access) needs to be disabled.
Pre-Installation Verification
Before installing, verify AVX support on each node:
- If the output contains avx, the CPU is compatible.
- If there is no output, the CPU does not support AVX and Turbine deployment will fail.
Virtualized Environment — VM CPU Type Compatibility
If deploying in a virtualized environment, ensure the VM CPU type exposes AVX instructions to the guest OS. Use the table below to check compatibility:
VM CPU Type | AVX Support | Turbine Compatible |
|---|---|---|
x86-64-v2 | No | No — deployment will fail |
x86-64-v3 | Yes (AVX + AVX2) | Yes |
x86-64-v4 | Yes | Yes |
host (passthrough) | Yes (if physical CPU supports AVX) | Yes |
Hypervisor-specific guidance:
- PROXMOX: Set the VM CPU type to x86-64-v3 or higher, or use host passthrough mode.
- VMware ESXi: Ensure the VM hardware version and CPU compatibility mode expose AVX instructions to the guest. Check VM settings → CPU → Expose hardware-assisted virtualization.
- Hyper-V: Use a VM configuration version that supports AVX passthrough. Verify CPU compatibility settings in the VM properties.
- KVM/QEMU: Use -cpu host or a CPU model that includes AVX (e.g., SandyBridge or later).
Exceptions to Network Access Control Lists (ACL)
Swimlane installations on servers with tight Network Access Control (NAC) will need several exceptions made to properly install, license, and stage a Swimlane deployment with the Swimlane Platform Installer. See the tables below for the Outbound and Inbound exceptions.
Required Outbound URL ACL Exceptions
Exception | Purpose |
|---|---|
get.swimlane.io | Swimlane platform installation script |
k8s.kurl.sh | Swimlane platform installation script |
kurl.sh | Swimlane platform installation script |
kurl-sh.s3.amazonaws.com | Swimlane platform installation script dependencies |
registry.replicated.com | Swimlane platform container images |
proxy.replicated.com | Swimlane platform container images |
k8s.gcr.io | Swimlane platform container dependency images |
ghcr.io | Swimlane platform container dependency images |
registry.k8s.io | Swimlane platform container dependency images |
storage.googleapis.com | Swimlane platform container dependency images |
quay.io | Swimlane platform container dependency images |
replicated.app | Swimlane Platform Installer license verification |
auth.docker.io | Docker authentication |
registry-1.docker.io | Docker registry |
production.cloudflare.docker.com | Docker infrastructure |
files.pythonhosted.org | Python packages for Swimlane integrations |
pypi.org | Python packages for Swimlane integrations |
<LoadBalancerIP\>:6443 | Kubernetes API |
Port Requirements
Ports | Protocol | Purpose | Access From |
|---|---|---|---|
443 | TCP | Swimlane platform UI | Clients that need to access the Swimlane platform UI |
80 | TCP | Swimlane platform UI | Optional - HTTP to HTTPS redirect for the Swimlane platform UI |
8800 | TCP | Swimlane Platform Installer UI | Clients that need to access the Swimlane Platform Installer UI |
22 | TCP | Shell access | Management workstations to manage the cluster nodes and install Swimlane |
External Monitoring Considerations
Swimlane recommends that any TPI installation has some amount of external monitoring set up and set to alert when any user-defined thresholds are met as to possible cases of your production instances going down. Different installation scenarios may call for different metrics to monitor, so your implementation may vary. As a baseline the following metrics are recommended for nodes that are running Turbine pods:
- Are all nodes healthy?
- Does each node have sufficient free space in all partitions?
- Are CPU and memory usage levels within acceptable levels?
- Is disk latency within acceptable ranges?
- Are any pods in an not ready state?
- Are any deployments or StatefulSets not reporting the correct number of ready replicas?
- Do any load balancers have health checks in place? Are they healthy?
Third Party Monitoring Solutions
There are several third-party monitoring solutions that you can use to monitor resource usage for a node. Any tool that you put into use should be installed externally to the cluster so as to not interfere with cluster operations and to be able to alert if a metric enters into a failing scenario. These products may require that their own agents or exporters be installed on the nodes in order to facilitate monitoring. Any agent or exporter should be tested against your cluster to validate that they do not interfere with Turbine operations.