Forum Discussion

advancedspectru's avatar
advancedspectru
Icon for Nimbostratus rankNimbostratus
Nov 17, 2017

BIG IP as a load balancer for service discovery

Hello Group,

 

I am very new to BIG IP and have basic questions not answered through the documents:

 

  1. What I do not understand is each load balancer has its own native configuration format and so does BIG IP; how does that map to a Consul Template or do I set up the Consul template to match that of the BIG IPs internally recognized configuration file, which would mean I need to know what the configuration file looks?

I am trying to set up a server side discovery for microservices. Many examples out there but not for F5 BIG IP.

 

Microservices will be running in docker containers inside k-Pods. I want to set up an external service registry and external Load balancer to manage north-south traffic to the container services. k-clusters will be set up by environment: dev, uat, PAT and prod.

 

If a common Load balancer is used what are the ways to route an HTTP request coming from a service outside the k-pod via this load balancer into a microservices. If the external service wants to talk to a SIT microservice, I want the load balancer to know to route it to the right URL in SIT. Should the caller service pass a service ID and an environment identifier in the payload which the load balancer extracts and uses to narrow down its search on the location of the right SIT service?

 

I am also thinking iControlRestAPI and iRules could be used to solve this problem?

 

Any help would be appreciated.

 

Thanks Adam

 

7 Replies

  • Thank you Chris. I am understanding though that using Load Balancer in the middle of a REST call between two microservices has consequences. Traditional load balancers such as BIG IP are built on power of scripts. How would a microservice A that makes a REST call to Microservice B when there is BIG IP in the middle? Microservice A can only pass the REST call in an HTTP post to the Load balancer. The load balancer must use scripts to extract the REST request and then call Service B on behalf of service A. This becomes more than routing for the LB. The LB now must be REST aware. In essence it is becoming a Microservice Gateway. Am I misunderstanding?

     

  • A lot depends on what you are trying to do. From the BigIP's perspective what is in the packets is only relevant if you want the BigIP to do something with them based on data in that layer. So, for instance, if you wanted us to load balance based on data in the HTTP headers or the request, then you would need to have an HTTP profile on the virtual server and either use Local Traffic Policies or iRules. If you want to use a layer3 or layer4 load balancing method, this would not be needed.

     

    So lets say that you want to evenly distribute traffic across a pool of three rest servers, the BigIP can simply round robin route traffic to these servers, possibly persisting based on source address of the request. We don't need to know that you are using REST, or even that the traffic is HTTP. We look at the incoming packet, determine which server gets requests from that IP, generate an entirely new TCP packet destined for that Server's IP address, and send the request on as we received it.

     

    Now if you wanted to rewrite the POST, you would need to have an HTTP profile, and would likely require some additional logic via iRules, local traffic policies, etc. But if it's a standards compliant HTTP request/Method we can work with it.

     

    So no, the BigIP only needs to be a microservice gateway if you decide that you want it to change the REST request in some way.

     

  • Thanks Chris! This is what I am trying to do:

     

    Consider a server side service discovery infrastructure. Say I have a legacy web logic application (standard 3 tier application) that wants to make a RESTful call to microservice A running inside a docker container in Kubernetes. Say the Service Registry is Consul and my load balancer is a F5 BIG IP. The legacy application is not containerized. It is outside of Kubernetes.

     

    Say that I also used Consul template to create a BIG IP config file that BIG IP will read from and reload whenever the config file changes. So BIG IP knows the physical location of microservice A.

     

    What I am struggling to understand is how this pattern maintains the integrity of a REST architecture.

     

    The legacy application will hit the BIG IP with an HTTP request like: https://[IP address of BIG IP]:port/?optional_query_string. The actual REST URI can only then be in the message body. Am I correct?

     

    Unless I am writing some BIG IP scripts, there is no way that BIG IP will know what the intent of the call is by the legacy application. The scripts would have to parse the HTTP body and extract the intended REST request, create an HTTP REST request and then call the microservice A. When the response arrives from A to BIG IP, BIG IP will forward that to the legacy app through the http connection from the original request.

     

    Am I getting the fundamental understanding right? So to me BIG IP needs to be REST aware. The online blogs on this pattern never explicitly say this but isn't that what needs to happen? The whole message transfer from legacy application to microservice A using a load balancer is assumed but never discussed.

     

    Can you shed some light please or correct me where I am wrong? How can this pattern be adjusted so that it works for my use case?

     

    Many thanks, Sajjad

     

  • Thanks Chris! This is what I am trying to do:

     

    Consider a server side service discovery infrastructure. Say I have a legacy web logic application (standard 3 tier application) that wants to make a RESTful call to microservice A running inside a docker container in Kubernetes. Say the Service Registry is Consul and my load balancer is a F5 BIG IP. The legacy application is not containerized. It is outside of Kubernetes.

     

    Say that I also used Consul template to create a BIG IP config file that BIG IP will read from and reload whenever the config file changes. So BIG IP knows the physical location of microservice A.

     

    What I am struggling to understand is how this pattern maintains the integrity of a REST architecture.

     

    The legacy application will hit the BIG IP with an HTTP request like: https://[IP address of BIG IP]:port/?optional_query_string. The actual REST URI can only then be in the message body. Am I correct?

     

    Unless I am writing some BIG IP scripts, there is no way that BIG IP will know what the intent of the call is by the legacy application. The scripts would have to parse the HTTP body and extract the intended REST request, create an HTTP REST request and then call the microservice A. When the response arrives from A to BIG IP, BIG IP will forward that to the legacy app through the http connection from the original request.

     

    Am I getting the fundamental understanding right? So to me BIG IP needs to be REST aware. The online blogs on this pattern never explicitly say this but isn't that what needs to happen? The whole message transfer from legacy application to microservice A using a load balancer is assumed but never discussed.

     

    Can you shed some light please or correct me where I am wrong? How can this pattern be adjusted so that it works for my use case?

     

    Many thanks, Sajjad

     

  • Thanks Chris! This is what I am trying to do:

     

    Consider a server side service discovery infrastructure. Say I have a legacy web logic application (standard 3 tier application) that wants to make a RESTful call to microservice A running inside a docker container in Kubernetes. Say the Service Registry is Consul and my load balancer is a F5 BIG IP. The legacy application is not containerized. It is outside of Kubernetes.

     

    Say that I also used Consul template to create a BIG IP config file that BIG IP will read from and reload whenever the config file changes. So BIG IP knows the physical location of microservice A.

     

    What I am struggling to understand is how this pattern maintains the integrity of a REST architecture.

     

    The legacy application will hit the BIG IP with an HTTP request like: https://[IP address of BIG IP]:port/?optional_query_string. The actual REST URI can only then be in the message body. Am I correct?

     

    Unless I am writing some BIG IP scripts, there is no way that BIG IP will know what the intent of the call is by the legacy application. The scripts would have to parse the HTTP body and extract the intended REST request, create an HTTP REST request and then call the microservice A. When the response arrives from A to BIG IP, BIG IP will forward that to the legacy app through the http connection from the original request.

     

    Am I getting the fundamental understanding right? So to me BIG IP needs to be REST aware. The online blogs on this pattern never explicitly say this but isn't that what needs to happen? The whole message transfer from legacy application to microservice A using a load balancer is assumed but never discussed.

     

    Can you shed some light please or correct me where I am wrong? How can this pattern be adjusted so that it works for my use case?

     

    Many thanks, Sajjad

     

  • Okay, I think I understand. BigIP is a full proxy system. The legacy app would make a request to the IP and port of a virtual server on the BigIP. If you have different back end IPs depending on the URI, then yes, the BigIP would need to look at the URI. It can do this by adding an HTTP profile and either configuring a local traffic policy or an irule. The fact that it's a REST call shouldn't be relevant. So here is how it would work.

     

    Your client would send a request to the Virtual server which would terminate SSL (if needed) and inspect the HTTP payload of the TCP packet. Based on the rules you had defined it would then pick a pool member (back end server) to send the request too. The fact that it's a REST call is only as relevant as you would like to make it.

     

    You can read about local traffic policies (the easiest, and least flexible way) here: https://support.f5.com/csp/article/K04597703

     

    If you would like to use irules instead (the most complicated, and most powerful way). A devCentral search for URI load balancing or URI redirection should return many examples, but here are two that may be relevant to what you want to do:

     

    https://devcentral.f5.com/questions/help-with-irules-and-uri-redirection-54035

     

    https://devcentral.f5.com/questions/http-header-and-uri-redirect

     

    In your case I suspect the first example will be more helpful.

     

    Note that the next two days are the Thanksgiving holiday in the US, so responses may be delayed.