Author: Benjamin Wende
Reviewer: Torsten Wilms
Introduction
With IBM Business Teams Service (BTS) release 3.17.0, a new feature called Deployment Profiles is introduced. These pre-defined sets of pod replica count and Kubernetes resource requests and limits enable easy scaling of BTS and it's database pods. Further it is now possible to manually scale BTS by using replica count and resources.
The following chapters shows how to exploit the new feature using the BTS Custom Resource in Openshift.
Built-in Deployment Profiles and Sizes
BTS 3.17.0 introduces built-in Deployment Profiles using new properties in the BTS Custom Resource. The new properties deploymentProfile and deploymentProfileSize can be used to scale BTS without the need to further learn about Kubernetes resources and replicas. The built-in profiles were determined using sophisticated performance profiling and measurements.
The table shows the new properties and their values:
|
Property
|
Values
|
Notes
|
|
spec.deploymentProfile
|
Starter, Production
|
Starter not supported for production deployments
|
|
spec.deploymentProfileSize
|
Small, Medium, Large
|
Not available for Starter
|
Note: The values are case-insensitive, so production or Production means the same.
Below is an example of a BTS Custom Resource that contains the new properties:
apiVersion: operator.ibm.com/v1alpha1
kind: BusinessTeamsService
metadata:
name: bts
namespace: cp4ba
spec:
deploymentProfile: Production
deploymentProfileSize: Medium
The presence of these properties has an impact on the BTS deployment. The BTS-Operator will deploy the BTS and PostgreSQL pods requesting a certain amount of CPU and Memory, as well different limits for these resources.
Further the it affects the number of pods that get deployed, the so called replica count. Requests to the BTS pods get distributed round-robin via the Kubernetes service. In contrast, the requests to the PostgreSQL database pods only ready the primary pod. All further pods are secondaries and will be used only if the primary experiences a service interruption.
The tables below describes this in detail:
Replica Count
|
Deployment Profile / Size
|
BTS Replica Count
|
DB Replica Count
|
|
Starter - n/a
|
1
|
1
|
|
Production - Small
|
2
|
2
|
|
Production - Medium
|
3
|
2
|
|
Production - Large
|
4
|
2
|
BTS CPU and Memory
|
Deployment Profile / Size
|
BTS Requests
|
BTS Limits
|
|
Starter - n/a
|
150m / 256Mi
|
500m / 512Mi
|
|
Production - Small
|
100m / 256Mi
|
400m / 512Mi
|
|
Production - Medium
|
100m / 256Mi
|
400m / 512Mi
|
|
Production - Large
|
100m / 256Mi
|
400m / 512Mi
|
PostgreSQL CPU and Memory
|
Deployment Profile / Size
|
DB Requests
|
DB Limits
|
|
Starter - n/a
|
50m / 768Mi
|
100m / 1Gi
|
|
Production - Small
|
50m / 768Mi
|
200m / 1Gi
|
|
Production - Medium
|
100m / 768Mi
|
300m / 2Gi
|
|
Production - Large
|
200m / 768Mi
|
400m / 3Gi
|
Note that CPU requests and limits are given in Milli-CPUs (e.g. 100m means 1/10th of a CPU core) and Memory either in Mi or Gi, which stands for Megabyte or Gigabyte). All resource requests and limits are per pod. More information can be found in the Kubernetes documentation [1].
As you can see, the BTS pods scale mainly with their Replica Count, while the PostgreSQL database pods scale through increase in CPU and Memory.
Custom scaling using Replicas and Resources
When it comes to scenarios where the built-in Deployment Profiles do not match the requirements anymore, it can be an option to manually scale BTS using Replica Counts and Resource Requests and Limits.
It is possible to assign Replica Counts and Resource Requests and Limits using properties in the BTS Custom Resource. It is also possible to use these custom values together with the built-in Deployment Profiles. In this case the explicitly assigned value will overwrite the respective value from the Deployment Profile. For example it is possible to increase the replicas of the database to 3, while retaining the Production / Small Deployment Profile and Size values for all other values.
The table below contains the properties for Replicas and Resources:
|
Property
|
Example Value
|
Notes
|
|
spec.replicas
|
2
|
Requests are distributed round-robin to all pods.
|
|
spec.replicasDatabase
|
3
|
Requests are sent to the one primary pod, secondary pods are used if the primary experiences a service interruption.
|
|
spec.resources
|
resources:
requests:
cpu: 300m
memory: 512Mi
limits:
cpu: 1000m
memory: 1024Mi
|
resources consists of:
resources.requests.cpu
resources.requests.memory
resources.limits.cpu
resources.limits.memory
|
|
spec.resourcesPostgres
|
resourcesPostgres:
requests:
cpu: 100m
memory: 512Mi
limits:
cpu: 500m
memory: 2Gi
|
resourcesPostgres consists of:
resourcesPostgres.requests.cpu
resourcesPostgres.requests.memory
resourcesPostgres.limits.cpu
resourcesPostgres.limits.memory
|
Below is an example of a BTS Custom Resource that contains a combination of Deployment Profile and explicit resources for the database pods:
apiVersion: operator.ibm.com/v1alpha1
kind: BusinessTeamsService
metadata:
name: bts
namespace: cp4ba
spec:
deploymentProfile: Production
deploymentProfileSize: Medium
replicasDatabase: 3
resourcesPostgres:
requests:
cpu: 100m
memory: 512Mi
limits:
cpu: 500m
memory: 2Gi
Reference
#Kubernetes#RedHat#Openshift