-
Notifications
You must be signed in to change notification settings - Fork 69
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add a blog to introduce "MultipleHubs".
Signed-off-by: xuezhaojun <[email protected]>
- Loading branch information
1 parent
7e484de
commit 27f0fda
Showing
2 changed files
with
84 additions
and
3 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,75 @@ | ||
--- | ||
title: The HA Hub clusters solution -- MultipleHubs | ||
--- | ||
|
||
August 11, 2024 [Zhao Xue](https://github.com/xuezhaojun) | ||
|
||
{{<toc>}} | ||
|
||
The `MultipleHubs` is a new feature in Open Cluster Management (OCM) that allows you to configure a list of bootstrapkubeconfigs of multiple hubs. This feature is designed to provide a high availability (HA) solution of hub clusters. In this blog, we will introduce the MultipleHubs feature and how to use it. | ||
|
||
The high availability of hub clusters means that if one hub cluster is down, the agent clusters can still communicate with other hub clusters. Users can also specify the hub cluster that the agent cluster should connect to by configuring the `ManagedCluster` resource. | ||
|
||
The `MultipleHubs` feature is currently in the experimental stage and is disabled by default. To enable the `MultipleHubs` feature, you need to set the `featureGate` in `Klusterlet`'s registration configuration. The following is an example of the `Klusterlet`'s registration configuration: | ||
|
||
```yaml | ||
apiVersion: operator.open-cluster-management.io/v1 | ||
kind: Klusterlet | ||
... | ||
spec: | ||
... | ||
registrationConfiguration: | ||
... | ||
featureGates: | ||
- feature: MultipleHubs | ||
mode: Enable | ||
``` | ||
If `MultipleHubs` is enabled, you don't need to prepare the default `bootstrapKubeConfig` for the agent. The agent will use the `bootstrapKubeConfigs` in the `Klusterlet`'s registration configuration to connect to the hub clusters. An example of `bootstrapKubeConfigs` is like following: | ||
|
||
```yaml | ||
apiVersion: operator.open-cluster-management.io/v1 | ||
kind: Klusterlet | ||
... | ||
spec: | ||
... | ||
registrationConfiguration: | ||
... | ||
featureGates: | ||
- feature: MultipleHubs | ||
mode: Enable | ||
bootstrapKubeConfigs: | ||
type: "LocalSecrets" | ||
localSecretsConfig: | ||
kubeConfigSecrets: | ||
- name: "hub1-bootstrap" | ||
- name: "hub2-bootstrap" | ||
hubConnectionTimeoutSeconds: 600 | ||
``` | ||
|
||
In the above configuration, the `hub1-bootstrap` and `hub2-bootstrap` are the secrets that contain the kubeconfig of the hub clusters. You should create the secrets before you set the `bootstrapKubeConfigs` in the `Klusterlet`'s registration configuration. | ||
|
||
The order of the secrets in the `kubeConfigSecrets` is the order of the hub clusters that the agent will try to connect to. The agent will try to connect to the first hub cluster in the list first. If the agent cannot connect to the first hub cluster, it will try to connect to the second hub cluster, and so on. | ||
|
||
Note that the expiration time of the credentials in kubeconfigs should be long enough to ensure the agent can connect to another hub cluster when one hub cluster is down. | ||
|
||
The `hubConnectionTimeoutSeconds` is the timeout for the agent to connect to the hub clusters. If the agent cannot connect to the hub cluster within the timeout, it will try to connect to another hub cluster. It is also used to avoid the effect of network disturbance. The default value is 600 seconds and the minimum value is 180 seconds. | ||
|
||
Currently, the `MultipleHubs` feature only supports the `LocalSecrets` type of `bootstrapKubeConfigs`. | ||
|
||
As we mentioned before, you can also specify the hub's connectivities in the `ManagedCluster` resource from the hub side. We using the `hubAcceptsClient` field in the `ManagedCluster` resource to specify whether the hub cluster accepts the agent cluster. The following is an example of the `ManagedCluster` resource: | ||
|
||
```yaml | ||
apiVersion: cluster.open-cluster-management.io/v1 | ||
kind: ManagedCluster | ||
... | ||
spec: | ||
... | ||
hubAcceptsClient: false | ||
``` | ||
|
||
If the `hubAcceptsClient` is set to `false`, the agent cluster currently connected to the hub will immediately disconnect from the hub and try to connect to another hub cluster. | ||
|
||
And the agent clusters that are trying to connect to another hub cluster will ignore the hub cluster that the managedcluster's `hubAcceptsClient` is set to `false`. | ||
|
||
That's the brief introduction of the `MultipleHubs` feature in Open Cluster Management. We hope this feature can help you to start building a high availability solution of hub clusters and we are looking forward to your feedback. If you have any questions or suggestions, please feel free to contact us. |