Suggested topologies for production clusters

Plan your production-grade Component Pack deployment according to your needs.

Designing for cost cutting

If you can afford cluster downtime, if you're still scalling the company and number of users, or if you're in an early adoption phase, and simply don't see yourself using a full-blown, 9-to-10-node cluster for setting and using Component Pack, that's fine! Here are some suggestions for those scenarios as well.

Table 1. Low-cost scenarios
Number of Concurrent Users	Cluster Layout
Up to 300	One master with at least 2 CPUs and 8G of RAM (m4.large) and at least two workers with 8 CPUs and 32G of RAM each (m4.2xlarge). For the sake of high availability, you can always add more masters. More than one master requires a load balancer in front of all the masters as an interface between the Connections and Kubernetes/Component Pack cluster.
Up to 1000	One master with at least 4 CPUs and 16G of RAM (m4.xlarge) and at least four workers, each with 8 CPUs and 32G of RAM (m4.2xlarge). Two of the four workers must be used exclusively for infrastructure pods. For the sake of high availability, you can always add more masters. More than one master requires a load balancer in front of all the masters as an interface between the Connections and Kubernetes/Component Pack cluster.
More than 1000	With careful monitoring of resource usage, you can plan on scaling your cluster by either adding more workers where needed or adding both masters and workers. For the sake of high availability, you can always add more masters. More than one master requires a load balancer in front of all the masters as an interface between the Connections and Kubernetes/Component Pack cluster.

Designing for load and growth

If you have a chance to design for proper growth and scaling, here are some suggestions for you, using a couple of more specialized AWS instances as examples for tuning different sides of the stack. However, note that there is no magic formula. You need to observe your cluster properly, apply best practices, and make your own decisions about when to scale and in which direction. Whatever way you go, be sure to update your quotas as well.

Table 2. Scalable scenarios
Number of Concurrent Users	Cluster Layout
Up to 1000	One front-end load balancer, pointing toward all three Kubernetes masters Three masters, 2 CPUs and 8G of RAM (m4.large) Three generic workers, 8CPUs and 32G of RAM (m4.2xlarge) Three infrastructure workers, 8CPUs and 32G of RAM (m4.2xlarge); disable scheduling for everything else (to be used exclusively for infrastructure containers) Here there is no need to optimize the network speed, communication to the storage (in AWS, a dedicated EBS bandwidth), and so on.
More than 1000	One front-end load balancer, pointing toward all the Kubernetes masters inside the cluster At least three masters, 4 CPUS and 16G of RAM (m4.xlarge) At least three generic workers, 8CPUs and 32G of RAM (m4.2xlarge) At least three infrastructure workers, 8CPUs and 32G of RAM (m5a.2xlarge, with improved network and EBS bandwidth)