Pega nodes deployed into various tiers and services in a network topology

Pega applications and services are deployed by mapping Kubernetes objects with Pega Platform applications and services. Each tier of Pega nodes is built by using the same Pega Docker image, but they can be configured with unique parameters to allow for dedicated groups of nodes to be defined with unique node classifications, resource allocations, configurations, or scaling strategies.

By default, Pega deploys with three tiers of Pega nodes:

• Web – Includes nodes that are exposed to the load balancer using the “foreground” or “WebUser” type of node classification.
• Batch – Includes nodes that are not exposed by the load balancer, but are configured to handle background processing using the “background” type node classification. This tier handles workloads for BackgroundProcessing, ADM, Batch, RealTime, RTDG, Custom1, Custom2, Custom3, Custom4, Custom5, and BIX processing.
• Stream – Includes nodes that are configured to run an embedded Kafka service using the “stream” type node classification.

You can also customize the deployment of other services, including:

• Elasticsearch – Elasticsearch is required for the Pega Platform application’s search and reporting capabilities. The Pega Platform deployment includes this service by default using a customized Elasticsearch Docker image that includes all required plug-ins. To use your own pre-deployed Elasticsearch service, you must provide a URL to your service.
• Cassandra / DDS – A Cassandra deployment is required for applications that are built using the Decisioning and Marketing capabilities of Pega Platform. The included Helm chart will configure a standard Cassandra deployment using the publicly available image from DockerHub. If you do not want to deploy a new Cassandra instance, you can disable the setting; alternatively, to use your own predeployed Cassandra service, you can provide the location and security credentials of your service.
• Load Balancer – Use the Pega Addons chart to automatically deploy and configure a load balancer for your deployment. Pega Platform requires a load balancer or ingress for users and services to connect to the cluster. If to configure your own load balancer in your Kubernetes environment, you disable the Traefik deployment and add parameters to the Addons chart specific to your deployment. You can find more details about load balancer compatibility, including session affinity requirements in the Platform Support Guide. For your configuration options, see the Load Balancer section of the Addons Helm chart readme.
• EFK – Elasticsearch-Fluentd-Kibana is a standard logging stack that is provided as an example to help you get started. If your Kubernetes environment provides a logging stack, such as OpenShift or EKS, you can disable this deployment and use the native logging. For configuration options, see the Logging with Elasticsearch-Fluentd-Kibana (EFK) section of the Addons Helm chart readme.
  Note: This EFK stack is not used for Pega search nodes. A separate Elasticsearch deployment is used for search as described above.

Kubernetes objects used to orchestrate a Pega Platform deployment

The orchestration of the Pega Platform uses the following Kubernetes objects:

• Pod - A scalable unit of one or more containers with a specific configuration defined by a replica set. Pods are configured to use one of the Pega-provided Docker images which are detailed throughout this documentation, or a publicly available image in the case of some dependent services. Pega provides a Docker image for Web, Batch, and Stream Pega node types, and also an Elasticsearch Docker image to support Pega search nodes.

The Pega web and optional stream nodes are associated with an ingress and require external network configuration to allow user access. In particular, the Pega web nodes allow user access to the Pega Platform and all Pega applications installed. For DNS host name requirements, see Meeting requirements and prerequisites.

• Service - Defines a logical set of pods and a policy by which to access them. A deployment includes a definition of how services are exposed internally to other Kubernetes- managed resources or externally.
• ConfigMap - Manages configuration data that is injected into a container. You can use this object for XML-based configuration such as the Pega prconfig.xml file.
• Ingress - Manages external access to the services in a cluster to provide load balancing of the nodes across the deployment.

For information about these objects and managing your Docker images for pod configurations, see the Kubernetes documentation.

To support Kubernetes deployments of the Pega application and its required services, Pega provides configuration definitions for multiple tiers as defined with the following Kubernetes logical objects:

Kubernetes objects mapped to Pega nodes