Skip to content

Deploy on OpenShift

Install Koldan on OpenShift with the same chart and release inputs used for Kubernetes. This page covers OpenShift-specific access, Routes, security constraints, and storage; follow Install with Helm for the complete installation procedure.

Before you begin

In addition to the Helm prerequisites, confirm that:

  • the project permits creation of Deployments, Services, Secrets, PVCs, and Routes;
  • a cluster administrator has approved the Security Context Constraints (SCCs) required by the enabled workloads;
  • the ingress router supports the chosen HTTP and gRPC TLS design;
  • the selected storage classes satisfy access mode, expansion, topology, and reclaim requirements; and
  • DNS records can be created for each Route hostname.

Use a dedicated OpenShift project. Review resource quotas, limit ranges, egress policies, and default network policies before rendering the chart.

Configure workload security

Keep OpenShift's namespace-assigned UID and restricted security policy wherever possible. Configure podSecurityContext and securityContext only through the supported values for each enabled workload, and verify that mounted volumes are writable by the assigned UID. Do not set a fixed UID unless the image and an approved SCC require it.

Render the manifests and inspect them with the target namespace's SCC policy before installation. Pay particular attention to host networking, service-account token mounting, container UID, Linux capabilities, writable paths, and volume ownership.

Configure Routes

Expose the HTTP and gRPC interfaces independently. The HTTP Ingress and HTTP Route are mutually exclusive in the chart:

web:
  ingress:
    enabled: false
  route:
    enabled: true
    host: koldan.apps.example.com
    path: /
    annotations:
      haproxy.router.openshift.io/timeout: 360s
    tls:
      enabled: true
      termination: edge
      insecureEdgeTerminationPolicy: Redirect

grpc:
  service:
    type: ClusterIP
  route:
    enabled: true
    host: grpc.apps.example.com
    path: /
    annotations:
      haproxy.router.openshift.io/timeout: 360s
    tls:
      enabled: true
      termination: edge
      insecureEdgeTerminationPolicy: Redirect

The timeout values are examples. Set them from the longest supported request or stream duration and your platform policy. Confirm that the router negotiates HTTP/2 for the gRPC Route and forwards to the chart's grpc service port; test this behavior on the exact OpenShift release and router configuration in use.

Choose one TLS design per Route:

  • Edge termination: the router terminates external TLS and sends cleartext traffic to the service. Use the router's default certificate or provide the serving certificate and key through the supported *.route.tls values.
  • Re-encrypt termination: the router terminates external TLS and creates a second TLS connection to Koldan. Configure the backend gRPC certificate where applicable and provide the destination CA expected by the router.
  • Passthrough termination: the router passes TLS directly to the backend. The backend must be configured to serve a certificate for the external hostname; router-managed certificates do not apply.

Do not use re-encrypt or passthrough until the selected Koldan endpoint is configured for backend TLS. Route private keys supplied as values are stored in Helm release metadata and in the Route object; protect cluster access accordingly. Keep certificate hostname verification enabled for all outbound dependencies.

If the bundled Keycloak dependency is enabled and exposed by a Route, disable its Ingress to prevent duplicate exposure:

keycloak:
  ingress:
    enabled: false
  route:
    enabled: true
    host: login.apps.example.com

Configure storage and placement

Set a storage class and requested capacity for every bundled stateful dependency and for the Koldan updates PVC. Confirm the resulting PVC access modes match the storage provider. ReadWriteOnce volumes can constrain rescheduling to a zone or node; use a storage class with topology-aware binding and test pod rescheduling before production.

Use the component and worker-pool nodeSelector, tolerations, and affinity values for dedicated or specialized MachineSets. Check project quota for CPU, memory, ephemeral storage, and PVC requests before installation.

Install and verify

Run the lint, render, and helm upgrade --install procedure from Install with Helm, using oc for cluster inspection:

oc get deployment,statefulset,pod,pvc,service,route -n koldan
oc get events -n koldan --sort-by=.lastTimestamp
oc describe route koldan-web -n koldan
oc describe route koldan-grpc -n koldan

Verify all general Helm acceptance checks, then confirm:

  1. each Route is admitted and resolves to the expected router;
  2. the external certificate chain and hostname are correct;
  3. HTTP redirects to HTTPS when required;
  4. an authenticated HTTP request succeeds through the HTTP Route;
  5. a gRPC client completes TLS negotiation and an authenticated call through the gRPC Route;
  6. pods run under the intended SCC without repeated admission failures; and
  7. PVCs bind and workloads can be rescheduled without losing access to required storage.

Troubleshoot and recover

If a pod is rejected, inspect its events and the effective SCC selection. Correct the narrowest security-context or service-account setting that satisfies the workload; do not assign a broadly privileged SCC as a workaround.

For a Route that is not admitted or returns router errors, check the hostname, target service and port, endpoint readiness, TLS termination mode, certificate/key match, destination CA, router HTTP/2 support, and timeout annotations. For a pending PVC, check the StorageClass provisioner, access mode, quota, allowed topology, and node scheduling constraints.

Reapply corrections through Helm. Use the rollback rules in Install with Helm; a Helm rollback does not reverse SCC grants, DNS changes, external certificates, or storage changes, so track and revert those platform changes separately when required.