"value": "-Xms3072m -Xmx3072m" } ], "name": "es-data", "resources": { "limits": {  "memory": "6144M" } } } ] } } } }' Example 5-14 kubectl patch for Elasticsearch master node kubectl -n kube-system patch deployment logging-elk-master --patch '{ "spec": {  "template": { "spec": { "containers": [ { "env": [ { "name": "ES_JAVA_OPTS",  "value": "-Xms2048m -Xmx2048m" } ], "name": "es-master", "resources": { "limits":  { "memory": "4096M" } } } ] } } } }' These commands are sufficient to scale the containers vertically, but not horizontally. Due to  the cluster settings being integrated in to the Elasticsearch configuration, you cannot simply  add and remove master or data nodes using standard Kubernetes capabilities such as the  HorizontalPodAutoscaling resource.  Using kubectl patch should be used for testing to find a suitable value. Updating the logging  resources in this way will not persist during chart or IBM Cloud Private upgrades. Permanent  configuration changes can only be made using  helm upgrade . To update the JVM and  container memory for the data nodes, for example, run the upgrade: Scaling an Elasticsearch node in IBM Cloud Private entirely depends on the type of node, the  volume of logs and the performance of the Elasticsearch cluster against the logs generated.  Sending thousands of smaller, simple log messages per second may have a different impact  than a fewer number of larger log messages, so the data nodes may perform differently when  configured as several smaller nodes or a few larger nodes. What works best in an  environment generally comes down to experience by tuning the Elasticsearch cluster against  your workloads to find which configuration provides the best performance for the type of log  data the deployed applications are producing. Consider the following scenarios if a banking  application is sending thousands of transactions and transaction logs to Elasticsearch every  second: With the above in mind it’s important to be able to scale the components as and when it is  required. helm upgrade logging ibm-icplogging-2.2.0.tgz --reuse-values --set  elasticsearch.data.heapSize="3072m" --set elasticsearch.data.memoryLimit="6144Mi"  --force --no-hooks --tls Scaling an Elasticsearch cluster GLYPH<SM590000> Logstash may be the bottle neck (assuming the host network can handle this volume of  traffic anyway) and will require either more memory or additional replicas deployed to meet  the high demand. GLYPH<SM590000> if the transaction data generated is a very large data set with lots of fields, then the data  node may be the bottle neck as it has to index such a large volume of data, so additional  memory or even additional data nodes may be required.  GLYPH<SM590000> Logstash may also struggle with low resources and large volumes of JSON formatted  data, as it will parse the JSON and bring fields to the root level. GLYPH<SM590000> As the master node is responsible for tracking which data nodes all the documents are  stored on, thousands of logs means the master node has to track thousands of documents  which can be difficult to achieve without enough memory and CPU. GLYPH<SM590000> When querying the stored data, the client node has to parse the potentially complex or  time-based lucene query and lack of memory can result in request timeouts. GLYPH<SM590000> Logstash and client pods - increase the number of replicas by using Helm: Chapter 5. Logging and monitoring  175