第8章 OpenShift Container Platform での Ingress シャーディング

OpenShift Container Platform では、Ingress コントローラーはすべてのルートを提供することも、ルートのサブセットを提供することもできます。デフォルトでは、Ingress コントローラーは、クラスター内の任意の namespace で作成されたすべてのルートを提供します。別の Ingress コントローラーをクラスターに追加して、選択した特性に基づくルートのサブセットである シャード を作成することにより、ルーティングを最適化できます。ルートをシャードのメンバーとしてマークするには、ルートまたは namespace の メタデータ フィールドでラベルを使用します。Ingress コントローラーは、選択式 とも呼ばれる セレクター を使用して、ルートのプール全体からルートのサブセットを選択し、サービスを提供します。

Ingress シャーディングは、受信トラフィックを複数の Ingress コントローラー間で負荷分散する場合に、トラフィックを分離して特定の Ingress コントローラーにルーティングする場合、または次のセクションで説明する他のさまざまな理由で役立ちます。

デフォルトでは、各ルートはクラスターのデフォルトドメインを使用します。ただし、代わりにルーターのドメインを使用するようにルートを設定できます。詳細は Ingress コントローラーシャーディングのルートの作成 を参照してください。

8.1. Ingress コントローラーのシャード化

Ingress シャーディング (ルーターシャーディングとも呼ばれます) を使用して、ルート、namespace、またはその両方にラベルを追加することで、一連のルートを複数のルーターに分散できます。Ingress コントローラーは、対応する一連のセレクターを使用して、指定されたラベルが含まれるルートのみを許可します。各 Ingress シャードは、特定の選択式を使用してフィルタリングされたルートで設定されます。

トラフィックがクラスターに送信される主要なメカニズムとして、Ingress コントローラーへの要求が大きくなる可能性があります。クラスター管理者は、以下を実行するためにルートをシャード化できます。

  • Ingress コントローラーまたはルーターを複数のルートに分散し、変更に対する応答を加速します。
  • 特定のルートを他のルートとは異なる信頼性の保証を持つように割り当てます。
  • 特定の Ingress コントローラーに異なるポリシーを定義することを許可します。
  • 特定のルートのみが追加機能を使用することを許可します。
  • たとえば、異なるアドレスで異なるルートを公開し、内部ユーザーおよび外部ユーザーが異なるルートを認識できるようにします。
  • blue green デプロイ中に、アプリケーションの別のバージョンにトラフィックを転送します。

Ingress コントローラーがシャーディングされると、特定のルートがグループ内の 0 個以上の Ingress コントローラーに受け入れられます。ルートのステータスは、Ingress コントローラーがルートを受け入れたかどうかを示します。Ingress コントローラーは、ルートがそのシャードに固有である場合にのみルートを受け入れます。

Ingress コントローラーは、次の 3 つのシャーディング方法を使用できます。

  • namespace セレクターとラベルが同じ namespace 内のすべてのルートが Ingress シャードに含まれるように、namespace セレクターのみを Ingress コントローラーに追加します。
  • Ingress コントローラーにルートセレクターのみを追加して、ルートセレクターとラベルが同じ全ルートが Ingress シャードに含まれるようにします。
  • namespace セレクターとラベルが同じ namespace 内のルートセレクターのラベルがルートと同じ場合に、Ingress シャード内に含まれるように、namespace セレクターとルートセレクターの両方を Ingress コントローラーに追加します。

シャーディングを使用すると、ルートのサブセットを複数の Ingress コントローラーに分散できます。これらのサブセットは、重複なし (従来 のシャーディングとも呼ばれる) にすることも、重複 (重複 シャーディングとも呼ばれる) にすることもできます。

8.1.1. 従来のシャーディングの例

Ingress コントローラーの finops-router は、ラベルセレクター spec.namespaceSelector.matchLabels.namefinance および ops に指定して設定されます。

finops-router の YAML 定義の例

apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: finops-router
    namespace: openshift-ingress-operator
  spec:
    namespaceSelector:
      matchLabels:
        name:
          - finance
          - ops

2 番目の Ingress コントローラー dev-router は、ラベルセレクター spec.namespaceSelector.matchLabels.namedev に指定して設定されます。

dev-router の YAML 定義の例

apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: dev-router
    namespace: openshift-ingress-operator
  spec:
    namespaceSelector:
      matchLabels:
        name: dev

すべてのアプリケーションルートが個別の namespace にあり、それぞれに name:financename:ops、および name:dev というラベルが付けられている場合、この設定は 2 つの Ingress コントローラー間でルートを効果的に分散します。コンソール、認証、およびその他の目的の OpenShift Container Platform ルートは処理しないでください。

上記のシナリオでは、シャード化は重複するセットを持たないパーティション設定の特別なケースとなります。ルートは複数のルーターシャード間で分割されます。

警告

デフォルト の Ingress コントローラーは、namespaceSelector または routeSelector フィールドに除外対象のルートが含まれていない限り、引き続きすべてのルートを提供します。デフォルトの Ingress コントローラーからルートを除外する方法の詳細は、この Red Hat ナレッジベースのソリューション と「デフォルトの Ingress コントローラーのシャーディング」のセクションを参照してください。

8.1.2. 重複シャーディングの例

上記の例の finops-routerdev-router に加えて、ラベルセレクター spec.namespaceSelector.matchLabels.namedevops に指定して設定された devops-router もあります。

Devops-router の YAML 定義の例

apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: devops-router
    namespace: openshift-ingress-operator
  spec:
    namespaceSelector:
      matchLabels:
        name:
          - dev
          - ops

name:dev および name:ops という 名前の namespace のルートは、2 つの異なる Ingress コントローラーによって処理されるようになりました。この設定では、ルートのサブセットが重複しています。

重複するルートのサブセットを使用すると、より複雑なルーティングルールを作成できます。たとえば、優先度の低いトラフィックを devops-router に送信しながら、優先度の高いトラフィックを専用の finops-router に迂回させることができます。

8.1.3. デフォルトの Ingress コントローラーのシャーディング

新しい Ingress シャードを作成した後に、デフォルトの Ingress コントローラーと、新しい Ingress シャードの両方により許可されるルートが存在する場合があります。これは、デフォルトの Ingress コントローラーにセレクターがなく、デフォルトですべてのルートを許可するためです。

namespace セレクターまたはルートセレクターを使用して、Ingress コントローラーが特定のラベルが割り当てられたルートの処理を制限できます。次の手順では、namespace セレクターを使用して、デフォルトの Ingress コントローラーが新しく分割された financeops、および dev ルートにサービスを提供しないように制限します。これにより、Ingress シャードがさらに分離されます。

重要

OpenShift Container Platform のすべての管理ルートを同じ Ingress コントローラーで保持する必要があります。したがって、これらの重要なルートを除外するセレクターをデフォルトのIngress コントローラーに追加することは避けてください。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • プロジェクト管理者としてログインしている。

手順

  1. 次のコマンドを実行して、デフォルトのIngress コントローラーを変更します。

    $ oc edit ingresscontroller -n openshift-ingress-operator default
  2. Ingress Controller を編集して、financeops、および dev ラベルのいずれかを持つルートを除外する namespaceSelector を含めます。

    apiVersion: v1
    items:
    - apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
      namespaceSelector:
        matchExpressions:
        - key: type
          operator: NotIn
          values:
          - finance
          - ops
          - dev

デフォルトの Ingress コントローラーでは、name:financename:ops、および name:dev という名前の namespace が提供されなくなります。

8.1.4. Ingress シャーディングと DNS

クラスター管理者は、プロジェクト内のルーターごとに個別の DNS エントリーを作成します。ルーターは不明なルートを別のルーターに転送することはありません。

以下の例を考慮してください。

  • Router A はホスト 192.168.0.5 にあり、*.foo.com のルートを持つ。
  • Router B はホスト 192.168.1.9 にあり、*.example.com のルートを持つ。

個別の DNS エントリーは、*.foo.com をルーター A をホストするノードに解決し、*.example.com をルーター B をホストするノードに解決する必要があります。

  • *.foo.com A IN 192.168.0.5
  • *.example.com A IN 192.168.1.9

8.1.5. ルートラベルを使用した Ingress コントローラーのシャード化の設定

ルートラベルを使用した Ingress コントローラーのシャード化とは、Ingress コントローラーがルートセレクターによって選択される任意 namespace の任意のルートを提供することを意味します。

図8.1 ルートラベルを使用した Ingress シャーディング

ルートの所属先の namespace に関係なく、特定のルートと一致するラベルが含まれるルートにサービスを提供するさまざまなルートセレクターと複数の Ingress コントローラーを示す図

Ingress コントローラーのシャード化は、一連の Ingress コントローラー間で着信トラフィックの負荷を分散し、トラフィックを特定の Ingress コントローラーに分離する際に役立ちます。たとえば、Company A のトラフィックをある Ingress コントローラーに指定し、Company B を別の Ingress コントローラーに指定できます。

手順

  1. router-internal.yaml ファイルを編集します。

    # cat router-internal.yaml
    apiVersion: v1
    items:
    - apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: sharded
        namespace: openshift-ingress-operator
      spec:
        domain: <apps-sharded.basedomain.example.net> 1
        nodePlacement:
          nodeSelector:
            matchLabels:
              node-role.kubernetes.io/worker: ""
        routeSelector:
          matchLabels:
            type: sharded
      status: {}
    kind: List
    metadata:
      resourceVersion: ""
      selfLink: ""
    1
    Ingress Controller が使用するドメインを指定します。このドメインは、デフォルトのイングレスコントローラードメインとは異なる必要があります。
  2. Ingress コントローラーの router-internal.yaml ファイルを適用します。

    # oc apply -f router-internal.yaml

    Ingress コントローラーは、type: sharded というラベルのある namespace のルートを選択します。

  3. router-internal.yaml で設定されたドメインを使用して新しいルートを作成します。

    $ oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net

8.1.6. namespace ラベルを使用した Ingress コントローラーのシャード化の設定

namespace ラベルを使用した Ingress コントローラーのシャード化とは、Ingress コントローラーが namespace セレクターによって選択される任意の namespace の任意のルートを提供することを意味します。

図8.2 namespace ラベルを使用した Ingress シャーディング

指定の namespace セレクターと同じラベルが含まれる namespace に所属するルートにサービスを提供するさまざまな namespace セレクターと複数の Ingress コントローラーを示す図

Ingress コントローラーのシャード化は、一連の Ingress コントローラー間で着信トラフィックの負荷を分散し、トラフィックを特定の Ingress コントローラーに分離する際に役立ちます。たとえば、Company A のトラフィックをある Ingress コントローラーに指定し、Company B を別の Ingress コントローラーに指定できます。

手順

  1. router-internal.yaml ファイルを編集します。

    # cat router-internal.yaml

    出力例

    apiVersion: v1
    items:
    - apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: sharded
        namespace: openshift-ingress-operator
      spec:
        domain: <apps-sharded.basedomain.example.net> 1
        nodePlacement:
          nodeSelector:
            matchLabels:
              node-role.kubernetes.io/worker: ""
        namespaceSelector:
          matchLabels:
            type: sharded
      status: {}
    kind: List
    metadata:
      resourceVersion: ""
      selfLink: ""

    1
    Ingress Controller が使用するドメインを指定します。このドメインは、デフォルトのイングレスコントローラードメインとは異なる必要があります。
  2. Ingress コントローラーの router-internal.yaml ファイルを適用します。

    # oc apply -f router-internal.yaml

    Ingress コントローラーは、type: sharded というラベルのある namespace セレクターによって選択される namespace のルートを選択します。

  3. router-internal.yaml で設定されたドメインを使用して新しいルートを作成します。

    $ oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net