5.7. クラスターローカルの可用性


デフォルトで、Knative サービスはパブリック IP アドレスに公開されます。パブリック IP アドレスに公開されているとは、Knative サービスがパブリックアプリケーションであり、一般にアクセス可能な URL があることを意味します。

一般にアクセス可能な URL は、クラスター外からアクセスできます。ただし、開発者は プライベートサービス と呼ばれるクラスター内からのみアクセス可能なバックエンドサービスをビルドする必要がある場合があります。開発者は、クラスター内の個々のサービスに networking.knative.dev/visibility=cluster-local ラベルを使用してラベル付けし、それらをプライベートにすることができます。

重要

OpenShift Serverless 1.15.0 以降のバージョンの場合には、serving.knative.dev/visibility ラベルは利用できなくなりました。既存のサービスを更新して、代わりに networking.knative.dev/visibility ラベルを使用する必要があります。

5.7.1. クラスターローカルへのクラスター可用性の設定

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
  • Knative サービスを作成している。

手順

  • networking.knative.dev/visibility=cluster-local ラベルを追加して、サービスの可視性を設定します。

    $ oc label ksvc <service_name> networking.knative.dev/visibility=cluster-local

検証

  • 以下のコマンドを入力して出力を確認し、サービスの URL の形式が http://<service_name>.<namespace>.svc.cluster.local であることを確認します。

    $ oc get ksvc

    出力例

    NAME            URL                                                                         LATESTCREATED     LATESTREADY       READY   REASON
    hello           http://hello.default.svc.cluster.local                                      hello-tx2g7       hello-tx2g7       True

5.7.2. クラスターローカルサービスの TLS 認証の有効化

クラスターローカルサービスの場合、Kourier ローカルゲートウェイ kourier-internal が使用されます。Kourier ローカルゲートウェイに対して TLS トラフィックを使用する場合は、ローカルゲートウェイで独自のサーバー証明書を設定する必要があります。

前提条件

  • OpenShift Serverless Operator および Knative Serving がインストールされている。
  • 管理者権限がある。
  • OpenShift (oc) CLI がインストールされている。

手順

  1. サーバー証明書を knative-serving-ingress namespace にデプロイします。

    $ export san="knative"
    注記

    これらの証明書が <app_name>.<namespace>.svc.cluster.local への要求を処理できるように、Subject Alternative Name (SAN) の検証が必要です。

  2. ルートキーと証明書を生成します。

    $ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 \
        -subj '/O=Example/CN=Example' \
        -keyout ca.key \
        -out ca.crt
  3. SAN 検証を使用するサーバーキーを生成します。

    $ openssl req -out tls.csr -newkey rsa:2048 -nodes -keyout tls.key \
      -subj "/CN=Example/O=Example" \
      -addext "subjectAltName = DNS:$san"
  4. サーバー証明書を作成します。

    $ openssl x509 -req -extfile <(printf "subjectAltName=DNS:$san") \
      -days 365 -in tls.csr \
      -CA ca.crt -CAkey ca.key -CAcreateserial -out tls.crt
  5. Courier ローカルゲートウェイのシークレットを設定します。

    1. 前の手順で作成した証明書から、knative-serving-ingress namespace にシークレットをデプロイします。

      $ oc create -n knative-serving-ingress secret tls server-certs \
          --key=tls.key \
          --cert=tls.crt --dry-run=client -o yaml | oc apply -f -
    2. KnativeServing カスタムリソース (CR) 仕様を更新して、Kourier ゲートウェイによって作成されたシークレットを使用します。

      KnativeServing CR の例

      ...
      spec:
        config:
          kourier:
            cluster-cert-secret: server-certs
      ...

Kourier コントローラーはサービスを再起動せずに証明書を設定するため、Pod を再起動する必要はありません。

クライアントから ca.crt をマウントして使用することにより、ポート 443 経由で TLS を使用して Kourier 内部サービスにアクセスできます。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.