A self-hosted instance of Tonic Ephemeral has the following requirements.
The Ephemeral application database stores information about Ephemeral objects and users.
For the application database, you must provide a PostgreSQL database with the following characteristics:
Version:
PostgreSQL 16+
Database user:
Must have permission to:
Create a database
Create tables
Insert
Select
Your Kubernetes cluster supports your Ephemeral databases. For persistent storage, it uses one volume mount per database instance.
When you provision your Kubernetes cluster, it is important to select the appropriate node types and block storage types.
These recommendations are based on your workload requirements, and cover the following major cloud providers:
AWS
Azure
Google Cloud
Determine the CPU and memory requirements of your Ephemeral database instances to ensure that the selected node types can handle the workload.
For information, go to Setting the required resources for a database.
Evaluate the network performance requirements, especially if your application involves significant data transfer between nodes.
To balance performance and cost, select instance types that meet your requirements, but that do not over-provision resources.
When you use Helm to install the Ephemeral application, the baseline values for Kubernetes deployment resources are:
Each instance type has volume attachment limits. When you select a node type, you need to consider these limits.
Each Ephemeral database requires one block storage volume attachment.
General-purpose compute options typically support between 20 and 30 volume attachments.
Large instance types support higher limits.
When you configure block storage for Ephemeral database instances, select the appropriate block storage type based on your performance requirements.
AWS
gp3
General-purpose solid-state drive (SSD). Suitable for most workloads.
Provides consistent performance with the ability to provision IOPS and throughput independently.
Azure
Standard SSD
Suitable for most workloads. Provides a balance between cost and performance.
Premium SSD
Suitable for I/O-intensive workloads that require low latency.
Provides consistent performance with high IOPS and throughput.
Google Cloud
SSD Persistent Disk
Suitable for I/O-intensive workloads that require low latency.
Provides consistent performance with high IOPS and throughput.
The table below covers multiple scenarios for deploying an Ephemeral database in AWS on a single m6a.4xlarge node, which has 16 vCPU and 64 GB memory.
It demonstrates the factors to consider when you determine the number of databases that a node can support.
Note that this instance type can support a maximum of 28 Amazon Elastic Block Store (EBS) attachments. Because EBS attachments correspond one-to-one with Ephemeral databases, this instance type can support no more than 28 Ephemeral databases, regardless of the CPU and memory considerations.
You might have any combination of provisioned compute resources for the databases on a node, but this simplified example covers the following scenarios:
Only Nano (0.125 vCPU / 0.5 GB memory)
Only Micro (0.250 vCPU / 2.0 GB memory)
Only Small (1 vCPU / 4.0 GB memory)
Only Nano
In the only Nano scenario, the instance has enough CPU and memory to support 128 databases. However, it will reach the limit of 28 EBS attachments before it reaches the other resource limits.
If you run many minimally resourced Ephemeral databases, you should instead deploy multiple smaller nodes that better balance the usage of CPU/memory and the EBS attachment limits.
Only Micro
In the only Micro scenario, the instance has enough CPU and memory to support 32 databases. However, similar to the only Nano scenario, the instance will reach the limit of 28 EBS attachments before it reaches the other resource limits.
While the CPU and memory are still not fully utilized, they are closer to full utilization.
This instance might be suitable for this scenario.
Only Small
In the only Small scenario, the instance has enough CPU and memory to support 16 databases. The memory and CPU are fully utilized before they are bottlenecked by the limit on EBS attachments.
This is an efficient use of the instance, and the instance is suitable for this scenario.
Database resource configuration
0.125 cores / 0.5 GiB (Only Nano)
0.500 cores / 2.0 GiB (Only Micro)
1.000 core / 4.0 GiB (Only Small)
CPU per pod
0.125
0.5
1
Memory per pod
0.5 GiB
2.0 GiB
4.0 GiB
Max pods by CPU
128
32
16
Max pods by memory
128
32
16
Max pods by EBS attachments
28
28
28
Max pods on node
28
28
16
The Kubernetes cluster where you deploy Ephemeral has the following requirements:
Runtime is either:
AWS EKS - For this option, AWS EBS CSI driver must be installed and configured. For details, go to the AWS EBS documentation.
Azure AKS - For this option, Azure Disk CSI driver must be installed and configured. For details, go to the Azure Disk documentation.
Google Cloud Platform (GCP) Google Kubernetes Engine (GKE) - For this option, the Google Compute Engine persistent disk CSI driver must be installed and configured. For details, go to the GKE documentation.
Volume Snapshot CRDs and the Volume Snapshot controller are installed and configured. For installation instructions, go to the kubernetes-csi documentation. For snapshotter documentation, go to the external-snapshotter GitHub repository.
external-dns is installed and configured. For details, go to the external-dns GitHub repository.
(Optional) Kubernetes autoscaler is installed and configured. For details, go to the autoscaler GitHub repository.
To deploy Tonic Ephemeral, you use Helm charts. The OCI reference for the Ephemeral chart is oci://quay.io/tonicai/ephemeral
. The Ephemeral repository is at https://quay.io/repository/tonicai/ephemeral.
During the onboarding process, Tonic.ai provides you with access credentials for the Quay repository, which gives you access to the charts and application images.
To access the Helm chart assets, you first authenticate Helm to Quay:
helm registry login quay.io
After you authenticate, download the configuration template to a .yaml file.
helm show values oci://quay.io/tonicai/ephemeral --version <ephemeral-version> <yaml-file>
For --version
, you must provide the full version number. The repository Tag History lists the available Ephemeral versions.
The .yaml file contains the Helm chart configuration. It is typically named values.yaml.
The following example downloads the configuration template for version 1.062.0 to values.yaml.
helm show values oci://quay.io/tonicai/ephemeral --version 1.062.0 > values.yaml
To configure Ephemeral, you edit values.yaml.
Before you deploy Ephemeral, you must configure the following Helm chart values:
environmentName
Free text that is used to label Ephemeral assets such as databases or log files.
For example, ACME_WEB_QA
.
dockerConfigAuth
ephemeralDatabase
ephemeralVersion
The Ephemeral version, which is expressed as a 3-digit string.
For example, for the full version number 1.062.0, ephemeralVersion
is 062.
ingress
ephemeralWeb.annotaions
To configure the connection information for the Ephemeral application database:
For details about the sslMode
options, go to the PostgreSQL SSL documentation.
To allow external access to the Ephemeral web application, set ingress.enable
to true
, then configure the ingress.
Different environments - such as Amazon Elastic Kubernetes Service (Amazon EKS), Google Kubernetes Engine (GKE), or Azure Kubernetes Service (AKS) - have different annotation options.
The following example shows the required options for GKE. For help with other environments, contact Tonic.ai support.
Ephemeral web server or API access might require specific annotations.
In the following example, the configuration ensures that GKE correctly recognizes https traffic.
To install Ephemeral:
helm install -n <your-namespace> ephemeral oci://quay.io/tonicai/ephemeral --version 1.<ephemeral-version>.0 -f values.yaml
To monitor the progress of the installation:
kubectl get all -n <your-namespace>
.
The ephemeral-web
pod should be in the running state.
If you enabled ingress, then to check the ingress state:
kubectl describe ingress/ephemeral-web -n <your-namespace>
The Address
field contains any expected external address. For example:
The Ephemeral web service should be accessible at http://<ingress-IP-address>
.
If you have specific requirements related to ingress or SSL, contact Tonic.ai support.
To upgrade to a newer version of Ephemeral:
helm upgrade -n <your-namespace> ephemeral oci://quay.io/tonicai/ephemeral --version 1.<ephemeral-version>.0 -f values.yaml
You can install a self-hosted instance of Ephemeral on your own Kubernetes cluster.
The access token to allow command line access to quay.io. To get the token, on the web console, go to Account Settings -> Generate Encrypted Password.
Connection details for the Ephemeral application database, a PostgreSQL database where Ephemeral stores configuration data. When you install Ephemeral, the database must be empty. For details, go to .
Used to configure external access to the Ephemeral application. For details, go to .
Any specific annotations needed for web server or API access. For more information, go to .