クラスタ自動スケーリングによるOCI Kubernetes EngineへのGitLabランナーのデプロイ

GitLab RunnersをOracle Cloud Infrastructure (OCI) Kubernetes Engineに自動スケーリング機能を使用してデプロイし、ロードに基づいてワーカー・ノードを自動的にスケーリングして、CI/CDパイプラインでスムーズにジョブを実行します。

アーキテクチャ

このアーキテクチャは、OCI Kubernetes Engine (OKE)クラスタにデプロイされたGitLabランナーを示しています。

次の図は、このリファレンス・アーキテクチャを示しています。

git-lab-runner-kubernetes.pngの説明が続きます
図git-lab-runner-kubernetes.pngの説明

git-lab-runner-kubernetes-oracle.zip

このアーキテクチャには、次のコンポーネントがあります。

  • リージョン

    Oracle Cloud Infrastructureリージョンとは、可用性ドメインと呼ばれる1つ以上のデータ・センターを含む、ローカライズされた地理的領域です。リージョンは他のリージョンから独立し、長距離の場合は(複数の国または大陸にまたがって)分離できます。

  • 可用性ドメイン

    可用性ドメインは、リージョン内の独立したスタンドアロン・データ・センターです。各可用性ドメイン内の物理リソースは、他の可用性ドメイン内のリソースから分離されているため、フォルト・トレランスが提供されます。可用性ドメインどうしは、電力や冷却、内部可用性ドメイン・ネットワークなどのインフラを共有しません。そのため、ある可用性ドメインでの障害は、リージョン内の他の可用性ドメインには影響しません。

  • フォルト・ドメイン

    フォルト・ドメインは、可用性ドメイン内のハードウェアおよびインフラストラクチャのグループです。各アベイラビリティ・ドメインに3つのフォルト・ドメインがあり、電源とハードウェアは独立しています。複数のフォルト・ドメインにリソースを分散する場合、アプリケーションは、物理サーバーの障害、システム・メンテナンスおよびフォルト・ドメイン内の電源障害を許容できます。

  • 仮想クラウド・ネットワーク(VCN)およびサブネット

    VCNは、Oracle Cloud Infrastructureリージョンで設定する、カスタマイズ可能なソフトウェア定義のネットワークです。従来のデータ・センター・ネットワークと同様に、VCNを使用するとネットワーク環境を制御できます。VCNには重複しない複数のCIDRブロックを含めることができ、VCNの作成後にそれらを変更できます。VCNをサブネットにセグメント化して、そのスコープをリージョンまたは可用性ドメインに設定できます。各サブネットは、VCN内の他のサブネットと重複しない連続した範囲のアドレスで構成されます。サブネットのサイズは、作成後に変更できます。サブネットはパブリックにもプライベートにもできます。

  • サービス・ゲートウェイ

    サービス・ゲートウェイは、VCNからOracle Cloud Infrastructure Object Storageなどの他のサービスへのアクセスを提供します。The traffic from the VCN to the Oracle service travels over the Oracle network fabric and does not traverse the internet.

  • Kubernetes Engine

    Oracle Cloud Infrastructure Kubernetes Engine (OCI Kubernetes EngineまたはOKE)は、コンテナ化されたアプリケーションをクラウドにデプロイするために使用できる、完全に管理されたスケーラブルで可用性の高いサービスです。アプリケーションで必要なコンピュート・リソースを指定すると、KubernetesエンジンがそれらをOracle Cloud Infrastructureの既存のテナンシにプロビジョニングします。OKEは、Kubernetesを使用して、ホストのクラスタにわたるコンテナ化されたアプリケーションのデプロイメント、スケーリングおよび管理を自動化します。

  • クラウド・ガード

    Oracle Cloud Guardを使用して、Oracle Cloud Infrastructure内のリソースのセキュリティをモニターおよびメンテナンスできます。クラウド・ガードでは、ディテクタ・レシピを使用して、リソースでセキュリティの弱点を調べたり、特定のリスクのあるアクティビティについてオペレータおよびユーザーをモニターしたりするために定義できます。構成の誤りやセキュアでないアクティビティが検出されると、クラウド・ガードは修正アクションを推奨し、ユーザーが定義できるレスポンダ・レシピに基づいてそれらのアクションの実行を支援します。

  • セキュリティ・ゾーン

    セキュリティ・ゾーンは、データの暗号化やコンパートメント全体のネットワークへのパブリック・アクセスの防止などのポリシーを適用することで、Oracleのセキュリティのベスト・プラクティスを最初から保証します。セキュリティ・ゾーンは、同じ名前のコンパートメントに関連付けられ、コンパートメントとそのサブコンパートメントに適用されるセキュリティ・ゾーン・ポリシーまたは「レシピ」が含まれます。セキュリティ・ゾーン・コンパートメントに標準コンパートメントを追加または移動することはできません。

  • Kubernetesクラスタ・自動スケーリング

    Kubernetes Cluster Autoscalerは、ノード・プール内のノードのリソース使用率ではなく、リソース・リクエストに基づいてノード・プールのサイズを自動的に増減します。

  • OKEサービス

    Kubernetes (OKE)サービスは、ポッドの論理セットおよびポッドへのアクセスに使用するポリシーを定義する抽象概念です。サービスのターゲットとなるポッドのセットは、通常、セレクタによって決定されます。Kubernetesサービスは自動スケーリングを管理します。

  • OKEワーカー・ノード・プール

    Kubernetesワーカー・ノードは、Kubernetesクラスタ内でコンテナ化されたアプリケーションを実行するワーカー・マシンです。各クラスタには、少なくとも1つのワーカー・ノードがあります。

    Kubernetes (OKE)ワーカー・ノード・プールは、すべて同じ構成を持つクラスタ内のワーカー・ノードのサブセットです。ノード・プールを使用すると、クラスタ内に異なる構成を持つマシンのプールを作成できます。たとえば、クラスタ内のノードの1つのプールを仮想マシンとして作成し、ノードの別のプールをベア・メタル・マシンとして作成できます。クラスタには最低1つのノード・プールが必要ですが、ノード・プールにはワーカー・ノードが含まれている必要はありません。

    ノード・プール内のワーカー・ノードは、VCN内のワーカー・ノード・サブネットに接続されます。

  • インターネット・ゲートウェイ

    インターネット・ゲートウェイは、VCN内のパブリック・サブネットとパブリック・インターネット間のトラフィックを許可します。

  • ネットワークアドレス変換(NAT)ゲートウェイ

    NATゲートウェイを使用すると、VCN内のプライベート・リソースは、受信インターネット接続にこれらのリソースを公開することなく、インターネット上のホストにアクセスできます。

レコメンデーション

次の推奨事項を開始点として使用します。要件は、ここで説明するアーキテクチャとは異なる場合があります。
  • VCN

    VCNを作成するときには、必要なCIDRブロックの数を決定し、VCN内のサブネットにアタッチする予定のリソースの数に基づいて各ブロックのサイズを決定します。標準のプライベートIPアドレス領域内にあるCIDRブロックを使用します。

    プライベート接続を設定する他のネットワーク(Oracle Cloud Infrastructure、オンプレミス・データ・センターまたは別のクラウド・プロバイダ)と重複しないCIDRブロックを選択します。

    VCNを作成した後、そのCIDRブロックを変更、追加および削除できます。

    サブネットを設計するときには、トラフィック・フローおよびセキュリティ要件を考慮してください。特定の層またはロール内のすべてのリソースを、セキュリティ境界として機能できる同じサブネットにアタッチします。

    リージョナル・サブネットを使用します。

  • セキュリティ

    Oracle Cloud Guardを使用して、OCI内のリソースのセキュリティをプロアクティブにモニターおよびメンテナンスします。Oracle Cloud Guardでは、定義できるディテクタ・レシピを使用して、リソースでセキュリティの弱点を調べたり、オペレータやユーザーにリスクのあるアクティビティを監視したりできます。構成の誤りやセキュアでないアクティビティが検出されると、Oracle Cloud Guardは修正アクションを推奨し、ユーザーが定義できるレスポンダ・レシピに基づいてそれらのアクションの実行を支援します。

    最大限のセキュリティーを必要とするリソースの場合、Oracleではセキュリティーゾーンを使用することをお勧めします。セキュリティ・ゾーンは、ベスト・プラクティスに基づくセキュリティ・ポリシーのOracle定義レシピに関連付けられたコンパートメントです。たとえば、セキュリティ・ゾーン内のリソースにパブリック・インターネットからアクセスできず、顧客管理キーを使用して暗号化する必要があります。セキュリティ・ゾーンでリソースを作成して更新すると、OCIでは、セキュリティ・ゾーン・レシピのポリシーに対して操作が検証され、ポリシーに違反する操作が拒否されます。

  • クラウド・ガード

    Oracleが提供するデフォルトのレシピをクローニングおよびカスタマイズして、カスタム・ディテクタおよびレスポンダ・レシピを作成します。これらのレシピを使用すると、警告を生成するセキュリティ違反のタイプ、およびそれらに対して実行を許可するアクションを指定できます。たとえば、可視性がpublicに設定されているオブジェクト・ストレージ・バケットを検出できます。

    クラウド・ガードをテナンシ・レベルで適用して、最も広い範囲をカバーし、複数の構成を維持する管理上の負担を軽減します。

    管理対象リスト機能を使用して、特定の構成をディテクタに適用することもできます。

  • ネットワーク・セキュリティ・グループ(NSG)

    NSGを使用して、特定のVNICに適用されるイングレスおよびエグレス・ルールのセットを定義できます。NSGでは、VCNのサブネット・アーキテクチャをアプリケーションのセキュリティ要件から分離できるため、セキュリティ・リストではなくNSGを使用することをお薦めします。

  • OCI Kubernetes Engine

    オペレータは汎用Kubernetesクラスタをサポートしていますが、このアーキテクチャではKubernetes Engineクラスタを使用します。これらのクラスタには、異なる可用性ドメインとフォルト・ドメインにまたがる3つのワーカー・ノードがあります。表示されるクラスタには、異なる物理ホストに分散したワーカー・ノードがあります。1つのクラスタに最大1000個のノードを作成できます。

  • セキュリティ・ゾーン

    最大限のセキュリティーを必要とするリソースの場合、Oracleではセキュリティーゾーンを使用することをお勧めします。セキュリティ・ゾーンは、ベスト・プラクティスに基づくセキュリティ・ポリシーのOracle定義レシピに関連付けられたコンパートメントです。たとえば、セキュリティ・ゾーン内のリソースにパブリック・インターネットからアクセスできず、顧客管理キーを使用して暗号化する必要があります。セキュリティ・ゾーンでリソースを作成および更新すると、Oracle Cloud Infrastructureでは、その操作がセキュリティ・ゾーン・レシピのポリシーに対して検証され、ポリシーに違反する操作が拒否されます。

  • コンピュート

    適切なOCPUとメモリーの組合せでシェイプを選択し、Kubernetesクラスタのノードに対して、必要に応じてローカルのNVMeおよびブロック・ストレージをプロビジョニングします。

考慮事項

このリファレンス・アーキテクチャをデプロイする場合は、次の点を考慮してください。

  • パフォーマンス

    クラスタの自動スケーリングは、デプロイメント・リソースの予約に基づきます。gitlab-ci.yamlファイルを編集することで、ジョブ・リソースの予約を制御できます。

  • セキュリティ

    会社が所有するOracle Cloud Infrastructure (OCI)リソースに誰がアクセスできるか、およびその方法を制限するポリシーを使用します。

    OCI Kubernetes EngineOCI Identity and Access Managementと統合されており、ネイティブOCIアイデンティティ機能による簡単な認証を提供します。

    次の変数を使用して、ジョブのリソース予約を制御します。

    KUBERNETES_CPU_REQUEST: 1  
    KUBERNETES_MEMORY_REQUEST: 4000M
  • スケーラビリティ

    負荷に応じてKubernetesクラスタ内のワーカー・ノードの数を更新することで、アプリケーションをスケール・アウトできます。同様に、クラスタ内のワーカー・ノードの数を減らすことでスケール・インできます。Kubernetesクラスタでサービスを作成すると、ロード・バランサを作成して、そのサービスに割り当てられているノード間でサービス・トラフィックを分散できます。クラスタの自動スケーリングはデプロイメント・リソースの予約に基づいており、gitlab-ci.yamlファイルを編集して予約を制御できます。

    ノート:

    gitlab-ci.yamlファイルのパラメータを使用したジョブ・リソース予約は、locals.tfファイルの次の行の一部としてGitLab Runnerに定義されている最大許容予約数を超えないようにしてください。
    cpu_request_overwrite_max_allowed = "1"        
    memory_request_overwrite_max_allowed = "4096M"
  • コスト

    OCI Kubernetes Engineの使用は無料であり、Oracleコンテナ・レジストリの使用は無料です。Kubernetesクラスタのノードは、同じシェイプの他のコンピュート・インスタンスと同じレートで請求されます。

デプロイ

Terraformコードを使用すると、すべての依存リソース(ネットワーク、ワーカー・ノード・プール)を含むOCI Kubernetes Engine (OKE)クラスタをデプロイし、クラスタの自動スケーリングおよびGitLabランナーをデプロイできます。このコードは、Oracle Cloud Infrastructure Resource Managerのサンプル・スタックとして使用できます。GitHubからコードをダウンロードし、要件に合わせてカスタマイズすることもできます。
  • Oracle Cloud Infrastructure Resource Managerのサンプル・スタックを使用してデプロイします:
    1. Oracle Cloudへのデプロイに移動します。

      まだサインインしていない場合は、テナンシおよびユーザー資格証明を入力します。

    2. スタックをデプロイするリージョンを選択します。
    3. 画面に表示されるプロンプトと手順に従ってスタックを作成します。
    4. スタックの作成後、「Terraformアクション」をクリックし、「プラン」を選択します。
    5. ジョブが完了するまで待機し、計画をレビューします。

      変更を行うには、「スタックの詳細」ページに戻り、「スタックの編集」をクリックして、必要な変更を行います。次に、「プラン」アクションを再実行します。

    6. これ以上の変更が必要ない場合は、「スタックの詳細」ページに戻り、「Terraformアクション」をクリックして、「適用」を選択します。
  • GitHubのTerraformコードを使用してデプロイします:
    1. GitHubに移動します。
    2. リポジトリをローカル・コンピュータにクローニングまたはダウンロードします。
    3. READMEドキュメントの手順に従います。

詳細の参照

Oracle Cloud Infrastructure (OCI)およびKubernetesについてさらに学習します。

ベスト・プラクティスについては、Oracle Cloud Infrastructureのベスト・プラクティス・フレームワーク・ソリューション・プレイブックを参照してください。

次の追加のOCIおよびGitLabリソースを確認します:

確認

  • 原本著者: Chandrashekar Avadhani、Andrei Ilas
  • 原本協力者: Ben Romine、Lukasz Feldman