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: README.md
+85-11Lines changed: 85 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,7 +16,8 @@ This is a Kubernetes controller that will do the following:
16
16
## Notes
17
17
18
18
For the above, you don't technically need NFD if you add and select your own labels, but I want to use NFD to better integrate with the larger
19
-
community. The controller webhook will work with or without it, assuming the labels you have on nodes that you are selecting for exist.
19
+
community. I've also scoped the matching labels to be for `feature.node` instead of `feature.node.kubernetes.io` so any generatd compatibility specs can be used for cases outside of Kubernetes (without the user thinking it is weird).
20
+
The controller webhook will work with or without it, assuming the labels you have on nodes that you are selecting for exist.
20
21
Next, we place this controller on the level of a webhook, meaning that it isn't influencing scheduling, but is anticipating what container
21
22
should be selected for a node based on either:
22
23
@@ -96,18 +97,18 @@ In our real world use case we would select based on operating system and kernel
96
97
we are just going to add the same label to all nodes and then check our controller based on the image selected. Let's first add "vanilla":
At this point, we want to test compatibility. This step is already done, but I'll show you how I designed the compatibility spec. The logic for this dummy case is the following:
142
143
143
-
1. If our custom label "compspec.ocifit-k8s.flavor" is vanilla, we want to choose a debian container.
144
-
1. If our custom label "compspec.ocifit-k8s.flavor" is chocolate, we want to choose a ubuntu container.
145
-
1. If our custom label "compspec.ocifit-k8s.flavor" is strawberry, we want to choose a rockylinux container.
144
+
1. If our custom label "feature.node.ocifit-k8s.flavor" is vanilla, we want to choose a debian container.
145
+
1. If our custom label "feature.node.ocifit-k8s.flavor" is chocolate, we want to choose a ubuntu container.
146
+
1. If our custom label "feature.node.ocifit-k8s.flavor" is strawberry, we want to choose a rockylinux container.
146
147
147
148
Normally, we would attach a compatibility spec to an image, like [this](https://github.com/kubernetes-sigs/node-feature-discovery/blob/master/docs/usage/image-compatibility.md#attach-the-artifact-to-the-image). But
148
149
here we are flipping the logic a bit. We don't know the image, and instead we are directing the client to look directly at one artifact. Thus, the first step was to package the compatibility artifact and push to a registry (and make it public). I did that as follows (you don't need to do this):
@@ -151,9 +152,82 @@ here we are flipping the logic a bit. We don't know the image, and instead we ar
We aren't going to be using any referrers API or linking this to an image. The target images are in the artifact.
155
+
We aren't going to be using any referrers API or linking this to an image. The target images are in the artifact, and we get there directly from the associated manifest.
156
+
Try creating the pod
155
157
156
-
**being written**
158
+
```bash
159
+
kubectl apply -f ./example/pod.yaml
160
+
```
161
+
162
+
Now look the log, the selection was vanilla, so we matched to the debian image.
163
+
164
+
```console
165
+
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
166
+
NAME="Debian GNU/Linux"
167
+
VERSION_ID="11"
168
+
VERSION="11 (bullseye)"
169
+
VERSION_CODENAME=bullseye
170
+
ID=debian
171
+
HOME_URL="https://www.debian.org/"
172
+
SUPPORT_URL="https://www.debian.org/support"
173
+
BUG_REPORT_URL="https://bugs.debian.org/"
174
+
```
175
+
176
+
Because we matched the feature.node label and it was the best fit container. Now delete that label and install
Boum! Conceptually, we are selecting a different image depending on the rules in the compatibility spec. Our node features were dummy, but they could be real attributes related to kernel, networking, etc.
0 commit comments