fbpx

CL LAB

HOME > CL LAB > EKS on Fargate で GitLab Runner を動かす #GitLab #Kubernetes #AWS

EKS on Fargate で GitLab Runner を動かす #GitLab #Kubernetes #AWS

 ★ 11

はじめに

Amazon Elastic Kubernetes Service(以降EKS)はAWSのManaged Kubernetesサービスです。
Kubernetesを本気で運用しようと思うとかなり大変ですが、EKSを利用するとKubernetesの運用の多くをAWSに任せることができ、より多くの時間をその上で動作させるアプリケーションのために使うことができます。
AWS Fargateはコンテナ向けサーバレスコンピューティングで、これを利用するとコンテナを必要な時・必要な分だけリソースを確保し実行することができます。
EKSでは通常のEC2インスタンスとは別に、Fargateをバックエンドとして利用することができます。
EKS on Fargateと呼ばれているようです。また、これらは併用することもできます。
Jobのような何かのイベントを契機に実行されるワークロードは、それが必要とするリソースを都度確保・実行できるFargateと相性が良いです。
今回はEKS on Fargateを用いて、GitLab RunnerのJobを動かそうという内容です。

Managed Kubernetesを使えば何でも解決してくれる?

一度ここでFargateがない世界を考えてみましょう。
Managed Kubernetesのサービスを利用したとしても、コンテナアプリケーションを動かすときノード(基本的なEKSの場合EC2インスタンス)を意識する必要はあります。
例えばコンテナアプリケーションをスケールアウトするには、当然それらが動作できるだけのノード数が必要となります。
一つのコンテナで大量にリソースが必要となるような特性のアプリケーションがある場合は、ノードのインスタンスタイプも気にしなければなりません。
そういう事を考えたくないために「えいや!」とあらかじめノードを大量に用意してしまうと、余剰分のリソースが常に発生してしまい無駄な料金を払うことになってしまいます。

Kubernetesでは一つのノードに複数のコンテナアプリケーションが同時に起動していることも普通です。Podに対して適切なリソースのrequests/limitsが設定されていなければ、ノイジーネイバーな状態になってしまうものもあるでしょう。
この状態から特定アプリケーションを保護するために、Taint/Tolerationを利用した専用ノードを用意することも珍しくないかと思います。このアプローチをとった場合、今後それらのノード群の考慮も増えてしまうということになります。

そしてこの専用ノードが常時リソースが利用されない遊びのリソースがある場合だとどうでしょう?これも料金を考えるとなるべく避けたい状態です。
例えば少し重めなバッチ処理を一時的にKubernetesクラスタのJobとして動作させる必要がある場合、これらの処理は同一クラスタの他のアプリケーションの処理を妨害して欲しくない(逆も然り)場合もあるでしょう。
一時的にJobを実行するために専用ノードを追加して、Jobが終わればノードを削除して...とすることは技術的にできることではありますが、極力こんな管理はしたくないはずです。

このようにManaged Serviceだからと言って全ての面倒事が解決するわけではなく、利用するアプリケーションの特性によってはノードのこともしっかり考慮する必要があります。
Cluster Autoscalerを利用することで、これらの一部は自動化できますが、全ての問題を解決してくれるわけではありません。
必要な時・必要な分だけだけリソースを確保し、不要になればすぐに破棄でき、料金は利用した分だけといったサービスがあると嬉しいなと誰しもが考えることでしょう。

Fargateではそのような悩みの多くを解決してくれるサービスです。
EKS on Fargateの利用方法としていくつか例を紹介すると、

  • 他のワークロードのノイジーネイバーになり得そうなアプリケーションをFargateとして動かし、簡易的な専用ノードのような使い方をする
  • 定期実行のバッチ処理を実行するワークロードとしてFargateを利用する etc...

便利な分、同一リソース量のノードと比べると若干割高な料金となっており、そのため何かイベント起因で動作するJobのようなものに相性が良さそうです。
前置きが長くなってしまいましたが、今回はそのGitLab RunnerのJobをFargateで動かしてみよう!という内容です。

Fargate で GitLab Runner の Job を動かす

GitLab Runnerは、GitLab CI/CDと連携してパイプラインのジョブを実行するアプリケーションです。
パイプラインのジョブは、Runner登録時に指定したExecutorの環境をプロセスジョブとして起動し、そこで実行されます。
DockerやSSH先のノード、Kubernetesもその実行環境として利用することができます。
どのような環境がExecutorとして設定できるかはこちらをご確認ください。

GitLab RunnerをFargateで動作させる方法として公式ページでは以下のような実装例が紹介されています。

上記ではEC2インスタンス上でGitLab Runnerを管理し、JobをFargateで実行するためのCustom Executorを利用しているようです。
EKSを利用する場合は、よりシンプルにこのような環境を実現することができます。
何故ならGitLab Runnerは公式で提供されているHelm Chartを利用することで容易にインストールでき、KubernetesのPodでJobを実行するExecutorが実装されているため、別途Custom Executorを入れる必要がないからです。

EKS on Fargateについて

EKSでFargateを利用できるようにする具体的な設定方法はここでは割愛しますが、
特定の "ネームスペース" と "ラベル" が指定された場合のみ、Fargateを利用してPodを起動するという設定ができます。
それ以外のPodはEC2インスタンス上で実行されます。

GitLab Runner自体は常にGitLabのCI/CDの実行に関するイベントを受け取る必要があるため、Jobとは異なり常時稼働させなくてはなりません。
常時稼働を考慮すると、Fargateより費用が抑えられるEC2インスタンスのノードに載せたくなることも十分に考えられます。そのため今回はそのように設定します。
上記のラベルやネームスペースによりFargateかEC2どちらをノードとして利用するか選択でき、この機能により常にGitLabのイベントを受け取る必要があるGitLab RunnerはEC2インスタンスで、JobはFargateを利用する方針で進めていきます。
この動作確認をする上で、gitlab-runnerネームスペースでuse-fargate = "true"ラベルが付与されたPodがFargateを利用できるようクラスタに設定してあります。

Helm を利用してGitLab Runnerをインストール

GitLab Runnerのインストール自体はHelmを利用すると非常に簡単です。
Fargateを利用する場合もインストール方法はGitLab Runnerをkubernetes上でラフに動かしてみようで紹介されている通りですが、設定パラメータを投入するvalues.yamlで以下のような追加の設定が必要となります。

runners:
  config: |
    [[runners]]
      [runners.kubernetes]
        cpu_request = "2"
        memory_request = "8Gi"
        namespace = "gitlab-runner"
        poll_timeout = 600
        [runners.kubernetes.pod_labels]
          use-fargate = "true"

上記の設定を少し解説します。
cpu_requestmemory_requestはJobを実行するPodのspec.containers[].resources.requestsの設定となります。
FargateはPodのrequestsに応じて適切なリソースを確保するため、どのようなJobを実行したいかにより設定が変わります。
namespaceでJobを実行するnamespaceを指定します。指定しなければGitLab Runnerと同じnamespaceで動きます。
pod_labelsはJobを実行するPodに付与するラベルで、ここが今回の設定で一番大事な部分です。
ここでFargateとして実行するためのラベルを指定することで、全てのJobはFargateで実行されます。
一方このラベルを指定せず起動するGitLab RunnerはEC2インスタンス上で実行されます。
Fargateを利用したPodは起動に多少時間がかかるため、poll_timeoutの時間を伸ばしておくと良いです。
その他のGitLab RunnerのKubernetes Executorの設定項目はこちらをご参照ください。

後はこのvalues.yamlを利用し、Fargateを動作させることができるネームスペース(今回の例の場合gitlab-runner)へGitLab Runnerをインストールすれば準備は完了です。

動作確認

インストールが成功していると以下のようにGitLab RunnerのPodはEC2のノードで実行されていることがNODEから確認できます。

$ kubectl get pod -o wide
NAME                                           READY   STATUS    RESTARTS   AGE     IP          NODE                                           NOMINATED NODE   READINESS GATES
gitlab-runner-gitlab-runner-54d4d768bc-f24lt   1/1     Running   0          4m50s   10.0.2.28   ip-10-0-2-39.ap-northeast-2.compute.internal              

この状態でGitLab RunnerのJobを実行させます。
すると以下のようにFargateで実行されていることがわかります。

$ kubectl get pod -o wide
NAME                                             READY   STATUS    RESTARTS   AGE     IP           NODE                                           NOMINATED NODE   READINESS GATES
gitlab-runner-gitlab-runner-54d4d768bc-f24lt     1/1     Running   0          20m     10.0.2.12    ip-10-0-2-39.ap-northeast-2.compute.internal              
runner-1sbvnz1z-project-1083-concurrent-0wnhk7   2/2     Running   0          2m43s   10.0.2.133   fargate-10.0.2.133                                        

Fargateでは1Podに1Node作成されます。

$ kubectl get node
NAME                                           STATUS   ROLES    AGE   VERSION
fargate-10.0.2.133                             Ready       28s   v1.20.4-eks-6b7464
ip-10-0-0-43.ap-northeast-2.compute.internal   Ready       11d   v1.20.4-eks-6b7464
ip-10-0-1-48.ap-northeast-2.compute.internal   Ready       11d   v1.20.4-eks-6b7464
ip-10-0-2-39.ap-northeast-2.compute.internal   Ready       11d   v1.20.4-eks-6b7464

Jobが終了されるとNodeが削除されていることも確認できます。

$ kubectl get node
NAME                                           STATUS   ROLES    AGE   VERSION
ip-10-0-0-43.ap-northeast-2.compute.internal   Ready       11d   v1.20.4-eks-6b7464
ip-10-0-1-48.ap-northeast-2.compute.internal   Ready       11d   v1.20.4-eks-6b7464
ip-10-0-2-39.ap-northeast-2.compute.internal   Ready       11d   v1.20.4-eks-6b7464

このようにJobで必要な時・必要な量だけのリソースを利用することができました。

最後に

GitLab RunnerのJobに限らず他のノードのコンテナへ影響を与えることなく、何かしらイベント起因でPodを動かす必要がある物(例えばCronJob/Jobなど)では同様のメリットが得られます。
しかしFargateにはいくつかの制約があり、例えばPrivilegedなPodが作成できません。
そのため例えばDocker in Dockerによるイメージビルドはできず、Jobの中でイメージビルドが必要な場合はkanikoを利用するなどして対応する必要があります。
制約があるものの、それらと上手に付き合っていけばEKS on Fargateは様々な利用方法がありそうです。

New call-to-action

CL LAB Mail Magazine

CL LABの情報を逃さずチェックしよう!

メールアドレスを登録すると記事が投稿されるとメールで通知します。

メールアドレス: 登録

※登録後メールに記載しているリンクをクリックして認証してください。

Related post