actions-runner-controllerの設計

actions-runner-controllerの設計の説明が画像埋め込みの英語だった為、文字起こしして、ChatGPTに翻訳させました.
良ければどうぞ.

翻訳

1. まず、提供された Helm チャートを使用して actions-runner-controller をインストールします。これにより、コントローラマネージャーポッドが所望の名前空間にデプロイされます。次に、提供された Helm チャートまたはカスタマイズしたマニフェストファイルを使用して、AutoScalingRunnerSet リソースをデプロイすることができます
2. 新しい AutoScaling RunnerSet がデプロイされると、Actions Service 内に Runner ScaleSet が作成されるトリガが発生します。
3. その後、AutoScalingListener コントローラによって Runner ScaleSet Listener ポッドが作成されます。このポッドでは、リスナーアプリケーションが Actions Service に接続して認証し、長期ポーリング HTTPS 接続を確立します。リスナーは、Actions Service から Job Available メッセージを受信するまでアイドル状態になります
4. ユーザがワークフローの実行をトリガすると、Actions Service は、個々のジョブ実行をジョブを実行可能なランナーや Runner ScaleSet にディスパッチします。つまり、ラベルが一致し、必要な権限がある適切なランナーグループに属しています
5. Runner ScaleSet Listener が Job Available メッセージを受信すると、デスクリプタされた状態にスケーリングアップできるかどうかを確認し、できる場合は、メッセージを確認します
6. Runner ScaleSet Listener は、Service Account およびそのアカウントにバインドされた役割を使用して、Kubernetes API を通じて HTTPS 呼び出しを行い、希望のレプリカ数を EphemeralRunner Set に更新します
7. EphemeralRunner Set は新しいランナーの作成を試みます。EphemeralRunner コントローラは、JIT 構成トークンを要求し、これを使用してランナーを登録します。次に、コントローラはポッドの作成を試みます。ポッドのステータスが失敗した場合は、最大5回までリトライし、それ以降はあきらめます。24時間後に Actions Service がジョブの割り当てを解除します
8. ランナーポッドが作成されると、ポッド内のランナーサービスは JIT 構成トークンを使用して Actions Service に登録し、実行するジョブの詳細を受信するための別の HTTPS ロングポーリング接続を確立します。
9. Actions Service はランナー登録を確認し、ジョブ実行詳細をディスパッチします
10. ジョブの実行中、ランナーはログとジョブの実行ステータスを継続的に Actions Service に通信します
11. ランナーがジョブを正常に完了したら、EphemeralRunner コントローラは Actions Service と照合し、このランナーが削除しても問題ないかを確認し、EphemeralRunnerSet がクリーンアップを行います

英語

1. You start by installing actions-runner-controller through the supplied helm charts. This will deploy the controller manager pod in the desired namespace. Then you can proceed to deploying an AutoScalingRunnerSet resource via the supplied helm charts or via a manifest file that you customise
2. When a new AutoScaling RunnerSet is deployed, this will trigger the creation of Runner ScaleSet in the Actions Service.
3. Then, a Runner ScaleSet Listener pod is created by the AutoScalingListener Controller. In this pod, the listener application will connect to the Actions Service to authenticate and establish a long poll HTTPS connection. The listener will stay idle until it receives a Job Available message from the Actions Service
4. When a user triggers a workflow run, the Actions Service will dispatch individual job runs to the runners or Runner ScaleSets that are capable of running the job i.e. labels match and they belong to the appropriate runner group with the necessary permissions
5. When the Runner ScaleSet Listener receives the Job Available message, it will check whether it can scale up to the desired state and if it can, the listener will acknowledge the message
6. The Runner ScaleSet Listener will use a Service Account and a Role bound to that account to make an HTTPS call through the Kubernetes APIs to update the EphemeralRunner Set with the number of desired replicas count
7. The EphemeralRunner Set will make an attempt at creating a new runner. The EphemeralRunner Controller will request a JIT config token which will be used to register the runner. Then the controller will attempt to create the pod. If the pod's status is failed, we retry up to 5 times then we give up. After 24 hours the Actions Service will unassign the job
8. Once the runner pod is created, the runner service (in the pod) will use the JIT config token to register itself with the Actions Service and establish another HTTPS long poll connection to receive the job details it needs to execute
9. The Actions Service will acknowledge the runner registration and dispatch the job run details
10. Throughout the job run execution, the runner will continuously communicate the logs and job run status back to the Actions Service
11. When the runner completes its job successfully, the EphemeralRunner Controller double checks with the Actions Service whether this runner is good to be deleted and then EphemeralRunnerSet takes care of the cleanup