第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 から Route リソースへのラベル伝播について

Ingress Operator がラベルを自動的に伝播できるようにする機能を有効にすることができます。これにより、リソースの追跡や管理に役立つメタデータを追加したり、ラベルに依存する特定の動作を制御したりすることが可能になります。

デフォルトでは、管理対象の Route オブジェクトは Ingress リソースからラベルを継承しません。伝播機能を有効にすると、Operator は生成された ルート リソースのラベルを、親の イングレス リソースのラベルと一致するように積極的に調整します。

注記

ラベル伝播が有効になっている場合、Ingress Operator は、管理対象の Route リソース上のすべてのラベルを、親 Ingress リソースからの正確なラベルセットに置き換えます。Route リソースに手動で追加されたラベルはすべて削除されます。

伝播動作は、Ingress リソースの route.openshift.io/reconcile-labels アノテーションによって制御されます。Operator の動作は、このアノテーションの状態に応じて変化します。

  • アノテーションが存在しません (デフォルト):Operator は、Ingress リソースから Route リソースにラベルを同期しません。ルート 上に既存の標識はすべて保存されます。
  • アノテーションが有効になっています (route.openshift.io/reconcile-labels: "true"): Operator がラベルの伝播を有効にします。次のリコンシリエーション (Ingress の 作成または更新イベントによってトリガーされる) で、Operator は生成された Route リソース上のすべてのラベルを Ingress リソースのラベルに置き換えます。
  • アノテーションが無効になっています (削除されたか、値が true 以外に設定されています):Operator はラベルの伝播を無効にします。Route リソースに現在存在するラベルはそのまま保持されますが、Operator はそれらを Ingress リソースと同期しなくなります。
  • アノテーションが再び有効になりました:Operator は伝播を再開します。これにより、Route リソース上のすべてのラベルが、Ingress リソースの現在のラベルに再度置き換えられます。

1.1.4. Ingress から Route リソースへのラベル伝播を有効にする

Ingress Operator を有効にすると、Ingress リソースから管理対象の Route リソースへラベルを自動的に伝播させることができます。これを有効にするには、Ingress リソースに reconcile-labels アノテーションを追加する必要があります。

前提条件

  • Red Hat OpenShift Service on AWS クラスターにアクセスできます。
  • あなたは cluster-admin ロール、またはプロジェクト内で Ingress リソースを作成および編集するための権限を持っています。

手順

  1. Ingress リソースマニフェストを作成または編集します。
  2. metadata.annotations セクションに route.openshift.io/reconcile-labels: "true" を追加します。
  3. metadata.labels セクションに、伝播させたいラベルを追加します。

    ラベル伝播が有効になっている Ingress リソースの例:

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: example-ingress
      annotations:
        route.openshift.io/reconcile-labels: "true"
      labels:
        app: my-app
        owner: dev-team
    spec:
      ingressClassName: openshift-default
      rules:
      - host: example.com
        http:
          paths:
          - backend:
              service:
                name: example-service
                port:
                  number: 27017
            path: "/"
            pathType: "Prefix"
  4. マニフェストをクラスターに適用します。

    $ oc apply -f <example-ingress-manifest.yaml>

    <example-Ingress-manifest.yaml> を、ご使用のマニフェストファイルの名前に置き換えてください。

  5. Ingress リソースのラベルが生成された Route リソースに伝播されていることを確認してください。

    $ oc get route -l app=my-app --show-labels

    出力例:

    NAME          HOST/PORT     PATH   SERVICES          PORT    TERMINATION   WILDCARD   LABELS
    example-rt    example.com   /      example-service   8080                  None       app=my-app,owner=dev-team
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

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

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

Legal Notice

Theme

© 2026 Red Hat
トップに戻る