AWS Cloud Operations Blog
Auto discovery and dynamic route registration of services running in Amazon Elastic Kubernetes Service (EKS) with AWS Migration Hub Refactor Spaces
AWS Migration Hub Refactor Spaces automates infrastructure management, and traffic routing between monolithic and microservices endpoints. It uses two key constructs, service and route, to distribute incoming user traffic between monolithic and microservices endpoints. You can create the service and route configuration in Refactor Spaces from either the AWS Management Console, CLI, or the service APIs . To learn how to configure Services and Routes with Refactor Spaces, refer to the blog “AWS Migration Hub Refactor Spaces Helps to Incrementally Refactor Your Applications.”
In this blog, we focus on automating the discovery of endpoint URLs of microservices running inside Amazon Elastic Kubernetes Service (EKS), and registering those as Routes in Refactor Spaces.
Why we need service discovery and dynamic route registration
In an incremental modernization project, development teams working on microservices 1) create application container images, 2) Kubernetes manifest files, 3) deploy these on EKS, 4) and then manually register those new service endpoint URLs with Refactor Spaces. In a large modernization projects, where a high number of microservices are used, this manual process creates additional complexity. In addition, the volume of manual changes grows as you promote Refactor Spaces service and route configurations through each environment in your software development lifecycle.
In this blog we will address how to reduce the manual effort and provide the following benefits from the solution:
- Microservices deployed in EKS are auto discovered and dynamically registered with Refactor Spaces. This also keeps both EKS and Refactor Spaces in synch. When a new microservice is deployed in EKS, it also gets registered with Refactor Spaces. Similarly when a microservice is deleted in EKS, the corresponding routing configuration in Refactor Spaces also gets deleted.
- If routing configuration of Refactor Spaces is maintained as files in a source control system, it becomes version controlled and auditable.
- Endpoint URLs of microservices exposed as Kubernetes service objects (NodePort, Ingress, LoadBalancer) are auto discovered and registered with Refactor Spaces. There is no static configuration required. This makes the application promotion across environments (dev, test, stage, prod) less complex.
About the solution
The solution uses a custom-built Kubernetes operator, which looks for Kubernetes services of type LoadBalancer, Ingress and NodePort in the EKS cluster where the operator is installed. It then uses API operations to manage the service and route configuration in Refactor Spaces.
You can check the full implementation of the solution here. [https://github.com/aws-samples/refactorspaces-operator]
Prerequisites:
You must have the following installed:
- AWS CLI
- helm
- eksctl
- kubectl installed
Walkthrough:
First, you must install the AWS Migration Hub Refactor Spaces EKS operator in your EKS cluster. And then configure roles to be used by the operator to interact with Refactor Spaces.
- Enable IAM OIDC provider in your EKS cluster, if not done already.
- Create a role with name “refactorspaces-role-cluster” with the following managed policies –
- AWSMigrationHubRefactorSpacesFullAccess
- AWSResourceAccessManagerFullAccess
Edit the Trust Relationship of the role as follows.
Replace {ACCOUNTID} and {REGION} with your own account ID and Region code. You can retrieve the OIDC ID with the following command and replace {OIDC_ID} placeholder:
aws eks describe-cluster –name {EKS-CLUSTER-NAME} –query “cluster.identity.oidc.issuer” –output text
Use the output value that appears after /id/.
https://oidc.eks.us-east-1.amazonaws.com/id/XXXXXXXXXXXXXXXXX
- Clone the github repository
- Edit values.yaml and replace the “<accountID>” with your account ID.
- Log in to the EKS cluster and install the helm chart
- Verify that rs-operator helm chart is installed property.
Output looks like:
Refactor Spaces EKS Operator (rs-operator) uses two Custom Resource Definition (CRDs) – a) RefactorSpacesConfig and b) RefactorSpacesService. Issue the following command to verify if both the CRDs are created:
Output looks like:
Check the status of deployment with the following command:
You should find the deployment refactorspaces-operator in ready state.
- Now, create a namespace and a RefactorSpacesConfig object in that namespace.
Create banking-app-config.yaml file with the following content:
Replace the placeholders ENVID, APPID, and VPCID in the manifest with the values from Refactor Spaces:
Execute the following command to create the object.
kubectl create -f banking-app-config.yaml
On success, you will see the following output:
- Now, deploy a microservice. For the demonstration purpose, lets create an NGINX deployment and expose the deployment as LoadBalancer service.
Create microservices.yaml with the following content:
Create the deployment and service objects with the following command:
Check if the deployment and service has been created:
You should see the following output.
- Now, the final magic step. We will create a RefactorSpacesService manifest file with the following content, and name it nginx-rss.yaml.
In this spec, we have mentioned to look for NodePort or LoadBalancer service or Ingress in the namespace ‘micro’ with label “app: nginx-loadbalancer”. Once a match is found, get the endpoint URL of the service and create entries in the Refactor Spaces. Notice that we are referring to the RefactorSpaceConfig object with the statement “configurationName: refactorspaces-config-ns.banking-app-config”, that we created in the earlier step.
Create the RefactorSpacesService object with following command:
Once the object is created, check the status:
You will see the following output:
Notice the status section of the object.
Now, on the AWS Management Console navigate to Refactor Spaces. You will be able to see that the services and routes are configured:
Note: The first service and route you create for your Refactor Spaces Application will show the route with a “Source Path” as “/” instead of “/somepath.jsp.” This is because an application must have a default route before any other routes are created.
- Now, lets create another RefactorSpacesService object. Copy the following content, and save in a file named nginx-another-rss.yaml.
Create the RefactorSpacesService object with following command:
On the AWS Management Console navigate to AWS Migration Hub, and then select AWS Refactor Spaces. You will be able to see that another service and route are configured:
- Now, delete the RefactorSpacesService objects.
- Once the objects are deleted in EKS, the corresponding services and routes are also deleted in Refactor Spaces. On the Refactor Spaces AWS Management Console, you will see that the configurations no longer exist.
Cleanup:
If you are not using the solution, remember to uninstall the operator using following helm uninstall command.
Conclusion
In this blog, we demonstrated how to auto discover the endpoint url of microservices deployed in Amazon Kubernetes Services (EKS) and dynamically register those Routes with Refactor Spaces. This helps you to continue refactoring your application while it is in use and take further advantage of the microservices you’ve created.
Author: