it's a PaaS .. heroku for k8s
https://github.com/knative/docs/tree/master/serving/samples/...
https://github.com/knative/docs/tree/master/serving/samples/...
The samples show that you can make an app, make a container, and make a service config file, and deploy your app to K8s. Yes, we've been able to do that for some time now.
This thing is supposed to provide a bunch of advanced features for devs to not have to think about. However, the build repo says this:
"While Knative builds are optimized for building, testing, and deploying source code, you are still responsible for developing the corresponding components that: + Retrieve source code from repositories. + Run multiple sequential jobs against a shared filesystem (for example, Install dependencies, Run unit and integration tests). + Build container images. + Push container images to an image registry, or deploy them to a cluster."
"While today, a Knative build does not provide a complete standalone CI/CD solution, it does however, provide a lower-level building block that was purposefully designed to enable integration and utilization in larger systems."
So as a developer you still have to have all the things you had before, but with extra layers of abstraction now, apparently just to support hybrid cloud installations.
The marketing lingo appeals to developers as if it makes all this simple, when in fact it may be more complicated.
This seems nice though: https://github.com/knative/docs/tree/master/serving#more-sam...
It seems to have OpenTracing (Zipkin) integration: https://github.com/knative/docs/blob/master/serving/debuggin... (you need to install elasticsearch and stuff for it of course: https://github.com/knative/docs/blob/master/serving/installi... )
And assigning a custom domain: https://github.com/knative/docs/blob/master/serving/using-a-... ... okay, I was hoping that I can specify a whole URL where to mount the "app" (something like https://my.fancy.pants.tld/api/app2/
It seems to me that the weakest part of this is build currently. Mostly because that's what's pretty linear and one-off, and well explored by other projects (GitLab CI/CD can easily run on and deploy to k8s), and knative is mostly about serving and eventing, meaning all the interaction between the lifecycles of stuff on k8s.
https://docs.openshift.com/container-platform/3.3/install_co...
https://deis.com/docs/workflow/understanding-workflow/archit...
disclaimer: I was one of the core maintainers of Deis Workflow.
I think looking at build is not interesting, because it seems that knative currently focuses on the serving and events part (some thoughts on this you might find interesting: https://news.ycombinator.com/item?id=17607401 )
The repository is just an example. Using an internal repo seems just as easy.
I had to learn Kubernetes very recently and this seems to simplify a lot of the boilerplate needed to have an app running.
One the most grating part for me was having the ingress run with a proper SSL certificate with the right handshakes though (had to install a nginx controller just for that).
That’s the kind of things that everyone will go through, and is solved in one click on heroku. Yet it seems to be left out of all the samples, if it’s out of the scope that diminishes a lot the appeal.
https://github.com/Kong/kubernetes-ingress-controller
Knative uses parts of Istio for servign and TLS/SSL setup: https://github.com/knative/docs/blob/master/serving/using-an...
It's a bit funny that knative serving is so complicated I have still no idea what they use under the many layers of abstraction (probably something hacked together in go), and I don't understand why don't they use a generic configurable ingress component.