21.3. Ingress Controller を使用した Ingress クラスターの設定
OpenShift Container Platform は、クラスター内で実行されるサービスを使用してクラスター外からの通信を可能にする方法を提供します。この方法は Ingress Controller を使用します。
21.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 つのワーカーノードで実行する必要があります。
- 追加のノードにレプリカを組み込むためにスケールアップすることができます。
このセクションの手順では、クラスターの管理者が事前に行っておく必要のある前提条件があります。
21.3.2. 前提条件
以下の手順を開始する前に、管理者は以下の条件を満たしていることを確認する必要があります。
- 要求がクラスターに到達できるように、クラスターネットワーク環境に対して外部ポートをセットアップします。
クラスター管理者ロールを持つユーザーが 1 名以上いることを確認します。このロールをユーザーに追加するには、以下のコマンドを実行します。
$ oc adm policy add-cluster-role-to-user cluster-admin username
- OpenShift Container Platform クラスターを、1 つ以上のマスターと 1 つ以上のノード、およびクラスターへのネットワークアクセスのあるクラスター外のシステムと共に用意します。この手順では、外部システムがクラスターと同じサブセットにあることを前提とします。別のサブセットの外部システムに必要な追加のネットワーク設定については、このトピックでは扱いません。
21.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 アドレスがありません。
21.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 ...
21.3.5. ルートラベルを使用した Ingress Controller のシャード化の設定
ルートラベルを使用した Ingress コントローラーのシャード化とは、Ingress コントローラーがルートセレクターによって選択される任意 namespace の任意のルートを提供することを意味します。
Ingress コントローラーのシャード化は、一連の Ingress コントローラー間で着信トラフィックの負荷を分散し、トラフィックを特定の Ingress コントローラーに分離する際に役立ちます。たとえば、Company A のトラフィックをある Ingress Controller に指定し、Company B を別の Ingress Controller に指定できます。
手順
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 Controller ドメインとは異なる必要があります。
Ingress Controller の
router-internal.yaml
ファイルを適用します。# oc apply -f router-internal.yaml
Ingress Controller は、
type: sharded
というラベルのある namespace のルートを選択します。router-internal.yaml
で設定されたドメインを使用して新しいルートを作成します。$ oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net
21.3.6. namespace ラベルを使用した Ingress Controller のシャード化の設定
namespace ラベルを使用した Ingress コントローラーのシャード化とは、Ingress コントローラーが namespace セレクターによって選択される任意の namespace の任意のルートを提供することを意味します。
Ingress コントローラーのシャード化は、一連の Ingress コントローラー間で着信トラフィックの負荷を分散し、トラフィックを特定の Ingress コントローラーに分離する際に役立ちます。たとえば、Company A のトラフィックをある Ingress コントローラーに指定し、Company B を別の Ingress コントローラーに指定できます。
Keepalived Ingress VIP をデプロイする場合は、endpoint Publishing Strategy
パラメーターに Host Network
の値が割り当てられた、デフォルト以外の Ingress Controller をデプロイしないでください。デプロイしてしまうと、問題が発生する可能性があります。endpoint Publishing Strategy
に Host Network
ではなく、Node Port
という値を使用してください。
手順
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 Controller ドメインとは異なる必要があります。
Ingress Controller の
router-internal.yaml
ファイルを適用します。# oc apply -f router-internal.yaml
Ingress Controller は、
type: sharded
というラベルのある namespace セレクターによって選択される namespace のルートを選択します。router-internal.yaml
で設定されたドメインを使用して新しいルートを作成します。$ oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net
21.3.7. 関連情報
- Ingress Operator はワイルドカード DNS を管理します。詳細は、OpenShift Container Platform の Ingress Operator、クラスターのベアメタルへのインストール、および クラスターの vSphere へのインストール を参照してください。