Skip to content

Commit e6b1ee1

Browse files
jawnsyKatie Horne
and
Katie Horne
authored
chore: add missing node label step (coder#828)
With the example deployment manifest for smarter-device-manager, users need to label compatible nodes in order for the DaemonSet to run. Co-authored-by: Katie Horne <katie@coder.com>
1 parent 147ea4e commit e6b1ee1

File tree

1 file changed

+102
-56
lines changed

1 file changed

+102
-56
lines changed

guides/deployments/podman.md

Lines changed: 102 additions & 56 deletions
Original file line numberDiff line numberDiff line change
@@ -42,6 +42,7 @@ Linux kernel doesn't support CVMs.
4242
values:
4343
- system-node-critical
4444
- system-cluster-critical
45+
4546
---
4647
apiVersion: v1
4748
kind: ConfigMap
@@ -127,79 +128,124 @@ Linux kernel doesn't support CVMs.
127128
kubectl apply -f ./smarter-device-manager.yaml
128129
```
129130

131+
The example `DaemonSet` includes a `nodeSelector` that constrains the device
132+
plugin to nodes with the `smarter-device-manager` label set to `enabled`.
133+
Label the nodes that will include the FUSE device by using the following
134+
command, or remove the `nodeSelector` from the manifest:
135+
136+
```console
137+
kubectl get nodes
138+
kubectl label nodes --all smarter-device-manager=enabled
139+
```
140+
130141
1. If you haven't already done so for your Coder deployment, enable workspace
131142
templates. To do so, go to **Manage** > **Admin** > **Templates**, and set
132143
the **Enable workspace templates** to **On**. Click **Save**.
133144

134-
1. Create a YAML file with the following contents (the instructions ask the
135-
cluster to request the FUSE device for each workspace):
145+
1. Create a
146+
[workspace configuration file](../../workspaces/workspace-templates/templates.md)
147+
that includes instructions for resource requests and resource limits (the
148+
instructions ask the cluster to request the FUSE device for each workspace):
136149

137150
```yaml
138151
version: "0.2"
139152
workspace:
140-
configure:
141-
start:
142-
policy: write
143-
dev-urls:
144-
policy: write
145-
specs:
146-
aws-ec2-docker:
147-
container-image:
148-
policy: write
149-
disk-size:
150-
policy: write
151-
instance-type:
152-
policy: write
153-
docker:
154-
container-based-vm:
155-
policy: write
156-
image:
157-
policy: write
158-
kubernetes:
159-
annotations:
160-
policy: read
161-
container-based-vm:
162-
policy: write
163-
cpu:
164-
policy: write
165-
disk:
166-
policy: write
167-
env:
168-
policy: write
169-
gpu-count:
170-
policy: write
171-
image:
172-
policy: write
173-
labels:
174-
policy: read
175-
memory:
176-
policy: write
177-
node-selector:
178-
policy: read
179-
privileged:
180-
policy: read
181-
resource-requests:
182-
policy: write
183-
value:
184-
smarter-devices/fuse: "1"
185-
resource-limits:
186-
policy: write
187-
value:
188-
smarter-devices/fuse: "1"
189-
runtime-class-name:
190-
policy: read
191-
tolerations:
192-
policy: read
153+
specs:
154+
kubernetes:
155+
resource-requests:
156+
policy: write
157+
value:
158+
smarter-devices/fuse: "1"
159+
resource-limits:
160+
policy: write
161+
value:
162+
smarter-devices/fuse: "1"
163+
```
164+
165+
A complete workspace template might look something like
166+
167+
```yaml
168+
version: "0.2"
169+
workspace:
170+
configure:
171+
start:
172+
policy: write
173+
dev-urls:
174+
policy: write
175+
specs:
176+
aws-ec2-docker:
177+
container-image:
178+
policy: write
179+
disk-size:
180+
policy: write
181+
instance-type:
182+
policy: write
183+
docker:
184+
container-based-vm:
185+
policy: write
186+
image:
187+
policy: write
188+
kubernetes:
189+
annotations:
190+
policy: read
191+
container-based-vm:
192+
policy: write
193+
cpu:
194+
policy: write
195+
disk:
196+
policy: write
197+
env:
198+
policy: write
199+
gpu-count:
200+
policy: write
201+
image:
202+
policy: write
203+
labels:
204+
policy: read
205+
memory:
206+
policy: write
207+
node-selector:
208+
policy: read
209+
privileged:
210+
policy: read
211+
resource-requests:
212+
policy: write
213+
value:
214+
smarter-devices/fuse: "1"
215+
resource-limits:
216+
policy: write
217+
value:
218+
smarter-devices/fuse: "1"
219+
runtime-class-name:
220+
policy: read
221+
tolerations:
222+
policy: read
193223
```
194224
195225
1. In the Coder UI, navigate to **Manage** > **Admin** > **Templates** if you
196226
haven't already done so. Under **template policy**, upload the configuration
197227
file you created in the previous step. Click **Save**.
198228
199-
1. If you have SELinux and AppArmor enabled, please disable both.
229+
With the above template policy, all workspaces will acquire a FUSE device,
230+
which enables Podman to operate in rootless mode.
231+
232+
## For systems running AppArmor and SELinux
233+
234+
Running Podman in rootless mode requires a FUSE device to implement the overlay
235+
filesystem (fuse-overlayfs) in unprivileged mode. The following directions work
236+
by mounting the FUSE device from the host into workspace containers, which
237+
conflicts with the isolation provided by SELinux and AppArmor.
238+
239+
For systems running AppArmor (typically Debian- and Ubuntu-derived systems),
240+
please disable AppArmor before proceeding.
241+
242+
For systems running SELinux (typically Fedora-, CentOS-, and Red Hat-based
243+
systems), please disable SELinux or set it to `permissive` mode.
200244

201245
## Testing
202246

203247
At this point, you can create a workspace that leverages Podman. If you need a
204248
sample Podman image, you can obtain one
205249
[from RedHat](https://quay.io/repository/podman/stable?tag=latest&tab=tags).
250+
When using this image, switch to the unprivileged `podman` user before creating
251+
containers to ensure that `podman` runs in rootless mode.

0 commit comments

Comments
 (0)