OpenShiftのIngress

GitLab OperatorでOpenShiftに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にデプロイされた標準Ingress以外のIngressを適切に無視するようにOpenShift Routerコントローラーに指示します:

  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 Controllerによって適切に所有され、OpenShift Routerによって無視されるはずです。

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

設定

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

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

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

2. Webservice用に作成されたルートに関連付けられているドメイン名を見つけます:

   $ 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のサービス（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レコードを作成すると、既存のルート（OpenShiftダッシュボードのルートなど）が期待どおりに動作し続けるようになります。

   これらのレコードは、クラウドプロバイダーのネットワーキング設定のパブリックゾーン_と_プライベートゾーンとに存在する必要があります。これらのゾーン間の同等性により、適切なクラスター内部ルーティングが保証され、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ルートを使用するには、次の手順を実行します:

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

2. Webservice用に作成されたルートに関連付けられているドメイン名を見つけます:

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

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

GitLabはhttps://gitlab.yourdomain.comで利用可能になるはずです。

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