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


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

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

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

4.7.2. カスタムドメインマッピング

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

4.7.2.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-domain
     namespace: default
    spec:
     ref:
       name: example-service
       kind: Service
       apiVersion: serving.knative.dev/v1

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

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

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

    $ oc apply -f <filename>

4.7.3. Knative CLI を使用した Knative サービスのカスタムドメイン

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

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

前提条件

  • 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-domain-map --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-domain-map --ref ksvc:example-service:example-namespace

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

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

    コマンドの例

    $ kn domain create example-domain-map --ref kroute:example-route

4.7.4. Developer パースペクティブを使用したドメインマッピング

所有するカスタムドメイン名を Knative サービスにマッピングすることで、Knative サービスのドメインをカスタマイズできます。OpenShift Container Platform Web コンソールの Developer パースペクティブを使用して、DomainMapping カスタムリソース (CR) を Knative サービスにマッピングできます。

4.7.4.1. Developer パースペクティブを使用したカスタムドメインのサービスへのマッピング

前提条件

  • Web コンソールにログインしている。
  • Developer パースペクティブを使用している。
  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。これはクラスター管理者が完了する必要があります。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • Knative サービスを作成し、そのサービスにマップするカスタムドメインを制御できる。

    注記

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

手順

  1. Topology ページに移動します。
  2. ドメインにマッピングするサービスを右クリックし、サービス名が含まれる Edit オプションを選択します。たとえば、サービスの名前が example-service である場合は、Edit example-service オプションを選択します。
  3. Advanced options セクションで、Show advanced Routing options をクリックします。

    1. サービスにマッピングするドメインマッピング CR がすでに存在する場合は、ドメインマッピング リストで選択できます。
    2. 新規ドメインマッピング CR を作成する場合は、ドメイン名をボックスに入力し、Create オプションを選択します。たとえば、example.com と入力すると、Create オプションは Create "example.com" になります。
  4. Save をクリックしてサービスへの変更を保存します。

検証

  1. Topology ページに移動します。
  2. 作成したサービスをクリックします。
  3. サービス情報ウィンドウの Resources タブで、Domain mappings セクションにサービスにマッピングしたドメインが表示されます。

4.7.5. Administrator パースペクティブを使用したドメインマッピング

OpenShift Container Platform Web コンソールで Developer パースペクティブに切り替えたり、Knative (kn) CLI または YAML ファイルを使用しない場合は、OpenShift Container Platform Web コンソールの Administator パースペクティブを使用できます。

4.7.5.1. Administrator パースペクティブを使用したカスタムドメインのサービスへのマッピング

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

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

クラスター管理者パーミッションを持つ場合、OpenShift Container Platform Web コンソールの Administrator パースペクティブを使用して DomainMapping カスタムリソース (CR) を作成できます。

前提条件

  • Web コンソールにログインしている。
  • Administrator パースペクティブに切り替えられている。
  • OpenShift Serverless Operator がインストールされている。
  • Knative Serving がインストールされています。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
  • Knative サービスを作成し、そのサービスにマップするカスタムドメインを制御できる。

    注記

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

手順

  1. CustomResourceDefinitions に移動し、検索ボックスを使用して DomainMapping カスタムリソース定義 (CRD) を検索します。
  2. DomainMapping CRD をクリックしてから Instances タブに移動します。
  3. Create DomainMapping をクリックします。
  4. インスタンスの以下の情報が含まれるように 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 のタイプ。

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

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

検証

  • curl リクエストを使用してカスタムドメインにアクセスします。以下に例を示します。

    コマンドの例

    $ curl custom-ksvc-domain.example.com

    出力例

    Hello OpenShift!

4.7.6. TLS 証明書を使用してマッピングされたサービスを保護する

4.7.6.1. 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. networking.internal.knative.dev/certificate-uid: <id>' ラベル を Kubernetes TLS シークレットに追加します。

    $ oc label secret <tls_secret_name> networking.internal.knative.dev/certificate-uid="<id>"

    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 フラグを追加して検証を省略します。

4.7.6.2. シークレットフィルターリングを使用した net-kourier のメモリー使用量の改善

デフォルトでは、Kubernetes client-go ライブラリーの informers の実装は、特定のタイプのすべてのリソースをフェッチします。これにより、多くのリソースが利用可能になると大きなオーバーヘッドが発生する可能性があり、メモリーリークが原因で Knative net-kourier Ingress コントローラーが大規模なクラスターで失敗する可能性があります。ただし、フィルターリングメカニズムは Knative net-kourier Ingress コントローラーで利用できます。これにより、コントローラーは Knative 関連のシークレットのみを取得できます。このメカニズムを有効にするには、環境変数を KnativeServing カスタムリソース(CR)に設定します。

重要

シークレットフィルターリングを有効にする場合は、すべてのシークレットに networking.internal.knative.dev/certificate-uid: "<id>" でラベルを付ける必要が あります。それ以外の場合、Knative Serving はそれらを検出しないため、エラーが発生します。新規および既存のシークレットの両方にラベルを付ける必要があります。

前提条件

  • クラスター管理者のアクセスを持つ OpenShift Container Platform アカウントを使用できる。
  • OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するためにロールおよびパーミッションを持つプロジェクト、または作成したプロジェクト。
  • OpenShift Serverless Operator および Knative Serving をインストールします。
  • OpenShift CLI (oc) をインストールしている。

手順

  • KnativeServing CR の net-kourier-controllerENABLE_SECRET_INFORMER_FILTERING_BY_CERT_UID 変数を true に設定します。

    KnativeServing CR の例

    apiVersion: operator.knative.dev/v1beta1
    kind: KnativeServing
    metadata:
     name: knative-serving
     namespace: knative-serving
    spec:
     deployments:
       - env:
         - container: controller
           envVars:
           - name: ENABLE_SECRET_INFORMER_FILTERING_BY_CERT_UID
             value: 'true'
         name: net-kourier-controller

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.