This message was deleted.

Importing an EKS cluster as an EKS cluster (rather than a generic cluster) requires that the EKS cluster has at least one EKS (not Rancher) managed node group. If your EKS cluster doesn't have a managed node group, then you can always import it into Rancher as a generic cluster.

thank you ! i do not understand the requirement behind having the node group for genuine eks cluster versus generic, however if i was to import the cluster as generic, would i be missing out on a functionality ? how does rancher use node group, that it's a hard prerequisite ?

The requirement comes from the fact that Rancher wants to put a deployment on the EKS cluster, but the pods in that deployment can't be scheduled on the control plane. Therefore, in order to try to guarantee that the pods will be successfully scheduled, Rancher will check for a managed node group (the only type of node group that can be found via the EKS API). If you import the cluster as a generic cluster versus an EKS cluster, then you won't be able to manage the cluster itself (add managed node groups, update the Kubernetes version, etc). You will be able to manage the items in the cluster (essentially anything you can do with helm and kubectl you would be able to do from the Rancher UI).

understood, thank you for this explanation!

That is again related to the workloads that Rancher deploys in the downstream (your EKS) cluster. You can check the

cattle-cluster-agent

pods in the

cattle-system

namespace on your EKS cluster. Those pods and their logs should give an indication of what is happening.