OpenShiftのIngress

OpenShiftでGitLab Operatorを使用してIngressを提供するためにサポートされている方法は2つあります:

• NGINX Ingress Controller（デフォルト）
• OpenShift Routes

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サービスの外部IPアドレスではなく、GitLabインスタンスのホスト名を受信する場合があります。これは、kubectl get ingress -n <namespace>の出力のADDRESS列に表示されます。

OpenShift Routerコントローラーは、Ingressクラスが異なるため、Ingressリソースを無視する代わりに、誤って更新します。次のコマンドは、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はそれらを手動で再作成します。それらは、NGINX Ingressコントローラーによって適切に所有され、OpenShift Routerによって無視される必要があります。

NGINX Ingressコントローラーの作成をブロックするSCC関連のイシューのトラブルシューティングについては、Operatorトラブルシューティングドキュメントの追加のドキュメントを参照してください。

設定

デフォルトでは、GitLab Operatorは、GitLabのNGINX Ingressコントローラーチャートのフォークをデプロイします。

IngressにNGINX Ingressコントローラーを使用するには、以下を完了します:

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 _after_の部分です。

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コントローラーの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など）が期待どおりに動作し続けることが保証されます。

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

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

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 _after_の部分です。

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

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

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

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