複数のクラスター内の Tekton パイプライン

複数のクラスター内の Tekton パイプライン

[[407477]]

1. 複数のクラスターでTektonを構築する利点

Kubernetes の助けにより、Tekton は優れた弾力性を備え、大規模なビルドをサポートできます。同時に、タスク開発では主に Yaml と Shell が使用されるため、Tekton の適応性がさまざまなシナリオに拡張されます。

上記は、複数のクラスター内の Tekton の図です。 Tekton がパイプラインを実行するために複数のクラスターを必要とするのはなぜですか?

  • いつでも変更できる Kubernetes クラスター。単一の Kubernetes クラスターでは運用と保守の要件を満たすことができず、クラスターをいつでも変更することはできません。マルチクラスター環境では、メンテナンスのために一部のクラスターをオフラインにすることができます。
  • より大規模なビルド。 CI は CPU、メモリ、IO リソースを大量に消費し、ノードやクラスターに簡単に負担をかけてしまう可能性があります。複数のクラスターにより負荷圧力を効果的に分散し、可用性を向上させることができます。
  • ビジネスの分離。企業によって、コードのセキュリティ レベル、ビルド速度、ビルド環境に対する要件は異なります。マルチクラスターは、分離された環境とカスタマイズされたパイプライン サービスを提供できます。

2. Kubernetes クラスターフェデレーション

Kubernetes Cluster Federation は KubeFed と略されます。 KubeFed v2 と v1 との最大の違いは、API サーバーの削除と、CRD メカニズムによるフェデレーテッド リソースの拡張です。 KubeFed コントローラーはこれらの CRD を管理し、リソースの同期やクラスター間のオーケストレーションなどの機能を実装して、モジュール性とカスタマイズを実現します。以下はコミュニティ アーキテクチャ図です。

KubeFed は次の 2 種類の情報で構成されます。

  • KubeFedが処理するAPIタイプを宣言するタイプ構成
  • KubeFed が管理するクラスターを宣言するクラスター構成

タイプ構成には 3 つの基本的な概念があります。

  • テンプレート、クラスター内のリソースのテンプレート記述を定義します
  • 配置は、リソースをどのクラスターに配布する必要があるかを定義します。
  • クラスターで定義されたオーバーライドは、テンプレートのフィールドの内容をオーバーライドする必要があります。

さらに、ステータス、ポリシー、スケジュールを通じて、より高度な機能を実現できます。

  • ステータスは各クラスタ内のリソースのステータスを収集して配布します
  • ポリシーにより、どのクラスターにリソースが割り当てられるかをポリシーで制御できます。
  • スケジューリングにより、リソースはクラスタ間でレプリカを移行できる

さらに、KubeFed は、複数のクラスター間のサービス検出に使用できる MultiClusterDNS も提供します。

3. フェデレーテッド Kubernetes クラスター

3.1 クラスターを準備し、コンテキストを構成する

ここでは 2 つのクラスターがデプロイされています。dev1 はメイン クラスターであり、Tekton のコントロール プレーンとして使用され、パイプライン タスクは実行されません。 dev2 は、Tekton パイプライン タスクを実行するために使用されるサブクラスターです。

2つのクラスターを準備する

メインクラスタ dev1

  1.  kubectl ノードを取得する
  2.  
  3. 名前ステータス 役割 年齢 バージョン
  4. node1 コントロールプレーン、マスター、ワーカー 151m v1.20.4 が準備完了
  1. ヘルムバージョン
  2.  
  3.  version.BuildInfo{バージョン: "v3.2.1" 、GitCommit: "fe51cd1e31e6a202cba7dead9552a6d418ded79a" 、GitTreeState: "clean" 、GoVersion: "go1.13.10" }

サブクラスタ dev2

  1.  kubectl ノードを取得する
  2.  
  3. 名前ステータス 役割 年齢 バージョン
  4. node1 コントロールプレーン、マスター、ワーカー 42d v1.20.4 が準備完了

メインクラスタ上のすべてのクラスタのコンテキストを構成して（クラスタのApiserverの入り口が同じネットワークにあり、直接接続できる必要があります）、サブクラスタを追加します。

コンテキスト内の名前には @ などの特殊文字を含めることはできません。そうしないと、結合時にエラーが報告されます。名前は Secret の作成に使用されるため、Kubernetes の命名規則に準拠する必要があります。

メイン クラスター dev1 の kubeconfig を ~/.kube/config-1 に配置し、名前とその他の情報を次の形式で変更します。

  1.  APIバージョン: v1
  2. クラスター:
  3.  - クラスター:
  4.     ...
  5. 名前: dev1.cluster.local  
  6. コンテキスト:
  7.  - コンテクスト：
  8.     クラスター: dev1.cluster.local  
  9. ユーザー: dev1-kubernetes-admin
  10. 名前: dev1-コンテキスト
  11. ユーザー:
  12.  -名前: dev1-kubernetes-admin
  13. ユーザー:
  14.     ...

サブクラスター dev2 の kubeconfig を ~/.kube/config-2 に配置し、名前とその他の情報を次の形式で変更します。

  1.  APIバージョン: v1
  2. クラスター:
  3.  - クラスター:
  4.     ...
  5. 名前: dev2.cluster.local  
  6. コンテキスト:
  7.  - コンテクスト：
  8.     クラスター: dev2.cluster.local  
  9. ユーザー: dev2-kubernetes-admin
  10. 名前: dev2-context
  11. ユーザー:
  12.  -名前: dev2-kubernetes-admin
  13. ユーザー:
  14.     ...

kubeconfigをマージする

  1. $HOME/.kube/ をコピーします。
  2.  KUBECONFIG=config-1:config-2 kubectl 構成ビュー  --flatten > $HOME/.kube/config  

追加されたクラスターコンテキストを表示する

  1. kubectl config コンテキストを取得する
  2.  
  3. 現在   名前クラスター AUTHINFO 名前空間
  4.           dev1 コンテキスト dev1.cluster。ローカルdev1-kubernetes-admin
  5.           dev2 コンテキスト dev2.cluster。ローカルdev2-kubernetes-admin

メインクラスタ dev1 に切り替える

  1. kubectl config 使用コンテキスト dev1 コンテキスト
  2.  
  3. コンテキスト「dev1-context」に切り替えました。

3.2 メインクラスターにKubeFedをインストールする

Helmを使用してKubeFedをインストールする

  1. Git クローン https://github.com/kubernetes-sigs/kubefed.git
  2.  cd kubefed/チャート/
  3.  helm で kubefed をインストールします。/kubefed/ --namespace kube-federation-system --create-namespace  

表示負荷

  1. kubectl get deploy、pod -n kube-federation-system を実行します。 
  2.  
  3. 名前準備完了最新利用可能年齢
  4. デプロイメント.apps/kubefed-admission-webhook 1/1 1 1 95秒
  5. デプロイメント.apps/kubefed-controller-manager 2/2 2 2 95秒
  6.  
  7. 名前準備完了 ステータス 再起動 年齢
  8. pod/kubefed-admission-webhook-598bd776c6-gv4qh 1/1 実行中 0 95秒
  9. pod/kubefed-controller-manager-6d9bf98d74-n8kjz 1/1 実行中 0 17 秒
  10. pod/kubefed-controller-manager-6d9bf98d74-nmb2j 1/1 実行中 0 14 秒

3.3 メインクラスタにkubefedctlをインストールする

コマンドを実行:

  1.  https://github.com/kubernetes-sigs/kubefed/releases/download/v0.8.0/kubefedctl-0.8.0-linux-amd64.tgz を実行します。
  2.  tar -zxvf kubefedctl-*.tgz
  3.  mv kubefedctl /usr/ローカル/bin/

3.4 クラスターの追加

プライマリ クラスターでコマンドを実行して、dev1 と dev2 をプライマリ クラスター dev1 に追加します。

  1.  kubefedctl dev1-context に参加--host-cluster-context dev1-context --kubefed-namespace=kube-federation-system --v=2   
  2.  
  3.  I0625 14:32:42.969373 25920 join .go:861] 次のシークレットを使用します: dev1-context-dev1-context-token-2w8km
  4.  I0625 14:32:42.972316 25920 join .go:934] ホスト クラスターにdev1-context-ln6vx という名前のシークレットを作成しました
  5. I0625 14:32:42.991399 25920 join .go:299] フェデレーション クラスタ リソースを作成しました
  1. kubefedctl は、dev2 コンテキスト--host-cluster-context と dev1 コンテキスト --kubefed-namespace=kube-federation-system --v=2 を結合します。   
  2.  
  3.  I0625 14:33:11.836472 26424 join .go:861] 次のシークレットを使用します: dev2-context-dev1-context-token-dcl8s
  4.  I0625 14:33:11.840121 26424 join .go:934]ホスト クラスターにdev2-context-264dz という名前のシークレットを作成しました
  5. I0625 14:33:11.898044 26424 join .go:299] フェデレーション クラスタ リソースを作成しました

クラスター リストを表示します。

  1.  kubectl -n kube-federation-system kubefedclusters を取得する
  2.  
  3. 名前年齢 準備完了
  4. dev1-context 45秒真 
  5.  dev2-context 16s真 

3.5 クラスタが正常にフェデレーションされているかどうかをテストする

  • 連邦化されたリソースを表示する

KubeFed をインストールすると、多くの共通リソースが統合され、CRD で表示できるようになります。

  1.  kubectl 取得 crd |grep フェデレーション
  2.  
  3. フェデレーションクラスタロール.types.kubefed.io 2021-06-26T06:22:50Z
  4.  federatedconfigmaps.types.kubefed.io 2021-06-26T06:22:50Z
  5. フェデレーションデプロイメント.types.kubefed.io 2021-06-26T06:22:50Z
  6. フェデレーションイングレス.types.kubefed.io 2021-06-26T06:22:50Z
  7.  federatedjobs.types.kubefed.io 2021-06-26T06:22:50Z
  8. フェデレーションネームスペース.types.kubefed.io 2021-06-26T06:22:50Z
  9. フェデレーションレプリカセット.types.kubefed.io 2021-06-26T06:22:50Z
  10. フェデレーションシークレットタイプ.kubefed.io 2021-06-26T06:22:50Z
  11. フェデレーションサービスアカウント.types.kubefed.io 2021-06-26T06:22:50Z
  12. フェデレーションサービスタイプ.kubefed.io 2021-06-26T06:22:50Z
  13. フェデレーションサービスステータス.core.kubefed.io 2021-06-26T06:22:50Z
  14.  federatedtypeconfigs.core.kubefed.io 2021-06-26T06:22:50Z

federatedtypeconfigs でフェデレーション リソースを確認することもできます。

  1.  kubectl get federatedtypeconfigs.core.kubefed.io -n kube-federation-system 
  2.  
  3. 名前年齢
  4. クラスターロール.rbac.authorization.k8s.io 29 分
  5. 構成マップ 29 分
  6. デプロイメント.apps 29分
  7. イングレス.拡張 29 分
  8. ジョブバッチ 29 分
  9. 名前空間 29m
  10. レプリカセット.アプリ 29分
  11. 秘密 29分
  12. サービスアカウント 29 分
  13. サービス 29m
  • フェデレーション名前空間の作成

名前空間レベルのリソースは、フェデレーションされた名前空間に配置する必要があります。そうしないと、コントローラーはリソースを配布するときにエラーを報告します。

  1.  APIバージョン: v1
  2. 種類: 名前空間
  3. メタデータ:
  4. 名前: テストフィード
  5. ---  
  6.  APIバージョン: types.kubefed.io/v1beta1
  7. 種類: フェデレーテッド名前空間
  8. メタデータ:
  9. 名前: テストフィード
  10.   名前空間: テストフィード
  11. 仕様:
  12.   配置:
  13.     クラスター:
  14.     -名前: dev1-コンテキスト
  15.     -名前: dev2-コンテキスト
  • プライマリクラスタにフェデレーションデプロイメントを作成する

一般的な展開は次のとおりです。

  1.  APIバージョン: アプリ/v1
  2. 種類: デプロイメント
  3. メタデータ:
  4. 名前: nginx
  5.   名前空間:デフォルト 
  6. 仕様:
  7.   レプリカ: 1
  8.   セレクタ：
  9.     一致ラベル:
  10.       アプリ: nginx
  11.   テンプレート：
  12.     メタデータ:
  13.       ラベル:
  14.         アプリ: nginx
  15.     仕様:
  16.       コンテナ:
  17.       - 画像: nginx
  18. 名前: nginx

これは連邦政府の配備の場合です。

  1.  APIバージョン: types.kubefed.io/v1beta1
  2. 種類: フェデレーテッドデプロイメント
  3. メタデータ:
  4. 名前: nginx-fed
  5.   名前空間: テストフィード
  6. 仕様:
  7.   上書き:
  8.     - クラスター名: dev1-コンテキスト
  9.       クラスターオーバーライド:
  10.         - パス: /spec/replicas
  11.           値: 2
  12.     - クラスター名: dev2-context
  13.       クラスターオーバーライド:
  14.         - パス: /spec/replicas
  15.           値: 3
  16.   配置:
  17.     クラスター:
  18.       -名前: dev1-コンテキスト
  19.       -名前: dev2-コンテキスト
  20.   テンプレート：
  21.     メタデータ:
  22.       ラベル:
  23.         アプリ: nginx
  24.       名前空間: テストフィード
  25.     仕様:
  26.       レプリカ: 1
  27.       セレクタ：
  28.         一致ラベル:
  29.           アプリ: nginx
  30.       テンプレート：
  31.         メタデータ:
  32.           ラベル:
  33.             アプリ: nginx
  34.         仕様:
  35.           コンテナ:
  36.             - 画像: nginx
  37. 名前: nginx

FederatedDeploymentを書くときは、3つのフィールドに注意する必要があります。

- オーバーライド、異なるクラスターに応じてオーバーライドする必要があるフィールド属性。ここで、dev1 のレプリカ数は 2 に変更され、dev2 のレプリカ数は 3 に変更されます。

- 配置、リソースを配置する必要があるクラスターのリスト。ここでは、dev1 と dev2 の 2 つのクラスターに配置されます。

- テンプレート、リソースのテンプレート。以下は、apiVersion と kind を除いたデプロイメントの残りの部分です。

  • リソースが正常に配布されたことを確認する

dev1クラスタ上

  1. kubectl -n テストフィードでポッドを取得する
  2.  
  3. 名前準備完了 ステータス 再起動 年齢
  4. nginx-fed-6799fc88d8-7llk9 1/1 実行中 0 8分2秒
  5. nginx-fed-6799fc88d8-clc5w 1/1 実行中 0 8分2秒

dev2クラスタ上

  1. kubectl -n テストフィードでポッドを取得する
  2.  
  3. 名前準備完了 ステータス 再起動 年齢
  4. nginx-fed-6799fc88d8-2ld4k 1/1 実行中 0 7分49秒
  5. nginx-fed-6799fc88d8-6dncp 1/1 実行中 0 7分49秒
  6. nginx-fed-6799fc88d8-x64fb 1/1 実行中 0 7分49秒

4. Tekton の CRD リソースの連携

4.1 Tektonをインストールする

Tektonはすべてのクラスタにインストールする必要がある

  1. kubectl apply -f https://raw.githubusercontent.com/shaowenchen/scripts/main/image-sync/tektondev/dockerhub/release-0.24.1.yaml

Tekton コミュニティは gcr.io イメージを使用しているため、一部のホスト環境ではそれをプルできない可能性があります。私はこれを Dockerhub にバックアップしました。関連する yaml は https://github.com/shaowenchen/scripts/tree/main/image-sync/tektondev/dockerhub にあります。

4.2 Tekton の CRD の連邦化

KubeFed をインストールすると、共通のデプロイメント、シークレットなどがデフォルトでフェデレーションされますが、ユーザー定義の CRD の場合は手動で有効にする必要があります。

コマンドを実行:

  1.  kubefedctl で clustertasks.tekton.dev を有効にします。
  2.  kubefedctl 条件を有効にする.tekton.dev
  3.  kubefedctl パイプラインリソースを有効にする.tekton.dev
  4.  kubefedctl パイプライン実行を有効にする.tekton.dev
  5.  kubefedctl パイプラインを有効にする.tekton.dev
  6.  kubefedctl を有効にすると、runs.tekton.dev が実行されます。
  7.  kubefedctl タスクランを有効にする。
  8.  kubefedctl タスクを有効にする.tekton.dev

taskruns を例にとると、kubefedctl enable taskruns.tekton.dev は次の 2 つのリソースを自動的に作成します。

  • customresourcedefinition.apiextensions.k8s.io/federatedtaskruns.types.kubefed.io、federatedtaskruns、フェデレーション CRD リソース
  • federatedtypeconfig.core.kubefed.io/taskruns.tekton.dev、kube-federation-system 名前空間で、federatedtypeconfig タイプのリソース taskruns を作成し、リソース配布を有効にします。

4.3 新しく作成したフェデレーションCRDリソースを編集し、フィールドを追加する

この手順がない場合、サブクラスターに同期された CR リソース コンテンツは空になります。 kubefedctl enable フェデレーテッド CRD リソースにはテンプレート フィールドがないため。

コマンドを実行:

  1.  kubectl 編集 crd federatedtasks.types.kubefed.io

オーバーライドと配置と同じレベルで、次の例に示すテンプレート コンテンツを追加します。

  1.  apiバージョン: apiextensions.k8s.io/v1
  2.  ...
  3. 仕様:
  4.   バージョン:
  5.   -名前: v1beta1
  6. スキーマ:
  7.       オープンAPIV3スキーマ:
  8.         プロパティ:
  9.           仕様:
  10.             プロパティ:
  11.               上書き:
  12.                 ...
  13.               配置:
  14.                 ...
  15.               テンプレート：
  16.                 タイプ: オブジェクト
  17.                 x-kubernetes-preserve-不明フィールド: true  
  18.             タイプ: オブジェクト

十分に明確でない場合は、https://github.com/shaowenchen/scripts/tree/main/image-sync/tektondev/kubefed を参照して変更できます。バージョン 0.24.1 も使用している場合は、これらの CRD リソースを kubectl で直接適用できます。

4.4 複数のクラスターにおけるTektonオブジェクトの分布をテストする

大量の YAML を貼り付けることを避けるために、配布に FederatedTask を使用するのではなく、事前にサブクラスター上に Task リソースを直接作成します。

  • サブクラスターにタスクを作成する
  1. kubectl apply -f https://raw.githubusercontent.com/tektoncd/catalog/main/task/git-clone/0.4/git-clone.yaml -n テストフィード
  • メインクラスタ dev1 に FederatedTaskRun リソースを作成し、サブクラスタ dev2 に配布します。
  1.  APIバージョン: types.kubefed.io/v1beta1
  2. 種類: FederatedTaskRun
  3. メタデータ:
  4. 名前: git-clone-test
  5.   名前空間: テストフィード
  6. 仕様:
  7.   配置:
  8.     クラスター:
  9.     -名前: dev2-コンテキスト
  10.   テンプレート：
  11.     メタデータ:
  12.       名前空間: テストフィード
  13.     仕様:
  14.       ワークスペース:
  15.         -名前:出力 
  16.           空ディレクトリ: {}
  17.       タスク参照:
  18. 名前: git-clone
  19.       パラメータ:
  20.         -名前: URL
  21.           値: https://github.com/kelseyhightower/nocode
  • サブクラスタ dev2 上の Tekton の Taskrun タスクを表示します。
  1.  kubectl get taskrun -n テストフィード
  2.  
  3. 名前成功 理由 開始時間 完了時間
  4. git-clone-test True成功 15秒 7秒

5. 結論

この記事では主に、KubeFed を使用して複数のクラスターを管理し、Tekton CRD リソースを統合する方法について紹介し、実践します。

複数のクラスターの下にある Tekton は、メイン クラスターを使用してリソースを管理し、サブ クラスターを使用してパイプラインを実行します。これにより、負荷を効果的に分散し、パイプラインの同時実行を増やし、CICD システムの保守性を向上させることができます。

ここでの KubeFed は主に Tekton オブジェクト リソースの保存と配布に使用されます。独自のコードを開発する場合は、データ ストレージとループ コントローラーを使用して完成させることができますが、KubeFed コントローラーを使用すると、迅速に実装でき、多くの潜在的な問題を回避できます。 KubeFed はクラスター間のリソース分散に使用され、非常に適しています。

6. 参考文献

https://github.com/kubernetes-sigs/kubefed

<<:  Netty を使用して高性能な分散サービス フレームワークを作成する方法は?

>>:  Longxingyoufengは、Beanオブジェクトの初期化と破棄のメソッドを実装するために仮想マシンにフックを登録します。

推薦する

初雪から考えるインターネットマーケティング

今日は雪が降りました。2012年最初の雪が降りました。家に帰ってから、私はこう考えました。「神様は本...

2018年上半期、これらのマーケティング事例は注目を集めている

月給5,000～50,000のこれらのプロジェクトはあなたの将来ですテクノロジーの発展に伴い、新しい...

エッジコンピューティングの台頭：そのメリットと応用を探る

従来のクラウド コンピューティングに伴う遅延や遅れにうんざりしていませんか?次に、デジタル環境を一変...

推奨: prometeus-39 ユーロ/8 GB RAM/320 GB HDD/8 TB Flow/イタリア

18 年の歴史を持つホスティング会社 prometeus.net は、基本的にサーバーとして使用でき...

製造、小売、医療の事例から：エッジコンピューティングと人工知能が収益向上にどのように役立つか

[[403666]]ストラトキャスターとテレキャスターのギターを製造するカリフォルニア州コロナに本社...

再入荷: Xenspec: 米国無制限トラフィック VPS、月額 2.95 ドルから、1Gbps 帯域幅、40Gbps 防御内蔵

xenspec(年～)の無制限通信VPSサービスは長らく在庫切れだったようですが、最近再入荷したよう...

事例分析：ウェブサイトが開けないのにランキングが残る理由

なぜ一部のウェブサイトは開けないのでしょうか？なぜランキングが残っているのでしょうか？中には長期間ラ...

2018 年のクラウド コンピューティング: ハイブリッド、エッジ、AI

時が経ち、2018 年半ばには、クラウド コンピューティングに対する企業の姿勢も変化しています。 I...

#黒5# liquidweb: フルマネージド専用サーバーが34%オフ、フルマネージド VPSが37%オフ

Liquidweb がブラックフライデーのプロモーションを実施します。3 つの完全管理型 VPS (...

なぜ Apple のクラウドサービスは貴州省に行き着いたのか?担当者は3つの理由を指摘した。

中国国営ラジオ北京1月11日ニュース（記者張昭夫王希）中国国営ラジオの「ニュースパノラマ」の報道によ...

実際の事例：ウェブサイトのホームページが1週間ブロックされ、その後回復した

医療系サイトの場合、ホームページが削除され、ランキングが下がった場合の損失は想像に難くありませんが、...

ウェブサイト内部のページランキング最適化の利点と具体的な最適化方法の簡単な分析

ウェブサイトの最適化を行う際、ウェブサイトのコアキーワードのランキングを向上させたいと考えています。...

K8S関連の知識を徹底的に理解する

その名前は多くの人が知っていると思いますが、Docker との関係を区別できず、何に使用され、どのよ...

インスピレーションを活用してソフトコンテンツマーケティングを推進する

私たちのネットワークプロモーションにおけるソフト記事プロモーションの位置は、「軸」という単語で説明で...

電子商取引のトレンド分析: モバイル、ソーシャル、垂直市場の台頭

ベンチャーキャピタル会社メイフィールド・ファンドは30億ドル以上の資金を管理しており、その投資分野に...