--- title: "Deployment prerequisites" slug: "kubernetes-by-customer-prerequisites" updated: 2026-04-10T07:27:05Z published: 2026-04-10T07:27:05Z --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.knovvu.com/llms.txt > Use this file to discover all available pages before exploring further. # Deployment Prerequisites {{snippet.PlatformTerminalServerPrereq}} ### Kubernetes Distributions Knovvu applications run on any compatible Kubernetes flavor from different providers like AWS, Azure, RedHat, Rancher, etc with the version restriction specified in the following section. Knovvu applications also honour and embrace provider specific features to deliver better experience for their users. Tested/verified distributions and providers are given below however please note that this is not an exhaustive list of all. | Distro | Provider | --- | --- | OpenShift Container Platform | RedHat | Rancher | SUSE | EKS | AWS | AKS | Azure | GCP | Google Cloud | Anthos | Google Cloud | OKE | Oracle Cloud | Vanilla | Community ### Kubernetes Versions Minimum Kubernetes version supported by SESTEK is **v.1.22.X** and maximum supported version is **v1.34.X**. ## Ingress settings SSL Redirection should be disabled on ingress. ```yaml nginx.ingress.kubernetes.io/ssl-redirect: "false" ``` ### Kubernetes Namespaces Namespaces (OpenShift projects) for common components and each product should be created before the installation. Names of the namespaces will be shared by SESTEK based on the product being deployed. :::(Warning) (Important) Network access between namespaces must be enabled for Knovvu products. This allows necessary communication between different components of the Knovvu system that may be deployed in separate namespaces. ::: ### Persistent Volumes Knovvu applications require persistent volumes to store their data. Therefore persistent volume support should be enabled in the cluster. Additionally, Knovvu applications should have the permission to request persistent volumes from the cluster. If this is not the case, customers can create the requested persistent volumes manually. However, this requires communication between SESTEK and the customer and may slow down the deployment process. #### Persistent Volume Access Mode For optimal performance, Knovvu applications should use ReadWriteOnce (RWO) access mode for persistent volumes. This configuration provides faster deployment and better overall performance. While ReadWriteMany (RWM) access mode is supported, using ReadWriteOnce is recommended to ensure efficient operation of the applications. {{snippet.PlatformStorageClassNFSPreference}} ### Cluster Permissions Customers should provide admin permissions in SESTEK namespaces. SESTEK applications **don't** require cluster admin permissions. Service accounts will be created by SESTEK during deployment. #### EndpointSlice Management Access Requirement Managing Kubernetes EndpointSlices (creating, updating, or deleting) requires permissions beyond the default project/namespace admin role in OpenShift. By default, project admins do not have write access to endpointslices.discovery.k8s.io. To enable these operations, a custom Role granting the necessary verbs (get, list, watch, create, update, patch, delete) must be created and bound to the specific user within the target namespace. This additional RBAC configuration is required for any user who needs to manage Sestek projects. ### OpenShift Resource Quota Sizing It is recommended to set the quota based on the total resource requests of all workloads in the namespace, plus a 30% buffer to account for rolling deployments and pod restarts. ### LimitRanges #### Common Namespace The pod limits for the common namespace should be as follows: | Resource | Minimum | Maximum | |---------------|------------|----------| | **CPU** | `10m` | `3` | | **Memory** | `6Mi` | `6Gi` | #### STAI, Core, CA and VA Namespace The pod limits for those namespaces should be as follows: | Resource | Minimum | Maximum | |---------------|---------|---------| | **CPU** | `10m` | `16` | | **Memory** | `6Mi` | `32Gi` | ### Network {{snippet.PlatformNetworkPrereq}} ### Container Registry {{snippet.PlatformRegistryPrereq}} The following container registries are supported: * Docker Hub (also any container registry supporting Docker Registry v2 API) * Quay.io * Nexus * ghcr (GitHub Container Registry) * ECR (Elastic Container Registry by AWS) * ACR (Azure Container Registry) * gcr (Google Container Registry) * JFrog Deployments are bootstrapped using a Knovvu Command Line tool called Maestro. The machine running Maestro (either a terminal server or the customer’s client machine) must have access to the Customer Container Registry. :::(Warning) () The user provided for the docker registry must have the permissions to **list** and **push** images. ::: {{snippet.PlatformMinIOPreference}} ### License Server We will be utilizing the windows license server customer provide us with to setup our license server. We need the below exe to be downloaded to license server machines, so that we can setup the licensing. ### Maintenance and Support of Third-Party Applications When a component is deployed and managed by SESTEK (including open-source third-party applications such as Redis and RabbitMQ), its maintenance and technical support are also provided by SESTEK. For more information, please refer to the [Component Responsibility Matrix](/v1/docs/component-responsibility-matrix). Ownership of certain components may vary depending on customer policies. For these components, ownership must be clearly defined before the start of the project. ### Observability **Application Logging** For all deployments, the Elastic Stack is deployed and managed by Sestek within the cluster. For customers who require integration with their own logging solutions (such as Elastic Stack, Splunk, or similar platforms), we support forwarding logs to a customer-managed instance. For this integration, Logstash is used to ship logs, and both data streams and indices are supported. **Metrics and Alerts** Knovvu applications expose metrics in Prometheus format. If the customer already has a Prometheus Operator installed in their cluster, full permissions for the ServiceMonitor, PrometheusRule, and AlertmanagerConfig CRDs must be granted in the Knovvu namespaces. This allows Prometheus to scrape application metrics and apply the associated alert definitions. **Distributed Tracing** All Knovvu applications are instrumented with OpenTelemetry for distributed tracing, using vendor-neutral telemetry standards. Customers may integrate any OpenTelemetry-compatible observability platform (commercial or open source) to collect, store, and visualize these traces. Once configured, traces appear in the selected tool with end-to-end request timelines and cross-service correlation for troubleshooting and performance analysis. By default, Sestek deploys Elastic Stack APM to collect traces and uses Kibana for visualization. ### Information expected from customer - Base domain name Customers should choose a base domain name that SESTEK applications will use (e.g. knovvu.mycompany.com). Changing the domain address later in the deployment process requires additional actions, that might delay the installation process. - Preferred database (**Microsoft SQL Server** or **PostgreSQL**). Version should be verified based on the product being deployed. - Database server's IP, port, DNS (if exist) and credentials with dbowner privileges. - Kubernetes platform and version (e.g. **Openshift v4.12.0**) - Kubernetes Engine version (e.g. **1.19.4**) - Storage class name (e.g. **my-storage-class**) - Kubeconfig file for the cluster that Knovvu applications will be installed to - Address and credentials of the container registry - Whether or not a service mesh (e.g. Istio) is deployed in the cluster - Whether or not network policies are enabled and configured in the cluster - Whether Redis/RabbitMQ will be deployed inside the cluster by Sestek, or if externally provided instances supplied by the customer will be used (If customer-provided, whether they will be configured in cluster/sentinel mode, and if so, the relevant endpoint information)