This feature tracks the ability to automatically grow and shrink memory based on application usage.

Considering

Dynamic Memory Ballooning

For services that are intended to be reachable only from certain IPs/IP ranges, adding the ability for whitelisting would improve security.

IP whitelisting for services

Manage environment variables in a group of variables and be able to reference the group when creating an instance.

Environmental Variable Groups

This feature allows applications on Unikraft to use the <code>fork</code> and <code>vfork</code> system calls to spawn processes, in cases where the <code>fork</code> is followed by an <code>exec</code> system call.This will allow executing many multi-process applications as well as allow shells like <code>bash</code> to execute scripts on Unikraft.

In Progress

Multi-process Applications

Currently, autoscale allows policies based on CPU utilization only. It should be possible to also create policies based on network load. More specifically:<ul><li>Requests / second (or connections for non-HTTP services)</li><li>Number of in-flight requests (or in-flight connections for non-HTTP services)</li></ul>

Connection-based autoscale metrics

Currently, once you create a service group all properties are fixed. You have to re-create the service group if you want to change something. This is problematic especially for service groups, where you want to add/remove/update services or domains after creation because it means you also have to re-create the instances. Furthermore, you cannot avoid a downtime in this case.It should thus be possible to change settings of service groups without having to re-create the group.

Changing properties of service groups after creation

This feature allows multiple instances to mount the same volume in read-only mode.

Completed

Shared Read-only Volumes

This feature tracks the ability to monitor application instance network traffic, e.g. network ingress/egress (bytes); CPU utilization; and memory utilization.

Instance Usage Statistics

Scale-to-zero is currently based on a cooldown period. This means If the application is performing a background task, which is running after the response has been send to the last request, the background task will be canceled if it takes too long.It would be desirable to be able to disable/enable scale-to-zero from the application to allow background tasks to finish.This would be achieved using a pseudofs controls, e.g.:<pre><code>import "fmt"

func main() {
 // echo 1 &gt; /sys/kraftcloud/scale-to-zero
 _ = os.WriteFile("/sys/kraftcloud/scale-to-zero", []byte{"1\n"}, 0644)
}</code></pre>and via our native SDKs e.g.<pre><code>import (
 kcp "github.com/kraftcloud/go-sdk/platform"
)

func main() {
 _ = kcp.ScaleToZero()
}</code></pre>

Let applications control when scale-to-zero is allowed

Currently, scale-to-zero is implemented as part of autoscale when the service group is scaled down to 0 instances. This means you cannot have multiple instances scaled-to-zero for the same service.However, to reduce scaling latency to a minimum it would be preferable to have scale-to-zero as a property on the instance, completely independent of the periodic policy-based autoscale. This would allow you to have a set of replicas all in <code>standby</code> and immediately available when needed.

Allow scale-to-zero for multiple instances in a service group

This feature allows using a wildcard domain, e.g. <code>*.example.com</code>.

Wildcard Domain Support

This feature allows for setting different actions to occur when an instance's state changes from <code>running</code> to either restart "<code>never</code>", "<code>always</code>" or only "<code>on-failure</code>".

Instance Restart Policies

This feature allows application instances to be suspended in a manner that saves their state; allowing them to be resumed (in milliseconds).

Stateful Cold-Starts

This feature allows creating and running Linux-based instances with multiple vCPUs. Currently, all instances irrespective of type are limited to 1 vCPU.

Planned

Multi-core Linux Instances

Currently it is only possible to set environmental variables and application arguments one time and that's during instance creation. It should be possible to set new environmental variables and application arguments after an instance has been created (e.g. when it is first started or after restarted).

Set environmental variables and arguments after creating an instance

Provide support to connect to Unikraft-based instances and execute various built-in commands like:<ul><li>listing open sockets / connections</li><li>checking network and DNS configuration</li><li>pinging remote hosts</li><li>browsing the file system</li></ul>

Virtual TTY Console

Trace all actions in your account; from API requests to change of state from instances, services, volumes and more.

Unikraft Cloud Platform