Skip to main content

Step 1: Prepare the cluster

Prepare your cluster for OpenLM Platform: create the namespace, check storage and ingress, create the DNS name, and confirm that pods can reach it. Load the variables from openlm-install.env, the file you created from the installation worksheet:

source ./openlm-install.env

1.1 Create the namespace​

kubectl create namespace "$NS"

On OpenShift, create a project instead, so the namespace gets its security settings:

oc new-project "$NS"

1.2 Check the storage class​

kubectl get storageclass "$STORAGE_CLASS"

It must print one line. If it says NotFound, list the classes with kubectl get storageclass and correct STORAGE_CLASS in your worksheet.

1.3 Check the ingress controller​

Confirm that your cluster has a controller to serve web traffic. OpenLM Platform brings web traffic in through one Ingress object, or through Routes on OpenShift.

kubectl get ingressclass

Your INGRESS_CLASS must be in the list. If the list is empty, install an ingress controller first. Your platform page says which one to use. On OpenShift, the built-in router does this job, and you can skip this check.

Then find the controller's external address, which is where your DNS name points:

kubectl get service -A | grep -iE "LoadBalancer"

Note the EXTERNAL-IP of your ingress controller's service. It's a host name on EKS, an IP on AKS, or your node's IP on K3s.

1.4 Create the DNS name​

Ask your network team to create a DNS record for $DOMAIN:

ClusterRecord
EKSCNAME → the load balancer host name from 1.3
AKS, K3sA → the IP from 1.3
OpenShiftCNAME → the cluster's router address (*.apps.<cluster> wildcard), or covered by it already

1.5 Raise the node file-watch limit​

Set fs.inotify.max_user_instances to 8192 on every node. About 85 services start at the same time. On many Linux defaults that exhausts fs.inotify.max_user_instances (128), and pods fail with too many open files. How to set it depends on the platform: see the Node settings section of your platform page.

1.6 Make the address reachable from inside the cluster​

Test now, before anything else depends on it, that pods can reach your web address. Services call https://$DOMAIN/identity from inside the cluster. On most cloud clusters this works without changes. On other clusters, pods can't reach the cluster's own load balancer ("hairpin" traffic). Run the test pod:

kubectl -n "$NS" run nettest --rm -it --restart=Never \
--image=public.ecr.aws/docker/library/busybox:stable -- \
sh -c "nslookup $DOMAIN && wget -qO- --no-check-certificate -T 5 https://$DOMAIN/ >/dev/null; echo exit=\$?"

Read the result:

  • nslookup must return an address.
  • exit=0, or exit=1 with "404", "503", "TLS error" or "Connection reset by peer", means the connection worked. The platform isn't installed yet, so the ingress answers with an error page or its own default certificate.
  • exit=1 with "timed out" or "can't connect" means pods can't reach the address. Fix it now: Networking: reaching the platform address from inside.
Check

Confirm these results:

  • kubectl get namespace $NS shows Active.
  • nslookup $DOMAIN from your workstation returns the address from 1.3.
  • The test pod in 1.6 connected.

The documentation team might draft this page using a large language model. A technical writer reviews every page and verifies it against the product before publishing it. A human makes the final decision.