Introduce Runtime Core (Spawn, Pods, Containers, Instances, VMs, and Cells)

[krisnova]

Introduce the concept of Pods, Instances, Cells, Virtual Machines, Executables, and Containers to Aurae.

This calls out the Core service in the Runtime subsystem.

  rpc RunExecutable(Executable) returns (ExecutableStatus) {}
  rpc RunPod(Pod) returns (PodStatus) {}
  rpc Spawn(SpawnRequest) returns (SpawnResponse) {}
  rpc RunVirtualMachine(VirtualMachine) returns (VirtualMachineStatus) {}
  rpc RunCell(Cell) returns (CellStatus) {}

What is an "Aurae Pod"?

In order to play as nicely as possible with Kubernetes and the community we make the assumption that most users of Aurae will try to "run pods".

In order to introduce an added layer of security, and make the secure path the easy path we make Aurae pods behave like normal Kubernetes pods, but create a more secure and elaborate runtime isolation zone.

An Aurae pod is a set of containers (called a Cell in Aurae) running in a unique cgroup. This cell runs inside of a nested Aurae virtual instance that is created using the Spawn() RPC.

First Aurae spawns a new virtual instance of itself, and inherits properties from the parent. Then a cell of containers is established in the newly created nested Aurae instance.

What about the Kubelet? Will it be a drop in replacement?

In short, no. Aurae will not be a drop-in replacement for the kubelet. However we can build and support adapter patterns, shims, and translation services later if necessary.

The rational to keep the pod nomenclature is as follows:

If we intend to support the Kubernetes control plane (which I believe we should) we will need to play as nice as possible with the API server. While I don't believe Aurae itself should be a drop in replacement for the Kubelet. There is nothing wrong with building a lightweight service in the future to spoof the Kubelet the same way the virtual kubelet has.

Kubelet Documentation To Consider while developing.

In an effort to bring light to the Kubelet documentation here are some notes from my years of hacking on Kube.

• The Pod Manager is the source of truth for Pod functionality
• The Host Interface are the methods that the Kubelet HTTP server uses to populate HTTP routes
• Install Default Handlers are the aforementioned routes.

Signed-off-by: Kris Nóva kris@nivenly.com