I have an always growing Kubernetes cluster. I currently have a cluster made of 2 Raspberry Pis and 1 PC but HOW, isn’t that frowned upon? Well, you can use the NodeSelector attribute to make the containers stick to specific nodes. The specifics we are covering in this article are the CPU architectures of the nodes since the Raspberry Pis run ARM and my PCs run AMD64.
The more nodes you have the more redundancy your containers have but that comes at a cost of the underlying compute and storage. I am mixing my Raspberry Pis with my “older” PCs. The only thing I have to do before a deployment is check if the container’s support the CPU types I have in the cluster. If containers don’t have support for both or if I only want to run the containers on specific nodes I can use the NodeSelector attribute to do so. If the containers can run both then you can deploy as is since any trigger to move the containers will destroy the current container and pull the new one which will trigger the build based on the node.
I. Checking container’s compatibility
The best place to check is in the repo. DockerHub makes it easy to check since you can go to the tags and see the different architectures.
If your containers are not hosted in DockerHub you can check the build steps of the Dockerfile:
II. Adding the node selector
The nodeSelector can be added by simply adding the following lines to your Helm Chart deployments.
Raspberry Pis:
nodeSelector:
kubernetes.io/arch: arm64PCs
nodeSelector:
kubernetes.io/arch: amd64III. Deployment
Once you deploy them you can see the node restrictions when you describe your Pod
If you have Portainer you can see the Placement Preferences
IV. Wrap-Up
This will allow you to control the load of the containers in specific nodes so your lab can have high availability and containers can “self-heal” if issues.
III. Sources
https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/