クラウド

Autoscaler for Runners on Kubernetes

多数のセルフホスト型ランナーを管理するには時間がかかり、カスタム ツールが必要になる場合があります。Autoscaler for Runners on Kubernetes は、Kubernetes でホストされているランナーのオーケストレーションと管理を改善するように設計されています。

オートスケーラーは、お客様が運営および管理する既存の Kubernetes クラスターにデプロイされるサービスです。デプロイされると、オートスケーラーによって、実行可能なジョブに応じて Linux エージェントの数が自動的にスケーリングされます。

まずはじめに

スケーリング ポリシーは設定ファイルで設定できます。これにより、オートスケーラーでは Bitbucket Cloud Runner API をポーリングして、ビルドを受信できるランナーを自動的に増減できます。

Base64 パスワードの作成

Choose one of the authentication methods, either app password or oauth, and encode it in base64. These values will be used in the installation steps below.

base64 でエンコードする方法の例

OAuth の場合

echo -n $BITBUCKET_OAUTH_CLIENT_ID | base64 echo -n $BITBUCKET_OAUTH_CLIENT_SECRET | base64

アプリ パスワードの場合

echo -n $BITBUCKET_USERNAME | base64 echo -n $BITBUCKET_APP_PASSWORD | base64

Kubernetes リソースのインストール

  1. Git リポジトリを複製します。

git clone git@bitbucket.org:bitbucketpipelines/runners-autoscaler.git

2. kustomize フォルダーに移動します。

cd kustomize

3. values フォルダー内のファイルを設定します。

  • runner_config.yaml ファイルで次の操作を実行します。

    • ワークスペースの UUID を設定します。

    • リポジトリ ランナーの場合はリポジトリの UUID を設定します。

    • コメントを読み、他のパラメーターを確認します。

  • kustomization.yaml ファイルで次の操作を実行します。

    • OAuth を使用している場合

      • Secret セクションの Option 1 の下にあるコードのコメントを解除し、/data/bitbucketOauthClientId と /data/bitbucketOauthClientSecret のパスの value フィールドに、さきほど生成した base64 エンコード値を設定します。

      • Deployment セクションの Option 1 の下にあるコードのコメントを解除します。

    • アプリ パスワードを使っている場合

      • Secret セクションの Option 2 の下にあるコードのコメントを解除し、/data/bitbucketUsername と /data/bitbucketAppPassword のパスの value フィールドに、さきほど生成した base64 エンコード値を設定します。

      • Deployment セクションの Option 2 の下にあるコードのコメントを解除します。

4. 生成された出力を確認します。

kubectl kustomize values

5. 出力を適用します。

kubectl apply -k values

6. runner-controller ポッドが動作しているかを確認します。

kubectl logs -f -l app=runner-controller -n bitbucket-runner-control-plane

7. ランナーが作成されているかどうかを確認します。

kubectl logs -l runner_uuid -c runner

Kubernetes ノードのスケーリング (強く推奨)

Kubernetes クラスターにはノード水平オートスケーラーを設定する必要があります。escalator など、大規模なバッチまたはジョブベースのワークロードに合わせて最適化されたツールを使用することをおすすめします。詳細については、デプロイ ドキュメントを参照してください。

AWS を使用している場合は、通常使用しているものではなく、デプロイ aws/escalator-deployment-aws.yaml を使用する必要があります。

Kubernetes ノードの設定

ジョブ設定マップを見ると、nodeSelector があることがわかります。これは、ランナーが実行されるノードには、それと一致するラベルが必要であることを意味します。AWS EKS では、EKS マネージド型ノード グループを介してこれを設定できます。

たとえば、設定マップのジョブ テンプレートには customer=shared というラベルがあります。そのため、Kubernetes ノードはラベル kubectl label nodes <kubernetes-node> customer=shared で更新する必要があります。

注: このラベルは escalator 設定マップで設定したものとも一致させる必要があります。

メモリ リソースと CPU リソースの設定 (省略可)

設定マップ テンプレートを見ると、resources タグが定義されているのがわかります。メモリと CPU の上限は必要に応じて設定できます。ただし、ほとんどのシナリオでは、メモリの 2Gi と CPU の 1000m という既定の設定で問題ありません。

インスタンス上のランナーの密度を考えてみましょう。たとえば、インスタンスのサイズが 8Gb の場合、ランナーに 4Gi を使用するだけの価値がない可能性があります。この場合、割り当て可能なメモリの半分強を占めることになるため、インスタンスごとに 1 つのランナー ポッドしか使用できないためです。ランナーには現在の最小値である 1Gi のメモリをおすすめします。

定数の設定 (省略可)

設定マップ テンプレートを見ると、constants タグが定義されているのがわかります。runner_api_polling_interval は、ランナー オートスケーラー コントローラーが Bitbucket API からデータを取得する頻度を定義するために使用されます。既定値は 600 秒ですが、これは必要に応じて変更できます。リクエストがスロットリングされることにつながる可能性があるため、この値を 120 秒未満に設定することは推奨されていません。

設定をおすすめするもう 1 つのパラメーターが runner_cool_down_period です。これは、最近作成されたランナーをスケール ダウンするまでの待機時間を決定するために使用されます。300 秒以上に設定することが推奨されています。

オートスケーラー クリーナーの使用

Runner Autoscaler Cleaner は、よりクリーンなデプロイで構成されたアプリです。このアプリでは、異常なランナーやリンクされたジョブを自動的に消去 (削除) できます。

現在のところ、Autoscaler Cleaner を起動する前にカスタム設定は必要ありません。ただし、設定オプションが将来追加される可能性があります。

設定の例と説明

ランナー オートスケーラー ツールの初期設定ではインフラストラクチャが次のような状態になっています。

  • Kubernetes ノードが 1 つ

  • 1 つの Kubernetes ジョブがある 1 つのランナーがオンライン

  • 必要に応じて追加の Kubernetes ノードを作成する escalator ポッド

escalator の configMap

data: nodegroups_config.yaml: | node_groups: - name: "pipes-runner-node" ... scale_up_threshold_percent: 70 max_nodes: 5

上記の escalator のConfigMap では、Kubernetes ノードの CPU 使用率が 70％ を超えると、Kubernetes ノードのキャパシティを満たすようオートスケーラーによってジョブがスケールアップされます。その後、escalator によって追加の Kubernetes ノードがプロビジョニングされます。

オートスケーラーがスケールアップとスケールダウンを判断する仕組み

オートスケーラーの動作は次の計算に基づいています。

runners scale threshold value = BUSY_ONLINE_RUNNERS / ALL_ONLINE_RUNNERS

次に、指定された設定ファイルにある scale_up_threshold と scale_down_threshold がオートスケーラーで上記の式と比較されます。

ランナーのスケールしきい値が scale_up_threshold よりも大きい場合は、ほとんどの「 ONLINE」ランナーが BUSY 状態 (パイプライン ジョブを実行中) で、新しいランナーが作成されることになります。ランナーのスケールしきい値が scale_down_threshold よりも小さい場合は、ほとんどの「 ONLINE」ランナーが IDLE 状態で、オンライン ランナーの数が最小数まで減ることになります。

ランナー数を増減する速度は、設定ファイルの scale_up_multiplier と scale_down_multiplier の値を使用して上げ下げできます。

オートスケーラーによって計算される必要ランナー数の計算式は以下のとおりです。

desired count of runners = ALL_ONLINE_RUNNERS * scale_up_multiplier # scale up case or desired count of runners = ALL_ONLINE_RUNNERS * scale_down_multiplier # scale down case

トラブルシューティングと制限事項

  • Kubernetes オートスケーラーは Linux ランナーでのみ動作確認が行われています。

  • オートスケーラー ツールでは、ランナーのライフサイクルを作成および管理することで、負荷に応じて利用可能なビルドをサポートするのに必要な数のランナーを用意します。設定ファイルで宣言されている最大値、または Bitbucket API ランナーのインフラストラクチャ上限 (現在は 100) までこの処理が続けられます。

  • 最大値である 100 は現在検討中です。チームでは、将来のリリースで修正を提供するために引き続き取り組んでいきます。

サポート モデル

Kubernetes オートスケーラーは、お客様が Kubernetes に関する既存のコンピテンシーを活用する必要があるツールです。こちらは、セルフホスト型ランナーを実行する上級ユーザー向けのオプションとなっています。ネットワーク、カスタム インフラストラクチャ設定、その他の問題に関する課題は Bitbucket Support の対象外です。コミュニティ グループ「Bitbucket Pipelines: Runner Autoscaler for Kubernetes」で問題を確認して話し合うことができます。

「Bitbucket Pipes 統合 | Bitbucket」同様、bitbucketpipelines/runners-autoscaler のソース コードは公開されており、必要に応じてコードをフォークし、ニーズに合わせて調整できるようにすることを目的としています。

Runners Autoscaler はサポート範囲外であり、カスタム設定に関するコンサルティング サービスは提供できまないため、あらかじめご了承ください。機能のリクエストを検討している場合やバグを発見した場合は、コミュニティ グループで共有していただければ対応させていただきます。

さらにヘルプが必要ですか?

アトラシアン コミュニティをご利用ください。
コミュニティに質問
このページの内容まずはじめにBase64 パスワードの作成Kubernetes リソースのインストール推奨されるアクションKubernetes ノードのスケーリング (強く推奨)Kubernetes ノードの設定メモリ リソースと CPU リソースの設定 (省略可)定数の設定 (省略可)オートスケーラー クリーナーの使用設定の例と説明オートスケーラーがスケールアップとスケールダウンを判断する仕組みトラブルシューティングと制限事項サポート モデル
コミュニティ質問、ディスカッション、記事