Terminal Server
Preferred Option: Dedicated Server/VM
A dedicated Windows server or virtual machine is the preferred option for the terminal server from which the SESTEK Application Support Engineer connects to in order to bootstrap the installation process.
Using a dedicated server/VM ensures better security, reliability, and avoids potential conflicts with other applications during the installation process.
Alternative Option: Employee Workstation
As an alternative option, customers can designate an employee's Windows workstation as the terminal server. This approach is commonly used by customers who prefer not to provision a dedicated server/VM.
When using an employee workstation:
- Ensure the workstation can be exclusively used during the installation period
- The workstation should meet all security and technical requirements
- Consider potential downtime for the employee during installation
Required Applications
Regardless of whether you choose a dedicated server/VM or an employee workstation, the following applications must be installed:
- OpenSSH Client - Required for secure remote connections
- Windows Terminal - Enhanced terminal experience for installation procedures
- Notepad++ - Text editor for configuration file editing
- Postman - API testing tool for verification procedures
- SQL Server Management Studio - Required when MS SQL Server is used as the database
- PgAdmin 4 - Required when PostgreSQL is used as the database
Additional Requirements
- Administrator privileges on the terminal server/workstation
- Stable network connection to reach the customer's infrastructure
- Sufficient disk space for temporary files during installation (minimum 2GB free space recommended)
- Windows Server 2016 or newer, or Windows 10/11 for workstations
- With the provided docker credentials, we need customers to download one of the following depending on the Terminal Server's OS they provide.
maestro.windows-latest.zip
maestro.linux-latest.zip
The terminal server/workstation must have network access to:
- The Kubernetes cluster nodes
- Database servers
- Any external systems that will be configured during installation
- Registry access to the proxy registry customer provides us with.
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.
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.
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.
If NFS-backed Persistent Volumes are used for any stateful applications (MinIO, Git repositories, databases, etc.), ensure that the NFS export policy does NOT have all_squash enabled. This setting causes all file operations to be mapped to an anonymous user (typically nobody:nogroup with UID 65534), leading to permission errors. The export should allow proper UID/GID mapping to match the container's running user.
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
Worker nodes in the cluster should be able to access the services using the protocols and ports that are provided below.
| Server | Port | Protocol | Conditions |
|---|---|---|---|
| License service | 30113 | TCP | Always |
| MS SQL Server | 1433 | TCP | Required only if MS SQL Server is used as database. |
| PostgreSQL | 5432 | TCP | Required only if PostgreSQL is used as database. |
| SESTEK Call Recorder | 2050 | TCP | Required only if SESTEK Recorder is used with Knovvu Analytics product. |
| SR Servers | 10097 | HTTP | Required only if SESTEK SR Server is used separately. |
Container Registry
Customers are required to proxy their container registries to the Central Knovvu Container Registry (docker.sestek.com). If this is not possible, then customers should pull all the images from Central Knovvu Container Registry and push them to their container registry. If this is the case, image list will be provided by SESTEK.
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.
The user provided for the docker registry must have the permissions to list and push images.
Object Storage
If customers already have a managed S3-compatible object store, SESTEK recommends using it instead of deploying MinIO inside the cluster. Based on our experience, customer-managed object stores are typically well-maintained and high-performing, whereas a SESTEK-managed MinIO instance, mounted via a Persistent Volume backed generally by an NFS storage which is by nature slow, may not offer the same level of reliability and performance.
If customers perform regular CVE scanning, MinIO should not be used. The MinIO codebase is in a maintenance-only state, and CVEs, including critical security vulnerabilities, are evaluated and fixed on a case-by-case basis. For such customers, an S3-compatible object storage service must be provided and managed by the customer.
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.
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