Configure parameters of portable services using ConfigMap

You can set limits and parameters for deploying microservices from portable services in modules using ConfigMap, a Kubernetes resource for working with configuration data. This allows you to:

  • Limit the dedicated resources.
  • Define the number of microservice instances that are deployed in Kubernetes, and configure their autoscaling.
  • Configure the distribution of microservice pods across cluster nodes in ConfigMap.
  • Pass Kubernetes secrets to portable services.
  • Configure a connection to the local image registry.

You can specify global settings for portable services configured in all modules of the system, as well as add individual settings for a specific service.

You can use ConfigMap for:

  • Fine tuning of microservice deployment. You can specify parameter values that are not available when editing a portable service in a module.
  • Changing settings without editing the module. It is useful for paid modules. For example, you can set the number of microservice instances because the parameter in ConfigMap is prioritized over the value set by the developer when creating the module.

To configure ConfigMap, do the following steps:

  1. Enable ConfigMap.
  2. Set parameters in ConfigMap.

Step 1: Enable ConfigMap

To use ConfigMap for configuration of portable services, enable the HUMMIX_BABYSITTER_ENABLE_CONFIGMAP_WATCHER environment variable for the babysitter service. To do this, make changes to the values-hummix.yaml configuration file:

  1. Create a backup copy of the values-hummix.yaml file filled in when installing HUMMIX. This is required before editing, as incorrect parameter settings may cause HUMMIX application malfunction.
  1. In the values-hummix.yaml configuration file, enable the following parameters:

global:
...
# Enable portable services
    managedServices:
        enabled: true
...
# ConfigMap use
        watchableConfigMap:
          enabled: true

  1. Update the HUMMIX application using the following command:

helm upgrade hummix ./hummix -f values-hummix.yaml --timeout=30m

After that, a file that stores ConfigMap parameters will be automatically created. It will be added to the namespace where the portable services are placed, which is hummix-applets by default. The file is preconfigured with a ConfigMap named hummix-babysitter-config. For correct operation, it is recommended to not change the default name.

Now you can set the parameters in ConfigMap.

To return to the default settings and start the configuration again, delete the cfg.yaml file and run the following command to regenerate it:

kubectl apply -f cfg.yaml -n hummix-applets

Where hummix-applets is the namespace for placing the portable services.

Step 2: Set parameters in ConfigMap

To change the settings:

  1. Run the command to open the ConfigMap file for editing:

kubectl edit configmap hummix-babysitter-config -n hummix-applets

Where:

  • hummix-babysitter-config is the name of the ConfigMap in the cfg.yaml file.
  • hummix-applets is the namespace that hosts the portable services.
  1. In the opened file, set:
  • Global parameters. They are applied by default to portable services in all modules. Set them in the global block.
  • Parameters for a particular service. To set them, add a block with the service name according to the template: {company}.ext_{id}.{unique_name} where:
    • company is the HUMMIX company code. You can find it in its URL address.
    • id is the identifier of the module where the portable service is configured. You can copy it from the URL address of the module in HUMMIX.
    • unique_name is the unique name of the portable service from the module settings.

Please note that parameter values from the block specific to a portable service have a higher priority than the global parameter values. If a parameter is not specified at the portable service level, the value from the global block is used.

ConfigMap example

apiVersion: v1
kind: ConfigMap
metadata:
  name: hummix-babysitter-config
  annotations:
    "helm.sh/resource-policy": keep
data:
   # Global settings
  global:
    replicaCount: 1
    nodeSelector: 
      role: hummix 
    tolerations:
      - effect: NoSchedule
        key: dedicated
        operator: Equal
        value: hummix
    autoscaling:
      enabled: true
      minReplicas: 1
      maxReplicas: 9
      targetMemoryUtilizationPercentage: 80
      targetCPUUtilizationPercentage: 80
    resources:
      requests:
        memory: "384Mi"
        cpu: "250m"
      limits:
        memory: "1024Mi"
        cpu: "1000m"
 
   # Settings for a particular service
   abcd12345efgh.ext_4a685c94-3dcd-433a-ac5f-6367aaf38950.portableservice:
    resources:
      requests:
        memory: "512Mi"
        cpu: "500m"
      limits:
        memory: "2048Mi"
        cpu: "1000m"
    image:
      repository: registry.example.com
      pullSecret:
        - "my-registry-secret"

Available parameters:

  1. Resources (resources):
  • requests are memory and CPU resources to be dedicated for the microservice.
  • limits is the maximum values of dedicated resources.

Read more about possible values of these parameters in the official Kubernetes documentation.

Example

Example

resources:
 requests:
   memory: "512Mi"
   cpu: "500m"
 limits:
   memory: "2048Mi"
   cpu: "1000m"

  1. Number of instances (replicaCount). How many pods to start for the microservice. Available values: 0-32k.

Example

Example

replicaCount: 4

  1. Autoscaling (autoscaling):
  • enabled enables autoscaling.
  • minReplicas is the minimum number of microservice instances. Available values: 0-32k.
  • maxReplicas is the maximum number of instances. Available values: 0-32k.
  • targetMemoryUtilizationPercentage is desired memory usage in percentage. Available values: 0-100.
  • targetCPUUtilizationPercentage is desired CPU resource utilization in percentage. Available values: 0-100.

Example

Example

autoscaling:
  enabled: true
  minReplicas: 1
  maxReplicas: 9
  targetMemoryUtilizationPercentage: 80
  targetCPUUtilizationPercentage: 80

  1. Select nodes for pod placement (nodeSelector). Configure microservices pods to be placed on specific cluster nodes using special tags.

Read more about using the parameter in the official Kubernetes documentation.

Example

Example

nodeSelector:
  role: hummix
  disk: ssd

  1. Tolerations for placing pods (tolerations). Set tolerations for microservice pods so that they can be placed on nodes with appropriate taints.

Example

Example

tolerations:
  - effect: NoSchedule
    key: dedicated
    operator: Equal
    value: monitoring

  1. Getting Kubernetes secrets (secretMappings). If you need to pass sensitive information to the portable service, e. g. a database connection string, first save it in a Kubernetes secret, and then specify the rule for getting it in the secretMappings parameter. For more information, see the Pass Kubernetes secrets to portable services using ConfigMap article.
  2. Path and secrets for the local image registry (image).  To run the portable service in an isolated environment without internet access, you must first download and save its Docker image to your local image registry. Then specify:
  • repository. The address of the local image registry. This allows you to replace the domain part of the image address specified in the module on the Services tab in the Docker container block.
  • pullSecret. The name of the secret containing the access keys to the local image registry if authentication is required to access them.

Example

Example

In the module on the Services tab, the following public Docker Hub address is specified: chialab/math-api. In the ConfigMap, you specified the following parameters:

image:
  repository: registry.example.com
  pullSecret:
    - "my-registry-secret"

As a result, the source of the image for deploying the microservice will be the local repository: registry.example.com/chialab/math-api.

  1. After making the changes, apply them using the command specifying the namespace that hosts the portable services:

kubectl apply -f cfg.yaml -n hummix-applets

The settings will be applied automatically as the babysitter service tracks changes in ConfigMap. All microservices for which the settings have changed will restart.

kubernetes-air-gap.html configmap-secrets.html