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:
parent
0cbb316ec3
commit
5277ab5bad
@ -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
|
||||
|
@ -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 `""`.
|
||||
|
@ -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:
|
||||
|
@ -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"}`
|
||||
)
|
||||
|
Loading…
Reference in New Issue
Block a user