OpenShiftにおけるIngress

GitLab OperatorでOpenShiftにおけるトラフィックルーティングを提供するためにサポートされている方法は、次のとおりです:

• Gateway APIとEnvoy Gateway（推奨）
• NGINX Ingress Controller（非推奨、GitLab 20.0で削除予定）
• OpenShift Routes

Gateway APIとEnvoy Gateway

Gateway APIは、OpenShiftにおけるトラフィックルーティングに推奨されるアプローチです。プラットフォームに依存せず、Git over SSHを含むすべてのGitLab機能をサポートしています。

詳細な設定手順と前提条件については、Gateway APIとEnvoy Gatewayのドキュメントを参照してください。

NGINX Ingress Controller

この構成では、トラフィックは次のように流れます:

graph TD
    U(End User) --> GTLB([gitlab.domain.com])
    GTLB -- resolves to --> SRV_N[/Service/gitlab-nginx-ingress-controller/]
    SRV_N -- connects to --> DPL_N[Deployment/gitlab-nginx-ingress-controller]
    DPL_N -- looks up corresponding ingress --> ING{{Ingress/gitlab-webservice-default}}
    ING -- proxies to --> SRV_W[/Service/gitlab-webservice-default/]
    SRV_W -- connects to --> DPL_W[Deployment/gitlab-webservice-default]

OpenShift RouterがNGINX Ingress Controllerをオーバーライドする場合の回避策

OpenShift環境では、GitLab Ingressが、NGINX Serviceの外部IPアドレスではなくGitLabインスタンスのホスト名を受け取る場合があります。これは、kubectl get ingress -n <namespace>の出力のADDRESS列に表示されます。

これは、Ingressクラスが異なるため本来無視すべきIngressリソースを、OpenShift Routerコントローラーが誤って更新してしまうために発生します。次のコマンドは、OpenShift Routerコントローラーに対し、OpenShiftにデプロイされた標準Ingress以外のIngressを適切に無視するように指示します:

  kubectl -n openshift-ingress-operator \
    patch ingresscontroller default \
    --type merge \
    -p '{"spec":{"namespaceSelector":{"matchLabels":{"openshift.io/cluster-monitoring":"true"}}}}'

Ingressがすでに作成された後にこのパッチを適用した場合は、Ingressを手動で削除してください。GitLab Operatorがそれらを手動で再作成します。その後、それらのIngressはNGINX Ingress Controllerによって適切に所有され、OpenShift Routerからは無視されるようになります。

NGINX Ingress Controllerの作成を妨げるSCC関連の問題のトラブルシューティングについては、Operatorトラブルシューティングドキュメントの追加ドキュメントを参照してください。

設定

デフォルトでは、GitLab Operatorは、GitLabがフォークしたNGINX Ingress Controllerチャートをデプロイします。

IngressにNGINX Ingress Controllerを使用するには、次の手順を実行します:

1. インストール手順の最初のステップに従って、GitLab Operatorをインストールします。

2. Webservice用に作成されたRouteに関連付けられているドメイン名を確認します:

   $ kubectl get route -n openshift-console console -ojsonpath='{.status.ingress[0].host}'
   
   console-openshift-console.yourdomain.com

   次のステップで使用するドメインは、console-openshift-consoleより_後_の部分です。

3. GitLab CRマニフェストを作成するステップで、次のようにドメインを設定します:

   spec:
     chart:
       values:
         global:
           # Configure the domain from the previous step.
           hosts:
             domain: yourdomain.com

   デフォルトでは、CertManagerがGitLab関連のIngressのTLS証明書を作成および管理します。その他のオプションについては、TLSドキュメントを参照してください。

4. 残りのインストール手順に従ってGitLab CRを適用し、最終的にCRのステータスがReadyになることを確認します。

5. NGINX Ingress ControllerのService（LoadBalancerタイプ）の外部IPアドレスを確認します:

   $ kubectl get svc -n gitlab-system gitlab-nginx-ingress-controller -ojsonpath='{.status.loadBalancer.ingress[].ip}'
   
   11.22.33.444

6. DNSプロバイダーでAレコードを作成し、ドメインと前のステップで確認した外部IPアドレスを関連付けます:

   • gitlab.yourdomain.com -> 11.22.33.444
   • registry.yourdomain.com -> 11.22.33.444
   • minio.yourdomain.com -> 11.22.33.444

   ワイルドカードAレコードではなく個別のAレコードを作成することで、既存のRoute（OpenShiftダッシュボード用のRouteなど）が想定どおりに引き続き動作することが保証されます。

   これらのレコードは、クラウドプロバイダーのネットワーク設定で、パブリックとプライベートの_両方の_ゾーンに存在する必要があります。これらのゾーン間で同等性を保つことで、クラスター内部のルーティングが適切に行われ、CertManagerが証明書を適切に発行できるようになります。

その後、https://gitlab.yourdomain.comでGitLabを利用できるようになります。

OpenShift Routes

デフォルトでは、OpenShiftはRoutesを使用してIngressを管理します。

この構成では、トラフィックは次のように流れます:

graph TD
    U(End User) --> GTLB([gitlab.domain.com])
    GTLB -- resolves to --> SRV_R[/Service/router-default/]
    SRV_R -- connects to --> DPL_R[Deployment/router-default]
    DPL_R -- looks up corresponding Route --> RT{{Route/gitlab-webservice-default-xyz}}
    RT -- proxies to --> SRV_W[/Service/gitlab-webservice-default/]
    SRV_W -- connects to --> DPL_W[Deployment/gitlab-webservice-default]

セットアップ

IngressにOpenShift Routesを使用するには、次の手順を実行します:

1. インストール手順の最初のステップに従って、GitLab Operatorをインストールします。

2. Webservice用に作成されたRouteに関連付けられているドメイン名を確認します:

   $ kubectl get route -n openshift-console console -ojsonpath='{.status.ingress[0].host}'
   console-openshift-console.yourdomain.com

   次のステップで使用するドメインは、console-openshift-consoleより_後_の部分です。

3. GitLab CRマニフェストを作成するステップで、以下も設定します:

   spec:
     chart:
       values:
         # Disable NGINX Ingress Controller.
         nginx-ingress:
           enabled: false
         global:
           # Configure the domain from the previous step.
           hosts:
             domain: yourdomain.com
           ingress:
             # Unset `spec.ingressClassName` on the Ingress objects
             # so the OpenShift Router takes ownership.
             class: none
             annotations:
               # The OpenShift documentation says "edge" is the default, but
               # the TLS configuration is only passed to the Route if this annotation
               # is manually set.
               route.openshift.io/termination: "edge"

   デフォルトでは、CertManagerがGitLab関連のRouteのTLS証明書を作成および管理します。その他のオプションについては、TLSドキュメントを参照してください。OpenShiftクラスターがワイルドカード証明書で保護されている場合、オプション2では、そのワイルドカード証明書でGitLab関連のRoutesを保護できます。

4. 残りのインストール手順に従ってGitLab CRを適用し、最終的にCRのステータスがReadyになることを確認します。

その後、https://gitlab.yourdomain.comでGitLabを利用できるようになります。

この設定では、GitLab Operatorが作成したIngressを変換してOpenShift Routesが作成されます。この変換の詳細については、Routeドキュメントを参照してください。