27.3. Ingress コントローラーを使用した Ingress クラスターの設定
OpenShift Container Platform は、クラスター内で実行されるサービスを使ってクラスター外からの通信を可能にする方法を提供します。この方法は Ingress コントローラーを使用します。
27.3.1. Ingress コントローラーおよびルートの使用
Ingress Operator は Ingress コントローラーおよびワイルドカード DNS を管理します。
Ingress コントローラーの使用は、OpenShift Container Platform クラスターへの外部アクセスを許可するための最も一般的な方法です。
Ingress コントローラーは外部要求を許可し、設定されたルートに基づいてそれらをプロキシー送信するよう設定されます。これは、HTTP、SNI を使用する HTTPS、SNI を使用する TLS に限定されており、SNI を使用する TLS で機能する Web アプリケーションやサービスには十分な設定です。
管理者と連携して Ingress コントローラーを設定します。外部要求を許可し、設定されたルートに基づいてそれらをプロキシー送信するように Ingress コントローラーを設定します。
管理者はワイルドカード DNS エントリーを作成してから Ingress コントローラーを設定できます。その後は管理者に問い合わせることなく edge Ingress コントローラーと連携できます。
デフォルトで、クラスター内のすべての Ingress コントローラーはクラスター内の任意のプロジェクトで作成されたすべてのルートを許可します。
Ingress コントローラー:
- デフォルトでは 2 つのレプリカがあるので、これは 2 つのワーカーノードで実行する必要があります。
- 追加のノードにレプリカを組み込むためにスケールアップすることができます。
このセクションの手順では、クラスターの管理者が事前に行っておく必要のある前提条件があります。
27.3.2. 前提条件
以下の手順を開始する前に、管理者は以下の条件を満たしていることを確認する必要があります。
- 要求がクラスターに到達できるように、クラスターネットワーク環境に対して外部ポートをセットアップします。
クラスター管理者ロールを持つユーザーが 1 名以上いることを確認します。このロールをユーザーに追加するには、以下のコマンドを実行します。
$ oc adm policy add-cluster-role-to-user cluster-admin username
- OpenShift Container Platform クラスターを、1 つ以上のマスターと 1 つ以上のノード、およびクラスターへのネットワークアクセスのあるクラスター外のシステムと共に用意します。この手順では、外部システムがクラスターと同じサブセットにあることを前提とします。別のサブセットの外部システムに必要な追加のネットワーク設定については、このトピックでは扱いません。
27.3.3. プロジェクトおよびサービスの作成
公開するプロジェクトおよびサービスが存在しない場合、最初にプロジェクトを作成し、次にサービスを作成します。
プロジェクトおよびサービスがすでに存在する場合は、サービスを公開してルートを作成する手順に進みます。
前提条件
-
クラスター管理者として
oc
CLI をインストールし、ログインします。
手順
oc new-project
コマンドを実行して、サービス用の新しいプロジェクトを作成します。$ oc new-project myproject
oc new-app
コマンドを使用してサービスを作成します。$ oc new-app nodejs:12~https://github.com/sclorg/nodejs-ex.git
サービスが作成されたことを確認するには、以下のコマンドを実行します。
$ oc get svc -n myproject
出力例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nodejs-ex ClusterIP 172.30.197.157 <none> 8080/TCP 70s
デフォルトで、新規サービスには外部 IP アドレスがありません。
27.3.4. ルートの作成によるサービスの公開
oc expose
コマンドを使用して、サービスをルートとして公開することができます。
手順
サービスを公開するには、以下を実行します。
- OpenShift Container Platform にログインします。
公開するサービスが置かれているプロジェクトにログインします。
$ oc project myproject
oc expose service
コマンドを実行して、ルートを公開します。$ oc expose service nodejs-ex
出力例
route.route.openshift.io/nodejs-ex exposed
サービスが公開されていることを確認するには、cURL などのツールを使って、クラスター外からサービスにアクセスできることを確認します。
ルートのホスト名を調べるには、
oc get route
コマンドを使用します。$ oc get route
出力例
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD nodejs-ex nodejs-ex-myproject.example.com nodejs-ex 8080-tcp None
cURL を使用して、ホストが GET 要求に応答することを確認します。
$ curl --head nodejs-ex-myproject.example.com
出力例
HTTP/1.1 200 OK ...
27.3.5. ルートラベルを使用した Ingress コントローラーのシャード化の設定
ルートラベルを使用した Ingress コントローラーのシャード化とは、Ingress コントローラーがルートセレクターによって選択される任意 namespace の任意のルートを提供することを意味します。
図27.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
27.3.6. namespace ラベルを使用した Ingress コントローラーのシャード化の設定
namespace ラベルを使用した Ingress コントローラーのシャード化とは、Ingress コントローラーが namespace セレクターによって選択される任意の namespace の任意のルートを提供することを意味します。
図27.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
27.3.7. Ingress コントローラーシャーディングのルート作成
ルートを使用すると、URL でアプリケーションをホストできます。この場合、ホスト名は設定されず、ルートは代わりにサブドメインを使用します。サブドメインを指定すると、ルートを公開する Ingress コントローラーのドメインが自動的に使用されます。ルートが複数の Ingress コントローラーによって公開されている状況では、ルートは複数の URL でホストされます。
以下の手順では、例として hello-openshift
アプリケーションを使用して、Ingress コントローラーシャーディングのルートを作成する方法について説明します。
Ingress コントローラーのシャード化は、一連の Ingress コントローラー間で着信トラフィックの負荷を分散し、トラフィックを特定の Ingress コントローラーに分離する際に役立ちます。たとえば、Company A のトラフィックをある Ingress コントローラーに指定し、Company B を別の Ingress コントローラーに指定できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 - プロジェクト管理者としてログインしている。
- あるポートを公開する Web アプリケーションと、そのポートでトラフィックをリッスンする HTTP または TCP エンドポイントがあります。
- シャーディング用に Ingress コントローラーを設定しました。
手順
次のコマンドを実行して、
hello-openshift
というプロジェクトを作成します。$ oc new-project hello-openshift
以下のコマンドを実行してプロジェクトに Pod を作成します。
$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
以下のコマンドを実行して、
hello-openshift
というサービスを作成します。$ oc expose pod/hello-openshift
hello-openshift-route.yaml
というルート定義を作成します。シャーディング用に作成されたルートの YAML 定義:
apiVersion: route.openshift.io/v1 kind: Route metadata: labels: type: sharded 1 name: hello-openshift-edge namespace: hello-openshift spec: subdomain: hello-openshift 2 tls: termination: edge to: kind: Service name: hello-openshift
次のコマンドを実行し、
hello-openshift-route.yaml
を使用してhello-openshift
アプリケーションへのルートを作成します。$ oc -n hello-openshift create -f hello-openshift-route.yaml
検証
次のコマンドを使用して、ルートのステータスを取得します。
$ oc -n hello-openshift get routes/hello-openshift-edge -o yaml
結果の
Route
リソースは次のようになります。出力例
apiVersion: route.openshift.io/v1 kind: Route metadata: labels: type: sharded name: hello-openshift-edge namespace: hello-openshift spec: subdomain: hello-openshift tls: termination: edge to: kind: Service name: hello-openshift status: ingress: - host: hello-openshift.<apps-sharded.basedomain.example.net> 1 routerCanonicalHostname: router-sharded.<apps-sharded.basedomain.example.net> 2 routerName: sharded 3
27.3.8. 関連情報
Ingress Operator はワイルドカード DNS を管理します。詳細は、以下を参照してください。