FAQ

Q: Can SESTEK deploy and maintain the Kubernetes environment for me?

Yes. If customers don't maintain Kubernetes environments or don't want to use them for Knovvu applications, SESTEK can deploy Kubernetes as part of the deployment process. This approach is referred to as Kubernetes by SESTEK. For more information, refer to Kubernetes by SESTEK Deployment Topology.

Q: Can I use my own Kubernetes cluster for Knovvu applications?

Yes. Customers can choose to deploy Knovvu products on their own Kubernetes environments. This approach is referred to as Kubernetes by Customer. For more information, refer to Kubernetes by Customer Deployment Topology.

Q: How does a Knovvu product gets provisioned?

Deployments are handled by a SESTEK Application Support Engineer, triggering an automated process using an internal SESTEK tool called Maestro. For more information on deployment refer to the following links.

Deployment Procedure - Kubernetes by SESTEK
Deployment Procedure - Kubernetes by Customer

Q: Can I provide my own endpoints for stateful applications like RabbitMQ, Minio and Redis instead of SESTEK deploying these applications?

Yes. This requires extra communication between the customer and SESTEK.

Q: Which relational databases are supported by the Knovvu Platform?

Knovvu applications support Microsoft SQL Server and PostgreSQL.

Q: Can SESTEK deploy databases into the Kubernetes cluster?

No. For reliability of the crucial data stored in the relational database, SESTEK expects customers to manage the databases, outside of the Kubernetes cluster.

Q: Can SESTEK deploy Knovvu applications without Kubernetes?

No. Knovvu applications run within containers orchestrated by Kubernetes and depends on the cloud native capabilities of Kubernetes to ensure high performance, fault tolarance and efficient resource management.

Q: Can I use my own load balancer?

Yes. In this case, customers are expected to manage certificates.

Q: How will we receive the application images?

The application images are stored on docker.sestek.com. You can access them by pulling them using the credentials provided to you.

Q: Is an internet connection required during deployment?

For the duration of the deployment, access to docker.sestek.com is all that is required. Depending on the type of deployment, the direction of this access may vary. Specifically:

• If we are setting up the Kubernetes cluster (Kubernetes by SESTEK), the VM named 'Origin' must have access to docker.sestek.com

• If we are installing on your cluster and you have your own registry, it will suffice to set up a proxy from your registry to docker.sestek.com

Q: Can you perform the deployment without internet access?

Air-gapped installation is only supported in Kubernetes by Customer deployments. In this case, the image list provided by SESTEK must be pulled from the SESTEK registry and pushed to your own registry. Please note that this approach can significantly delay deployment and is not recommended.

Q: Why is Jenkins included in the platform?

Due to the variety of deployment options within Knovvu, we use our own Jenkins to deploy all Knovvu applications after the platform is up and running. This ensures that you always have access to the most up-to-date Knovvu applications through this Jenkins.

However, if you prefer to initiate the processes from your own Jenkins, it is possible to trigger the jobs within the Knovvu Platform's Jenkins from your Jenkins.

Q: Does Knovvu applications use a service mesh?

No. But customers can integrate service mesh solutions, such as Istio.

Q: If SESTEK provides the necessary configuration (yaml) files, can customers deploy Knovvu Platform and Knovvu Applications by themselves?

No. Deployment and configuration are managed and automated through code for stability and consistency. The tools used for deployment cannot be modified per customer deployment.

Q: Why does Knovvu require permissions for EndpointSlice resources on Kubernetes/OpenShift?

One of the Knovvu services operates by watching EndpointSlice resources on Kubernetes. EndpointSlices are core Kubernetes objects that hold the up-to-date status of pod IPs and connection details associated with a given service.
For the service to function correctly, it needs to:

Track the dynamic addition and removal of pods associated with a service in real time
Use up-to-date endpoint information during traffic routing and connection management
Enable automatic self-healing in the event of outages or rescheduling scenarios

These operations are only possible when the appropriate permissions for EndpointSlice objects are granted.