Allocating Resources To Services

Efficient resource allocation is crucial for the stability and performance of services running within a Kubernetes environment like Thingshub. This document outlines how resources, primarily CPU and memory, are managed for Thingshub services, which are deployed as Kubernetes Pods.

Kubernetes utilizes the concepts of resource requests and limits to control resource consumption by containers. A request is the minimum amount of a resource that a container is guaranteed to receive, which is used by the Kubernetes scheduler to place the Pod on a suitable node. A limit is the maximum amount of a resource that a container is allowed to consume.

Exceeding a memory limit can lead to the container being terminated (OOMKilled), while exceeding a CPU limit will result in the container being throttled.

In the context of Thingshub, resource allocation can be managed at different levels depending on the service architecture.

Allocating Resources in Thingshub

Thub-Services With Single Container:

For Thingshub services that consist of a single container within a Kubernetes Pod:

Thingshub allows allocation of resources from the top level. This means that resource requests and limits configured for the Thingshub service are directly applied to the single container within its corresponding Kubernetes Pod.
In this case, the resources allocated to a thub-service will directly go to the container. The resource configuration for the Pod is effectively the resource configuration for its sole container.
Resource for a pod = resource for a container. The resource requests and limits defined for the Pod are inherited and enforced for the single container it contains.

YAML

global:
 ....
 
engine:
  resources:
    cpuRequest: XX
    cpuLimit: XX
    memoryRequest: XXMi
    memoryLimit: XXGi
    ephemeralStorageRequest: XX
    ephemeralStorageLimit: XX

Services (Pod) With Multiple Containers:

For Thingshub services that are structured as Kubernetes Pods containing multiple containers:

Thingshub allows the allocation of resources for each container. This provides finer-grained control over the resources consumed by each component within a multi-container service.
In this case, the resources need to be allocated to each container individually within the Thingshub service configuration.
Resources for a pod = the sum of resources of all the containers within the pod. The total resource requests and limits for a Pod with multiple containers are the sum of the individual resource requests and limits defined for each container within that Pod. Kubernetes ensures that the node where the Pod is scheduled can satisfy the sum of the resource requests of all its containers.
Currently, there are 3 thub-services that bring multiple containers. These are heavy-duty services that provide specific functionality and features.
- Business-Objects
  This service provides the features relating to the processing of business-critical data or to control your processes with your own fields and views through users' own custom fields, views and dependencies and meta infromation.
- Thingsflow
  This service provides the integration platform and interface for external services. The features provide users the ability to process and logically control the flow of data from the thingshub system to external systems and environments.
- Visualizer
  This service provides the dashboarding and visualization of IOT data present in the system.

When configuring these multi-container services in Thingshub, you will need to specify the desired CPU and memory requests and limits for each individual container composing the service.

YAML

global:
  ....
  

business_objects:
  resources:
      business_objects_engine:
        cpuRequest: XX
        cpuLimit: XX
        memoryRequest: XXMi
        memoryLimit: XXGi
        ephemeralStorageRequest: XX
        ephemeralStorageLimit: XX
        
      business_objects:
        cpuRequest: XX
        cpuLimit: XX
        memoryRequest: XXMi
        memoryLimit: XXGi
        ephemeralStorageRequest: XX
        ephemeralStorageLimit: XX
        
thingsflow:
  resources:
      thingsflow_engine:
        cpuRequest: XX
        cpuLimit: XX
        memoryRequest: XXMi
        memoryLimit: XXGi
        ephemeralStorageRequest: XX
        ephemeralStorageLimit: XX
        
      thingsfow_auth:
        cpuRequest: XX
        cpuLimit: XX
        memoryRequest: XXMi
        memoryLimit: XXGi
        ephemeralStorageRequest: XX
        ephemeralStorageLimit: XX
        
visualizer:
  resources:
      visualizer_engine:
        cpuRequest: XX
        cpuLimit: XX
        memoryRequest: XXMi
        memoryLimit: XXGi
        ephemeralStorageRequest: XX
        ephemeralStorageLimit: XX
        
      visualizer_auth:
        cpuRequest: XX
        cpuLimit: XX
        memoryRequest: XXMi
        memoryLimit: XXGi
        ephemeralStorageRequest: XX
        ephemeralStorageLimit: XX
        
        dashboards:
          cpuRequest: XX
          cpuLimit: XX
          memoryRequest: XXMi
          memoryLimit: XXGi
          ephemeralStorageRequest: XX
          ephemeralStorageLimit: XX

Default Resources for Thingshub Services

Thingshub provides default resource configurations for services and containers if no explicit resource requests or limits are specified. These defaults are pre-configured within Thingshub Helm Charts and provide the minimum resources to start a thub-service. Default resources ensure that services have a baseline allocation even if not explicitly configured, so that all the services and dependencies are up and running and the Thingshub System is Stable.

Business-Objects Engine:

YAML

resources:
  business_objects_engine:
   cpuLimit:  105m
   memoryLimit: 420Mi
   cpuRequest: 35m
   memoryRequest: 140Mi
   ephemeralStorageRequest: 10Mi
   ephemeralStorageLimit: 100Mi

Thingsflow Engine:

YAML

resources:
  thingsflow_engine:
    cpuLimit: 45m
    memoryLimit: 180Mi
    cpuRequest: 15m
    memoryRequest: 60Mi
    ephemeralStorageRequest: 10Mi
    ephemeralStorageLimit: 100Mi

Visualizer Engine:

YAML

resources:
  visualizer_engine:
    cpuLimit: 45m
    memoryLimit: 180Mi
    cpuRequest: 15m
    memoryRequest: 60Mi
    ephemeralStorageRequest: 10Mi
    ephemeralStorageLimit: 100Mi

Other Containers:

YAML

cpuRequest: 10m
cpuLimit: 700m
memoryRequest: 25Mi
memoryLimit: 200Mi
ephemeralStorageRequest: 10Mi
ephemeralStorageLimit: 100Mi

Checking Current Resource Usage

To monitor the actual resource consumption of your Thingshub services running on Kubernetes, you can use standard Kubernetes tools.

The kubectl top command is commonly used to view the current CPU and memory usage for Pods and containers.
- To check Pod usage:
  CODE
```
kubectl top pod <pod-name> -n <namespace>
```
- To check container usage within a Pod:
  CODE
```
kubectl top pod <pod-name> --containers -n <namespace>
```
- To check the container usage of all the Pods:
  CODE
```
kubectl get pod -n demo | awk 'NR>1 {print $1}' | xargs -I {} kubectl top pod {} --containers -n demo
```

By understanding and appropriately configuring resource requests and limits for your Thingshub services, you can ensure they have the necessary resources to operate reliably while contributing to the overall efficiency and stability of the Kubernetes cluster.