Syndesis: Support for vanilla Kubernetes

Created on 15 Oct 2018 · 7Comments · Source: syndesisio/syndesis

This is a...


[ x] Feature request
[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Documentation issue or request

Description

Is it possible to get a deployment for on vanilla Kubernetes? So, in the same way, there are openshift deployments have a section for kubernetes scripts.

cafeature statunever-stale

Source

kevinbayes

👍3

Most helpful comment

To grow community support running on k8s is a must in my opinion, and any healthy project needs a community. It's disappointing we let go of k8s support to easily. I'm def interested to help out on this effort.

KurtStam on 15 Oct 2018

👍4

All 7 comments

Thank you for your interest @kevinbayes in Syndesis! We started out with OpenShift and we don't (currently) support Kubernetes.

We're constantly re-evaluating out feature set and trying to find the right set of requirements we need to make the project successful. We would also very much appreciate any contributions in this area. So thank you for opening up this discussion and providing feedback :+1:

To support Kubernetes we would have to look at two areas in particular:

installation and upgrades - this we currently do either via OpenShift templates in addition to which we could also add Helm Charts; or via the Syndesis operator which we could extend to fully support Kubernetes. In the long run Syndesis operator is going to be the best way to install and upgrade Syndesis.
building and deploying integrations - we're using OpenShift source to image (S2I) builds to do this, we're hoping that Kamel (https://github.com/apache/camel-k) is going to replace this and it already has Kubernetes support.

zregvart on 15 Oct 2018

KurtStam on 15 Oct 2018

👍4

Sure it should be fine to give some support on this.

kevinbayes on 16 Oct 2018

@kevinbayes Can you elaborate on what you mean with "vanilla" Kubernetes?

heiko-braun on 16 Oct 2018

I think Kubernetes support would be good to have. However, I think we have a lot of subtle dependencies on OpenShift. Maybe it's a good start to collect the differences before we can break that down in smaller tasks?

Out of my head, I see the following areas which would need to be updated:

Building integration runtimes when publishing. Uses S2I on OpenShift, would need to use (Knative ?) or implement similar build service for Kubernetes
Installation uses OpenShift templates. We are currently moving the installation into an operator where the template becomes an internal implementation detail which could be changed to something which can be used on both, OpenShift and Kubernetes
Using OpenShift SSO via OAuth proxy.
Using Imagestreams in DeploymentConfigs for updates. This concept doesn't exist on Kubernetes
Not 100% sure how the API Provider and Webhook exposes their routes, but if its via an OpenShift Routes this would have to be changed to Ingress objects.

Anything else ?

rhuss on 16 Oct 2018

By switching to Camel K as Camel runtime, we can support build on vanilla Kubernetes. It uses Kaniko (it probably will use Knative build when Knative is available). The only thing to decide is the Docker registry where to publish images (on Minikube, Camel K uses the "addon registry").

Also last point about exposing routes is covered (Route / Ingress).

nicolaferraro on 16 Oct 2018

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!