Skip to main content

Set Edge Location Preferences

Use Kubectl to deploy a ConfigMap named location-optimizer. The Section control plane detects this ConfigMap and uses it to orchestrate the edge presence of your entire environment. Individual pods do not consume this ConfigMap on their own.

There are many ways to specify the locations that you want. Please see the explanation of the AEE to see an overview of LocationOptimizer parameters, their interpretations, and default values. Please also see our reference on the traffic signal used when policy is dynamic. This guide will assume familiarity with these terms and concepts and will focus on examples of common scenarios to illustrate possible ConfigMaps.

Below is an example of boilerplate ConfigMap to implement a dynamic policy. The Name must be location-optimizer:

location-optimizer.yaml
apiVersion: v1
kind: ConfigMap
data:
strategy: |
{
"strategy": "SolverServiceV1",
"params": {
"policy": "dynamic",
"mustInclude": [],
"mustNotInclude": [],
"minimumLocations": 2,
"maximumLocations": 5,
"minimumUsagePerLocation": 20
}
}
metadata:
name: location-optimizer

Above, all parameters except policy are at their default values. Therefore, an equivalent and simpler ConfigMap is:

location-optimizer.yaml
apiVersion: v1
kind: ConfigMap
data:
strategy: |
{
"strategy": "SolverServiceV1",
"params": {
"policy": "dynamic"
}
}
metadata:
name: location-optimizer

Examples

The first and simplest scenario is when you want your app to be deployed according to current traffic patterns. You are satisfied with the default values of 2, 5, and 20 for the minimumLocations, maximumLocations, and minimumUsagePerLocation, respectively, so you don't need to enter any values for those. Also, you don't have any demands such as "always have at least one location in Europe", so the LocationOptimizer is free to choose from any existing location to host your app. That situation would be captured by this ConfigMap:

location-optimizer.yaml
apiVersion: v1
kind: ConfigMap
data:
strategy: |
{
"strategy": "SolverServiceV1",
"params": {
"policy": "dynamic"
}
}
metadata:
name: location-optimizer

The drawback with the ConfigMap above is when you don't have reliable traffic being served by your app. This is common in the early stages of development. The LocationOptimizer is being told to select locations according to traffic but the traffic signal doesn't exist. We have methods to handle these "fallback" situations, but you can exert more control to obtain a more desirable, predictable outcome. The best way to handle this is to add add the mustInclude parameter to your ConfigMap. (See Tips section below for low/no traffic apps).

For example, we could add 2 elements to the mustInclude array to ensure that we will always have a presence in these locations. If there is no traffic, then these will be your only locations. If there is traffic, you will have these locations and anything else that is warranted by the traffic. Here is what the ConfigMap would look like if we forced a presence in Europe and North America:

location-optimizer.yaml
apiVersion: v1
kind: ConfigMap
data:
strategy: |
{
"strategy": "SolverServiceV1",
"params": {
"policy": "dynamic",
"mustInclude": [
{
"region": "europe"
},
{
"region": "northamerica"
}
]
}
}
metadata:
name: location-optimizer

The mustInclude parameter accepts an array of objects. Supported keys for the objects are listed in our Location Parameters reference guide.

It is worth taking a moment to restate what this ConfigMap represents. This is a dynamic config, so traffic patterns will be analysed to choose suitable locations. And there are mustInclude conditions, so these must be met under any conditions. It gives you a few known locations but others can be added as needed according to the traffic analysis. If you want your mustInclude locations to be more specific, you can consult our Location Parameters reference guide and use suitable "locationcode" references like this:

location-optimizer.yaml
apiVersion: v1
kind: ConfigMap
data:
strategy: |
{
"strategy": "SolverServiceV1",
"params": {
"policy": "dynamic",
"mustInclude": [
{
"locationcode": "ams"
},
{
"locationcode": "syd"
}
]
}
}
metadata:
name: location-optimizer

This will cause the selection of Amsterdam and Sydney no matter what, and up to 3 more locations will be added where and when they are needed according to traffic patterns, because the default value for maximumLocations is 5.

Another suitable ConfigMap for apps that do not serve HTTP traffic or for development scenarios (low or no traffic), is to use a static policy. A static policy is simply one in which you specify characteristics of locations that you want and this entirely defines the locations that are selected for you. No traffic signal is analysed. Your app will be deployed to suitable locations and stay there until the ConfigMap is changed. The parameters for static look very similar to the example given above. As noted here, the static policy does not honor any concept of minimum or maximum locations. The LocationOptimizer will try to meet your mustInclude array as exactly as possible. So a static deployment with locations in Europe and North America would be configured like this:

location-optimizer.yaml
apiVersion: v1
kind: ConfigMap
data:
strategy: |
{
"strategy": "SolverServiceV1",
"params": {
"policy": "static",
"mustInclude": [
{
"region": "europe"
},
{
"region": "northamerica"
}
]
}
}
metadata:
name: location-optimizer

The only explicit change is the name of the policy. Implicitly, you are saying: 'pay no attention to traffic and stay in only these locations until I tell you otherwise by updating my ConfigMap.' With static, the locations are stable and "static" over time, to the extent that is possible. So the first two locations selected will be used consistently unless some issue forces us to move your app. If we move it, we will again choose locations that meet the mustInclude conditions.

In the dynamic version above where your app will always be in one European and one North American location, but there may be additional locations as well, if traffic is sufficient to warrant additional locations. Also, the locations within Europe and North America will change over time in response to traffic patterns.

We offer multiple levels of geographic abstraction when specifying mustInclude conditions. You can exert more fine-grained control with something like "locationcode" and coarser control with "region". Beware that if you specify a fine-scale entity, like a city, then the LocationOptimizer has fewer options in meeting this condition. If, for some reason, there are no available facilities in that city, then your app cannot be scheduled there. Fall-back locations in such a scenario may seem arbitrary to the stated COnfigMap, depending on conditions. So the more general you can be, the better in terms of reliably obtaining your desired results.

Tips

When the LocationOptimizer cannot obtain a solution based on your ConfigMap and current network and traffic conditions, it will check to see where your app is currently deployed. If it has current locations (i.e., is currently deployed), the LocationOptimixer will select those current locations, leaving your app where it is. If your app does not have any current locations, then two fall-back locations are returned, typically in NYC and SFO.

To avoid these situations and take more control over your outcomes:

  1. Use a static policy when you initially deploy your app and when there is no meaningful traffic. This forces your app to deploy to locations of your choosing regardless of traffic.

  2. Once your app has been deployed and you want to do some load-testing or you are going to start serving traffic, then switching to a dynamic policy could make sense.

  3. When using a dynamic policy with relatively little traffic, the selected locations can change often over a given time period. At low traffic levels, the signal is highly variable and can cause location flapping. If you are doing relatively little traffic, consider using a static policy to get in the places you want and stay there. The dynamic policy works best with strong, geographically-correlated traffic signals.