Cluster types compared

OpenLM Platform installs the same way on every cluster type: same chart, same images, same steps. What changes is the cluster around it: how traffic comes in, which storage class you use, how you configure the nodes, and which managed data services you can use.

At a glance

The following table compares the four cluster types:

	Amazon EKS	AKS	Red Hat OpenShift	K3s
Ingress	Traefik or ingress-nginx behind an NLB	ingress-nginx or Traefik behind the Azure LB	OpenShift Routes (router)	Built-in Traefik
INGRESS_CLASS	traefik / nginx	nginx / traefik	(not used)	traefik
STORAGE_CLASS	gp3 (EBS CSI)	managed-csi (Azure Disk)	cluster's block class, for example gp3-csi, managed-csi, thin-csi	local-path
TLS terminated at	Ingress controller	Ingress controller	Router (edge)	Traefik
Pod user IDs	Set by the chart	Set by the chart	Assigned by OpenShift (useOpenShift: true)	Set by the chart
Node placement	Optional (node group labels)	Optional (node pool labels)	Usually off (you can't label nodes)	Usually off (one or few nodes)
SQL Server	RDS for SQL Server, or your own	Azure SQL Database / Elastic Pool, or your own	Any reachable SQL Server	Your own
Redis	ElastiCache (Redis/Valkey)	Azure Managed Redis / Azure Cache	Any	Your own
Kafka	Amazon MSK or your own	Your own or Confluent Cloud	Your own (an operator, for example Strimzi)	Your own
MongoDB	MongoDB Atlas or your own (not DocumentDB)	MongoDB Atlas or your own (not Cosmos DB)	Atlas or your own	Your own
Extra steps	NLB, node file-watch limit	Firewall rules for the NAT IP	OpenShift values file, extra Routes, certificate	Redirect, DNS rewrite

Each platform page covers the same topics in the same order: before you start, ingress, storage, node settings, values, data services, and platform-specific checks. Open the page for your cluster type:

• Amazon EKS
• Azure Kubernetes Service (AKS)
• Red Hat OpenShift (including ROSA and ARO)
• K3s

Node settings that apply everywhere

OpenLM Platform starts about 100 .NET services, so set two Linux file-watch limits on every node that runs them:

Setting	Minimum	Why
fs.inotify.max_user_instances	8192	Each service watches its configuration files. The common default of 128 runs out, and pods fail with too many open files.
fs.inotify.max_user_watches	524288	Same reason

If you manage the nodes, set the limits in /etc/sysctl.d/. If you can't, set them on every node with a small DaemonSet. The DaemonSet runs privileged, which your cluster policy might forbid:

apiVersion: apps/v1
kind: DaemonSet
metadata: { name: openlm-node-sysctl, namespace: kube-system }
spec:
  selector: { matchLabels: { app: openlm-node-sysctl } }
  template:
    metadata: { labels: { app: openlm-node-sysctl } }
    spec:
      initContainers:
        - name: sysctl
          image: public.ecr.aws/docker/library/busybox:stable
          securityContext: { privileged: true }
          command: ["sh", "-c", "sysctl -w fs.inotify.max_user_instances=8192 fs.inotify.max_user_watches=524288"]
      containers:
        - name: wait
          image: public.ecr.aws/docker/library/busybox:stable
          command: ["sleep", "2147483647"]
          resources: { requests: { cpu: 1m, memory: 8Mi }, limits: { memory: 16Mi } }
      tolerations: [{ operator: Exists }]

To check the value, run this command on a node or from a debug pod:

kubectl debug node/<node> -it --image=public.ecr.aws/docker/library/busybox:stable -- cat /proc/sys/fs/inotify/max_user_instances