On-premise to cloud migration mock drills using Istio

#DevOps   #Kubernetes   #aws  
Screen Shot 2022-01-05 at 2.12.15 PM.png

Part 1 of a series of articles about cloud migration

Introduction

For any organization considering its first venture into on-premise to cloud migration of data and applications, management will find no shortage of introductory literature on the subject.

I remember when I first started working on Cloud Migration. I encountered so many articles, and but the problem, however, is that much of the existing literature is just that — an introduction. It tends to take the form of generalized overviews, summaries of best practices, and checklists with numbers of steps that vary depending on the source.

From a technical perspective, a Cloud migration project can be quite simple or rather complex, depending on factors such as the migration scope and maturity and life cycle of workloads being moved.

In this article I am going to talk about large enterprise migration where we have 50+ Microservices running on kubernetes infrastructure in on-premise and we have to migrate this entire platform to AWS EKS cluster with kubernetes version 1.17.

Before we discuss about the migration , we need to understand few things about Istio (Service Mesh).

Istio Routing Basics

Ingress Gateway

One of the way for allowing traffic into the cluster is through Istio’s Ingress Gateway which positions itself at the edge of the cluster and on incoming traffic enables Istio’s features like routing, load balancing, security, and monitoring.

During Istio’s installation, the Ingress Gateway component and service that exposes it externally were installed into the cluster. To get the services External IP execute the command below:

                $ kubectl get svc -n istio-system -l istio=ingressgateway
NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP
istio-ingressgateway   LoadBalancer   10.0.132.127   13.93.30.120
$ EXTERNAL_IP=$(kubectl get svc -n istio-system \
  -l app=istio-ingressgateway \
  -o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}')
            

If you reach this EXTERNAL_ IP in your browser and you will get a Service Unavailable error, as by default Istio blocks any incoming traffic until we define a Gateway.

The Gateway Resource

A Gateway is a Kubernetes Custom Resource Definition defined upon Istio’s installation in our cluster that enables us to specify the Ports, Protocol and Hosts for which we want to allow incoming traffic.

A gateway controls the flow of traffic into and out of the service mesh.The overwhelming majority of use cases for gateways revolve around the management of inbound traffic. In this capacity, gateways act similarly to regular Kubernetes ingress resources

The VirtualService resource

The VirtualService instructs the Ingress Gateway how to route the requests that were allowed into the cluster.

The important points here are:

  1. This VirtualService applies to requests coming through the http-gateway.
  2. Destination defines the service where the requests are routed to.

The Mock Migration

Undergo a trial run of the migration project plan to uncover unintended results or unnoticed issues.

  • Before starting mock migration, you should have evaluated your workloads based on complexity, transactional dependencies, business impact and multiple other factors.
  • Get a complete visual of the entire existing infrastructure, understand dependencies for each, so you can prioritize applications for migration and efficiently build a roadmap to the cloud.
  • Start moving the application to cloud and perform testing and validation of the migrated applications.

Current onpremise setup in production.

Let’s start our cloud migration by first migrating Service E to AWS EKS cluster and for that we need to understand traffic routing between microservice B and microservice E in the onpremise cluster.

Microservice B is hitting Microservice E by calling host microservice-e-svc.namespace.svc.cluster.local and here the routing to microservice E will be decided by the virtual service of microservice E.

Virtual service of Microservice E in onpremise

                apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  labels:
    app.kubernetes.io/managed-by: Helm
  name: microservice-e-vs
  namespace: prod-service-namespace
spec:
  gateways:
  - prod-service-gateway
  - mesh
  hosts:
  - microservice-e-svc
  http:
  - route:
    - destination:
        host: microservice-e-svc
        port:
          number: 8080
            

Steps to migrate Microservice E to cloud

  • We have deployed the same stack of service in AWS EKS Cluster.
  • I have created a new destination block in the same virtual service of service E in onpremise. As per the new block , 10% of traffic will be routed to host microservice-e.aws.dummy.com. Weight associated with the host determines how much traffic it receives.
  • We need service entry too because this service is external to onpremise istio control plane and ServiceEntry enables adding additional entries into Istio’s internal service registry, so that auto-discovered services in the mesh can access/route to these manually specified services.
  • New host microservice-e.aws.dummy.com is pointing to istio-ingress gateway of aws eks cluster. So traffic will enter the istio control plane of aws.
  • Virtual service of microservice E in aws cluster has configured the ingress controller to route traffic for host microservice-e.aws.dummy.com.
  • With basically no downtime , 10% traffic for onpremise microservice E will start going towards cloud microservice E.

Virtual service of Microservice E in onpremise

                apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  labels:
    app.kubernetes.io/managed-by: Helm
  name: microservice-e-vs
  namespace: prod-service-namespace
spec:
  gateways:
  - prod-service-gateway
  - mesh
  hosts:
  - microservice-e-svc
  http:
  - route:
    - destination:
        host: microservice-e-svc
        port:
          number: 8080
      weight: 90
    - destination:
        host: microservice-e.aws.dummy.com
        port:
          number: 8080
      weight: 10
            

Virtual service of Microservice E in Cloud

                apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  labels:
    app.kubernetes.io/managed-by: Helm
  name: microservice-e-vs
  namespace: prod-service-namespace
spec:
  gateways:
  - prod-service-gateway
  - mesh
  hosts:
  - microservice-e-svc
  - microservice-e.aws.dummy.com
  http:
  - route:
    - destination:
        host: microservice-e-svc
        port:
          number: 8080
            

Service Entry of Microservice E in Onpremise

                apiVersion: networking.istio.io/v1beta1
 kind: ServiceEntry
 metadata:
 name: microservice-e-se
 namespace: env-lending-sit-service
 spec:
 endpoints:
 - address: 10.x.y.z
 - address: 10.x.y.z
 hosts:
 - microservice-e.aws.dummy.com
 location: MESH_EXTERNAL
 ports:
 - name: tcp
   number: 38080
   protocol: HTTP
 resolution: STATIC
            

Execute a Mock Migration

  1. Start traffic by 10% to cloud microservice.
  2. Monitor logs ,dashboards and the overall health.
  3. If everything is good then increase the traffic percentage.
  4. After getting sufficient data, stop routing the traffic to cloud.
  5. Next day , we can pick new services or start traffic for existing services to cloud based on our plan.
  6. Once we route traffic to all services like this on cloud and have confidence then we can take cutover to production.

Cutover to Production Cloud

Assuming a successful mock migration, or one that only encountered minor issues with a clear fix, establish a formal cutover schedule. If the mock migration ran into serious issues, then it needs to be repeated after correcting the causes

Putting It All Together

We can use service mesh like Istio to migrate from 1 kubernetes cluster to the other and from on-premises to cloud with zero downtime. There is undoubtedly a fair amount of practice necessary to become proficient in Istio, but it is a gentle ramp-up in comparison to the much steeper learning curve of Kubernetes. Also, when compared to the effort it would take to correctly implement each of its capabilities in isolation and to maintain these in the long run, the return makes the investment appear very viable indeed.

If you enjoy this article, please give it a like, comment, subscribe, and share it!

Start blogging about your favorite technologies and get more readers

Join other developers and claim your FAUN account now!

Stats
20

Influence

989

Total Hits

1

Posts

Join FAUN
Start blogging on FAUN

⚡ Grow your network and reach more readers!

Discussed tools