EKS tries to create system processes (kube-system namespace) incorrectly on Admiralty virtual nodes about admiralty HOT 4 OPEN

It looks like the virtual nodes have taints, but that the aws-node daemonset is ignoring it.

kubectl describe node admiralty-default-multi-cloud-test-cluster-c962bad2df | grep Taints
virtual-kubelet.io/provider=admiralty:NoSchedule

from admiralty.

I added a label to the EKS nodes and patched the aws-node daemonset to use a node selector, but only partial success. EKS no longer tries to deploy to the remote cluster's virtual node, but unfortunately the Admiralty virtual node for the local cluster also picked up the label, so aws-node is still trying to deploy to the Admiralty node.

from admiralty.

You can exclude labels from being picked up, cf. #115.

from admiralty.

Thanks for the recommendation @adrienjt. I should point out that my attempts to tweak aws-node are really kind of hacky since aws-node is supplied by EKS and isn't something I control (though I can obviously make changes to it).

Maybe I'm misunderstanding, but I think this conflict between Admiralty and EKS is something Admiralty needs to address, even if it's in documentation. Altering the aws-node daemonset might ultimately be part of the solution, but it seems to me it should be part of the Admiralty install.

Or am I missing something?

from admiralty.