camel-k installation struggles

[davesargrad]

I am struggling to install camel-k, the latest details in this struggle are at the bottom of the comment chain. I am following the install instructions here.

I get the camel integrationplatform installed, however the camel-k-cache pod enters crashloopbackoff. The details are towards the end of the comment chain.

In short the command

kubectl logs -p camel-k-cache

shows a segmentation violation.

---

The initial post was a question about using helm vs kamel to install. The instructions I received from @davsclaus were to use the camel-k operator. I've done that and refined this post accordingly.

[davsclaus]

camel-k is operator based, and you can install it via operatorhub etc
https://operatorhub.io/

[nicolaferraro]

We can evaluate helm as alternative way to install the Camel K operator, there are some old issues about that.

The most important problem we need to solve is to avoid duplicating resources in the codebase.

[davesargrad]

Thanks for the feedback guys. I do appreciate you taking the time.

[davesargrad]

I'm installing using the operator procedures. The operator installs a pod (camel-k-cache) that has an unbound PVC.

The result seems to be that the integration platform stays in the warming phase.

The instructions I am following are these:

Suggestions on how to fix this?

[davesargrad]

What storageclass is needed?

If possible, I'd like to use the fast-rbd class in the following. This will autoconfigure a PV, for any PVC that claims it.

[davesargrad]

This worked for me.. and yay.. i have camel-k running:

kubectl patch storageclass fast-rbd -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

[nicolaferraro]

Nice, if that annotation works also on other platforms, we can add it by default.

Note that for GKE there are some additional configurations required, e.g. to setup the platform to push images to gcr.io (and other requirements): https://camel.apache.org/camel-k/latest/installation/gke.html

[nicolaferraro]

Ok, no.. the default storage class needs to be set on the storage class, better not changing it from Camel K...

[davesargrad]

Thanks @nicolaferraro

That makes sense!!

Last step I have is seen in the following. What is the best way to see why this is waiting for the platform?

[davesargrad]

Hmm. Camel-K-Cache seems to be crashing

In the following we see exit code 2

[davesargrad]

What is the best way for me to determine why the camel-k-cache pod crashes?

[davesargrad]

I just found the following in the logs

[davesargrad]

Any thoughts on the CRASHLOOPBACKOFF problem guys (Invalid Memory Address or Nil Pointer Dereference)? Perhaps I should post this on a separate issue, since the title of the initial issue was quite different than the problem I am seeing.

[davesargrad]

Hi @nicolaferraro

The Camel-K operator instructions here dont say anything about installing the "kamel" tool.

Is it possible that the crash (panic runtime error seen in the logs of camel-k-cache).. relates to the fact that I've not installed the "kamel" binary?

[davesargrad]

I'm definitely confused relative to the proper way to get camel-k installed. The operator instructions on operatorhub got me almost all of the way there (if only i could isolate why i am seeing the crashloopbackoff).

At this point I've destroyed all the camel-k kubernetes resources and am going back to a clean slate, and trying to find the simplest instructions to follow.

Rather than these I could use these, however its not clear which of these apply to my k8s configuration. I dont use minikube, openshift, minishift, or gke).

Clean slate starting point:

K8S Version

Current Resources

[davesargrad]

We are considering giving up on camel-k for now. We can perhaps do what we need to with camel running outside of k8s. Its just really attractive to be able to get camel-k running and use camel on k8s.

Hopefully you can provide some guidance on this, that will allow us to get past this final step.

[jamesnetherton]

You could try to work around the issue by disabling the Kaniko build cache. E.g:

apiVersion: camel.apache.org/v1alpha1
kind: IntegrationPlatform
metadata:
  labels:
    app: camel-k
  name: camel-k
spec:
  build:
    kanikoBuildCache: false

Or if using the kamel binary:

 kamel install --kaniko-build-cache=false

[davesargrad]

You could try to work around the issue by disabling the Kaniko build cache. E.g:

apiVersion: camel.apache.org/v1alpha1
kind: IntegrationPlatform
metadata:
  labels:
    app: camel-k
  name: camel-k
spec:
  build:
    kanikoBuildCache: false

Hi @jamesnetherton
Thanks for this suggestion. I will review the integrationplatform spec that I used this morning, and update it as you suggest (ensure that kanikoBuildCache is false). The instructions I've followed are these.

The following indicates that the kanikoBuildCache is not explicitly part of the operator.io install instructions. I will try adding it, and recreating the integrationplatform on k8s

---

Or if using the kamel binary:

 kamel install --kaniko-build-cache=false

Per the suggestion of @davsclaus I'm not using the kamel binary, I'm using the instructions on operator.io.

I could possibly use the kamel binary instead. However I dont know what to set its various arguments to. The instructions found on the camel-k documentation page seem to apply to 4 different k8s environments (e.g. openshift, minishift, gke, minikube), that I dont have. What I have is a simple k8s installation on centos-7. From what @davsclaus says, its seems like the operator is the way to go. Looking at operator.io i do think it seems that the camel-k team is using operators as they move towards a full production release of camel-k. Currently it seems to be in alpha, and I'm guessing thats why I'm having the problems I am having. Though I do think that if I can get past this issue it will help them to harden their operator.

---

Anyways I will try this again and see if disabling that cache helps. @nicolaferraro I'd also try anything that the team suggests, since I'd like to see the team harden camel-k as you drive towards beta

[davesargrad]

I've tried the suggestion made by @jamesnetherton

So far it looks like this may have gotten me further. In the following you see the IntegrationPlatform spec that I've used.

Also you see that the camel-k integrationplatform is in phase Ready. Before it seemed to stay in Warming.

I'll try to run my first integration

[davesargrad]

[davesargrad]

[davesargrad]

Now the example integration seems to be stuck in "Building Kit"

I expect to see pods such as camel-k-groovy-builder, camel-k-jvm

There are new packageserver pods running.. perhaps it just takes time to build the kit

I'm pretty sure its hung in the Building Kit phase. I see no pod activity when I run:
kubectl get pods -w

[davesargrad]

I see a bunch of stuff in the camel-k-operator pod log.. too much to put into this comment.. not sure what any of this means

---

Top of the log:

---

Bottom of the log:

[davesargrad]

My current suspicion is as follows. I am looking at the integration platform as it runs on k8s. I see that it is using maven and has a settings.xml.

Since I am running behind a corporate proxy I typically have to put the following into my settings.xml (so that maven can download packages)

<?xml version="1.0" encoding="UTF-8"?>
<proxies>
   <proxy>
      <id>saab-sensis-proxy-http</id>
      <active>true</active>
      <protocol>http</protocol>
      <host>proxy.corp.sensis.com</host>
      <port>3128</port>
   </proxy>
   <proxy>
      <id>saab-sensis-proxy-https</id>
      <active>true</active>
      <protocol>https</protocol>
      <host>proxy.corp.sensis.com</host>
      <port>3128</port>
   </proxy>
</proxies>

How can I configure the integrationplatform to use a proxy?

This issue seems pertinent.

It would seem that 706 is closed. The comment from @nicolaferraro seemed to indicate that the proxy setting capability was rolled into 0.3.4 milestone.

I am using 1.0.0-M4

So I'm hopeful that I can set the proxy for camel-k. Can someone point me to a simple set of instructions for doing this?

I have found that 720 references a configmap ability to create custom settings. However the instructions under 720 use kamel.. I am using the operator methodology found under operatorhub

[davesargrad]

Digging further I see that camel-k is already auto-generating settings.xml. This is found under the following camel-k-maven-settings configmap

So I feel that we are very close. Please help me to understand how I can update this properly to use a proxy? The "kamel" binary is not the approach that makes sense to us since this is not part of an operator-based install of camel-k

[davesargrad]

I tried to update the configmap as follows:

Export the configmap

kubectl get configmap camel-k-maven-settings -o yaml --export > camel-configmap.yaml

Add the proxy entry

Reapply using
kubectl apply -f camel-configmap.yaml

I then verify that the configmap has changed. It does as you see below

I then recreated the camel-k integrationplatform and the example integration.

Unfortunately the integration is still seemingly stuck in Building Kit

[nicolaferraro]

Hi @davesargrad, we should make sure we print a more informative error and not proceed with making the integrationplatform ready if there are not the right conditions.

I see you're not declaring any target docker repository in the IntegrationPlatform. Camel K needs to produce the container images for you and push them somewhere in order to create the deployment later.

On minikube there's a unauthenticated registry that is configured automatically by the kamel CLI or you can provide the configuration in the integrationplatform. On minishift and openshift there's always an internal registry that we use by default. The only public (authenticated) registry that we support is gcr.io and instructions to configure it are provided in the link I've sent.

There's an issue open for working with any docker registry and we plan to fix it for 1.0.0-M5 (#613).

[asifdxtreme]

Hi @davesargrad , I have seen these type of errors before while setting up camel-k behind proxy, only difference in mine and your approach was that I was using kamel binary for installation and you are using operator framework for the installation. Anyhow I will list down my steps for installation behind proxy and you can check if this helps you in some way;
Before all of these you need to create a PVC/PV with name camel-k

1. Create http-proxy secrets

kubectl create secret generic kamel-test --from-literal=HTTP_PROXY='http://XXX/' --from-literal=HTTPS_PROXY='http://XXX' --from-literal=NO_PROXY='XXX'

2. Create config map for maven settings

kubectl create configmap maven-settings --from-file=settings.xml

3. Create a private docker registry

docker run -d -p 5007:5000 --restart=always --name registry registry:2

4. Add the internal ip(YYY) to your insecure registry ip in the docker configuration for all the nodes
5. Install camel-k using below command

kamel install --registry-insecure true --registry YYY:5007 --maven-settings=configmap:maven-settings/settings.xml --http-proxy-secret kamel-test --kaniko-build-cache=false

This might not be a recommended solution for production env but this will keep you going for now.

[davesargrad]

Hi @nicolaferraro
Thanks for this feedback. I will certainly try the operator-based installation process from a clean 1.0.0-M5 build, and I will continue to provide detailed descriptions of my progress to support the Camel-K team as you drive towards full support for such environments.

If there are any experiments you'd like me to do, I'd be glad to do them. Support for your team, helps us in the long term.

Hi @asifdxtreme
This is something I will try right now. I actually have a private docker registry setup. However I like the simplicity of your suggestion. I will try this.

Regards,
Dave

[davesargrad]

@asifdxtreme

I've used your instructions to set up camel-k.

I see some errors on the kit builder pods:

Describing one of these I see:

My secrets:

My configmaps:

My Maven Settings

Suggestions?

[davesargrad]

Interestingly "logs" on one of the errored camel-k-kit-####-builder pods seems to have succeeded

Top of logs:

Bottom of logs:
..

I dont see a single problem show up in the logs (for this builder pod)
Maven clearly worked (got past our proxy), and the build is a success, yet the pod shows an error

[davesargrad]

I do see this, on one of the camel-k-kit pods:

This suggests that the connection to the local docker registry i created did not work.

@asifdxtreme
So my kit builders are succesfully building the integration code.. but the connection to docker is failing. Is there a command that you might have missed, in your suggested working around?

In the following you see that my docker-proxy is running on port 5007

But that smells like an IPV6 transport.. I am using IPV4

In the following you see the IP address that I used in place of your "YYY"

[nicolaferraro]

@davesargrad I think the builder pod is trying to contact docker.io because the default base image (fabric8/s2i-java:3.0-java8) is hosted there. You may want to transfer it to your internal registry then reinstall the platform with the --base-image flag pointing to your image (note that you need to delete integration platform and recreate it).

[davesargrad]

Thank You @nicolaferraro

That makes sense. Based on the commands provided above by @asifdxtreme, what would be the command or two that I need to augment my installation? I can try to figure this out, but my guess is it would take several hours to do what you guys could probably do in several minutes.

Based on your feedback, the two commands I think I need are.
I'm guessing they are something such as the following:

1. Download the fabric8/s2i-java:3.0-java8 into my local docker registry
   I'm guessing this is actually several commands:
   docker pull fabric8/s2i-java:3.0-java8
docker image tag fabric8/s2i-java:3.0-java8 localhost:5007/cool-camel-k-base-image
docker push localhost:5007/cool-camel-k-base-image

2. Modify the call to kamel with a --base-image flag.
   kamel install --registry-insecure true --registry 10.93.97.202:5007 --maven-settings=configmap:maven-settings/settings.xml --http-proxy-secret kamel-test --kaniko-build-cache=false --base-image localhost:5007/cool-camel-k-base-image

I am not a docker expert.. So please bear with me.

Are the above commands right?

[davesargrad]

I've tried the above.. it seems to have pushed the cool-camel-k-base-image to localhost:5007. I

I then deleted all the camel-k resources:
kubectl delete all,pvc,configmap,rolebindings,clusterrolebindings,secrets,sa,roles,clusterroles,crd -l 'app=camel-k'
kubectl delete -n operators deployment.apps/camel-k-operator

I'm now running kamel again.. fingers crossed.

No errors in the following, not sure how long I expect to be in Building Kit

[davesargrad]

Hmm...

[davesargrad]

I think my issue is localhost.. changing to a proper name.

[davesargrad]

I've even tried to mark this as an insecure registry, as seen here:

Clearly docker is listening on 5007

There is my catalog

[davesargrad]

Why is my camel-k-kit pod failing to connect to the private docker registry?

Note: I've tried placing 10.93.97.202 onto the "NO_PROXY" definition as well
kubectl create secret generic kamel-test --from-literal=HTTP_PROXY='http:proxy.corp.sensis.com:3128' --from-literal=HTTPS_PROXY='http:proxy.corp.sensis.com:3128' --from-literal=NO_PROXY='10.93.97.202'

[davesargrad]

Ok.. the answer to that last question is.. dumb sloppy me! Look the integration is running !

The last bit of magic was to place the private docker server properly onto the NO_PROXY list.

Still running:

If it would help you guys, I can create a succinct document containing all the steps that I had to run in order to accomplish this. It may help as you drive towards full support of private docker registries on vanilla k8s installations.

[asifdxtreme]

@davesargrad Cool that you fugured out the error, yes the docker registry ip was supposed to be in NO_PROXY list, and sorry for the late reply as I was in a different time zone so I couldn't see your messages.
I think it will be really good if you can contribute all the steps as a guide to run camel-k behind corporate proxy.

[davesargrad]

@davesargrad Cool that you fugured out the error, yes the docker registry ip was supposed to be in NO_PROXY list, and sorry for the late reply as I was in a different time zone so I couldn't see your messages.
I think it will be really good if you can contribute all the steps as a guide to run camel-k behind corporate proxy.

Hi @asifdxtreme

I would be more than happy to document the steps I took. I'll do that with care over the next couple of days, and then I'll post it to this issue.

Though I've not heard you guys say this, I think the "kamel" installation process may ultimately be replaced by an operator based installation process (operatorhub.io). Is this the plan?

I do have one last issue that I'm trying to get past. To the extent that a camel component that is not in camel-core is needed by a route that I am building, what is the proper way to declare this maven dependency, and to ensure that the dependency jar is placed in the proper repository? I think the corporate proxy, and the vanilla k8s may add some wrinkles to the answer.

I've found one issue that seems to relate to this question. This issue references camel-mail as a camel component that is not in the camel-core used by camel-k.

Perhaps you can help me to answer this. I think this will create one more wrinkle relative to working behind a proxy, with a vanilla k8s/docker distribution on centos7.

Yesterday I was able to get the simplest integration running, but i quickly ran into additional problems when i tried one of the other examples (restwithrestlet). That integration complained about not being able to find the restlet component.

I was also looking for other examples that might use something such as camel-mail. Any example that allows me to push the integration platform further, so that i can be sure that i've covered all the cases that might be of interest.

Any suggestions/guidance would be appreciated.

[davesargrad]

The RestWithRestlet error

This is old, but related

[lburgazzoli]

camel-restled has been removed from camel 3 RC3, we need to update the example :)

[davesargrad]

camel-restled has been removed from camel 3 RC3, we need to update the example :)

Ah.. Ty @lburgazzoli

Your fast response .. appreciated,.
:)

[nicolaferraro]

@davesargrad Cool that you fugured out the error, yes the docker registry ip was supposed to be in NO_PROXY list, and sorry for the late reply as I was in a different time zone so I couldn't see your messages.
I think it will be really good if you can contribute all the steps as a guide to run camel-k behind corporate proxy.

Hi @asifdxtreme

I would be more than happy to document the steps I took. I'll do that with care over the next couple of days, and then I'll post it to this issue.

Though I've not heard you guys say this, I think the "kamel" installation process may ultimately be replaced by an operator based installation process (operatorhub.io). Is this the plan?

I do have one last issue that I'm trying to get past. To the extent that a camel component that is not in camel-core is needed by a route that I am building, what is the proper way to declare this maven dependency, and to ensure that the dependency jar is placed in the proper repository? I think the corporate proxy, and the vanilla k8s may add some wrinkles to the answer.

I've found one issue that seems to relate to this question. This issue references camel-mail as a camel component that is not in the camel-core used by camel-k.

Perhaps you can help me to answer this. I think this will create one more wrinkle relative to working behind a proxy, with a vanilla k8s/docker distribution on centos7.

Yesterday I was able to get the simplest integration running, but i quickly ran into additional problems when i tried one of the other examples (restwithrestlet). That integration complained about not being able to find the restlet component.

I was also looking for other examples that might use something such as camel-mail. Any example that allows me to push the integration platform further, so that i can be sure that i've covered all the cases that might be of interest.

Any suggestions/guidance would be appreciated.

The kamel installation will remain because it's handy. Everything that can be installed via kamel can be also installed via operator already. The problem is that when you install via operator, you need to add additional configuration on the IntegrationPlatform resource, and that is not so user friendly as the CLI, because the current UI does not allow to put something that helps the user.

The only place where the operator installation works with the default examples is OpenShift, because it has an internal registry that we automatically use to push images, so an empty IntegrationPlatform is ok. When you are outside Openshift, the operator does not know where to push images and you need to instruct it via the integrationplatform resource.

If you take your current IntegrationPlatform with k get integrationplatform camel-k -o yaml and you use it during installation from operator hub, you should be able to do a full installation without kamel.

[davesargrad]

@nicolaferraro

Thanks! I'll actually use your suggestion as part of the documentation I create. I'll also continue to support by installing camel-k updates as they are available, and continuing to refine that documentation.

[davesargrad]

Guys,
I am trying to get camel-k running on yet another k8s cluster. At this point I've gotten reasonably comfortable with camel-k. Of course as typically happens I am struggling yet again with proxy related issues. I dont want to post the details here, but I thought I'd link them here.

The issue I created on the kubernetes issue lists shows the failure of the camel-k-kit pod to download an image from the private docker registry I've created.

I am pretty sure I've done everything I need to do in order to deal with the proxy. I believe I've followed exactly the procedure that I eventually got working in the past. Yet.. here it rears its ugly head again.

The issue on k8s:
kubernetes/kubernetes#85904

Please let me know if you guys have suggestions on how to isolate this.

[nicolaferraro]

@davesargrad looking at the first image, the kit is in status "Error", not "ErrImagePull", so it means that it has run the build part and started the docker image packaging part and the logs that you posted are printed by the Kaniko builder.

Docker packaging is done by Kaniko at user level in the container, so my guess is that it does not change a lot if you configure the node docker daemon correctly. And I also don't think that the PROXY settings on the host have any effect on the container.

In these cases on OpenShift I use oc debug pod-name to start an identical pod to the one that failed and try to do some debugging to check the network. You can do a similar thing with Kubernetes.
I'd use a busybox first to to some connectivity checks: the final destination or the proxy should be reachable, depending on your config.

Then if the config is ok and (if needed) your camel k is configured with the --http-proxy-secret as in the messages above, I'd check with the Kaniko image that went in error. Kaniko images have a -debug variant, which in our case should be gcr.io/kaniko-project/executor:debug-v0.9.0. From that container you can try to build a random Dockerfile from an image of your choice and see what happens.

Hope that some suggestions can help your investigations.

[davesargrad]

Ty @nicolaferraro
Thats extremely useful detail. I did actually see that the maven build seems to have completed successfully, as you say.

I have used the camel-k-secret as you suggest. I've been very particular to reproduce the sequence of commands carefully.

How would I use the -debug variant of the kaniko image?

The way I create the sample integration is with:

kamel run Sample.java

[davesargrad]

As usual... your clue fixed me!!! I had done something dumb in creating the secret.. recreated and all good!!

@nicolaferraro .. you da man!

[davesargrad]

I am running the kamel example RestWithUndertow.java

The integration is running. Apparently it exposes the service on port 8080

[root@benin examples]# kubectl describe integration rest-with-undertow
Name:         rest-with-undertow
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  camel.apache.org/v1alpha1
Kind:         Integration
Metadata:
  Creation Timestamp:  2019-12-05T15:04:46Z
  Generation:          1
  Resource Version:    1426020
  Self Link:           /apis/camel.apache.org/v1alpha1/namespaces/default/integrations/rest-with-undertow
  UID:                 d26b52aa-b1ed-462e-819a-a81b5a1d0acd
Spec:
  Dependencies:
    camel:rest
    camel:undertow
  Sources:
    Content:  /*
 * Licensed to the Apache Software Foundation (ASF) under one or more
 * contributor license agreements.  See the NOTICE file distributed with
 * this work for additional information regarding copyright ownership.
 * The ASF licenses this file to You under the Apache License, Version 2.0
 * (the "License"); you may not use this file except in compliance with
 * the License.  You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

//
// To run this integrations use:
//
//     kamel run --name=rest-with-undertow --dependency=camel-rest --dependency=camel-undertow examples/RestWithUndertow.java
//

import org.apache.camel.Exchange;

public class RestWithUndertow extends org.apache.camel.builder.RouteBuilder {
    @Override
    public void configure() throws Exception {
        restConfiguration()
            .component("undertow")
            .host("0.0.0.0")
            .port("8080");

        rest()
            .get("/hello")
            .to("direct:hello");

        from("direct:hello")
            .setHeader(Exchange.CONTENT_TYPE, constant("text/plain"))
            .transform().simple("Hello World");
    }
}

    Name:  RestWithUndertow.java
Status:
  Camel Version:  3.0.0-RC3
  Conditions:
    Last Transition Time:  2019-12-05T15:04:46Z
    Last Update Time:      2019-12-05T15:04:46Z
    Message:               camel-k
    Reason:                IntegrationPlatformAvailable
    Status:                True
    Type:                  IntegrationPlatformAvailable
    Last Transition Time:  2019-12-05T15:05:24Z
    Last Update Time:      2019-12-05T15:05:24Z
    Message:               kit-bnkhp3jaee59h4n740hg
    Reason:                IntegrationKitAvailable
    Status:                True
    Type:                  IntegrationKitAvailable
    Last Transition Time:  2019-12-05T15:05:24Z
    Last Update Time:      2019-12-05T15:05:24Z
    Message:               rest-with-undertow
    Reason:                DeploymentAvailable
    Status:                True
    Type:                  DeploymentAvailable
    Last Transition Time:  2019-12-05T15:05:24Z
    Last Update Time:      2019-12-05T15:05:24Z
    Message:               rest-with-undertow(http/80) -> integration(http/8080)
    Reason:                ServiceAvailable
    Status:                True
    Type:                  ServiceAvailable
    Last Transition Time:  2019-12-05T15:05:24Z
    Last Update Time:      2019-12-05T15:05:24Z
    Message:               no host or service defined
    Reason:                IngressNotAvailable
    Status:                False
    Type:                  ExposureAvailable
  Dependencies:
    camel:bean
    camel:direct
    camel:rest
    camel:undertow
    mvn:org.apache.camel.k/camel-k-loader-java
    mvn:org.apache.camel.k/camel-k-runtime-main
  Digest:           v96oRUdREvEEVrwGm9DcL9iKMkyxkksMFt2UtyWgSD8s
  Image:            10.93.97.123:5007/default/camel-k-kit-bnkhp3jaee59h4n740hg:1425898
  Kit:              kit-bnkhp3jaee59h4n740hg
  Phase:            Running
  Platform:         camel-k
  Replicas:         1
  Runtime Version:  1.0.7
  Version:          1.0.0-M4
Events:             <none>

Do I need to create another k8s service (e.g. loadbalancer) to map a port to either 80 or 8080 in the pod?

The pod runs on spain.

I've tried to browse to the worker IP at both port 80 and port 8080

How do I browse to the "hello" endpoint?

[nicolaferraro]

Have you looked at the Ingress Trait?

I think you need to configure ingresses at cluster level, then tell camel k the host that you want your integration to be deployed at. E.g.

kamel run -t ingress.host=myintegration.thefullclusterdomain.com it.java
```

Then you should be able to access APIs at https://myintegration.thefullclusterdomain.com/

[davesargrad]

Have you looked at the Ingress Trait?
I think you need to configure ingresses at cluster level, then tell camel k the host that you want your integration to be deployed at. E.g.
kamel run -t ingress.host=myintegration.thefullclusterdomain.com it.java

Then you should be able to access APIs at https://myintegration.thefullclusterdomain.com/

Excellent direction. I will do this.

[davesargrad]

Hi @nicolaferraro

We are looking to extend our use of camel-k to include transaction support. I've spent a number of days reading about JTA and technologies such as narayana, and atomikos. I am trying to choose one for fast integration into our prototype architecture.

My goal is to run the transaction manager on kubernetes alongside the camel-k based camel services.

Do you have a recommendation as to a starting point? I'd really like to select and install a transaction manager this week. I dont see a lot of online documentation for running these transaction managers on k8s. Yet I have seen your name on a couple of github projects that seem to relate to this interest. I also know that its of interest to the camel-k and camel team to support the service elements that rely on safe transactions.

Any thoughts would be appreciated.

[nicolaferraro]

Hi, moving this conversation to another issue.