You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by nf...@apache.org on 2022/01/21 14:49:55 UTC

[camel-website] branch keda-blog updated (dcdc847 -> 25c090a)

This is an automated email from the ASF dual-hosted git repository.

nferraro pushed a change to branch keda-blog
in repository https://gitbox.apache.org/repos/asf/camel-website.git.


 discard dcdc847  Blogpost about Keda
     new 25c090a  Blogpost about Keda

This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version.  This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:

 * -- * -- B -- O -- O -- O   (dcdc847)
            \
             N -- N -- N   refs/heads/keda-blog (25c090a)

You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.

Any revisions marked "omit" are not gone; other references still
refer to them.  Any revisions marked "discard" are gone forever.

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 content/blog/2022/01/camel-keda/index.md | 2 ++
 1 file changed, 2 insertions(+)

[camel-website] 01/01: Blogpost about Keda

Posted by nf...@apache.org.
This is an automated email from the ASF dual-hosted git repository.

nferraro pushed a commit to branch keda-blog
in repository https://gitbox.apache.org/repos/asf/camel-website.git

commit 25c090aa5ac04dcf29ac71815b2fdfe86110fcd2
Author: nicolaferraro <ni...@gmail.com>
AuthorDate: Fri Jan 21 15:49:26 2022 +0100

    Blogpost about Keda
---
 content/blog/2022/01/camel-keda/featured.png | Bin 0 -> 54313 bytes
 content/blog/2022/01/camel-keda/index.md     |  69 +++++++++++++++++++++++++++
 2 files changed, 69 insertions(+)

diff --git a/content/blog/2022/01/camel-keda/featured.png b/content/blog/2022/01/camel-keda/featured.png
new file mode 100644
index 0000000..4992f1f
Binary files /dev/null and b/content/blog/2022/01/camel-keda/featured.png differ
diff --git a/content/blog/2022/01/camel-keda/index.md b/content/blog/2022/01/camel-keda/index.md
new file mode 100644
index 0000000..efff5fd
--- /dev/null
+++ b/content/blog/2022/01/camel-keda/index.md
@@ -0,0 +1,69 @@
+---
+title: "Camel meets KEDA"
+date: 2022-01-21
+authors: [nicolaferraro]
+categories: ["Camel K"]
+preview: "Camel K integrations can leverage KEDA to scale based on the number of incoming events"
+---
+
+NOTE: this post has first appeared [in the author's blog](https://www.nicolaferraro.me/2022/01/21/camel-meets-keda/).
+
+[KEDA](https://keda.sh) (Kubernetes Event Driven Autoscalers) is a fantastic project (currently [CNCF](https://cncf.io) incubating) that provides Kubernetes-based autoscalers to help applications to scale out according to the number of incoming events when they are listening to several kinds of event sources. In Camel K we've long supported [Knative](https://knative.dev) for providing a similar functionality for integrations that are triggered by HTTP calls, so supporting KEDA was someth [...]
+
+## Why KEDA and Camel K?
+
+Users may want to set up integrations that automatically scale, e.g. depending on the **number of messages left in a Kafka topic** (for their consumer group). The integration code may do e.g. transformations, aggregations and send data do a destination and it would be great if the number of instances deployed to a Kubernetes cluster could increase when there's work left behind, or they can **scale to zero** when there's no more data in the topic.
+This is what KEDA does by itself with scalers (Kafka is [one of the many scalers available in KEDA](https://keda.sh/docs/2.5/scalers/)). What you have now is that KEDA is now automatically configured by Camel K when you run integrations, so you get the autoscaling features out of the box (you just need to turn a flag on).
+
+## How does it work?
+
+In Camel K 1.8.0 a new [KEDA trait](/camel-k/next/traits/keda.html) has been introduced. 
+The trait allows to manually tweak the KEDA configuration to make sure that some *ScaledObjects* (KEDA concept) are generated as part of the *Integration* reconciliation, but this is mostly an internal detail. The interesting part about the KEDA trait is that it can recognize special KEDA markers in Kamelets and automatically create a KEDA valid configuration when those Kamelets are used as sources. So users can just use Kamelets to create bindings as usual and, if they **enable a KEDA f [...]
+
+The Kamelet catalog embedded in next release ([v0.7.0](https://github.com/apache/camel-kamelets/tree/v0.7.0)) contains two Kamelets enhanced with KEDA metadata: `aws-sqs-source` and `kafka-source`. These are just two examples of the many Kamelets that can be augmented in the future. The metadata configuration system is open and Kamelets can be marked at any time to work with KEDA: this means that you don't need to wait for a new Camel K release to enable KEDA on a different source and, m [...]
+
+The Kamelet developer guide contains a new section on [how to mark a Kamelet with KEDA metadata](/camel-k/next/kamelets/kamelets-dev.html#_keda_integration), but essentially markers are used to map Kamelet properties into KEDA configuration options, so that when you provide a Kamelet configuration, the corresponding KEDA options can be generated from it (all the work is done under the cover by the Camel K operator).
+
+## A binding example
+
+Before looking at the demo, here's an example of **autoscaling binding** that you can create with the latest Camel K:
+
+```yaml
+apiVersion: camel.apache.org/v1alpha1
+kind: KameletBinding
+metadata:
+  name: kafka-to-sink
+  annotations:
+    trait.camel.apache.org/keda.enabled: "true"
+spec:
+  source:
+    ref:
+      apiVersion: camel.apache.org/v1alpha1
+      kind: Kamelet
+      name: kafka-source
+    properties:
+      bootstrapServers: "<-- bootstrap servers -->"
+      consumerGroup: my-group
+      topic: "<-- the topic -->"
+      user: "<-- user -->"
+      password: "<-- pwd -->"
+  sink:
+    # ...
+```
+
+You can notice that the only difference from a standard binding is the presence of the `trait.camel.apache.org/keda.enabled=true` annotation that enables the 
+KEDA trait in Camel K. The information about how to map Kamelet properties into KEDA options is encoded in the Kamelet definition.
+
+## Demo
+
+Time for the demonstration. You'll see both the `aws-sqs-source` and the `kafka-source` in action with Camel K and KEDA.
+
+The code for the demo is in the [nicolaferraro/camel-k-keda-demo](https://github.com/nicolaferraro/camel-k-keda-demo) repository on GitHub.
+
+You can watch the [demo on YouTube!](https://www.youtube.com/watch?v=z67ES6VAYV4)
+
+## Next steps
+
+There are many other Kamelets to enhance in [apache/camel-kamelets](https://github.com/apache/camel-kamelets) and things to improve in Camel K that are listed in the [area/KEDA](https://github.com/apache/camel-k/issues?q=is%3Aopen+is%3Aissue+label%3Aarea%2FKEDA) section of the issue tracker.
+
+Contributions are always welcome!