You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/user-namespaces/README.md
+35-7
Original file line number
Diff line number
Diff line change
@@ -86,22 +86,22 @@ Different containerd versions have different limitations too, those are highligh
86
86
### containerd 1.7
87
87
88
88
One limitation present in containerd 1.7 is that it needs to change the ownership of every file and
89
-
directory inside the container image, during Pod startup. This means it has a storage overhead (the
90
-
size of the container image is duplicated each time a pod is created) and can significantly impact
91
-
the container startup latency.
89
+
directory inside the container image, during Pod startup. This means it has a storage overhead, as
90
+
**the size of the container image is duplicated each time a pod is created**, and can significantly
91
+
impact the container startup latency, as doing such a copy takes time too.
92
92
93
93
You can mitigate this limitation by switching `/sys/module/overlay/parameters/metacopy` to `Y`. This
94
94
will significantly reduce the storage and performance overhead, as only the inode for each file of
95
95
the container image will be duplicated, but not the content of the file. This means it will use less
96
96
storage and it will be faster. However, it is not a panacea.
97
97
98
-
If you change the metacopy param, make sure to do it in a way that is persistant across reboots. You
98
+
If you change the metacopy param, make sure to do it in a way that is persistent across reboots. You
99
99
should also be aware that this setting will be used for all containers, not just containers with
100
100
user namespaces enabled. This will affect all the snapshots that you take manually (if you happen to
101
101
do that). In that case, make sure to use the same value of `/sys/module/overlay/parameters/metacopy`
102
102
when creating and restoring the snapshot.
103
103
104
-
### containerd 2.0
104
+
### containerd 2.0 and above
105
105
106
106
The storage and latency limitation from containerd 1.7 are not present in container 2.0 and above,
107
107
if you use the overlay snapshotter (this is used by default). It will not use more storage at all,
@@ -111,8 +111,36 @@ This is achieved by using the kernel feature idmap mounts with the container roo
111
111
image). This allows an overlay file-system to expose the image with different UID/GID without copying
112
112
the files nor the inodes, just using a bind-mount.
113
113
114
-
You can check if you are using idmap mounts for the container image if you create a pod with user
115
-
namespaces, exec into it and run:
114
+
Containerd by default will refuse to create a container with user namespaces, if overlayfs is the
115
+
snapshotter and the kernel running doesn't support idmap mounts for overlayfs. This is to make sure
116
+
before falling back to the expensive chown (in terms of storage and pod startup latency), you
117
+
understand the implications and decide to opt-in. Please read the containerd 1.7 limitations for an
118
+
explanation of those.
119
+
120
+
If your kernel doesn't support idmap mounts for the overlayfs snapshotter, you will see an error
121
+
like:
122
+
123
+
```
124
+
failed to create containerd container: snapshotter "overlayfs" doesn't support idmap mounts on this host, configure `slow_chown` to allow a slower and expensive fallback
125
+
```
126
+
127
+
Linux supports idmap mounts on an overlayfs since version 5.19.
128
+
129
+
You can opt-in for the slow chown by adding the `slow_chown` field to your config in the overlayfs
return"", fmt.Errorf("snapshotter %q doesn't support idmap mounts on this host, configure `slow_chown` to allow a slower and expensive fallback", snapshotterName)
0 commit comments