flatcar
[RFE] PoC for smallest possible Flatcar OS base image to support sysext
Aiming for the smallest version that could be created for edge environments.
Small in terms of RAM usage or disk usage? If we diverge from the standard 1 GB + 1 GB disk partitions this is more involved. One can already use the PXE squashfs image with bootloader customization but while it needs lesser disk space there is no A/B update scheme and it currently would use more RAM.
A minimal PXE image would indeed be a good direction for this PoC. Please remember, this is a "What If..." without plans to bring this into production currently.
The PXE squashfs is a separate initrd but we could maybe support to load it from disk though a cmdline parameter that we evaluate in the initrd. This would save RAM. To minimize the image, candidates to throw out would be, for example, git and certain auth infra, but first I think we should make the use case a bit more detailed - I assume we still would have containerd, and maybe expect Kubernetes to run?
Agree on fleshing out the use case some more. This is a moonshot /proof-of-concept/hack with the sole purpose of gaining a rough understanding of the minimal size achievable. Can be a super basic hack that reduces the OS base image packages to an absolute minimum (systemd+kernel) so we can add sysexts on top, and a df -h on a live image to check for size,
With splitting out some base image content into a Flatcar "extras" extension we can reduce the size of the squashfs that the PXE boot uses.
For A/B updates I think that 1 GB for a partition is already quite low and if the system should be future proof I think it doesn't make sense to go below that.
Hello, was thinking about this concept and would like to start a list here on what should be changed / removed / added to the Flatcar Core image.
From what I see, the image will not be backwards compatible and we should use the best / latest concepts and projects industry has.
Core components:
- grub - maybe we can switch to systemd boot?
- linux
- systemd
Binaries:
- GNU base tooling
Services:
- ssh
- container runtime
I'm less concerned about the disk size. Which of course would be a benefit as well. But I'm coming into this more from the security / intrusion perspective. Because we would like to be able to build an image for one purpose only: "Running containers on Kubernetes".
Which would mean we should be able to remove all CLI/TTY related tools and utilities similar to how Talos Linux does it. Of course they are a different bread entirely as they don't rely on systemd and have their own so called minimalistic machined system manager.
