第1章 ルート
1.1. 基本ルートの作成 リンクのコピーリンクがクリップボードにコピーされました!
暗号化されていない HTTP がある場合は、ルートオブジェクトを使用して基本ルートを作成できます。
1.1.1. HTTP ベースのルートの作成 リンクのコピーリンクがクリップボードにコピーされました!
hello-openshift アプリケーションを例として、以下の手順で Web アプリケーションへの単純な HTTP ベースのルートを作成できます。
公開 URL でアプリケーションをホストするルートを作成できます。ルートは、アプリケーションのネットワークセキュリティー設定に応じて、セキュリティーで保護される場合と保護されない場合があります。HTTP ベースのルートとは、セキュアではないルートで、基本的な HTTP ルーティングプロトコルを使用してセキュリティー保護されていないアプリケーションポートでサービスを公開します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - 管理者としてログインしている。
- あるポートを公開する Web アプリケーションと、そのポートでトラフィックをリッスンする TCP エンドポイントがあります。
手順
次のコマンドを実行して、
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アプリケーションに対して、セキュアではないルートを作成します。$ oc expose svc hello-openshift
検証
作成した
routeリソースを確認するには、次のコマンドを実行します。$ oc get routes -o yaml hello-openshift作成したセキュアでないルートの YAML 定義例
apiVersion: route.openshift.io/v1 kind: Route metadata: name: hello-openshift spec: host: www.example.com port: targetPort: 8080 to: kind: Service name: hello-openshiftここでは、以下のようになります。
host-
サービスを指すエイリアス DNS レコードを指定します。このフィールドには、
www.example.comなどの有効な DNS 名を指定できます。DNS 名は DNS952 サブドメイン規則に従う必要があります。指定しない場合は、ルート名が自動的に生成されます。 targetPortこのルートが指すサービスによって選択される Pod のターゲットポートを指定します。
注記デフォルトの Ingress ドメインを表示するには、以下のコマンドを実行します。
$ oc get ingresses.config/cluster -o jsonpath={.spec.domain}
1.1.2. パスベースのルート リンクのコピーリンクがクリップボードにコピーされました!
単一のホスト名を使用して複数のアプリケーションにサービスを提供するには、パスベースのルーティングを設定します。この HTTP ベースの設定では、URL パスコンポーネントを比較することでトラフィックを特定のサービスに振り分け、リクエストが定義された最も具体的なルートと一致するようにします。
以下の表は、ルートのサンプルおよびそれらのアクセシビリティーを示しています。
| ルート | 比較すると | アクセス可能 |
|---|---|---|
| www.example.com/test | www.example.com/test | はい |
| www.example.com | いいえ | |
| www.example.com/test および www.example.com | www.example.com/test | はい |
| www.example.com | はい | |
| www.example.com | www.example.com/text | Yes (ルートではなく、ホストで一致) |
| www.example.com | はい |
パスを持つ保護されていないルートの例
apiVersion: route.openshift.io/v1
kind: Route
metadata:
name: route-unsecured
spec:
host: www.example.com
path: "/test"
to:
kind: Service
name: service-name
-
spec.host: パスベースのルートのパス属性を指定します。
ルーターは TLS を終了させず、要求のコンテンツを読み込みことができないので、パスベースのルーティングは、passthrough TLS を使用する場合には利用できません。
1.1.3. Ingress Controller シャーディングのルート作成 リンクのコピーリンクがクリップボードにコピーされました!
ルートを使用すると、アプリケーションを URL でホストできます。Ingress Controller のシャーディングは、一連の Ingress Controller 間での着信トラフィック負荷のバランスをとるのに役立ちます。Ingress Controller のシャーディング機能を使用すると、トラフィックを特定の Ingress Controller に分離することもできます。たとえば、Company A のトラフィックをある Ingress Controller に指定し、Company B を別の Ingress Controller に指定できます。
以下の手順では、例として hello-openshift アプリケーションを使用して、Ingress Controller シャーディングのルートを作成する方法を説明します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - プロジェクト管理者としてログインしている。
- ポートを公開する Web アプリケーションと、そのポート上のトラフィックをリッスンする HTTP または TLS エンドポイントがある。
- シャーディング用に Ingress Controller を設定している。
手順
次のコマンドを実行して、
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-openshifthello-openshift-route.yamlというルート定義を作成します。シャーディング用に作成したルートの YAML 定義
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ここでは、以下のようになります。
type-
ラベルキーとその対応するラベル値は、Ingress Controller で指定されたものと一致する必要があることを指定します。この例では、Ingress Controller にはラベルキーと値
type: shardedがあります。 subdomain-
サブドメインフィールドの値を使用して公開されるルートを指定します。subdomainフィールドを指定するときは、ホスト名を未設定のままにしておく必要があります。ホストフィールドとサブドメインフィールドの両方を指定した場合、ルートはホストフィールドの値を使用し、サブドメインフィールドは無視します。
次のコマンドを実行し、
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> routerCanonicalHostname: router-sharded.<apps-sharded.basedomain.example.net> routerName: shardedここでは、以下のようになります。
host-
イングレスコントローラー (ルーター) がルートを公開するために使用するホスト名を指定します。
hostフィールドの値は、Ingress Controller によって自動的に決定され、そのドメインを使用します。この例では、Ingress Controller のドメインは<apps-sharded.basedomain.example.net>です。 <apps-sharded.basedomain.example.net>- Ingress コントローラーのホスト名を指定します。ホスト名が設定されていない場合、ルートは代わりにサブドメインを使用できます。サブドメインを指定すると、ルートを公開する Ingress Controller のドメインが自動的に使用されます。ルートが複数の Ingress Controller によって公開される場合、ルートは複数の URL でホストされます。
routerName-
Ingress コントローラーの名前を指定します。この例では、Ingress Controller の名前は
shardedです。
1.1.4. Ingress オブジェクトを使用したルートの作成 リンクのコピーリンクがクリップボードにコピーされました!
Ingress リソースを必要とするエコシステムコンポーネントを統合するには、Ingress オブジェクトを設定します。OpenShift Container Platform は、対応するルートオブジェクトのライフサイクルを自動的に管理し、シームレスな接続を確保するためにルートオブジェクトを作成および削除します。
手順
OpenShift Container Platform コンソールで Ingress オブジェクトを定義するか、
oc createコマンドを実行します。Ingress の YAML 定義
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: frontend annotations: route.openshift.io/termination: "reencrypt" route.openshift.io/destination-ca-certificate-secret: secret-ca-cert spec: rules: - host: www.example.com http: paths: - backend: service: name: frontend port: number: 443 path: / pathType: Prefix tls: - hosts: - www.example.com secretName: example-com-tls-certificate # ...ここでは、以下のようになります。
route.openshift.io/termination-
route.openshift.io/terminationアノテーションを指定します。Ingress にはこのパラメーターがないため、Routeのspec.tls.terminationパラメーターを設定できます。受け入れられる値は、edge、passthrough、reencryptです。その他のすべての値は警告なしに無視されます。アノテーション値が設定されていない場合は、edgeがデフォルトルートになります。デフォルトの edge ルートを実装するには、TLS 証明書の詳細をテンプレートファイルで定義する必要があります。 ルールホスト-
Ingressオブジェクトのホスト名を明示的に指定します。必須パラメーター。<host_name>.<cluster_ingress_domain>構文 (apps.openshiftdemos.comなど) を使用して、*.<cluster_ingress_domain>ワイルドカード DNS レコードとクラスターのサービング証明書を利用できます。それ以外の場合は、選択したホスト名の DNS レコードがあることを確認する必要があります。 宛先 CA 証明書シークレットroute.openshift.io/destination-ca-certificate-secretアノテーションを指定します。このアノテーションは、Ingress オブジェクトで使用して、カスタム宛先証明書 (CA) を使用したルートを定義するために使用できます。アノテーションは、生成されたルートに挿入される kubernetes シークレットsecret-ca-certを参照します。route.openshift.io/terminationアノテーションでpassthroughの値を指定する場合は、仕様でpathを''に設定し、pathTypeをImplementationSpecificに設定します。apiVersion: networking.k8s.io/v1 kind: Ingress # ... spec: rules: - host: www.example.com http: paths: - path: '' pathType: ImplementationSpecific backend: service: name: frontend port: number: 443 # ...$ oc apply -f ingress.yaml-
Ingress オブジェクトから宛先 CA を使用してルートオブジェクトを指定するには、シークレットの
data.tls.crt指定子に PEM エンコード形式の証明書を使用してkubernetes.io/tlsまたはOpaqueタイプのシークレットを作成する必要があります。
ルートを一覧表示します。
$ oc get routes結果には、
frontend-で始まる名前の自動生成ルートが含まれます。NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD frontend-gnztq www.example.com frontend 443 reencrypt/Redirect None自動生成されたルートの YAML 定義例
apiVersion: route.openshift.io/v1 kind: Route metadata: name: frontend-gnztq ownerReferences: - apiVersion: networking.k8s.io/v1 controller: true kind: Ingress name: frontend uid: 4e6c59cc-704d-4f44-b390-617d879033b6 spec: host: www.example.com path: / port: targetPort: https tls: certificate: | -----BEGIN CERTIFICATE----- [...] -----END CERTIFICATE----- insecureEdgeTerminationPolicy: Redirect key: | -----BEGIN RSA PRIVATE KEY----- [...] -----END RSA PRIVATE KEY----- termination: reencrypt destinationCACertificate: | -----BEGIN CERTIFICATE----- [...] -----END CERTIFICATE----- to: kind: Service name: frontend