EKS Reference Architecture Overview

Recommendations for High Availability

When installing MATRIXX Digital Commerce on EKS, the following recommendations help ensure high availability (HA) of MATRIXX components.

• Within each region, distribute the EKS control plane and worker nodes across at least 2 availability zones.
• Use at least two instances of EKS (two separate Kubernetes clusters) for Active and Standby MATRIXX Engines. Make sure that all of the worker nodes for an engine in a Kubernetes cluster are in the same availability zone. Use multiple EKS clusters to perform maintenance on a standby cluster using standard MATRIXX upgrade procedures.
• AWS region-wide outages are rare, but they do occur. They are usually localized to a single service, but they can affect all availability zones within a region. For maximum HA, deploy active and standby EKS clusters in different AWS regions to mitigate AWS region-wide outages.
• Set Kubernetes affinity rules to make sure pods of the same type are not all deployed to the same worker node, or to worker nodes in the same availability zone.

Kubernetes Cluster Management

Figure 1 shows deployment of applications to the EKS reference architecture by an administrator or using a CI/CD pipeline:

• EKS, managed by AWS, is deployed over multiple availability zones.
• EC2 worker nodes are deployed in an autoscaling group.
• Amazon S3 hosts Helm charts. These are manually populated with releases downloaded from Flexnet.
• AWS Codecommit stores the Helm values.yaml files with custom Helm configuration.
• Amazon Elastic Container Registry (ECR) stores MATRIXX Docker images. Application configuration and pricing is contained in sideloader Docker containers and added to ECR. The values.yaml file specifies Docker images and tags along with configuration and pricing data.
• Helm sends kubectl commands to EKS to deploy and configure the software.

Figure 1 shows nodes deployed in a single private subnet in each of two availability zones.

Deploy across two availability zones to ensure HA. Optionally, to increase security, use EKS and and kubectl commands to configure the EKS cluster such that the primary network interface of the nodes is in a separate subnet from the network used for the pods. Once the cluster is configured in this way, when MATRIXX Digital Commerce is installed following the normal procedures, Kubernetes allocates IP addresses correctly to the pods.

EKS clusters can span multiple availability zones. The diagram shows two separate EKS clusters running in different availability zones and/or regions, with the active engine in one cluster and the standby engines in others.