出典｜KubeAdmiralオープンソースコミュニティ
プロジェクトアドレス: https://github.com/kubewharf/kubeadmiral
2014 年にオープンソース化されて以来、Kubernetes はオーケストレーションおよびスケジューリング システムの事実上の標準となり、開発者に大きな利便性を提供しています。クラウド ネイティブを採用する企業が増えるにつれて、グローバル クラウド インフラストラクチャの規模は依然として加速しており、同時に、Kubernetes コミュニティ バージョンの 5,000 ノードの単一クラスターではエンタープライズ レベルの大規模なアプリケーション シナリオに対応できなくなりました。コスト削減と効率向上、リモート災害復旧、環境分離の需要に応じて、マルチクラウド アーキテクチャの使用を選択する企業が増えています。マルチクラスタ管理の必要性がますます明らかになってきています。
背景
ビジネスの急速な発展に伴い、ByteDance 内の Kubernetes クラスターの数も増加し続けており、クラスターの数は 0 から 20,000 の範囲にあり、最大のアプリケーションでは 100 W コアを超えています。
初期の頃、Byte の各事業ラインには排他的なクラスターがあり、これらの排他的なクラスターによってリソースの島が生じ、最終的にはリソースの弾力的な効率に影響を及ぼしました。これは、まず、ビジネスラインごとに独立したバッファを維持する必要性に反映されます。次に、ビジネスがクラスターに深く結びついており、ビジネスは多数のクラスターを認識し、クラスター間のアプリケーションにもリソースを割り当てます。運用リソースの観点からビジネスとクラスターを深く認識する必要があり、最終的にはさまざまな事業部門間のリソースの回転が遅くなり、自動化効率が低くなり、導入率が最適化されません。したがって、フェデレーションを導入し、アプリケーションとクラスター間のバインディング関係を分離し、各ビジネスラインのリソースをプールし、バッファを削減し、リソースの自動化効率を向上させる必要があります。
マルチクラウドとハイブリッド クラウドが業界でますます主流になり、Kubernetes がクラウドネイティブ オペレーティング システムになるにつれて、さまざまなインフラストラクチャがさらに抽象化および標準化され、より統一された標準インターフェイスがアプリケーションに提供されます。これに基づいて、分散クラウド シナリオにおけるクラウド ネイティブ システムのベースとしてフェデレーションを導入し、アプリケーションに統合プラットフォームの入り口を提供し、クラスター間でアプリケーションを分散する機能を向上させ、クラスター間でのアプリケーションの分散とスケジューリングで適切な仕事をしたいと考えています。クラスターを作成し、ネイティブ シナリオで複数のクラウドを管理します。
KubeFed V2 バイトの実装
マルチクラスター管理によってもたらされる課題に直面し、インフラストラクチャ チームは2019 年にコミュニティKubeFed V2に基づくクラスター フェデレーションの構築を開始しました。 KubeFed V2 はマスター クラスターとメンバー クラスターを区別し、ユーザーはマスター クラスター内に「フェデレーション オブジェクト」を作成し、複数の KubeFed コントローラーがフェデレーション オブジェクトに基づいてメンバー クラスター間でリソースを分配します。フェデレーテッド オブジェクトには、オブジェクトのデプロイメント ステータスを宣言するための、テンプレート (オブジェクト テンプレート)、配置 (ターゲット クラスター)、およびオーバーライド (クラスターの区別) の 3 つのフィールドがあります。たとえば、以下に示すように、Deployment 配布用のマスター クラスターに FederatedDeployment を作成できます。
apiVersion: types.kubefed.k8s.io/v1beta1
kind: FederatedDeployment
metadata:
name: test-deployment
namespace: test-namespace
spec:
template: # 定义 Deployment 的所有內容，可理解成 Deployment 与 Pod template 之间的关联。
metadata:
labels:
app: nginx
spec:
...
placement:
# 分发到指定的两个集群中
clusters:
- name: cluster1
- name: cluster2
overrides:
# 在cluster2中修改副本数为5
- clusterName: cluster2
clusterOverrides:
- path: spec.replicas
value: 5
Deployment と ReplicaSet については、KubeFed では ReplicaSchedulingPreference (RSP) を通じてより高度なレプリカ配布戦略を指定することもできます。ユーザーは、RSP 上の各クラスターのレプリカの重み、最小および最大数を設定でき、RSP コントローラーは配置を自動的に計算してフィールドをオーバーライドし、FederatedDeployment または FederatedReplicaSet を更新します。
しかし、実装中に、KubeFed が運用環境の要件を満たせないことがわかりました。
- リソース使用率が低い - KubeFed のレプリカ スケジューリング ポリシー RSP は、各メンバー クラスターに対して静的な重みしか設定できず、クラスター リソースの変更に柔軟に対応できないため、さまざまなメンバー クラスターのデプロイメント レベルが不均一になります。
- 変更が十分にスムーズではない - スケールアップまたはスケールダウン時にインスタンスの不均一な分散がよく発生し、その結果、災害復旧機能が低下します。
- スケジューリングのセマンティック制限 - ステートレス リソースのみが適切にサポートされており、ステートフル サービスやジョブなどの多様なリソースに対するサポートが不十分であり、スケジューリングのスケーラビリティが不十分です。
- アクセス コストは高くなります。フェデレーテッド オブジェクトの作成を通じて分散する必要があり、ネイティブ API と互換性がなく、ユーザーと上位プラットフォームの使用習慣を完全に変える必要があります。
Bytedance のインフラストラクチャの進化に伴い、ステートフル サービス、ストレージ、オフライン オペレーション、機械学習などのビジネス シナリオがクラウド ネイティブをさらに受け入れ、多様なサポートを行うと同時に、効率、スケール、パフォーマンス、コストに対するより高い要件を提示してきました。特殊なシナリオにおけるクラスター間のオーケストレーションおよびスケジューリング機能がますます重要になっています。そこで、2021年末にKubeFed v2をベースにした新世代クラスターフェデレーションシステムKubeAdmiralを開発しました。
KubeAdmiral アーキテクチャの進化
KubeAdmiral という名前は、提督 ([ˈædm(ə)rəl] と発音) に由来しており、元々は艦隊司令官を意味します。Kube(rnetes) 接頭辞が追加されているということは、このツールが強力な Kubernetes マルチクラスター オーケストレーション機能とスケジューリング機能を備えていることを意味します。
KubeAdmiral は、Kubernetes ネイティブ API をサポートし、豊富でスケーラブルなスケジューリング フレームワークを提供し、スケジューリング アルゴリズムと配布プロセスを注意深く磨き上げています。いくつかの注目すべき機能については、以下で詳しく説明します。
1. 豊富なマルチクラスタースケジューリング機能
スケジューラは、フェデレーテッド システムのコア コンポーネントであり、レプリカ スケジューリング シナリオでは、各クラスターに必要なレプリカを計算する役割も担います。 、リソース効率、安定性などの重要な機能。
KubeFed は、レプリカ スケジューリング用の RSP スケジューラを提供しますが、そのカスタマイズとスケーラビリティは非常に限られており、その動作を変更するには、コードを変更することで完了する必要があり、同時にステートフル サービスもサポートされていません。 、求人リソースなど。
KubeAdmiral は、より豊富なスケジューリング セマンティクスを導入し、ラベルやステインなどを通じてより柔軟なクラスター選択をサポートし、ステートフルなジョブタイプのリソース スケジューリング機能を提供し、依存関係に従うスケジューリングなどの最適化を導入します。スケジューリングのセマンティクスは、次に示すように PropagationPolicy オブジェクトを通じて構成できます。
apiVersion: core.kubeadmiral.io/v1alpha1
kind: PropagationPolicy
metadata:
name: mypolicy
namespace: default
spec:
# 提供多种集群选择方式，最终结果取交集
placement: # 手动指定集群与权重
- cluster: Cluster-01
preferences:
weight: 40
- cluster: Cluster-02
preferences:
weight: 30
- cluster: Cluster-03
preferences:
weight: 40
clusterSelector: # 类似Pod.Spec.NodeSelector，通过label过滤集群
IPv6: "true"
clusterAffinity: # 类似Pod.Spec.NodeAffinity，通过label过滤集群，语法比clusterSelector更加灵活
- matchExpressions:
- key: region
operator: In
values:
- beijing
tolerations: # 通过污点过滤集群
- key: "key1"
operator: "Equal"
value: "value1"
effect: "NoSchedule"
schedulingMode: Divide # 是否为副本数调度
stickyCluster: false # 仅在首次调度，适合有状态服务或作业类服务
maxClusters: 1 # 最多可分发到多少个子集群，适合有状态服务或作业类服务
disableFollowerScheduling: false # 是否开启依赖调度
同時に、異なるクラスターにスケジュールされたリソースについては、OverridePolicy を使用してクラスター名またはラベルに基づいて区別できます。
apiVersion: core.kubeadmiral.io/v1alpha1
kind: OverridePolicy
metadata:
name: example
namespace: default
spec:
# 最终匹配的集群是所有rule匹配集群的交集
overrideRules:
- targetClusters:
# 通过名称匹配集群
clusters:
- member1
- member2
# 通过标签selector匹配集群
clusterSelector:
region: beijing
az: zone1
# 通过基于标签的affinity匹配集群
clusterAffinity:
- matchExpressions:
- key: region
operator: In
values:
- beijing
- key: provider
operator: In
values:
- volcengine
# 在匹配的集群中，使用jsonpatch语法修改第一个容器的镜像
overriders:
jsonpatch:
- path: "/spec/template/spec/containers/0/image"
operator: replace
value: "nginx:test"
2. スケジュール機能を拡張可能
KubeAdmiral は、kube-scheduler の設計を参照し、拡張可能なスケジューリング フレームワークを提供します。スケジューリング ロジックをフィルター、スコア、選択、レプリカの 4 つのステップに抽象化し、複数の比較的独立したプラグインを使用して各ステップでそのロジックを実装します。上の図に示されている PropagaionPolicy のほとんどすべてのフィールドは、独立した組み込みスケジューリング プラグインによって実装されており、プラグインは相互に干渉せず、スケジューラはグローバル オーケストレーションに必要なプラグインを呼び出します。
さらに、KubeAdmiral スケジューラは、http プロトコルを介した外部プラグインとの対話もサポートしており、ユーザーはカスタマイズされたスケジューリング ロジックを作成して展開し、スケジューリングのために社内システムにアクセスするニーズを満たすことができます。組み込みプラグインは、より一般的な機能を実装し、外部プラグインを補完します。ユーザーは、フェデレーション コントロール プレーンを変更せずに、最小限のコストでスケジューリング ロジックを拡張でき、KubeAdmiral の強力なマルチクラスター分散機能を利用してスケジューリングを行うことができます。効果的な結果が得られます。
3. アプリケーションのスケジュール設定が失敗した場合の自動移行
レプリカによってスケジュールされたリソースの場合、KubeAdmiral は、各メンバー クラスターに必要なレプリカの数を計算し、レプリカ数フィールドを上書きして、各メンバー クラスターに配信します。このプロセスは、リソースが配信された後、フェデレーテッド スケジューリングと呼ばれます。スケジューラーはリソースに対応するポッドを対応するノードに割り当てます。このプロセスは単一クラスターのスケジューリングになります。
リソースが発行された後、ノードのオフライン、リソースの不足、ノード アフィニティの不足などにより、単一クラスターのスケジューリングが失敗することがあります。処理されない場合、使用可能なビジネス インスタンスが予想よりも少なくなります。 KubeAdmiral は、スケジュール失敗時の自動移行機能を提供します。これを有効にすると、メンバー クラスター内のスケジュール不可能なレプリカを特定し、冗長レプリカを収容できるクラスターに移行し、マルチクラスターのリソース ターンオーバーを実現します。
たとえば、3 つのクラスター A、B、および C には、同じ重みで 6 つのコピーが割り当てられます。最初のフェデレーション スケジューリングの後、各クラスターには 2 つのコピーが割り当てられます。クラスター C の 2 つのコピーが単一クラスターでスケジュールされなかった場合、KubeAdmiral はそれらを自動的に A と B に移行します。
| 集まる | あ | B | C |
|---|---|---|---|
| 重み | 1 | 1 | 1 |
| 初期のフェデレーション スケジューリング インスタンスの数 | 2 | 2 | 2 |
| 単一クラスターでのスケジュールに失敗したレプリカ | 0 | 0 | 2 |
| 自動移行後のフェデレーション スケジューリング インスタンスの数 | 3 | 3 | 0 |
4. クラスターの水位に基づいてリソースを動的にスケジュールする
マルチクラスター環境では、マシンがオンラインになったりオフラインになったりすると、各クラスターのリソース レベルが動的に変化します。KubeFed RSP が提供する静的な重みスケジューリング レプリカのみに依存すると、クラスターのデプロイ率が高すぎると、クラスターのレベルが不均一になる可能性があります。サービスのアップグレード中に問題が発生しやすく、ポッドが長期間保留されているように見え、デプロイ率が低いクラスター リソースを十分に活用できません。この点において、KubeAdmiral は、クラスターの水位に基づいた動的重み付けスケジューリングを導入し、各クラスターの総リソース量と使用量を収集することによって使用可能な量を計算し、使用可能なリソース量をコピー スケジューリングの重みとして使用し、最終的に負荷分散を実現します。各メンバー クラスターの展開率は 95% 以上に維持されます。
5. コピー割り当てアルゴリズムの改善
KubeFed のコピー割り当てアルゴリズムにより、スケールアップまたはスケールダウン時にインスタンスの数が予想から逸脱することがよくあります。次に例を示します。
30 個のインスタンスが 3 つのメンバー クラスター A、B、および C に分散されています。 rsp.rebalance = false の場合、ユーザーは 15 個のインスタンスにスケールダウンしたいと考えています。
縮小する前:
| 集まる | あ | B | C |
|---|---|---|---|
| 重み | 10 | 10 | 10 |
| インスタンスの数 | 15 | 15 | 0 |
縮小後:
| 集まる | あ | B | C |
|---|---|---|---|
| 重み | 10 | 10 | 10 |
| インスタンスの数 | 15 | 0 | 0 |
この現象の理由は、KubeFed のレプリカ アルゴリズムが、まずクラスター内に現在存在するインスタンスの数を事前に割り当て、次に、現在のクラスター内にレプリカが多すぎる場合、各クラスターの重みに従って残りのインスタンスを割り当てるためです。これにより、インスタンスの分布と重みの間に重大な偏差が生じます。
KubeAdmiral は、KubeFed のコピー アルゴリズムを最適化して、最終的な分布を加重分布に可能な限り近づけると同時に、拡張および縮小中に予期しない移行が発生しないようにします。例として 30 インスタンスから 15 インスタンスにスケーリングすると、簡略化されたアルゴリズム プロセスは次のようになります。
- 現在の分布 = [15, 15, 0]、レプリカの総数: 30
- 望ましい分布 = [5, 5, 5]、レプリカの総数: 15
- 距離 = 希望 - 現在 = [-10, -10, 5]、合計距離: 15
- 縮小シナリオの場合は、正の項の距離 = [-10, -10, 0] を削除します。
- 距離を重みとして使用して、差 15 を再分配します: [-7, -8, 0]
- 最終的なスケジュール結果: [-7, -8, 0] + [15, 15, 0] -> [8, 7, 0]
| 集まる | あ | B | C |
|---|---|---|---|
| 重み | 10 | 10 | 10 |
| インスタンスの数 | 8 | 7 | 0 |
6. ネイティブリソースのサポート
完全に互換性のない新しい API をユーザーに使用する必要がある KubeFed とは異なり、KubeAdmiral は、Kubernetes 単一クラスター ユーザーの使用習慣に対応し、ネイティブ Kubernetes API のサポートを提供します。ユーザーがネイティブ リソース (デプロイメントなど) を作成すると、フェデレート コントローラーはそれらを他のコントローラーで使用できるフェデレーション内部オブジェクトに自動的に変換し、ユーザーは単一クラスターからマルチクラスター アーキテクチャに迅速に移行し、複数のクラスターの利便性を享受できます。敷居が低い。
KubeAdmiral はこれで終わりではありません。単一クラスターでは、Kubernetes のネイティブ コントローラーは一部のリソースのステータスを更新して、現在のステータスを反映します。多くの場合、ユーザーまたは上位層システムは、デプロイメント ステータスや正常性ステータスなどの情報を表示するためにステータスに依存します。マルチクラスタでは、リソースの状態が複数のクラスタに分散しているため、全体的な状態を確認するには、各クラスタのリソースの状態を1つずつ確認する必要があり、ビューが断片化して運用保守効率が低下するなどの問題が発生します。この問題を解決し、ネイティブ リソースをシームレスにサポートするために、KubeAdmiral は、複数のメンバー クラスター内のリソースのステータスをマージおよび統合し、それらをネイティブ リソースに書き戻すステータス集約機能を提供します。これにより、ユーザーはマルチ リソースを意識する必要がなくなります。 -クラスタートポロジ。フェデレーション全体のリソースのステータスを一目で確認できます。
現在と未来
KubeAdmiral は、Byte Group のビジネス TCE プラットフォームを長年にわたってサポートしており、Douyin や Toutiao などの大規模企業によって磨き上げられ、210,000 台以上のマシンと 1,000 万個以上のポッドを管理しています。実務の経験。 。コミュニティに恩返しするために、KubeAdmiral は GitHub で正式にオープンソース化されました。同時に、Volcano Engine は分散クラウド ネイティブ プラットフォーム (DCP) である KubeAdmiral に基づいた新しいエンタープライズ レベルのマルチクラウドおよびマルチクラスター管理モデルを構築していますので、ご期待ください。
将来に向けて、私たちは次の側面で進化し続ける予定です。
- ステートフル、ジョブタイプ、およびその他のリソースのオーケストレーションおよびスケジューリング機能の改善を継続し、バッチ コンピューティングのマルチクラウドおよびマルチクラスター時代の到来を受け入れるために、自動移行や価格比較スケジューリングなどの高度な機能を開発します。
- ユーザー エクスペリエンスを向上させ、すぐに使えるソリューションを提供して、ユーザーの認知負荷をさらに軽減します。
- 可観測性を向上させ、ログと監視インジケータを最適化し、スケジューラの解釈可能性を向上させます。
- ワンクリックフェデレーションやマルチクラスター移行などの機能を探索して、マルチクラスターアーキテクチャの可能性を最大限に引き出します。
マルチクラスターのオーケストレーションとスケジューリングは本質的に単純ではありません。普遍的で完全なマルチクラスターのフェデレーション システムは、さまざまなシナリオで洗練される必要があります。私たちは、より多くの友人が KubeAdmiral コミュニティに注目し、参加することを楽しみにしています。など、様々なご提案をさせていただきます！
GitHub ：https://github.com/kubewharf/kubeadmiral
仲間のニワトリがDeepin-IDE を 「オープンソース」化し、ついにブートストラップを達成しました。 いい奴だ、Tencent は本当に Switch を「考える学習機械」に変えた Tencent Cloud の 4 月 8 日の障害レビューと状況説明 RustDesk リモート デスクトップ起動の再構築 Web クライアント WeChat の SQLite ベースのオープンソース ターミナル データベース WCDB がメジャー アップグレードを開始 TIOBE 4 月リスト: PHPは史上最低値に落ち、 FFmpeg の父であるファブリス ベラールはオーディオ圧縮ツール TSAC をリリースし 、Google は大規模なコード モデル CodeGemma をリリースしました 。それはあなたを殺すつもりですか?オープンソースなのでとても優れています - オープンソースの画像およびポスター編集ツール