Are there any plans to support more Kubernetes resources and specs?

[mamiu]

First of all: Thanks a lot for building acorn! It's an amazing tool and would solve a lot of issues for us.

But what plans do you have in terms of supporting all the specs of the different resources (e.g. like Deployments or Pods)?
Because, as you know, things like Affinity, Deployment Strategy, DaemonSet, etc. are quite common in Kubernetes environments.

[ibuildthecloud]

Yes, absolutely, things are just in progress still. Scheduling rules and resource constraints are the two obvious things we are missing. We will add update strategies two, but we want to ensure we do things that are intuitive to the user and not just copy and paste every field from k8s.

DaemonSets are a tricky one. They really have almost no applicability in the application domain and almost always used for infrastructure services. I'm curious what your use case is. One approach we have looked at is doing basically something like

containers: ds: {
  image: "foo"
  scale: "per-node"
}

The only problem with this approach is that is gets wonky with volumes. k8s doesn't have a native way to essentially do a statefulset daemonset. So if you do per-node and use a volume the behavior is non-intuitive. For this reason, if we support daemonsets, we might actually do a fake daemonset in that we create one deployment per node under the hood to make the behavior make sense.

Similar to this is StatefulSets. We support stateful applications (I explain this in detail if you want the meetup from August 10) but we do it in a slightly different way from StatefulSets and as such we don't actually use StatefulSets under the hood. Maybe this will prove to be a bad idea, but so far has worked well.

I guess the point I'm making is that we aren't just looking to perfectly mirror everything in k8s because then all the complexities and oddities of k8s bleed through. So we are carefully adding each feature.

[mamiu]

Yes, absolutely, things are just in progress still. Scheduling rules and resource constraints are the two obvious things we are missing. We will add update strategies two, but we want to ensure we do things that are intuitive to the user and not just copy and paste every field from k8s.

That's amazing!
I 100% agree that just copy-and-pasting all the fields from k8s isn't a good idea. I clearly see that you haven't done this so far and that's what makes AML so elegant in comparison to all the alternatives!

DaemonSets are a tricky one. They really have almost no applicability in the application domain and almost always used for infrastructure services. I'm curious what your use case is.

Interesting... I've never thought about it, but you're right. We only use DaemonSets for infrastructure services.
So yes, if Acorn wants to focus exclusively on the application domain, then the support of DaemonSets might not be necessary.
But I like the scale: "per-node" approach anyway. You could even achieve a vertically scalable "DaemonSet" with it, which isn't possible with DaemonSets currently.

We support stateful applications (I explain this in detail if you want the meetup from August 10) but we do it in a slightly different way from StatefulSets and as such we don't actually use StatefulSets under the hood. Maybe this will prove to be a bad idea, but so far has worked well.

Yes, I watched the StatefulSet example from your first meetup and was amazed and impressed by this approach. I'm pretty sure that the storage and network part of this approach should work fine.
But how did you solve the up and down scaling, because it requires a very specific behavior for StatefulSets (or the uses cases StatefulSets are made for).

I guess the point I'm making is that we aren't just looking to perfectly mirror everything in k8s because then all the complexities and oddities of k8s bleed through. So we are carefully adding each feature.

Totally agree! That's the entire raison d'etre of Acorn.

[mamiu]

One more thing:
Since you mentioned Ingress a couple of times in the meetup, it would be great if Acorn supported the new Gateway API as well (in future versions), cause it seems to be the successor of the Ingress API and is much more flexible.

[cjellick]

Going to convert this to a dicsussion