# Installation on Kubernetes

# Infrastructure Requirements

These are the minimum infrastructure requirements to install Entando directly on a Kubernetes (K8s) cluster:

  • A working DNS server configured to resolve internal and external names. If you choose to configure K8s with a global wildcard domain name for the entire cluster, be sure it points to the public IP address of the external Load Balancer of the worker nodes.
  • A default Storage Class (opens new window) is needed for the Entando Operator to create the correct Persistent Volume Claims (PVC) for each pod.
  • Nginx Ingress-Controller (opens new window) is needed to expose the Entando applications.

# Minimum Hardware Requirements

The minimum hardware requirements depend on how you intend to use Entando. The more functionality you need, such as a content management system (CMS), the more you will need.

# For Entando install only:

  • 6 vCPU or virtual central processing unit (6000 millicores)
  • 6 GB of RAM
  • 5 GB of allocated storage distributed in many PVCs

Configure a single worker node with the requirements above or designate 3 worker nodes with the minimum of 2 PVC and 4 GB of RAM each.

# For Entando + Microservices:

  • 500 millicores per microservice or
  • 1000 millicores per microservice with a database

The tested instance was generated with a JHipster Entando blueprint.

# For Entando with CMS:

To install Entando with CMS, the hardware requirements depend on the complexity and number of pages and contents. The minimum requirements are:

  • 9 vCPU for a single CMS instance. To scale up, you need 4 vCPU per replica.
  • 8 GB of RAM for a single CMS instance. To scale up, you need 4 GB of RAM per replica.
  • A minimum of 50 GB of storage for all the static resources generated by the use of Entando CMS.

# Backup Strategies

The recommended method to secure your content is to use database services that automate backups and restores on a Kubernetes cluster like Azure, Red Hat OpenShift, Google K8s Service, Tanzu K8s Grid or Amazon Elastic. If this is not an option, there are tools like Velero (opens new window) and Cloudcase (opens new window) to manage them.

Note: Some DevOps teams warn against running databases inside pods in production environments.

If using the Entando CMS, be sure to protect related schemas (port and serv) with a valid disaster recovery plan. Protect all volumes containing your static resources with daily snapshots.

# Notes

See the Entando compatibility guide (opens new window) for compatible Kubernetes versions.

← Introduction →