Itential provides Helm charts for deploying Platform on Kubernetes. This page covers prerequisites, node sizing, secrets management, Helm chart architecture, adapter delivery, and validated configurations for Amazon EKS and Azure AKS.
Itential Helm charts install Platform and IAG only — not their dependencies. You must provide MongoDB and Redis separately. Neither Memcache nor MySQL can substitute for these dependencies.
Platform requires significant resources to run production automations. Requirements vary based on automation rate, complexity, and the number of adapters.
Development environments often have similar resource needs to production because engineers experiment with real automations in development. Avoid undersizing development environments.
If you are starting fresh with Itential, begin with minimum specifications and scale as needed. If you are an existing Itential customer migrating to Kubernetes, match your current resource specifications.
The instance types above are starting points. As production usage reveals your automation patterns, you may shift to memory-optimized (r5a) or general-purpose (m5a) instance types on AWS.
Schedule StatefulSet containers on dedicated nodes in separate availability zones, with one Platform pod per node. This provides continuity if an availability zone experiences an outage.
Manage secrets outside Kubernetes and inject them at deploy time using your preferred secrets management method. Three types of secrets are required before deploying.
Create an image pull secret to authenticate with your container registry. For AWS deployments, Platform images are hosted in Amazon ECR — configure credentials for an ECR-enabled account. This secret must exist in the cluster before deploying Itential applications.
If TLS is enabled, create a secret named itential-ca containing the TLS Certificate Authority (CA) certificate. This CA is used to generate all other TLS certificates used by Itential applications. This secret must exist in the cluster before deploying with TLS enabled.
Each Itential application (Platform, IAG4, IAG5) requires application-specific secrets including encryption keys, database passwords, and other sensitive configuration values. These secrets must exist in the cluster before deploying. For the required structure of each application’s secrets object, refer to the Itential Helm charts documentation.
Itential provides Helm charts for three products:
The following diagram shows the architecture of the Itential Kubernetes environment:
The Ingress provides external cluster access and supports a static hostname. It contains load balancer configuration and routing rules. ExternalDNS synchronizes exposed Services and Ingresses with your DNS provider automatically. While not required, it removes the need to manage DNS records manually.
Two services are created per application:
Platform runs as a StatefulSet to maintain predictable pod names and persistent volume mounts across restarts.
When TLS is enabled (useTLS: true in Helm values), the chart uses a CA stored in your cluster to generate certificates through a Kubernetes Issuer. The issued certificates are stored in a Secret that pods mount at runtime. Adding the CA to the cluster is outside the scope of this guide.
If cert-manager is unavailable, add TLS certificates manually in a secret named <Chart.name>-tls-secret with these keys:
If you use persistent volumes for adapters, a StorageClass is required to provision storage automatically. It defines the storage type to create (such as AWS EBS or Azure Managed Disks) and creates disk volumes when pods request storage.
Do not use EFS or NFS volumes. These volume types introduce application latency.
Start with 10 GB of disk space and adjust based on the number of adapters deployed.
Adapters can be delivered to your Kubernetes deployment using two methods: persistent volumes or layered containers.
Use persistent volumes if you:
Use layered containers if you:
Store adapters on a persistent disk volume that is mounted into the container at runtime.
/opt/itential/platform/services/custom.When you update files on the volume, restart the affected adapter from the Itential Platform UI or API — a full container restart is not required.
Use dedicated volumes per container. Shared volumes reduce performance.
Build adapters directly into the container image.
Itential has validated Kubernetes deployments on the following providers:
Contact Itential for information about additional providers.
Amazon EKS manages the Kubernetes control plane. You maintain only the VMs needed to run pods.
Two ingress controllers are supported on EKS:
These annotations configure the ALB to use HTTPS for backend traffic, check application health every 15 seconds, enable WebSocket support, and maintain session stickiness for one hour. Adjust timeouts, health check intervals, and other values to match your deployment.
If using persistent volumes for adapters, configure your StorageClass to use ebs.csi.aws.com as the provisioner.
Azure AKS manages the Kubernetes control plane. You maintain only the pods and Kubernetes components.
The validated design for AKS uses the NGINX Ingress Controller behind an Azure Load Balancer.
These annotations configure NGINX to use HTTPS for backend traffic, enable WebSocket support with one-hour timeouts, force SSL redirects, and attach an internet-facing Azure Load Balancer. Adjust SSL settings, timeouts, and load balancer type to match your deployment.
If using persistent volumes for adapters, configure your StorageClass to use disk.csi.azure.com as the provisioner.