Pod Scaling

We provide scaling possibilities with the help of KEDA - Kubernetes Event-driven Autoscaling.
Keda is installed as a managed service and can be used from each project manager without including the NEXT team.

How to use Keda in NEXT

You have to deploy your application which has to be scaled as a Deployment. Here the spec.replicas properties sets the default number of pods after the deployment

apiVersion: apps/v1
kind: Deployment
metadata:
    name: my-app
    labels:
        app: my-app
spec:
    replicas: 1
    selector:
        matchLabels:
            app: my-app
    template:
        metadata:
            labels:
                app: my-app
        spec:
            containers:
                - name: my-app
                  image: cir.endress.com/eh-xy-team/my-app
                  env:
                      - name: MY_ENV_1
                        value: 'my-env-value-1'
                      - name: MY_ENV_FROM_SECRET_1
                        valueFrom:
                            secretKeyRef:
                                key: my-key
                                name: keyvault-project

now you have to deploy another object of the type keda.sh/v1alpha1 ScaledObject

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
    name: my-app-scaled-object
spec:
    scaleTargetRef:
        name: my-app # needs to match the name of the corresponding deployment
    pollingInterval: 30 # Optional. Default: 30 seconds
    cooldownPeriod: 300 # Optional. Default: 300 seconds
    initialCooldownPeriod: 0 # Optional. Default: 0 seconds
    minReplicaCount: 0 # Optional. Default: 0
    maxReplicaCount: 1 # Optional. Default: 100
    triggers:
        - type: ...

The spec.scaleTargetRef.name has to match the name of the deployment. The other properties can be set as needed. For more information about the different properties or other possibilities please read the documentation or if you have any questions, feel free to contact us.

PLease be aware that you set the MaxReplicaCount to a number which allows all your pods to be started regarding the resources assigned to your project. If you are trying to use more resources your pods may not be started or other unwanted side effects may happen.

Scalers

The triggers in the example above can be one scaler or a list of scalers provided by Keda. To have an overview about the different possibilities you can check the complete list here

How to use scaling based on Kafka consumer lag

If you are using a Kafka consumer in your application, and you want to scale based on the kafka consumer lag, here is an example how this can be solved :

... # see example above
triggers:
    - type: kafka
      metadata:
          bootstrapServers: '[url to bootstrapservers - manually to add from external secrets]'
          sasl: 'plaintext' # fix for NEXT Kafka instance
          tls: 'enable' # fix for NEXT Kafka instance
          consumerGroup: 'myConsumerGroup' # has to match the consumerGroup used by the application
          topic: 'myTopic' # has to match the topic used by the application
          lagThreshold: '1' # consumer lag threshold when to scale
          offsetResetPolicy: 'earliest' # has to match the offsetResetPolicy of the application
      authenticationRef:
          name: my-app-trigger-auth

In this example, we have a 0 -> 1 scaling for infrequent messages where the service is idling most of the time. This is the reason, we are using this lagThreshold of 1, which scales the replicas to 1, when there is an unhandled message.

For other requirements, where there is regular traffic, the lagThreshold should be set to a number, one service can no more handle.
For example, if you know, that one service can handle normally 50 (and not more) unhandled messages, the threshold should be 50.
This configuration will scale up the number of replicas with an increasing consumer lag based on a “per-replica threshold”.

Example based on minReplicaCount=1, maxReplicaCount=10, lagThreshold=50

Kafka Lag	Calculated Replicas	Actual Replicas (bounded by min/max , but also # of partitions)
0–50	1	1 (minReplicaCount)
50-100	2	2
100–150	3	3
…	…	…
450–500	10	10 (maxReplicaCount)
>500	11+	10 (capped at maxReplicaCount)

More information about different configuration properties can be found here.

The bootstrapServer endpoint configuration can be found in your kubernetes secret.

Kafka credentials for trigger

Please be aware to not store any credentials directly into the deployment files.

For assigning secrets to the different triggers, you can use different Authentication Providers provided by Keda. The complete list of providers can be found here.

To use the already provided Kafka credentials from Kubernetes secrets you can use a deployment like this :

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
    name: my-app-trigger-auth # has to match the authenticationRef.name property of the ScaledObject
spec:
    secretTargetRef:
        - parameter: username
          name: keyvault-project
          key: confluent-sa-project-key
        - parameter: password
          name: keyvault-project
          key: confluent-sa-project-secret