Autoscaler for Runners on Kubernetes

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

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

まずはじめに

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

Base64 パスワードの作成

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

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 リソースのインストール

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

この内容はお役に立ちましたか?

正確ではなかった

明確ではなかった

関係なかった

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

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

コミュニティに質問