docs,pkg: use new well-known region label

This commit updates the well-known label to determine the region of the
node to topology.kubernetes.io/region, which is the new standard as
defined by the Kubernetes documentation, now that
failure-domain.beta.kubernetes.io/region has been deprecated.
This commit is contained in:
Lucas Servén Marín 2020-01-07 18:41:52 +01:00
parent 0cbb316ec3
commit 5277ab5bad
No known key found for this signature in database
GPG Key ID: 586FEAF680DA74AD
4 changed files with 4 additions and 4 deletions

View File

@ -45,7 +45,7 @@ By default, Kilo uses UDP port 51820.
By default, Kilo creates a mesh between the different logical locations in the cluster, e.g. data-centers, cloud providers, etc.
For this, Kilo needs to know which groups of nodes are in each location.
If the cluster does not automatically set the [failure-domain.beta.kubernetes.io/region](https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domain-beta-kubernetes-io-region) node label, then the [kilo.squat.ai/location](./docs/annotations.md#location) annotation can be used.
If the cluster does not automatically set the [topology.kubernetes.io/region](https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesioregion) node label, then the [kilo.squat.ai/location](./docs/annotations.md#location) annotation can be used.
For example, the following snippet could be used to annotate all nodes with `GCP` in the name:
```shell

View File

@ -35,7 +35,7 @@ _Note_: multiple nodes within a single location can be given the leader annotati
### location
Kilo allows nodes in different logical or physical locations to route packets to one-another.
In order to know what connections to create, Kilo needs to know which nodes are in each location.
Kilo will try to infer each node's location from the [failure-domain.beta.kubernetes.io/region](https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domain-beta-kubernetes-io-region) node label.
Kilo will try to infer each node's location from the [topology.kubernetes.io/region](https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesioregion) node label.
If the label is not present for a node, for example if running a bare-metal cluster or on an unsupported cloud provider, then the location annotation should be specified.
_Note_: all nodes without a defined location will be considered to be in the default location `""`.

View File

@ -10,7 +10,7 @@ This allows the encrypted network to serve several purposes, for example:
## Logical Groups
By default, Kilo creates a mesh between the different logical locations in the cluster, e.g. data-centers, cloud providers, etc.
Kilo will try to infer the location of the node using the [failure-domain.beta.kubernetes.io/region](https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domain-beta-kubernetes-io-region) node label.
Kilo will try to infer the location of the node using the [topology.kubernetes.io/region](https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesioregion) node label.
If this label is not set, then the [kilo.squat.ai/location](./annotations.md#location) node annotation can be used.
For example, in order to join nodes in Google Cloud and AWS into a single cluster, an administrator could use the following snippet could to annotate all nodes with `GCP` in the name:

View File

@ -58,7 +58,7 @@ const (
locationAnnotationKey = "kilo.squat.ai/location"
wireGuardIPAnnotationKey = "kilo.squat.ai/wireguard-ip"
regionLabelKey = "failure-domain.beta.kubernetes.io/region"
regionLabelKey = "topology.kubernetes.io/region"
jsonPatchSlash = "~1"
jsonRemovePatch = `{"op": "remove", "path": "%s"}`
)