26.3. Ingress Controller を使用した Ingress クラスターの設定
OpenShift Container Platform は、クラスター内で実行されるサービスを使用してクラスター外からの通信を可能にする方法を提供します。この方法は Ingress Controller を使用します。
26.3.1. Ingress Controller およびルートの使用 リンクのコピーリンクがクリップボードにコピーされました!
Ingress Operator は Ingress Controller およびワイルドカード DNS を管理します。
Ingress Controller の使用は、最も一般的な、OpenShift Container Platform クラスターへの外部アクセスを許可する方法です。
Ingress Controller は外部要求を許可し、設定されたルートに基づいてそれらをプロキシー送信するよう設定されます。これは、HTTP、SNI を使用する HTTPS、SNI を使用する TLS に限定されており、SNI を使用する TLS で機能する Web アプリケーションやサービスには十分な設定です。
管理者と連携して Ingress Controller を設定します。外部要求を許可し、設定されたルートに基づいてそれらをプロキシー送信するように Ingress Controller を設定します。
管理者はワイルドカード DNS エントリーを作成してから Ingress Controller を設定できます。その後は管理者に問い合わせることなく edge Ingress Controller と連携できます。
デフォルトで、クラスター内のすべての Ingress Controller はクラスター内の任意のプロジェクトで作成されたすべてのルートを許可します。
Ingress Controller:
- デフォルトでは 2 つのレプリカがあるので、これは 2 つのワーカーノードで実行する必要があります。
- 追加のノードにレプリカを組み込むためにスケールアップすることができます。
このセクションの手順では、クラスターの管理者が事前に行っておく必要のある前提条件があります。
26.3.2. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
以下の手順を開始する前に、管理者は以下の条件を満たしていることを確認する必要があります。
- 要求がクラスターに到達できるように、クラスターネットワーク環境に対して外部ポートをセットアップします。
クラスター管理者ロールを持つユーザーが 1 名以上いることを確認します。このロールをユーザーに追加するには、以下のコマンドを実行します。
oc adm policy add-cluster-role-to-user cluster-admin username
$ oc adm policy add-cluster-role-to-user cluster-admin username
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1 つ以上のマスターと 1 つ以上のノードを持つ OpenShift Container Platform クラスターと、クラスターへのネットワークアクセス権を持つクラスター外部のシステムを用意します。この手順では、外部システムがクラスターと同じサブセットにあることを前提とします。別のサブセットの外部システムに必要な追加のネットワーク設定については、このトピックでは扱いません。
26.3.3. プロジェクトおよびサービスの作成 リンクのコピーリンクがクリップボードにコピーされました!
公開するプロジェクトとサービスが存在しない場合は、プロジェクトを作成してからサービスを作成します。
プロジェクトとサービスがすでに存在する場合は、サービスを公開してルートを作成する手順に進みます。
前提条件
-
OpenShift CLI (
oc
) をインストールし、クラスター管理者としてログインしている。
手順
oc new-project
コマンドを実行して、サービス用の新しいプロジェクトを作成します。oc new-project <project_name>
$ oc new-project <project_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc new-app
コマンドを使用してサービスを作成します。oc new-app nodejs:12~https://github.com/sclorg/nodejs-ex.git
$ oc new-app nodejs:12~https://github.com/sclorg/nodejs-ex.git
Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービスが作成されたことを確認するには、以下のコマンドを実行します。
oc get svc -n <project_name>
$ oc get svc -n <project_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nodejs-ex ClusterIP 172.30.197.157 <none> 8080/TCP 70s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nodejs-ex ClusterIP 172.30.197.157 <none> 8080/TCP 70s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記デフォルトで、新規サービスには外部 IP アドレスがありません。
26.3.4. ルートの作成によるサービスの公開 リンクのコピーリンクがクリップボードにコピーされました!
oc expose
コマンドを使用して、サービスをルートとして公開することができます。
前提条件
- OpenShift Container Platform にログインしている。
手順
公開するサービスが置かれているプロジェクトにログインします。
oc project <project_name>
$ oc project <project_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc expose service
コマンドを実行して、ルートを公開します。oc expose service nodejs-ex
$ oc expose service nodejs-ex
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
route.route.openshift.io/nodejs-ex exposed
route.route.openshift.io/nodejs-ex exposed
Copy to Clipboard Copied! Toggle word wrap Toggle overflow サービスが公開されていることを確認するには、
curl
などのツールを使用して、クラスター外からサービスにアクセスできることを確認します。ルートのホスト名を見つけるには、次のコマンドを入力します。
oc get route
$ oc get route
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD nodejs-ex nodejs-ex-myproject.example.com nodejs-ex 8080-tcp None
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD nodejs-ex nodejs-ex-myproject.example.com nodejs-ex 8080-tcp None
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ホストが GET 要求に応答することを確認するには、次のコマンドを入力します。
curl
コマンドの例curl --head nodejs-ex-myproject.example.com
$ curl --head nodejs-ex-myproject.example.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
HTTP/1.1 200 OK ...
HTTP/1.1 200 OK ...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
26.3.5. OpenShift Container Platform での Ingress シャーディング リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform では、Ingress Controller はすべてのルートを提供することも、ルートのサブセットを提供することもできます。デフォルトでは、Ingress Controller は、クラスター内の任意の namespace で作成されたすべてのルートを提供します。別の Ingress Controller をクラスターに追加して、選択した特性に基づくルートのサブセットである シャード を作成することにより、ルーティングを最適化できます。ルートをシャードのメンバーとしてマークするには、ルートまたは namespace の metadata
フィールドでラベルを使用します。Ingress Controller は、選択式 とも呼ばれる セレクター を使用して、ルートのプール全体からルートのサブセットを選択し、サービスを提供します。
Ingress シャーディングは、受信トラフィックを複数の Ingress Controller 間で負荷分散する場合に、トラフィックを分離して特定の Ingress Controller にルーティングする場合、または次のセクションで説明する他のさまざまな理由で役立ちます。
デフォルトでは、各ルートはクラスターのデフォルトドメインを使用します。ただし、代わりにルーターのドメインを使用するようにルートを設定できます。
26.3.6. Ingress Controller のシャーディング リンクのコピーリンクがクリップボードにコピーされました!
Ingress シャーディング (ルーターシャーディングとも呼ばれます) を使用して、ルート、namespace、またはその両方にラベルを追加することで、一連のルートを複数のルーターに分散できます。Ingress Controller は、対応する一連のセレクターを使用して、指定されたラベルが含まれるルートのみを許可します。各 Ingress シャードは、特定の選択式を使用してフィルタリングされたルートで構成されます。
トラフィックがクラスターに送信される主要なメカニズムとして、Ingress Controller への要求が大きくなる可能性があります。クラスター管理者は、以下を実行するためにルートをシャード化できます。
- Ingress Controller またはルーターを複数のルートに分散し、変更に対する応答を高速化する。
- 特定のルートに、他のルートとは異なる信頼性保証を割り当てる。
- 特定の Ingress Controller に異なるポリシーを定義することを許可します。
- 特定のルートのみが追加機能を使用することを許可します。
- たとえば、異なるアドレスで異なるルートを公開し、内部ユーザーおよび外部ユーザーが異なるルートを認識できるようにします。
- Blue-Green デプロイ時に、あるバージョンのアプリケーションから別のバージョンにトラフィックを転送する。
Ingress Controller がシャーディングされると、特定のルートがグループ内の 0 個以上の Ingress Controller に受け入れられます。ルートのステータスから、Ingress Controller がルートを許可したかどうかがわかります。Ingress Controller は、ルートがシャードに固有のものである場合にのみルートを許可します。
シャーディングを使用すると、ルートのサブセットを複数の Ingress Controller に分散できます。ルートのサブセットは、重複なし (従来 のシャーディング) にすることも、重複あり (オーバーラップ シャーディング) にすることもできます。
次の表に、3 つのシャーディング方法の概要を示します。
シャーディング方法 | 説明 |
---|---|
namespace セレクター | Ingress Controller に namespace セレクターを追加すると、namespace セレクターに一致するラベルを持つ namespace 内のすべてのルートが Ingress シャードに追加されます。namespace 内に作成されたすべてのルートを Ingress Controller で提供する場合は、この方法を検討してください。 |
ルートセレクター | Ingress Controller にルートセレクターを追加すると、ルートセレクターに一致するラベルを持つすべてのルートが Ingress シャードに追加されます。ルートのサブセットのみ、または namespace 内の特定のルートのみを Ingress Controller で提供する場合は、この方法を検討してください。 |
namespace およびルートセレクター | namespace セレクターとルートセレクター両方の方法で Ingress Controller のスコープを指定します。namespace セレクターとルートセレクター両方の方法の柔軟性が必要な場合は、この方法を検討してください。 |
26.3.6.1. 従来のシャーディングの例 リンクのコピーリンクがクリップボードにコピーされました!
ラベルセレクター spec.namespaceSelector.matchExpressions
を持ち、キー値が finance
と ops
に設定された、設定済み Ingress Controller finops-router
の例:
finops-router
の YAML 定義の例
ラベルセレクター spec.namespaceSelector.matchLabels.name
を持ち、キー値が dev
に設定された、設定済み Ingress Controller dev-router
の例:
dev-router
の YAML 定義の例
すべてのアプリケーションルートが、それぞれ name:finance
、name:ops
、name:dev
などのラベルが付けられた別々の namespace にある場合は、設定によって 2 つの Ingress Controller 間でルートが効果的に分散されます。コンソール、認証、およびその他の目的の OpenShift Container Platform ルートは処理しないでください。
前のシナリオでは、シャーディングは重複するサブセットを持たないパーティション設定の特別なケースとなります。ルートは複数のルーターシャード間で分割されます。
デフォルトの Ingress Controller は、namespaceSelector
または routeSelector
フィールドに除外対象のルートが含まれていない限り、引き続きすべてのルートを提供します。デフォルトの Ingress Controller からルートを除外する方法の詳細は、この Red Hat ナレッジベースのソリューション と「デフォルトの Ingress Controller のシャーディング」のセクションを参照してください。
26.3.6.2. 重複シャーディングの例 リンクのコピーリンクがクリップボードにコピーされました!
ラベルセレクター spec.namespaceSelector.matchExpressions
を持ち、キー値が dev
と ops
に設定された、設定済み Ingress Controller devops-router
の例:
devops-router
の YAML 定義の例
name:dev
および name:ops
というラベルの付いた namespace のルートは、2 つの異なる Ingress Controller によって処理されるようになりました。この設定では、ルートのサブセットが重複しています。
重複するルートのサブセットを使用すると、より複雑なルーティングルールを作成できます。たとえば、優先度の低いトラフィックを devops-router
に送信しながら、優先度の高いトラフィックを専用の finops-router
に迂回させることができます。
26.3.6.3. デフォルトの Ingress Controller のシャーディング リンクのコピーリンクがクリップボードにコピーされました!
新しい Ingress シャードを作成した後に、デフォルトの Ingress Controller と、新しい Ingress シャードの両方により許可されるルートが存在する場合があります。これは、デフォルトの Ingress Controller にセレクターがなく、デフォルトですべてのルートを許可するためです。
namespace セレクターまたはルートセレクターを使用して、Ingress Controller が特定のラベルが割り当てられたルートの処理を制限できます。次の手順では、namespace セレクターを使用して、デフォルトの Ingress Controller が新しくシャード化された finance
、ops
、および dev
ルートにサービスを提供しないように制限します。これにより、Ingress シャードがさらに分離されます。
OpenShift Container Platform のすべての管理ルートを同じ Ingress Controller で保持する必要があります。したがって、これらの重要なルートを除外するセレクターをデフォルトの Ingress Controller に追加することは避けてください。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 - プロジェクト管理者としてログインしている。
手順
次のコマンドを実行して、デフォルトの Ingress Controller を変更します。
oc edit ingresscontroller -n openshift-ingress-operator default
$ oc edit ingresscontroller -n openshift-ingress-operator default
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress Controller を編集して、
finance
、ops
、およびdev
のいずれかのラベルを持つルートを除外するnamespaceSelector
を含めます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
デフォルトの Ingress Controller では、name:finance
、name:ops
、および name:dev
という名前の namespace が提供されなくなります。
26.3.6.4. Ingress シャーディングと DNS リンクのコピーリンクがクリップボードにコピーされました!
クラスター管理者は、プロジェクト内のルーターごとに個別の DNS エントリーを作成します。ルーターは不明なルートを別のルーターに転送することはありません。
以下の例を考慮してください。
-
Router A はホスト 192.168.0.5 にあり、
*.foo.com
のルートを持つ。 -
Router B はホスト 192.168.1.9 にあり、
*.example.com
のルートを持つ。
個別の DNS エントリーは、*.foo.com
を Router A をホストするノードに解決し、*.example.com
を Router B をホストするノードに解決する必要があります。
-
*.foo.com A IN 192.168.0.5
-
*.example.com A IN 192.168.1.9
26.3.6.5. ルートラベルを使用した Ingress Controller のシャーディングの設定 リンクのコピーリンクがクリップボードにコピーされました!
ルートラベルを使用した Ingress Controller のシャーディングとは、Ingress Controller がルートセレクターによって選択される任意 namespace の任意のルートを提供することを意味します。
図26.1 ルートラベルを使用した Ingress シャーディング
Ingress Controller のシャーディングは、一連の Ingress Controller 間で着信トラフィックの負荷を分散し、トラフィックを特定の Ingress Controller に分離する際に役立ちます。たとえば、Company A のトラフィックをある Ingress Controller に指定し、Company B を別の Ingress Controller に指定できます。
手順
router-internal.yaml
ファイルを編集します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Ingress Controller が使用するドメインを指定します。このドメインは、デフォルトの Ingress Controller ドメインとは異なる必要があります。
Ingress コントローラーの
router-internal.yaml
ファイルを適用します。oc apply -f router-internal.yaml
# oc apply -f router-internal.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress コントローラーは、
type: sharded
というラベルのある namespace のルートを選択します。router-internal.yaml
で設定されたドメインを使用して新しいルートを作成します。oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net
$ oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
26.3.6.6. namespace ラベルを使用した Ingress Controller のシャーディングの設定 リンクのコピーリンクがクリップボードにコピーされました!
namespace ラベルを使用した Ingress Controller のシャーディングとは、Ingress Controller が namespace セレクターによって選択される任意の namespace の任意のルートを提供することを意味します。
図26.2 namespace ラベルを使用した Ingress シャーディング
Ingress Controller のシャーディングは、一連の Ingress Controller 間で着信トラフィックの負荷を分散し、トラフィックを特定の Ingress Controller に分離する際に役立ちます。たとえば、Company A のトラフィックをある Ingress Controller に指定し、Company B を別の Ingress Controller に指定できます。
手順
router-internal.yaml
ファイルを編集します。cat router-internal.yaml
$ cat router-internal.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Ingress Controller が使用するドメインを指定します。このドメインは、デフォルトの Ingress Controller ドメインとは異なる必要があります。
Ingress コントローラーの
router-internal.yaml
ファイルを適用します。oc apply -f router-internal.yaml
$ oc apply -f router-internal.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ingress コントローラーは、
type: sharded
というラベルのある namespace セレクターによって選択される namespace のルートを選択します。router-internal.yaml
で設定されたドメインを使用して新しいルートを作成します。oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net
$ oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
26.3.6.7. Ingress Controller シャーディングのルート作成 リンクのコピーリンクがクリップボードにコピーされました!
ルートを使用すると、URL でアプリケーションをホストできます。この場合、ホスト名は設定されず、ルートは代わりにサブドメインを使用します。サブドメインを指定すると、ルートを公開する Ingress Controller のドメインが自動的に使用されます。ルートが複数の Ingress Controller によって公開されている状況では、ルートは複数の URL でホストされます。
以下の手順では、例として hello-openshift
アプリケーションを使用して、Ingress コントローラーシャーディングのルートを作成する方法について説明します。
Ingress Controller のシャーディングは、一連の Ingress Controller 間で着信トラフィックの負荷を分散し、トラフィックを特定の Ingress Controller に分離する際に役立ちます。たとえば、Company A のトラフィックをある Ingress Controller に指定し、Company B を別の Ingress Controller に指定できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 - プロジェクト管理者としてログインしている。
- あるポートを公開する Web アプリケーションと、そのポートでトラフィックをリッスンする HTTP または TCP エンドポイントがある。
- シャーディング用に Ingress Controller を設定している。
手順
次のコマンドを実行して、
hello-openshift
というプロジェクトを作成します。oc new-project hello-openshift
$ oc new-project hello-openshift
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行してプロジェクトに Pod を作成します。
oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを実行して、
hello-openshift
というサービスを作成します。oc expose pod/hello-openshift
$ oc expose pod/hello-openshift
Copy to Clipboard Copied! Toggle word wrap Toggle overflow hello-openshift-route.yaml
というルート定義を作成します。シャーディング用に作成されたルートの YAML 定義:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行し、
hello-openshift-route.yaml
を使用してhello-openshift
アプリケーションへのルートを作成します。oc -n hello-openshift create -f hello-openshift-route.yaml
$ oc -n hello-openshift create -f hello-openshift-route.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを使用して、ルートのステータスを取得します。
oc -n hello-openshift get routes/hello-openshift-edge -o yaml
$ oc -n hello-openshift get routes/hello-openshift-edge -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 結果の
Route
リソースは次のようになります。出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow