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 email@example.com to receive a free trial of the software.
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 metadata: name: wakeup-operator spec: replicas: 1 selector: matchLabels: name: wakeup-operator strategy: type: Recreate template: metadata: labels: name: wakeup-operator spec: serviceAccountName: wakeup-operator containers: - name: wakeup-operator image: macronova/wakeup-operator:latest imagePullPolicy: Never env: - name: WATCH_NAMESPACE value: "~" - name: FULL_RECONCILIATION_INTERVAL_S value: "60" - name: CONCURRENT_THREADS value: "5"
||Delay (in seconds) between runs of check procedure|
||Number of threads that operator will use to process all defined checks in parallel|
||Kubernetes namespace in which Custom Resources are created (read further).
Let us now configure a monitor for sample JMS service, so that the application is started when message appears on
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 metadata: name: sample-jms-service-wakeup spec: objectNamespace: default # (1) objectName: sample-jms-service # (2) objectKind: Deployment # (3) emsTrigger: 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) EOF
Key configuration properties:
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 metadata: name: sample-kafka-service-wakeup spec: objectNamespace: default objectName: sample-kafka-service objectKind: Deployment messageThreshold: 1000 # (1) instanceCount: 10 # (2) kafkaTrigger: clientProperties: # (3) - key: bootstrap.servers value: broker1:9092,broker2:9092 topicNames: [ "topic1", "topic2" ] # (4) consumerGroupId: "group1" # (5) EOF
Key configuration properties:
Please visit our blog post for a complete demo of WakeUp Operator.