© Charles Theodore Frere Apache Camel community is happy to announce the general availability of Camel K 2.5.0. In this release you will find several new features, fixes and a few deprecations that will simplify the project management in the long run. Default Runtime Let’s start highlighting the default runtime we are using in this release. The default is Camel K Runtime version 3.15.0 which is based on Camel Quarkus 3.
© Seattle Art Museum Apache Camel community is happy to announce the general availability of Camel K 2.4.0. We have released many new features and several works aimed to have a stable version, above all when using the so called “Sourceless” Integrations. Default security settings The first important change we’ve introduced is the default setting of security configuration in Kubernetes (SecurityContext). We’ve worked to introduce this both in the operator and in every application deployed after your Integration.
© Sir John Soane’s Museum London Apache Camel community is happy to announce the general availability of Camel K 2.3.0. This release version contains several fix which are increasing the operator stability and a few hidden changes which are making the software more modular, therefore future feature development quicker and independent from the Camel runtime chosen. First of all, we have changed the default runtime to Camel K Runtime version 3.
In the last 2.2.0 version release, Camel K added an interesting feature that gave the users the possibility to build their Camel application externally and run via the operator with certain limitations. In this blog we’re trying to analyze those limitations and provide some example that will show you how to possibly leverage this feature. What is a “sourceless” Integration? With a great effort of creativity (sarcasm), we have named this feature as “sourceless” Integration.
Apache Camel community is happy to announce the general availability of Camel K 2.2.0. This release has slipped finally in 2024 but here we are with a lot of new exciting developments. Enable source less Integrations This is the first step to onboard any Camel runtime. You may already have a process that build your application and containerize it in a container registry. From now on you can reference such container and use the operator to start that application without requiring the Integration to contain the source code:
Apache Camel community is happy to announce the general availability of Camel K 2.1. We have worked on the introduction of a lot of new exciting feature that will further simplify the deployment and management of Camel application on Kubernetes. Let’s see what you should expect from this release. Default Camel 4 runtime As Camel 4 is out since some time already, we’ve moved our default runtime to Camel K Runtime version 3.
This blog announce the availability of Camel K Runtime version 3.2.0 which will gives you the possibility to run Camel 4 workloads on Kubernetes with Camel K. Release details Apache Camel K Runtime 3.2.0 Apache Camel Quarkus 3.2.0 Apache Camel 4.0.0 How to run Camel 4 with Camel K If you are on Camel K 2.0, this is quite straightforward. If you recall, one of the major feature of version 2 is the ability to run any Camel K runtime.
We already explained how to take monitor your Integrations in the previous blog post about monitoring operations on Camel K. The good news is there are only a few changes with the move to Micrometer Metrics. From Microprofile to Micrometer Camel K 2.0 was the occasion to move from one technology (Microprofile) to another (Micrometer) for the Prometheus trait configuration implementation. The reason is the deprecation notice from Quarkus Microprile’s implementation in favor of using Micrometer Metrics.
© 2023, RoadTrafficSigns.com With a great level of excitement, on behalf of Apache Camel community, I’m proud to announce the general availability of Camel K 2.0. It’s been a long ride since the beginning of 2023 when we announced the desire to work on an heavy refactoring in order to introduce new shining features and be able to run the future Camel 4 runtimes. This is the first important milestone reached, and we thought that the work done so far is already mature to see general availability.
In this blog post we’ll be talking about GitOps and we’ll provide some approach that we hope can help you understand better how you can do such kind of operations togheter with Camel K. As we’re talking about processes, all the discussion we’re going to provide can be different in each company, environment and according the set of tools you’re using. The idea of the blog is to show the possibilities offered by Camel K in order to help you understand better how you can adapt your own tools and process to Camel K deployment model.
One of the main effort we’re putting in Camel K version 2 is to have a enterprise grade building system. Not that Camel K version 1 has not this capability, but some of the key features are not very explicit. So I thought that, while waiting for Camel K version 2 release, where we’re making all this configuration explicit, I can share some tip on how to improve the capacity to build and have a production enterprise ready environment also in Camel K 1.
Tracing is an important approach for controlling and monitoring the experience of users, it allows us to gather more information about an integration’s performance. Camel K has been providing support for distributed tracing using OpenTracing since long time. At the beginning of 2022, the CNCF announced that they were archiving the OpenTracing project in favor of the OpenTelemetry project. OpenTelemetry is the latest solution created by merging OpenTracing and OpenCensus. As a result, we decided in Camel K 1.
Image (c): Camel Vectors by Vecteezy Although we’re already in Camel K 2.0 mode, we had not forgotten to bring new fresh features on version 1. Camel K 1.12.0 has just been released and it brings a lot of new interesting upgrades and features. This may be the last release of Camel K 1 major version as we aim to have a release of Camel K 2 during half of this year.
Signpost png from pngtree.com/ We’re in 2023 since a while (just if nobody has noticed yet…) and we’ve taken the month of January to think about how to move Camel K development forward. We had a very good discussion about the new features we’d like to see during this year and this blog is trying to resume those ideas collected. I am going to do my best to resume everybody’s comments in a shared view in order to inspire any contributor to understand the direction we’re willing to take.
This post describes the steps to test a Camel K integration with YAKS both locally and on the Kubernetes platform. What is YAKS? YAKS is an Open Source test automation platform that leverages Behavior Driven Development concepts for running tests locally and on Cloud infrastructure (e.g. Kubernetes or OpenShift). This means that the testing tool is able to run your tests both as local tests and natively on Kubernetes. The framework is specifically designed to verify Serverless and Microservice applications and aims for integration testing with the application under test up and running in a production-like environment.
(c) @TivadarDanka 2023 has come, and with that it is time to make a little retrospective on the work we have completed in 2022 in Camel K project. We are already collecting ideas to submit to the community for 2023 in order to define the new roadmap. Stay tuned, more is coming shortly… Camel K 2022 roadmap update It’s been a long ride and here a short resume of what we accomplished during the last year in Camel K project.
Hey Camel K riders, there is a new Camel K 1.11.0 release, there is no big new feature, as we focused on fixing bug, improving current features, updating dependencies and maintain our release cadence, since our 1.10 release, three months ago. As usual let’s start by acknowledging the tech stack on top of Camel K and the new exciting versions our fellows have baked: Apache Camel K Runtime 1.16.0 Apache Camel Quarkus 2.
Testing is probably one of those operations we use to repeat most of the time while building any application. Applications in Camel world are no difference. With the advent of Camel JBang, we have a unified place that can be used to perform our testing/fine tuning locally before moving to a higher environment. During the last years of development, we have noticed that testing or fine tuning an integration directly connected to a Cloud Native environment can result a bit cumbersome.
In Camel K version 10, we’ve released the CLI `promote feature that provides Camel K an opinionated way of promoting an Integration through the stages of software development. This feature unlock the possibility to combine Camel K with external tooling and let the user develop according to any automated release process. We always ear about CI/CD (Continuous Integration/Continuous Delivery and/or Deployment), and in this blog we’re going to see how to make it for any Camel K integration.
It’s been a long ride to bring our beloved Camel (K) from 1.9.0 to 1.10.0. We’re particularly happy as we had the time to introduce many features and enhancements that we had planned in our 2022 roadmap back at the beginning of the year. As usual let’s start by acknowledging the tech stack on top of Camel K and the new exciting versions our fellows have baked: Apache Camel K Runtime 1.
Camel K offers a wide list of operations you can execute once your Integration has been deployed (likely in a production environment). When we talk about operations, the most typical question we got is “How to monitor a Camel K Integration?”. Fortunately, we have all the ingredients needed to let you manage this operation as smooth as possible. I’ll walk you through the different tools and configuration needed in this blog post.
The Integration is the resource which represents the actual Camel application and building a container image that packages the integration within an elevated cloud platform (be it locally in a Minikube or K8s hosted cluster to Openshift clusters) takes ample amount of time. Enhancing the Camel-K Integration build time Our goal was to reduce overhead and improve user experience. We were able to narrow down the major contributors that had a significant influence on the integration build time.
Attention, attention: time for a new exciting Camel K release! On behalf of Camel K community I am happy to announce the latest 1.9.0. Camel K release. As usual let’s use this blog to share with you the new stack of exciting technology we’ll be using in this version: Apache Camel K Runtime 1.13.0 Apache Camel Quarkus 2.8.0 Apache Camel 3.16.0 Apache Camel Kamelets 0.8.0 Thanks to Apache Camel, Camel Quarkus and Kamelet Catalog contributors for the great efforts they’ve put in those new releases as well.
Signpost png from pngtree.com/ During the last weeks we’ve been asked questions around the direction we’re willing to take on the future development of Camel K. I think it would be good to have some blog in order to let the community understand where our efforts are going. It will be useful for every Camel K user and Camel K developer, as a guide for the future development of the project.
Image copyright: stockunlimited Time for a new release! Time for Camel K 1.8 version. Keep reading to discover what’s new in Camel K! This is the set of technologies on which Camel K 1.8 is based: Apache Camel K Runtime 1.11.0 Apache Camel Quarkus 2.6.0 Apache Camel 3.14.0 Apache Camel Kamelets 0.7.0 As usual, thanks to Apache Camel, Camel Quarkus and Kamelet Catalog contributors for the great efforts they’ve put in those new releases as well.
NOTE: this post has first appeared in the author’s blog. KEDA (Kubernetes Event Driven Autoscalers) is a fantastic project (currently CNCF 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 for providing a similar functionality for integrations that are triggered by HTTP calls, so supporting KEDA was something planned since long time, because it enables full autoscaling from a wider collection of sources.
Karavan Serverless What’s new in Karavan preview release 0.0.8? In addition to VSCode extension and Standalone application, Karavan could be deployed in Serverless mode alongside Camel-K on Kubernetes. Karavan Serverless gets and applies Integration Custom Resources directly from/to Kubernetes. Try Karavan Serverless mode on Minikube Install Minikube Install Camel-K Install Karavan serverless git clone --depth 1 https://github.com/apache/camel-karavan cd camel-karavan/karavan-demo/serverless kubectl apply -k karavan -n default Get Karavan URL minikube service camel-karavan --url The output should be like the following:
Today we’re happy to announce a new major release for Camel K: Camel K 1.7 version, quite a big leap from latest 1.6 we released a couple of months ago. Keep reading to discover what’s new in Camel K! First of all, let’s highlight the set of technologies on which Camel K 1.7 is based: Apache Camel K Runtime 1.10.0 Apache Camel Quarkus 2.4.0 Apache Camel 3.12.0 Apache Camel Kamelets 0.
Apache Camel is a project in constant transformation. Anyone knows that Camel has been able to adapt to any new kinds of protocols and systems that have emerged in the past 15 years. But it’s not only that: Camel is also able to adapt to any new ways of dealing with integration problems in the cloud era. While Camel K represented a fundamental shift towards a new approach to cloud-native integration, “Kamelets” are driving a deeper transformation towards “low code” development.
The latest community version of the Knative client v0.26 includes a new kn plugin for managing Kamelets as Knative event sources (GitHub: knative-sandbox/kamelet-plugin-source-kamelet). With the new plugin users of the kn tooling can directly list the available Kamelet sources and bind these Kamelets to Knative resources such as brokers, channels or services. The Kamelets facilitate a whole new world of event source possibilities allowing users to connect to external services (AWS, Twitter, Telegram, Postgres) as part of Knative eventing.
We’re happy to announce Camel K 1.6 version release. About two months after releasing the previous version (1.5), we’re now glad to provide you some new exciting features and a few fixes on bugs that we discovered along the way. This is the new set of technologies on which Camel K 1.6 is depending: Apache Camel K Runtime 1.9.0 Apache Camel Quarkus 2.2.0 Apache Camel 3.11.1 Apache Camel Kamelets 0.4.0 New Camel Quarkus version We have a set of new exciting dependencies that we leverage.
A new release of VS Code Tooling support for Apache Camel K 0.0.26 is available. It notably includes compatibility with Camel K 1.5.0 and Code Lenses. Compatibility with Camel K 1.5.0 The Camel K binary provided by default is now 1.5.0. The commands are using the new API. Note: It is working too with Camel K 1.4.0 productized by Red Hat. The needed features were backported. Code Lenses A Code Lens is an information provided inside text editor.
Camel K version 1.5 is out. And with it, a new way of providing configuration and resources to your Integration. We have worked on a deep code refactoring in order to harmonize the existing configuration settings and add new ones to exploit the power of camel-quarkus runtime, which has become the main way to materialize an Integration. We added new features that will simplify your developer life. We also added new checks that will give you useful tips when using a feature in a wrong way.
Camel K 1.5 version is public since a few days. We’re proud to announce this new release containing enhancements and fixes. We’ve worked hard to fix the most important issues discovered with an eye on stabilization and performances. This new release is based on Camel Quarkus 2.0 and Apache Camel 3.11. Let’s find out what’s new in Camel K 1.5! New Camel Quarkus and Quarkus versions Camel Quarkus runtime has become the building block on which the Integration is materialized.
Kamelets (Kamel route snippets) are a new concept introduced in Camel K that allow users to connect to external systems via a simplified interface, hiding all the low level details about how those connections are implemented. There are several ways to consume them. One of them is as standard Camel Components. In this case, completion is provided to fill the template id and the parameter names. It is currently based on a fixed set of Kamelets provided by a snapshot of the kamelet catalog.
Camel K is providing a new feature to Java debug deployed integrations. Before VS Code Tooling for Apache Camel K 0.0.25, more complex steps were required to leverage the VS Code Java debugging capabilities as explained in this previous blogpost. I recorded a video which is following the steps in this blogpost. Requirements VS Code Extension Pack for Apache Camel with VS Code Tooling for Apache Camel K 0.0.25+ Camel K deployed to a cluster.
New Camel K Logging Features for Camel K 1.5
Apache Camel K 1.4.0 has just been released! This is a new major release of Camel K with an improved stability over previous versions, but also adding new features that simplify the overall user experience. It is based on Camel 3.9.0 and Camel-Quarkus 1.8.1, providing all improvements that they bring, plus much more. In this blog post, we’re going to describe the most important changes. Embedded Kamelet catalog Camel K 1.
We’re starting a new initiative at Apache Camel to create a community-driven catalog of reusable Kamelets (Camel route snipp_ets_, i.e. connectors) that can be used to stream data from/to external systems into any platform powered by Apache Camel. The “Apache Camel Kamelet catalog” is available here and it already contains a collection of useful Kamelets: we would like to extend it with help of the community. Kamelets are currently supported out-of-the-box by the Apache Camel K project and we’re working to support them also in Camel core, so that they can run eventually in any Apache Camel subproject, like Camel Kafka Connector (but also camel-quarkus, camel-spring-boot, …).
UPDATED ON 17 May 2021: More recent related content available in this blogpost. Camel K 1.3.0 is providing a new feature to Java debug deployed integrations. Even if Camel K 1.3.0 is not fully compatible with VS Code Tooling for Apache Camel K extension, it remains possible to leverage the VS Code Java debugging capabilities. I recorded a video which is following the steps in this blogpost. I let you choose your preferred way to discover how to java debug your Camel K integration in VS Code.
Apache Camel K 1.2.0 has been released! This version introduces some important features that will play an increasingly bigger role in future releases of Camel K. Quarkus as default runtime Camel K 1.2.0 uses camel-quarkus 1.1.0 (Quarkus 1.8.0.Final) as runtime, but Quarkus is no longer an optional runtime for Camel K: Quarkus is now the default runtime. This means that users no longer need to enable Quarkus explicitly when running their integrations (using kamel run -t quarkus.
Apache Camel K has made a lot of progress since its inception and we’re now proud to announce the 1.0 release. We’ve been working hard in the past months to add more awesome features to Camel K, but also to improve stability and performance. This post contains a list of cool stuff that you’ll find in the 1.0 GA release. First of all, if you’re living under a rock and it’s the first time you hear about Camel K, you can read some introductory blog posts here (1 - introducing camel k, 2 - camel k on knative) or look at the Apache Camel website that contains a Camel K section with a lot of material that is automatically generated from the Github repository.