Skip to main content
An ingress resource maps external HTTPS traffic to SeekrFlow’s services through path-based rules. An ingress controller runs inside your cluster, watches for ingress resources, and creates and configures the load balancer for them.

​
Choose an approach

  • Chart-managed ingress – SeekrFlow creates the ingress resource for you, and your ingress controller creates the load balancer from it. This is the quickest way to get running.
  • Externally managed ingress – You create the ingress resource yourself, with the routes listed in Create your own ingress resource. Recommended for production, because you keep control of Transport Layer Security (TLS), annotations, and lifecycle.

​
Install an ingress controller

Both approaches need an ingress controller. The chart doesn’t install one.
Install the AWS Load Balancer Controller. See Install AWS Load Balancer Controller with Helm. Use the settings in this table.To check that the controller is running, run:
READY shows 2/2 when it’s running.

​
Get a TLS certificate

TLS terminates at the ingress. Get a TLS certificate for the hostname your users will reach SeekrFlow at.
Request or import a certificate in AWS Certificate Manager (ACM). The Application Load Balancer uses it. ACM issues a requested certificate only after you validate that you own the domain, usually with a DNS record. If the domain is in Amazon Route 53, the ACM console can create the validation record for you. See Request a public certificate.

​
Create your own ingress resource

Skip this section if you use chart-managed ingress. Create your own ingress resource with these routes, in this order. Use pathType: Prefix for every path. Include a route only for services you enable. For example, include /v1/explainability only if you enable Explainability. On AWS, add the load balancer annotations to your ingress resource.
On AWS, the Application Load Balancer evaluates rules from top to bottom. A /v1 rule placed before /v1/explainability captures its traffic.

​
Create the DNS record

Create a DNS record that points your hostname at the address of your load balancer or ingress controller. The hostname must resolve from your users’ machines, from inside the cluster, and from wherever you run sfe.
When you create the record depends on your approach:
  • Chart-managed ingress – The load balancer doesn’t exist until you install SeekrFlow. Come back to this section after the install.
  • Externally managed ingress – Create the record once your ingress resource has a load balancer address.
1

Get the load balancer address

For chart-managed ingress, run:
For your own ingress, run the same command in your ingress resource’s namespace. The address is in the ADDRESS column.
2

Create the record

Point your hostname, the global.ingress.host value in your values file, at that address. On Amazon Route 53, use an alias record. On other DNS providers, use a CNAME record.

​
Plan network policies

SeekrFlow does not ship network policies, and it runs without any. If you apply a default-deny policy, put these allowances in place before you install, or the install fails:
  • The ingress controller to each SeekrFlow service port.
  • SeekrFlow pods to each other within the seekrflow namespace.
  • SeekrFlow pods to PostgreSQL, OpenSearch, and object storage.
  • These components to the Kubernetes API server: the operator, Training, Serving, Router, Explainability, License, Ingestion, AI-Ready Data, the LoRA controller, the Argo Workflows controller and its workflow pods, the JobSet controller when enabled, and the sfe preflight and database setup jobs.
  • External Secrets Operator to your secret store, from its own namespace.
  • Pods in seekrflow to the Argo server in argo-workflows, on port 2746. Argo Workflows runs in argo-workflows, and its job pods run in seekrflow.
  • The outbound connections your deployment uses. See Security considerations.

​
Plan admission policies

If your cluster runs a policy engine, such as Kyverno or Open Policy Agent (OPA) Gatekeeper, make sure its policies admit SeekrFlow’s pods before you install:
  • If your policies restrict user IDs, permit 65532 for the operator and 1001 for the workloads it creates.
  • The Argo server and the model catalog sync job don’t use SeekrFlow’s security context. Exempt them from policies that require it.

​
Record the values

Note these values. You will enter them when you create the values file.

​
Load balancer annotations

SeekrFlow requires the first two, because its services aren’t exposed on node ports and the load balancer must serve HTTPS. The idle timeout supports long-running requests. The controller creates an internal load balancer by default. If your users reach SeekrFlow from the internet, also add alb.ingress.kubernetes.io/scheme: internet-facing.
Last modified on October 16, 2026