rkt isn't built around systemd. It does use it internally and integrates well with it.
Inside of rkt there is an internal logical separation between the tool that sets up the container filesystems and the one that executes them. We call those things stages[1].
Now inside of rkt we have a few different "stage1" options today:
- systemd: this means that your container has a real init system
- clear containers: execute the container inside of a virtual machine with lkvm.[2]
- direct execution w/ fly: no init system is involved for special privileged containers.[3]
If someone wanted to contribute a stage1 that used a different init system that would be great. But, today systemd works fine and is generally an implementation detail. We also get some bonuses by using systemd on systemd systems like machinectl integration, and journald integration.
Also, I should note that rkt should work on non-systemd systems as well. Again, because, systemd is an internal detail.
Inside of rkt there is an internal logical separation between the tool that sets up the container filesystems and the one that executes them. We call those things stages[1].
Now inside of rkt we have a few different "stage1" options today:
- systemd: this means that your container has a real init system
- clear containers: execute the container inside of a virtual machine with lkvm.[2]
- direct execution w/ fly: no init system is involved for special privileged containers.[3]
If someone wanted to contribute a stage1 that used a different init system that would be great. But, today systemd works fine and is generally an implementation detail. We also get some bonuses by using systemd on systemd systems like machinectl integration, and journald integration.
Also, I should note that rkt should work on non-systemd systems as well. Again, because, systemd is an internal detail.
[1] https://coreos.com/rkt/docs/latest/devel/architecture.html#s... [2] https://coreos.com/blog/rkt-0.8-with-new-vm-support/ [3] https://coreos.com/blog/rkt-0.15.0-introduces-rkt-fly.html