Alibaba Cloud Service Mesh (ASM) ゲートウェイはイングレスレイヤーで TLS を終了させます。そのため、外部クライアントは HTTPS 経由で接続し、内部トラフィックは暗号化されずに Knative サービスに到達します。ゲートウェイは Kubernetes Secret から TLS 証明書を動的にロードするため、ゲートウェイ Pod を再起動することなく認証情報をローテーションできます。
このガイドでは、TLS 証明書の作成、Kubernetes Secret としての保存、HTTPS 用の ASM ゲートウェイの設定、およびエンドツーエンドの接続性の検証について順を追って説明します。
仕組み
クライアントが Knative サービスに HTTPS リクエストを送信すると、次のようになります。
リクエストは
istio-system名前空間にある ASM イングレスゲートウェイ Pod に到達します。ゲートウェイは、Kubernetes Secret に保存されている証明書と秘密鍵を使用して TLS を終了させます。
ゲートウェイは、復号されたリクエストをメッシュ内のターゲット Knative サービスに転送します。
この設定により、外部クライアントとゲートウェイ間のトラフィックが暗号化されます。メッシュ内部のコンポーネント間のトラフィックは暗号化されません。メッシュ内部のサービス間トラフィックを暗号化するには、ASM の mTLS (相互 TLS) を設定してください。
前提条件
開始する前に、以下が準備できていることを確認してください。
Knative on ASM を通じてデプロイされた Knative サービス。詳細については、「Knative on ASM を使用してサーバーレスアプリケーションをデプロイする」をご参照ください。
Knative on ASM で設定されたカスタムドメイン名 (このガイドでは例として
aliyun.comを使用します)。詳細については、「Knative on ASM でカスタムドメイン名を設定する」をご参照ください。ドメイン名
aliyun.comの ICP (Internet Content Provider) 登録ローカルマシンにインストールされた OpenSSL (自己署名証明書の場合にのみ必要)
ASM コントロールプレーンと、イングレスゲートウェイ Pod をホストするクラスターの両方にアクセスできるように設定された
kubectl
ステップ 1: TLS 証明書と秘密鍵の作成
aliyun.com の有効な証明書と秘密鍵をすでにお持ちの場合は、それらの名前を aliyun.com.crt と aliyun.com.key に変更し、「証明書を Kubernetes Secret として保存する」に進んでください。
OpenSSL を使用して自己署名証明書を生成するには:
ルート認証局 (CA) を作成します。
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 \ -subj '/O=myexample Inc./CN=aliyun.com' \ -keyout aliyun.root.key -out aliyun.root.crtルート CA によって署名されたサーバー証明書と秘密鍵を生成します。
openssl req -out aliyun.com.csr -newkey rsa:2048 -nodes \ -keyout aliyun.com.key -subj "/CN=aliyun.com/O=myexample organization" openssl x509 -req -days 365 -CA aliyun.root.crt -CAkey aliyun.root.key \ -set_serial 0 -in aliyun.com.csr -out aliyun.com.crt
本番環境では、パブリック認証局 (CA) からの証明書を使用するか、cert-manager と統合して証明書のプロビジョニングと更新を自動化してください。自己署名証明書は、開発およびテスト目的でのみ使用してください。
証明書を Kubernetes Secret として保存する
イングレスゲートウェイ Pod をホストするクラスターの kubeconfig を使用して、istio-system 名前空間に TLS Secret を作成します。
kubectl create -n istio-system secret tls myexample-credential \
--key=aliyun.com.key --cert=aliyun.com.crtSecret 名 (myexample-credential) をメモしておきます。次のステップで必要になります。
ステップ 2: ASM ゲートウェイでの HTTPS の設定
次の YAML を
default.yamlとして保存します。以下の値を置き換えてください。フィールド 説明 domainNameKnative on ASM で設定されたカスタムドメイン名 credentialName前のステップで作成した TLS Secret の名前 apiVersion: istio.alibabacloud.com/v1beta1 kind: ASMKnativeConfig metadata: name: default spec: enabled: true useExisting: true tag: 1.4.0 domainConfig: domainName: aliyun.com # ご利用のドメイン名に置き換えてください。 credentialName: myexample-credential # ご利用の Secret 名に置き換えてください。kubectl を ASM コントロールプレーンに接続し、設定を適用します。
kubectl apply -f default.yaml
ステップ 3: HTTPS アクセスの検証
ローカルの hosts ファイルの更新
Knative サービスのドメインから ASM ゲートウェイの IP アドレスへの DNS マッピングを追加します。
<gateway-ip> helloworld-go.default.aliyun.com<gateway-ip> を ASM イングレスゲートウェイの IP アドレスに置き換えます。このアドレスを見つけるには、「Knative on ASM を使用してサーバーレスアプリケーションをデプロイする」の「ステップ 3: ゲートウェイアドレスの照会」をご参照ください。
curl でのテスト
証明書検証のためにルート CA を使用して、Knative サービスに HTTPS リクエストを送信します。
curl --cacert aliyun.root.crt \
--cert aliyun.com.crt --key aliyun.com.key \
https://helloworld-go.default.aliyun.com期待される出力:
Hello Knative!--cacert フラグは、生成したルート CA に対してサーバー証明書を検証します。パブリック CA からの証明書を使用した場合は、--cacert を省略してください。
自己署名証明書を使用した簡単なテストで証明書検証をスキップするには、-k フラグを使用します。
curl -k --cert aliyun.com.crt --key aliyun.com.key \
https://helloworld-go.default.aliyun.comブラウザでのテスト
ブラウザで https://helloworld-go.default.aliyun.com を開きます。
ブラウザは自己署名証明書に対してセキュリティ警告を表示します。これは想定内の動作であり、設定の問題を示すものではありません。
トラブルシューティング
| 現象 | 考えられる原因 | 解決策 |
|---|---|---|
接続拒否 ポート 443 で | ASMKnativeConfig が適用されていないか、ゲートウェイ Pod が再読み込みされていない | kubectl get asmknativeconfig default -o yaml を実行して設定を確認します。ゲートウェイ Pod のログでエラーを確認します。 |
| TLS ハンドシェイクの失敗 | ASMKnativeConfig の Secret 名が istio-system | kubectl get secret -n istio-system を実行して Secret が存在し、名前が credentialName と一致することを確認します。 |
証明書の検証に失敗 | --cacert フラグが間違った CA 証明書を指している | サーバー証明書ではなく、ルート CA (aliyun.root.crt) を渡します。 |
| ブラウザに「保護されていない通信」の警告が表示される | 自己署名証明書が使用されている | 自己署名証明書では想定内の動作です。本番環境ではパブリック CA からの証明書を使用してください。 |
404 Not Found 設定を適用した後 | ASMKnativeConfig のドメイン名が Knative サービスのドメインと一致しない | domainName が Knative on ASM で設定されたドメインと一致することを確認します。 |
次のステップ
トラフィック分割によるカナリアリリース: Knative on ASM は、トラフィック分割に基づくカナリアリリースをサポートしています。Knative サービスを作成すると、Knative は最初の Revision を自動的に作成します。サービス構成が変更されるたびに、Knative は新しい Revision を作成し、異なる Revision に分散されるトラフィックの割合を調整します。詳細については、「Knative on ASM を使用して Knative サービスのトラフィック分割に基づくカナリアリリースを実行する」をご参照ください。
リクエストベースの Pod 自動スケーリング: Knative Serving は、各 Pod に Queue Proxy コンテナを追加します。Queue Proxy コンテナは、同時実行メトリックを Knative Pod Autoscaler (KPA) にレポートします。これらのメトリックに基づき、KPA は同時リクエスト数と関連する自動スケーリングアルゴリズムに従って、Deployment 用にプロビジョニングされる Pod の数を自動的に調整します。詳細については、「リクエスト数に基づく Pod の自動スケーリングを有効にする」をご参照ください。