Set Location Preferences
You can specify specific locations in which you would like your Project to run or let our Adaptive Edge Engine optimize the placement of your application across our global network of compute based on rules or strategies you define.
Use the K8s Dashboard we provide or Kubectl to deploy a ConfigMap named location-optimizer for each Project. Our platform control plane detects this ConfigMap and will use it to orchestrate the optimal distribution of your Project across our entire Composable Edge Cloud.
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.
note
You will not be able to specify specific locations or a minimum number of locations if they will cause your usage of RAM and CPU to exceed the boundaries of your current project plan.
Below is an example of boilerplate ConfigMap to implement a dynamic policy. The strategy data is a JSON blob. The ConfigMap Name must be location-optimizer:
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:
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:
apiVersion: v1
kind: ConfigMap
data:
strategy: |
{
"strategy": "SolverServiceV1",
"params": {
"policy": "dynamic"
}
}
metadata:
name: location-optimizer
Apply the above ConfigMap to your project using either the Kubernetes dashboard or the following kubectl command:
kubectl apply -f location-optimizer.yaml
You can adjust the defaults as needed. For example, if you want more coverage across the globe, you could increase minimumLocations from 2 to 5, giving you exactly 5 locations at all times, dynamically positioned according to traffic:
apiVersion: v1
kind: ConfigMap
data:
strategy: |
{
"strategy": "SolverServiceV1",
"params": {
"policy": "dynamic",
"minimumLocations": 5
}
}
metadata:
name: location-optimizer
A drawback with such a simple 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:
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:
apiVersion: v1
kind: ConfigMap
data:
strategy: |
{
"strategy": "SolverServiceV1",
"params": {
"policy": "dynamic",
"mustInclude": [
{
"locationcode": "sfo"
},
{
"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.
Finally, Enterprise plans allow you to require locations according to special capabilities. For example, the following ConfigMap constrains your workload to running at only those locations that support PCI (Payment Card Industry) compliance:
apiVersion: v1
kind: ConfigMap
data:
strategy: |
{
"strategy": "SolverServiceV1",
"params": {
"policy": "dynamic",
"chooseFrom": "pci"
}
}
metadata:
name: location-optimizer
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:
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:
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.
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.
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.