# Nix shim as an alternate workload for kubernetes?
**URL:** https://discourse.nixos.org/t/nix-shim-as-an-alternate-workload-for-kubernetes/28907
**Category:** Development
**Created:** [June 8, 2023, 4:22pm UTC](https://discourse.nixos.org/t/nix-shim-as-an-alternate-workload-for-kubernetes/28907 "2023-06-08T16:22:38Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@senorsmile](https://discourse.nixos.org/u/senorsmile)
#### Post date: [June 8, 2023, 4:22pm UTC](https://discourse.nixos.org/t/nix-shim-as-an-alternate-workload-for-kubernetes/28907/1 "2023-06-08T16:22:38Z")
PlatformCon 2023 is going on. During the first talk:
https://www.youtube.com/embed/53jy7hhaFsM?feature=oembed&wmode=opaque&list=PLR74Ng-6aEfAbZGP2HIRJBHkWNggMy-fS
the presenter explains how Web Assembly can replace the containerd shim with a wasm shim that runs wasm workloads directly (instead of containers).
The idea I’ve had for a while but now want to discuss viability publicly: develop a nix shim that works with containerd, replacing runc, that “spins up” Nix workloads without any of the container semantics involved at all.
This seems like a very cool use case to propel Nix into the distributed computing world by using Kubernetes.
To play my own devil’s advocate, the first con that comes to mind is that nix doesn’t provide any sort of isolation (by default) like containers do. However, if isolation is necessary for security reasons, there are methods of isolating processes similar to what containers do (but without the strict semantics of using OCI containers with the layered images etc).
What do you think? Is this an idea worth exploring?
EDIT: fix containerd vs runc confusion
---
### Author:  [@RaitoBezarius](https://discourse.nixos.org/u/RaitoBezarius)
#### Post date: [June 8, 2023, 5:11pm UTC](https://discourse.nixos.org/t/nix-shim-as-an-alternate-workload-for-kubernetes/28907/2 "2023-06-08T17:11:31Z")
I’m not sure if this is where Nix would be optimal regarding Kubernetes.
> [@senorsmile](#):
>
> To play my own devil’s advocate, the first con that comes to mind is that nix doesn’t provide any sort of isolation (by default) like containers do.
I don’t understand this. Are we talking about Nix the package manager? Nix during builds uses bubblewrap for sandboxing already.
If you are talking about just using Nix to build on-demand things and run it as a classical thing, you may as well, chain nix and runc and this becomes clear that Nix is just not providing any real value, is it?
You can just have Nix for your build phase.
> [@senorsmile](#):
>
> However, if isolation is necessary for security reasons, there are methods of isolating processes similar to what containers do (but without the strict semantics of using OCI containers with the layered images etc).
For run, this seems to be akin to reinventing existing shims IMHO.
* * *
I think your focus is really about building OCI containers and smart ways to do it.
---
### Author:  [@gytis-ivaskevicius](https://discourse.nixos.org/u/gytis-ivaskevicius)
#### Post date: [June 9, 2023, 10:46am UTC](https://discourse.nixos.org/t/nix-shim-as-an-alternate-workload-for-kubernetes/28907/3 "2023-06-09T10:46:37Z")
I believe this is what you are looking for, just for k8s [GitHub - input-output-hk/nomad-driver-nix: A Nomad task driver for systemd-nspawn](https://github.com/input-output-hk/nomad-driver-nix)
---
### Author:  [@senorsmile](https://discourse.nixos.org/u/senorsmile)
#### Post date: [June 10, 2023, 10:54pm UTC](https://discourse.nixos.org/t/nix-shim-as-an-alternate-workload-for-kubernetes/28907/4 "2023-06-10T22:54:28Z")
Cool. That may be the general direction I’m thinking.
---
### Author:  [@blaggacao](https://discourse.nixos.org/u/blaggacao)
#### Post date: [June 11, 2023, 3:49pm UTC](https://discourse.nixos.org/t/nix-shim-as-an-alternate-workload-for-kubernetes/28907/5 "2023-06-11T15:49:49Z")
@senorsmile Nix is rather sitting at the same functional system layer as OCI images:
- OCI images assemble envrionments for runnables
- Nix assembles environments for runnables
The difference is that the _current_ OCI image standard works on (127?) layers and resolves path conflicts with an overlay assembly spec, essentially a DSL that can express things like “remove that file” and similar things that higher layers might do to lower layers inside the context of the FSH.
On the other hand, Nix does never produce conflicts on “layers” due to unique (store-)paths and thus can afford to work with a DAG closure (a set rather than a list; order doesn’t matter) instead of (list-y) layers and is also not limited by the 127 layer limit, which iirc was an arbitrary performance-motivated cutoff.
* * *
Regarding a potential implicit confusion in this thread: Nix is _not_ NixOS, which, for the purpose of this argument, is “just” a wrapper around systemd.
I assume the quest is how Nix relates to the OCI spec and _not_ how systemd (or any other runtime jailing mechanism) relates to the OCI spec.
---
### Author:  [@senorsmile](https://discourse.nixos.org/u/senorsmile)
#### Post date: [October 10, 2023, 3:52pm UTC](https://discourse.nixos.org/t/nix-shim-as-an-alternate-workload-for-kubernetes/28907/6 "2023-10-10T15:52:42Z")
nix-snapshotter solves the problem space I envisioned: [Nix-snapshotter: Native understanding of Nix packages for containerd](https://discourse.nixos.org/t/nix-snapshotter-native-understanding-of-nix-packages-for-containerd/32696)