第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.name
を finance
および 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.name
を dev
に指定して設定されます。
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:finance
、name:ops
、および name:dev
というラベルが付けられている場合、この設定は 2 つの Ingress コントローラー間でルートを効果的に分散します。コンソール、認証、およびその他の目的の OpenShift Container Platform ルートは処理しないでください。
上記のシナリオでは、シャード化は重複するセットを持たないパーティション設定の特別なケースとなります。ルートは複数のルーターシャード間で分割されます。
デフォルト
の Ingress コントローラーは、namespaceSelector
または routeSelector
フィールドに除外対象のルートが含まれていない限り、引き続きすべてのルートを提供します。デフォルトの Ingress コントローラーからルートを除外する方法の詳細は、この Red Hat ナレッジベースのソリューション と「デフォルトの Ingress コントローラーのシャーディング」のセクションを参照してください。
8.1.2. 重複シャーディングの例
上記の例の finops-router
と dev-router
に加えて、ラベルセレクター spec.namespaceSelector.matchLabels.name
を dev
と ops
に指定して設定された 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 コントローラーが新しく分割された finance
、ops
、および dev
ルートにサービスを提供しないように制限します。これにより、Ingress シャードがさらに分離されます。
OpenShift Container Platform のすべての管理ルートを同じ Ingress コントローラーで保持する必要があります。したがって、これらの重要なルートを除外するセレクターをデフォルトのIngress コントローラーに追加することは避けてください。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 - プロジェクト管理者としてログインしている。
手順
次のコマンドを実行して、デフォルトのIngress コントローラーを変更します。
$ oc edit ingresscontroller -n openshift-ingress-operator default
Ingress Controller を編集して、
finance
、ops
、および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:finance
、name: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 シャーディング

Ingress コントローラーのシャード化は、一連の Ingress コントローラー間で着信トラフィックの負荷を分散し、トラフィックを特定の Ingress コントローラーに分離する際に役立ちます。たとえば、Company A のトラフィックをある Ingress コントローラーに指定し、Company B を別の Ingress コントローラーに指定できます。
手順
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 が使用するドメインを指定します。このドメインは、デフォルトのイングレスコントローラードメインとは異なる必要があります。
Ingress コントローラーの
router-internal.yaml
ファイルを適用します。# oc apply -f router-internal.yaml
Ingress コントローラーは、
type: sharded
というラベルのある namespace のルートを選択します。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 シャーディング

Ingress コントローラーのシャード化は、一連の Ingress コントローラー間で着信トラフィックの負荷を分散し、トラフィックを特定の Ingress コントローラーに分離する際に役立ちます。たとえば、Company A のトラフィックをある Ingress コントローラーに指定し、Company B を別の Ingress コントローラーに指定できます。
手順
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 が使用するドメインを指定します。このドメインは、デフォルトのイングレスコントローラードメインとは異なる必要があります。
Ingress コントローラーの
router-internal.yaml
ファイルを適用します。# oc apply -f router-internal.yaml
Ingress コントローラーは、
type: sharded
というラベルのある namespace セレクターによって選択される namespace のルートを選択します。router-internal.yaml
で設定されたドメインを使用して新しいルートを作成します。$ oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net