CNE Kubernetes Ready: Architecture, Sizing, and Support Model

Kubernetes Ready deployments of Liferay DXP follow a consistent runtime architecture across OpenShift, EKS, GKE, AKS, on-premises clusters, and other CNCF-conformant platforms.

Review the reference architecture, sizing tiers, and support model before configuring a Kubernetes Ready environment.

Reference Architecture

Every Kubernetes Ready deployment follows the same core runtime topology inside Kubernetes. External traffic reaches the ingress layer, which routes requests to the liferay-default Service. The Service distributes traffic across the Liferay StatefulSet replicas.

The supporting services used by Liferay DXP, including the database, search engine, and object storage, run in different locations depending on your deployment model. These services run in the same Helm release for evaluation environments, in-cluster through separate operators, or as external managed services.

External traffic routes through ingress to clustered Liferay pods and backend services.

Sizing Tiers

Use these initial sizing tiers to plan your Kubernetes Ready environments. Validate all sizing choices with load testing against your content model, integrations, and traffic patterns before promoting environments to production.

Property	Dev / Sandbox	Small	Medium	Large
Use case	Dev and QA	Light production	Standard production	Large production workloads
Concurrent users	Up to 50	Up to 500	Up to 5,000	5,000+
Liferay pod replicas	1	2	3	5+ with autoscaling
Per-pod CPU	2000m → 4000m	2000m → 4000m	4000m → 8000m	8000m → 16000m
Per-pod memory	8 GiB → 12 GiB	12 GiB → 16 GiB	16 GiB → 24 GiB	24 GiB → 32 GiB
JVM heap (`-Xmx`)	4 GiB	6 GiB	12 GiB	16 GiB
PVC per pod	5 GiB	20 GiB	50 GiB	100 GiB+
Database	Small single node	HA managed service	HA managed service	Multi-region architecture
Search topology	Single node	3 nodes	3 nodes	5+ nodes
Object storage	PVC	Bucket	Bucket	Replicated bucket
Autoscaling	Off	Off	HPA	KEDA / advanced scaling

Clustering and Autoscaling

For multi-replica deployments, the chart activates Tomcat session replication and Liferay cluster communication through the headless Service automatically.

This template sets your base replica configurations:

replicaCount: 3

Production environments use Horizontal Pod Autoscaler (HPA) or KEDA to scale replicas dynamically.

This template activates the autoscaler engine:

autoscaling:
   enabled: true
   type: hpa

When using KEDA, configure access to the in-cluster Prometheus endpoint so your autoscaler evaluates the metrics exposed by the built-in JMX Prometheus exporter.

Operational Responsibilities and Support Boundaries

Kubernetes Ready is a self-managed deployment model. Liferay supports the liferay-default Helm chart and the Liferay DXP container image. Your team manages the Kubernetes platform and its supporting services.

Customer Responsibilities

Your team handles these specific tasks:

Capacity planning and disaster recovery procedures
Database provisioning, scaling, and backups
GitOps pipelines and continuous delivery workflows
Ingress, TLS termination, DNS, and networking architectures
Kubernetes cluster operations and upgrades
Monitoring, logging infrastructure, alerting, and observability setups
Object storage configuration
Search cluster provisioning and ongoing maintenance
Secrets management and credential rotation routines

Supported Configurations

For a deployment to qualify as a supported Kubernetes Ready configuration, you must satisfy these conditions:

The Liferay DXP image version matches an entry in the compatibility matrix.
The liferay-default chart version supports the deployed DXP version.
The Kubernetes server version is within the upstream Kubernetes support window.
The configured database and search engine versions match the requirements listed in the Liferay DXP documentation.
Resource requests and limits meet or exceed the values in the small sizing tier.
The chart security contexts remain unchanged or become more restrictive.

Information to Include in Support Cases

Include these resources when opening support cases for Kubernetes Ready deployments:

Database and search engine topology details
Effective Helm values files
Helm chart version
Kubernetes server version
Logs from the affected liferay-default-* pods
Rendered deployment manifests
StatefulSet-deployed container image tags and digests
StatefulSet and pod resource descriptions

When Kubernetes Ready Is Not the Right Fit

Kubernetes Ready is designed for teams that operate Kubernetes platforms and supporting infrastructure services.

If your team requires Liferay-managed infrastructure provisioning and platform automation, use one of the managed Cloud Native Experience deployment paths instead:

Capability: