10.3. Knative サービスのカスタムドメインの設定


Knative サービスには、クラスターの設定に基づいてデフォルトのドメイン名が自動的に割り当てられます。例: <service_name>-<namespace>.example.com.所有するカスタムドメイン名を Knative サービスにマッピングすることで、Knative サービスのドメインをカスタマイズできます。

これを行うには、サービスの DomainMapping リソースを作成します。複数の DomainMapping を作成して、複数のドメインおよびサブドメインを単一サービスにマップすることもできます。

10.3.1. カスタムドメインマッピングの作成

所有するカスタムドメイン名を Knative サービスにマッピングすることで、Knative サービスのドメインをカスタマイズできます。カスタムドメイン名をカスタムリソース (CR) にマッピングするには、Knative サービスまたは Knative ルートなどのアドレス指定可能なターゲット CR にマッピングする DomainMapping CR を作成する必要があります。

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
  • OpenShift CLI (oc) をインストールしている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • Knative サービスを作成し、そのサービスにマップするカスタムドメインを制御できる。

    注記

    カスタムドメインは OpenShift Container Platform クラスターの IP アドレスを参照する必要があります。

手順

  1. マップ先となるターゲット CR と同じ namespace に DomainMapping CR が含まれる YAML ファイルを作成します。

    apiVersion: serving.knative.dev/v1alpha1
    kind: DomainMapping
    metadata:
     name: <domain_name> 1
     namespace: <namespace> 2
    spec:
     ref:
       name: <target_name> 3
       kind: <target_type> 4
       apiVersion: serving.knative.dev/v1
    1
    ターゲット CR にマップするカスタムドメイン名。
    2
    DomainMapping CR とターゲット CR の両方の namespace。
    3
    カスタムドメインにマップするサービス名。
    4
    カスタムドメインにマップされる CR のタイプ。

    サービスドメインマッピングの例

    apiVersion: serving.knative.dev/v1alpha1
    kind: DomainMapping
    metadata:
     name: example.com
     namespace: default
    spec:
     ref:
       name: example-service
       kind: Service
       apiVersion: serving.knative.dev/v1

    ルートドメインマッピングの例

    apiVersion: serving.knative.dev/v1alpha1
    kind: DomainMapping
    metadata:
     name: example.com
     namespace: default
    spec:
     ref:
       name: example-route
       kind: Route
       apiVersion: serving.knative.dev/v1

  2. DomainMapping CR を YAML ファイルとして適用します。

    $ oc apply -f <filename>

10.3.2. Knative CLI を使用したカスタムドメインマッピングの作成

所有するカスタムドメイン名を Knative サービスにマッピングすることで、Knative サービスのドメインをカスタマイズできます。Knative (kn) CLI を使用して、Knative サービスまたは Knative ルートなどのアドレス指定可能なターゲット CR にマップする DomainMapping カスタムリソース (CR) を作成できます。

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
  • Knative サービスまたはルートを作成し、その CR にマップするカスタムドメインを制御している。

    注記

    カスタムドメインは OpenShift Container Platform クラスターの DNS を参照する必要があります。

  • Knative (kn) CLI をインストールしている。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。

手順

  • ドメインを現在の namespace の CR にマップします。

    $ kn domain create <domain_mapping_name> --ref <target_name>

    コマンドの例

    $ kn domain create example.com --ref example-service

    --ref フラグは、ドメインマッピング用のアドレス指定可能なターゲット CR を指定します。

    --ref フラグの使用時に接頭辞が指定されていない場合、ターゲットが現在の namespace の Knative サービスであることを前提としています。

  • ドメインを指定された namespace の Knative サービスにマップします。

    $ kn domain create <domain_mapping_name> --ref <ksvc:service_name:service_namespace>

    コマンドの例

    $ kn domain create example.com --ref ksvc:example-service:example-namespace

  • ドメインを Knative ルートにマップします。

    $ kn domain create <domain_mapping_name> --ref <kroute:route_name>

    コマンドの例

    $ kn domain create example.com --ref kroute:example-route

10.3.3. TLS 証明書を使用してカスタムドメインでサービスを保護する

Knative サービスのカスタムドメインを設定したら、TLS 証明書を使用して、マップされたサービスを保護できます。これを行うには、Kubernetes TLS シークレットを作成してから、作成した TLS シークレットを使用するように DomainMapping CR を更新する必要があります。

注記

Ingress に net-istio を使用し、security.dataPlane.mtls: true を使用して SMCP 経由で mTLS を有効にする場合、Service Mesh は *.local ホストの DestinationRules をデプロイしますが、これは OpenShift Serverless の DomainMapping を許可しません。

この問題を回避するには、security.dataPlane.mtls: true を使用する代わりに PeerAuthentication をデプロイして mTLS を有効にします。

前提条件

  • Knative サービスのカスタムドメインを設定し、有効な DomainMapping CR がある。
  • 認証局プロバイダーからの TLS 証明書または自己署名証明書がある。
  • 認証局プロバイダーまたは自己署名証明書から cert ファイルおよび key ファイルを取得している。
  • OpenShift CLI (oc) をインストールしている。

手順

  1. Kubernetes TLS シークレットを作成します。

    $ oc create secret tls <tls_secret_name> --cert=<path_to_certificate_file> --key=<path_to_key_file>
  2. Red Hat OpenShift Service Mesh を OpenShift Serverless インストールのイングレスとして使用している場合は、Kubernetes TLS シークレットに次のラベルを付けます。

    “networking.internal.knative.dev/certificate-uid": “<value>”

    cert-manager などのサードパーティーのシークレットプロバイダーを使用している場合は、Kubernetes TLS シークレットに自動的にラベルを付けるようにシークレットマネージャーを設定できます。Cert-manager ユーザーは、提供されたシークレットテンプレートを使用して、正しいラベルを持つシークレットを自動的に生成できます。この場合、シークレットのフィルターリングはキーのみに基づいて行われますが、この値には、シークレットに含まれる証明書 ID などの有用な情報が含まれている可能性があります。

    注記

    {cert-manager-operator} はテクノロジープレビュー機能です。詳細は、{cert-manager-operator} のインストール に関するドキュメントを参照してください。

  3. 作成した TLS シークレットを使用するように DomainMapping CR を更新します。

    apiVersion: serving.knative.dev/v1alpha1
    kind: DomainMapping
    metadata:
      name: <domain_name>
      namespace: <namespace>
    spec:
      ref:
        name: <service_name>
        kind: Service
        apiVersion: serving.knative.dev/v1
    # TLS block specifies the secret to be used
      tls:
        secretName: <tls_secret_name>

検証

  1. DomainMapping CR のステータスが True であることを確認し、出力の URL 列に、マップされたドメインをスキームの https で表示していることを確認します。

    $ oc get domainmapping <domain_name>

    出力例

    NAME                      URL                               READY   REASON
    example.com               https://example.com               True

  2. オプション: サービスが公開されている場合は、以下のコマンドを実行してこれが利用可能であることを確認します。

    $ curl https://<domain_name>

    証明書が自己署名されている場合は、curl コマンドに -k フラグを追加して検証を省略します。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

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

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

会社概要

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

© 2024 Red Hat, Inc.