I didn’t quite “get” Juju when it was released, so I’m going to ask stupid questions now about the Juju K8S support stuff, purely for my own reasoning and helping planning future development efforts and focus.
I’ve been looking at the stuff @wallyworld has been doing with Gitlab and MariaDB/MySQL and its intriguing but I have a few noddy questions I’d like someone to help with if possible:
a) How does Juju’s K8S support differ from say, Helm or the new Applications support in GKE? For example, why would I bother using Juju to orchestrate my K8S deployments when I already have Helm charts?
b) What’s the roadmap look like?
c) What’s the rough target for the initial public release?
Possibly you have it backwards here ? I think the idea is, why use helm charts when you have juju
This way (@wallyworld please correct me) , things deployed via juju in k8s will have interoperability with the rest of your juju deployed stack + Consistency (using juju across all the clouds) + k8s operational/usability enhancement by abstracting the operational/workflow side of k8s to ‘juju deploy’. Look at the problem Deis solves, k8s models in juju could provide a similar solution.
Straight up, the use of charms offers an advantage over Helm charts as they work at a higher level of abstraction. Instead of having to deal with volumes, volume mounts, config map and all the low level boiler plate, you use the Juju storage modelling for setting up mounted volumes; the charm provides a nice way of defining and generating user customisable workload config at specified locations etc. Plus there’s the standard Juju syntax for constraints (mapped to resource limits), placement (mapped to node affinity) and now also devices (GPU).
By modelling the OCI (docker) images as resources, you also gain the nice benefits of controlled and deterministic publication of the tuple of image and charm; repeatable deployments etc. The charm store hosts both charm and image making offline/enterprise on prem deployments easier to set up.
Syntactic sugar aside, the real power of Juju comes into play in the same way as it does for cloud based deployments. A model based approach for managing complex workloads. And cross platform integration where containerised and non-containerised workloads can be deployed and managed across substrates. Kubernetes is great, but its current state of evolution reminds us of how things looked a few years back when everyone started jumping across to the cloud - problems exist which weren’t obvious at the time as people start started piling on and getting stuff working.
The mariadb/gitlab example is just an initial “hello world” thing. We plan on publishing more compelling deployment stories, especially around ML/AI workflows etc. @carmine-rimi is working hard on that. But imagine modelling an ML/AI solution with integration to version control, CI/CD, storage or other services located on external clouds etc.
The initial public release will be with Juju 2.5 in the coming weeks. You can use all of the stuff documented to date on this forum with the 2.5 edge snap.
The next cycle roadmap is being planned this week. We are considering features such as
bootstrap straight into Kubernetes without needing an external controller
Thanks folks, useful insight. I’m just trying to figure out roadmaps for Big Data charms etc and clearly Hadoop/Data Processing engines in K8S alongside baremetal/cloud deployments makes sense, but picking the orchestration less so, because as you point out @wallyworld because of how K8S is evovolving, there’s a lot of them!
I am certainly interested in giving this a go though, I might port my Apache Drill charm or similar in the next few weeks to get my toes wet.
Yup, the initial thinking is to do what you are asking for. It’s not top priority right now - we are working to get juju bootstrap directly into k8s working next up.
