The following steps describe how to connect an on-premises Amazon EKS Anywhere cluster that is deployed with PowerFlex storage to the AWS EKS Connector.

Step 1- Preparations

Before getting started the EKS Connector registration, the necessary roles and policies in AWS IAM need to be created.

1. Log in to your Amazon account using the administrator with enough permissions to manage EKS and IAM resources. You must create the following two roles for this connection to work:

i             Service-linked role for Amazon EKS

ii           EKS-Connector-agent role

Service-linked role – This role is a unique type of IAM role that is linked directly to Amazon EKS. Service-linked roles are predefined by Amazon EKS and include all the permissions that the service requires to call other AWS services. 

EKS-connector-agent Role – This IAM role allows the EKS connector agent to interact with AWS Systems Manager Agent (SSM) service. This IAM role is used by the EKS Connector agent on the Kubernetes cluster to connect to the SSM service on AWS. 

2. Create a policy document to associate it with the role. The permission that is associated with this policy enables the connector to talk back with the SSM service. When you navigate through the EKS console, The console goes through EKS and SSM service until it finally communicates with the agent running inside your cluster.

For more information about creating the role and policy, see the appendix section.

Figure 9.         Amazon EKS Connector 

Step 2 - EKS Connector Cluster Registration

The cluster registration process involves two steps:

1. Register the cluster with Amazon EKS. 

2. Applying a connector YAML manifest file in the target cluster to enable connectivity.

Register the cluster with Amazon EKS 

1. The EKS console in AWS includes a register option along with the create cluster option. Open the EKS console and go to the Clusters section. Select the Register from the AddCluster dropdown.

Figure 10.     Registering EKS Connector 

2. Enter the details in the Register Cluster form as shown in the following figure:
   1. Define a name for the cluster.
   2. Select the Provider as EKS Anywhere.
   3. Select the EKS Connector Role to provide Kubernetes control plane to create the resources on your behalf. If the role is precreated, it is loaded, and ready to select.
   4. Click Register cluster.

Figure 11.     Registering the cluster

3. Once the cluster is added, the cluster name is displayed, and its status shows as Active as shown in the following figure:

Figure 12.     Clusters status

4. After registering the cluster, you will be redirected to the Cluster Overview page. Click Download YAML file to get the Kubernetes configuration file to deploy all the necessary infrastructure to connect your cluster to EKS.

Figure 13.     Cluster Registration

Applying the connector YAML manifest file to the target 

Run the following command to apply the downloaded eks-connector.yaml.

The EKS Connector runs as a StatefulSet on your Kubernetes cluster. It establishes a connection and proxies the communication between the API server of your EKS Anywhere cluster and Amazon Web Services. It does this connection to display cluster data in the Amazon EKS console until you disconnect the cluster from AWS.

The manifest file that is generated from registering a cluster contains the following components:

InitContainer: This container registers the EKS Connector agent with the Systems Manager control plane service and persists the registration information in the Kubernetes backend data store. InitContainer mounts this data to the EKS Connector agent volume when it is recycled. This eliminates the need for registration whenever a pod is recycled.

EKS Connector agent: This is an agent based on the SSM agent, running in container mode. This agent creates an outbound connection from the Kubernetes cluster to the AWS network. All subsequent requests from AWS are performed using the connection channels that are established by the EKS Connector agent.

Connector proxy: This agent acts as a proxy between the EKS Connector agent and Kubernetes API Server. This proxy agent uses the Kubernetes service account to impersonate the IAM user that accesses the console and fetches information from the Kubernetes API Server.

The EKS connector agent interacts with the SSM service, which in turn interacts with EKS service using EventBridge. To facilitate these interactions, the EKS connector agent role is required with appropriate permissions to create, open, and control the SSM channels.

Upon successful registration, the changes can be seen in the AWS EventBridge services. A new event rule with the pattern of registration and deregistration is created under the default event bus.

Step 3 - Permission to view Kubernetes resources of connected cluster from AWS Console.

Granting access to a user to view the Kubernetes resources of a connected cluster from the AWS Console. 

This is a YAML consisting of cluster roles and bindings for the cluster to be registered. It gives access to all namespaces and resources that can be visualized in the console. 

Download and apply the eks-connector-console-dashboard-full-access.yaml file:

Granting access to IAM user or Role to view Kubernetes resources in Amazon EKS console

This is a YAML consisting of cluster roles and bindings for the cluster to be registered.

Download and apply eks-connector-clusterrole:

Appearance of the EKS Console

Dashboard: After the Kubernetes cluster has been registered successfully with the EKS Connector, the EKS Cluster Overview section shows all the Cluster resources. All the objects are read-only and the user cannot edit or delete an object in the registered cluster. The following figure shows the dashboard of the EKS console:

Figure 14.     Overview Dashboard

Compute: The Compute section shows all the Node resources in the EKS Anywhere Cluster as shown in the following figure:

Figure 15.     Compute

Workloads: The Workloads section displays all objects of Type: Deployment, DaemonSet, and StatefulSet. Users can select these objects to select a pod-level overview as shown in the following figure:

Figure 16.     Workloads