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 アドレスを参照する必要があります。
手順
マップ先となるターゲット 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
サービスドメインマッピングの例
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
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 アドレスを参照する必要があります。
手順
- Topology ページに移動します。
-
ドメインにマッピングするサービスを右クリックし、サービス名が含まれる Edit オプションを選択します。たとえば、サービスの名前が
example-service
である場合は、Edit example-service オプションを選択します。 Advanced options セクションで、Show advanced Routing options をクリックします。
- サービスにマッピングするドメインマッピング CR がすでに存在する場合は、ドメインマッピング リストで選択できます。
-
新規ドメインマッピング CR を作成する場合は、ドメイン名をボックスに入力し、Create オプションを選択します。たとえば、
example.com
と入力すると、Create オプションは Create "example.com" になります。
- Save をクリックしてサービスへの変更を保存します。
検証
- Topology ページに移動します。
- 作成したサービスをクリックします。
- サービス情報ウィンドウの 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 アドレスを参照する必要があります。
手順
- CustomResourceDefinitions に移動し、検索ボックスを使用して DomainMapping カスタムリソース定義 (CRD) を検索します。
- DomainMapping CRD をクリックしてから Instances タブに移動します。
- Create DomainMapping をクリックします。
インスタンスの以下の情報が含まれるように
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
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
) をインストールしている。
手順
Kubernetes TLS シークレットを作成します。
$ oc create secret tls <tls_secret_name> --cert=<path_to_certificate_file> --key=<path_to_key_file>
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} のインストール に関するドキュメントを参照してください。
作成した 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>
検証
DomainMapping
CR のステータスがTrue
であることを確認し、出力のURL
列に、マップされたドメインをスキームのhttps
で表示していることを確認します。$ oc get domainmapping <domain_name>
出力例
NAME URL READY REASON example.com https://example.com True
オプション: サービスが公開されている場合は、以下のコマンドを実行してこれが利用可能であることを確認します。
$ 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-controller
でENABLE_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