第1章 ルート


1.1. 基本ルートの作成

暗号化されていない HTTP がある場合は、ルートオブジェクトを使用して基本ルートを作成できます。

1.1.1. HTTP ベースのルートの作成

hello-openshift アプリケーションを例として、以下の手順で Web アプリケーションへの単純な HTTP ベースのルートを作成できます。

公開 URL でアプリケーションをホストするルートを作成できます。ルートは、アプリケーションのネットワークセキュリティー設定に応じて、セキュリティーで保護される場合と保護されない場合があります。HTTP ベースのルートとは、セキュアではないルートで、基本的な HTTP ルーティングプロトコルを使用してセキュリティー保護されていないアプリケーションポートでサービスを公開します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • 管理者としてログインしている。
  • あるポートを公開する Web アプリケーションと、そのポートでトラフィックをリッスンする TCP エンドポイントがあります。

手順

  1. 次のコマンドを実行して、hello-openshift というプロジェクトを作成します。

    $ oc new-project hello-openshift
  2. 以下のコマンドを実行してプロジェクトに Pod を作成します。

    $ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
  3. 以下のコマンドを実行して、hello-openshift というサービスを作成します。

    $ oc expose pod/hello-openshift
  4. 次のコマンドを実行して、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 パスコンポーネントを比較することでトラフィックを特定のサービスに振り分け、リクエストが定義された最も具体的なルートと一致するようにします。

以下の表は、ルートのサンプルおよびそれらのアクセシビリティーを示しています。

Expand
表1.1 ルートの可用性
ルート比較するとアクセス可能

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 を設定している。

手順

  1. 次のコマンドを実行して、hello-openshift というプロジェクトを作成します。

    $ oc new-project hello-openshift
  2. 以下のコマンドを実行してプロジェクトに Pod を作成します。

    $ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
  3. 以下のコマンドを実行して、hello-openshift というサービスを作成します。

    $ oc expose pod/hello-openshift
  4. hello-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 フィールドを指定するときは、ホスト名を未設定のままにしておく必要があります。ホストフィールドサブドメイン フィールドの両方を指定した場合、ルートは ホスト フィールドの値を使用し、サブドメイン フィールドは無視します。
  5. 次のコマンドを実行し、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 は、対応するルートオブジェクトのライフサイクルを自動的に管理し、シームレスな接続を確保するためにルートオブジェクトを作成および削除します。

手順

  1. 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 には このパラメーターがないため、Routespec.tls.termination パラメーターを設定できます。受け入れられる値は、edgepassthroughreencrypt です。その他のすべての値は警告なしに無視されます。アノテーション値が設定されていない場合は、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 を参照します。

    1. route.openshift.io/termination アノテーションで passthrough の値を指定する場合は、仕様で path'' に設定し、pathTypeImplementationSpecific に設定します。

      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
    2. Ingress オブジェクトから宛先 CA を使用してルートオブジェクトを指定するには、シークレットの data.tls.crt 指定子に PEM エンコード形式の証明書を使用して kubernetes.io/tls または Opaque タイプのシークレットを作成する必要があります。
  2. ルートを一覧表示します。

    $ 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

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Legal Notice

Theme

© 2026 Red Hat
トップに戻る