That’s right, version 0.6.0 of Acorn is here and it has some great features and enhancements. Headlining this release are features to simplify the scheduling and allocation of workloads and volumes.
ComputeClass for CPU and Memory
Have you ever been tripped up by Kubernetes resource management – resource requests, resource limits, CPU units, and the like? How about combining those with scheduling rules like taints, tolerations, and node affinities to get that workload placement “just right“?
Well, Acorn’s computeClass feature greatly simplifies that for end-users (developers that just want to ship their app) while still giving administrators a lot of control. With this feature, landing an application where you want and with proper constraints is just a couple extra flags:
acorn run --compute-class memory-optimized --memory 1Gi ghcr.io/acorn-io/library/hello-world
To an end-user, that’s very straightforward, but under the covers, a lot is going on. We are:
- setting memory resource limits and requests for each container in the application
- proportionally setting CPU resource requests based on the memory request and rules set forth in the “memory-optimized” computeClass
- adding tolerations and nodeAffinities to each container in the app, again based off of rules set forth in the computeClass
If a developer were to do this via traditional Kubernetes yaml, it would be dozens of lines of configuration per workload. With acorn, it’s just two flags!
ComputeClasses can be configured at the cluster level or on per-project basis by administrators via CRDs. When a user needs to discover what computeClasses are available to them, just need to run a simple command:
$ acorn offerings computeclasses NAME DEFAULT MEMORY RANGE MEMORY DEFAULT DESCRIPTION compute-optimized 1Gi-32Gi 1Gi Large compute for linux. Get a lot of CPU relative your memory request.
For more information, check out the docs for end-users and administrators.
VolumeClass for Persistent Storage
As computeClass simplifies and tidies the UX around CPU and memory, our volumeClass feature does the same for storage. This feature builds on Kubernetes’s storageClass feature by addressing some common usability problems.
End-users have much more visibility into their storage options. There’s a first-class command for it:
$ acorn offerings volumeclasses NAME DEFAULT INACTIVE STORAGE-CLASS SIZE-RANGE DEFAULT-SIZE ACCESS-MODES DESCRIPTION ephemeral Unrestricted Acorn-generated volume class representing ephemeral volumes not backed by a storage class hostpath * hostpath Unrestricted Acorn-generated volume class representing the storage class hostpath
The above output should highlight some other key aspects of the feature: administrators can explicitly control and expose things like valid sizes, default size, and access mode. Administrators can also control volumeClasses at both the cluster and project level. This means that volumeClasses can be made available to everyone or restricted to just specific projects.
To learn more, here are the end-user and admin docs.
This release is packed with other enhancements and bug fixes. You can check out the release notes to see them all, but a few highlights are:
- PodDisruptionBudgets have been added to all acorn workloads
- Fixes and enhancements to our auto-upgrade feature
- Improved and enhanced projects UX
- Leader election added to the acorn control plane for smoother upgrades of acorn
We hope you find these features useful and look forward to your feedback! As always, you can reach us on Github, Slack, Twitter, and LinkedIn with feedback or questions! Please join us for one of our live trainings if you’d like to get a hands-on overview of Acorn.