Bitbucket is getting a new navigation

We’re rolling out these changes, so the documentation may not match your experience in the Bitbucket Cloud app. Read about the new Bitbucket navigation

Autoscaler for Runners on Kubernetes

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

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

まずはじめに

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

Base64 パスワードの作成

API トークンか OAuth のいずれかの認証方法を選択し、base64 でエンコードします。これらの値は以下のインストール手順で使用されます。

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

For oauth:

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

For API token:

echo -n $ATLASSIAN_ACCOUNT_EMAIL | base64 echo -n $ATLASSIAN_API_TOKEN | base64

注:ATLASSIAN_API_TOKEN には次の必須スコープ read:repository:bitbucketread:workspace:bitbucketread:runner:bitbucketwrite:runner:bitbucket が必要です。

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 の下にあるコードのコメントを解除します。

    • API トークンを使用している場合

      • 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

Your Kubernetes cluster will need to have a node horizontal autoscaler configured. We recommend using a tool that is optimized for large batch or job-based workloads such as escalator. Refer to the deployment docs for more details.

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

Kubernetes ノードの設定

In the job configuration map, you will notice there's a nodeSelector, which means the nodes that the runners will be running on need to have a label that matches it. In AWS EKS, this can be configured via EKS Managed Node Groups.

たとえば、設定マップのジョブ テンプレート (config/runners-autoscaler-cm-job.template.yaml) には、customer: shared というラベルがあります。

Note: This label also must match the one you configured in escalator config map.

メモリ リソースと 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 ランナー) までこの処理が続けられます。

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

サポート モデル

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

Similar to Bitbucket Pipes integrations | Bitbucket the source code of bitbucketpipelines/runners-autoscaler is public, and the intention is that you can fork and adjust code to suit your needs as required.

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

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

アトラシアン コミュニティをご利用ください。