Migrating EKS EC2 Nodes to Fargate Nodes.

Hi All, we will see how one can migrate their existing workloads from EKS to Fargate

Agenda:

1. Introduction to EKS
2. Introduction to Fargate
3. Benefits of Fargate
4. Create a namespace in EKS Cluster
5. Create a Deployment in EKS Cluster
6. Create Fargate Pod Execution Role
7. Add a fargate Profile to the cluster
8. Migrate Workloads

Migrating EKS To Fargate

Prerequisties:

1. EKS Cluster Running
2. Kubectl , AWS CLI are installed in the instance from where you access your cluster

Introduction to EKS:

Amazon EKS (Amazon Elastic Kubernetes Service) is a managed service that lets you run Kubernetes in the AWS Cloud without having to set up, manage, or maintain your own control plane and nodes.

Kubernetes is an open-source technology that automates the deployment, scaling, and management of containers or containerized applications.

To achieve high availability, EKS runs and scales the Kubernetes control plane across multiple AWS Availability Zones.
In Amazon EKS, control plane instances automatically scale based on load, failed control plane instances are detected and replaced, and automatic version updates and patching are performed automatically.

Amazon EKS can be integrated with other AWS services to provide a variety of services. For example, worker nodes can be served by AWS EC2 instances, Elastic Container Registry (ECR) for container images, or Virtual Private Clouds (VPCs) for resource isolation.

Introduction to Fargate:

AWS Fargate is a carrier that provisions serverless compute resources to run AWS ECS and EKS containers. AWS states that Fargate allows you to consciousness on building your applications when you allow Fargate provision and manipulate the infrastructure required. consider it as bins on-call for and not using a underlying manually created infrastructure which are short to release and scale, wherein you manipulate everything on the field stage.

You specify the sources your software wishes to run and Fargate handles the provisioning of compute assets in an isolated and relaxed example.

Fargate determines the ideal amount of compute sources required, which means you don’t want to worry about deciding on example kinds or having to scale the cluster potential.
With Fargate, you only pay for the sources you want to run your bins while you operate them.

Fargate duties (modules) run on their own cores, offering a comfy and isolated compute surroundings that serves remoted workloads, ensuing in expanded safety.

Benefits of Fargate:

1. No need to manage the Workernodes.
2. No need to upgrade the workernodes to desired version
3. Right Sized resources
4. Less complicated
5. Secure Isolation

Create a namespace in EKS Cluster

Lets create a namespace called migrate in the cluster using imperative way

ubuntu@ip-xx-xx-xx-xxx:~$ k create ns migrate
namespace/migrate created
ubuntu@ip-xx-xx-xx-xxx:~$ k get ns
NAME                STATUS   AGE
aws-observability   Active   10d
default             Active   15d
kube-node-lease     Active   15d
kube-public         Active   15d
kube-system         Active   15d
migrate             Active   7s

Create a Deployment in EKS Cluster

We will create a Deployment of nginx with three replicas in migrate namespace using imperative way

ubuntu@ip--xx-xx-xx-xxx:~$ k create deploy migrate --image nginx --replicas 3 -n migrate
deployment.apps/migrate created
ubuntu@ip--xx-xx-xx-xxx:~$ k get deploy -n migrate
NAME      READY   UP-TO-DATE   AVAILABLE   AGE
migrate   3/3     3            3           8s

Now we need to migrate this existing deployments in EKS cluster to Fargate. For this, Firstly we need to create a Fargate Pod Execution Role in aws console , later will create a fargate profile and specify the same namespace and labels of the deployments which we have created previously.

Create Fargate Pod Execution Role:

Let’s create a policy(AmazonEKSFargatePodExecutionRolePolicy) and attach to the role(AmazonEKSFargatePodExecutionRole) with trusted entities as stated below

Trusted Entities
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "eks-fargate-pods.amazonaws.com"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:eks:REGION-CODE:ACCOUNT-ID:fargateprofile/EKSCLUSTERNAME/*"
                }
            }
        }
    ]
}

Policy
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ecr:GetAuthorizationToken",
                "ecr:BatchCheckLayerAvailability",
                "ecr:GetDownloadUrlForLayer",
                "ecr:BatchGetImage"
            ],
            "Resource": "*"
        }
    ]
}

Add a Fargate Profile to the cluster:

Now navigate to aws console and search for EKS and click on it, look for the eks cluster which you want to migrate to fargate. click on the cluster and inside the compute tab click on add profiles. Mention a name of Fargate profile and Select the Role which we have created earlier. Subnets should be same as that of EKS subnets, In my case those are private subnets of EKS worker nodes.

Click on Next and select the namespace and labels of deployments which you have created earlier. you can select upto five pod selectors in fargate profile.

Click on next and create the profile. Wait for 1 min so that your fargate profile comes to active state. Once profile is Active we are ready to migrate the existing deployment in EKS to Fargate.

Migrate Workloads:

Using Kubectl utility, Scale the deployment to five replicas and you can notice that the new replicas are getting placed on fargate nodes.

ubuntu@ip-xx-xx-xx-xx:~$ k scale deploy migrate -n migrate --replicas 5
deployment.apps/migrate scaled
ubuntu@ip-xx-xx-xx-xx:~$ k get po -n migrate -o wide
NAME                      READY   STATUS    RESTARTS   AGE     IP           NODE                                              NOMINATED NODE   READINESS GATES
migrate-c76655667-4rrzh   1/1     Running   0          56m     10.0.2.36    ip-10-0-2-181.sa-east-1.compute.internal          <none>           <none>
migrate-c76655667-f2lcr   1/1     Running   0          2m58s   10.0.2.43    fargate-ip-10-0-2-43.sa-east-1.compute.internal   <none>           <none>
migrate-c76655667-jzntj   1/1     Running   0          56m     10.0.3.153   ip-10-0-3-167.sa-east-1.compute.internal          <none>           <none>
migrate-c76655667-tss5j   1/1     Running   0          2m58s   10.0.2.21    fargate-ip-10-0-2-21.sa-east-1.compute.internal   <none>           <none>
migrate-c76655667-tzxf4   1/1     Running   0          56m     10.0.3.123   ip-10-0-3-167.sa-east-1.compute.internal          <none>           <none>

You might be wondering about the pods that are still on eks worker nodes, There are two ways to place the remaining pods on fargate nodes.

1. scale down the replicas to Zero(0) and scale them up, the thing with scaling down is there will be a downtime.
2. delete the pods on eks worker node then the new pods will be placed on fargate nodes without any down time.

ubuntu@ip-x-xx-xx-xx:~$ k delete po migrate-c76655667-jzntj -n migrate
pod "migrate-c76655667-jzntj" deleted
ubuntu@ip-x-xx-xx-xx:~$ k delete po migrate-c76655667-tzxf4  -n migrate
pod "migrate-c76655667-tzxf4" deleted
ubuntu@ip-x-xx-xx-xx:~$ k delete po migrate-c76655667-4rrzh   -n migrate
pod "migrate-c76655667-4rrzh" deleted

3. Now watch the pods using below command.

ubuntu@ip-xx-xx-xx-xx:~$ k get po -o wide -n migrate
NAME                      READY   STATUS    RESTARTS   AGE     IP           NODE                                               NOMINATED NODE                      READINESS GATES
migrate-c76655667-f2lcr   1/1     Running   0          12m     10.0.2.43    fargate-ip-10-0-2-43.sa-east-1.compute.internal    <none>                      <none>
migrate-c76655667-fkxwg   0/1     Pending   0          3m28s   <none>       <none>                                             e8fe42fc36-8b38512190f446a598ac223196df6e3e   <none>
migrate-c76655667-qqm8v   1/1     Running   0          2m59s   10.0.1.153   fargate-ip-10-0-1-153.sa-east-1.compute.internal   <none>                      <none>
migrate-c76655667-tss5j   1/1     Running   0          12m     10.0.2.21    fargate-ip-10-0-2-21.sa-east-1.compute.internal    <none>                      <none>
migrate-c76655667-vrxj5   0/1     Pending   0          2m35s   <none>       <none>                                             e8fe42fc36-413aba4a710e4

ubuntu@ip-xx-xx-xx-xx:~$ k get po -o wide -n migrate
NAME                      READY   STATUS    RESTARTS   AGE     IP           NODE                                               NOMINATED NODE   READINESS GATES
migrate-c76655667-f2lcr   1/1     Running   0          14m     10.0.2.43    fargate-ip-10-0-2-43.sa-east-1.compute.internal    <none>           <none>
migrate-c76655667-fkxwg   1/1     Running   0          5m9s    10.0.1.145   fargate-ip-10-0-1-145.sa-east-1.compute.internal   <none>           <none>
migrate-c76655667-qqm8v   1/1     Running   0          4m40s   10.0.1.153   fargate-ip-10-0-1-153.sa-east-1.compute.internal   <none>           <none>
migrate-c76655667-tss5j   1/1     Running   0          14m     10.0.2.21    fargate-ip-10-0-2-21.sa-east-1.compute.internal    <none>           <none>
migrate-c76655667-vrxj5   1/1     Running   0          4m16s   10.0.3.62    fargate-ip-10-0-3-62.sa-east-1.compute.internal    <none>           <none>

4. Now all the pods are placed on fargate nodes. This is how one can migrate their existing workloads on EKS to Fargate.

EveryCoin has two sides, In the same way Fargate does have its own advantages and disadvantages. It entirely depends on Customer requirements of choosing Fargate over EKS Workernodes.

Conclusion :

Thanks for going through my content please reach me out at LinkedIn for any queries :

https://www.linkedin.com/in/hemanth-kandukuri-971763211/