WakeUp Operator for Kubernetes

The WakeUp Operator dynamically scales Kubernetes applications when they do not need to process any request, and hence reduces cloud provider costs. The tool has been built on top of Kubernetes Operators API and runs natively on any Kubernetes or OpenShift cluster. WakeUp Operator listens for new messages published on configured messaging infrastructure and scales given application dynamically. Currently it supports TIBCO Enterprise Messaging Service and Apache Kafka, but new messaging solutions can be implemented depending on business needs of our customers.

Please do not hesitate to contact us at office@macronova.io to receive a free trial of the software.

Quick Start

The installation process of WakeUp Operator is quite simple - just import Docker image to your repository and create Kubernetes deployment.

$ docker load --input wakeup-operator.tar
$ kubectl apply -f operator.yaml

Deployment manifest configures service account and RBAC rules. Users may wish to update the last section that defines operators configuration parameters.

apiVersion: apps/v1
kind: Deployment
  name: wakeup-operator
  replicas: 1
      name: wakeup-operator
    type: Recreate
        name: wakeup-operator
      serviceAccountName: wakeup-operator
      - name: wakeup-operator
        image: macronova/wakeup-operator:latest
        imagePullPolicy: Never
          - name: WATCH_NAMESPACE
            value: "~"
            value: "60"
          - name: CONCURRENT_THREADS
            value: "5"
Configuration Parameters
FULL_RECONCILIATION_INTERVAL_S Delay (in seconds) between runs of check procedure
CONCURRENT_THREADS Number of threads that operator will use to process all defined checks in parallel
WATCH_NAMESPACE Kubernetes namespace in which Custom Resources are created (read further).
Use ~ for current namespace or * for all namespaces in the cluster

Let us now configure a monitor for sample JMS service, so that the application is started when message appears on queue.sample.v1 or queue.sample.v2. Technically speaking, we are going to create Kubernetes Custom Resource of type Wakeup, which is managed by the operator.

$ kubectl apply -f << EOF
apiVersion: com.supernova/v1
kind: Wakeup
  name: sample-jms-service-wakeup
  objectNamespace: default                                          # (1)
  objectName: sample-jms-service                                    # (2)
  objectKind: Deployment                                            # (3)
    serverUrl: tcp://server1:7222,tcp://server2:7223                # (4)
    username: wakeup-operator                                       # (5)
    password: "#!M6ZdnZrCvJhzdXO+vPD0AOfPTQrIZAxl"
    connectionProperties:                                           # (6)
      - key: com.tibco.tibjms.ssl.trusted_certs
        value: /path/to/trusted
      - key: com.tibco.tibjms.ssl.enable_verify_host
        value: false
      - key: com.tibco.tibjms.ssl.enable_verify_hostname
        value: false
    destinationNames: [ "queue.sample.v1", "queue.sample.v2" ]      # (7)

Key configuration properties:

  1. Kubernetes namespace of the application that needs to be scaled dynamically
  2. Name of the target application
  3. Type of target application. Use either Deployment, ReplicaSet or StatefulSet
  4. Address of TIBCO EMS servers
  5. Username and password used while connection to EMS. Password may be obfuscated using standard TIBCO utilities
  6. Custom connection properties. Useful while establishing SSL encrypted connection. SSL certificates need to be copied to new Docker image built based on macronova/wakeup-operator:latest.
  7. Array of JMS queues names that shall be monitored

Users may deal with batch workload. Operator allows to configure minimal number of records that consumer needs to lag before starting the application. In addition, we can also start multiple instances to process requests quicker.

$ kubectl apply -f << EOF
apiVersion: com.supernova/v1
kind: Wakeup
  name: sample-kafka-service-wakeup
  objectNamespace: default
  objectName: sample-kafka-service
  objectKind: Deployment
  messageThreshold: 1000                        # (1)
  instanceCount: 10                             # (2)
    clientProperties:                           # (3)
      - key: bootstrap.servers
        value: broker1:9092,broker2:9092
    topicNames: [ "topic1", "topic2" ]          # (4)
    consumerGroupId: "group1"                   # (5)

Key configuration properties:

  1. Minimal number of records that consumer group must lag on topic to scale up given application
  2. Number of instances to scale the deployment
  3. Standard Kafka client connection properties
  4. List of topics to monitor
  5. Identifier of the consumer group which lag should be monitored

Please visit our blog post for a complete demo of WakeUp Operator.