外部ロードバランサー

ホストが提供する外部ロードバランサーを使用している場合、cert-managerと連携させるためにいくつかの設定上の問題に直面する可能性があります。

このドキュメントは、外部ロードバランサーの背後にあるインスタンスに対してHTTP-01チャレンジタイプを設定するのに役立つことを目的としています。

NATループバック / ヘアピン

最初の設定ポイントはNATループバックです。ロードバランサーが背後のインスタンスがその外部インターフェースにアクセスするのを妨げるため、チェックの問題に直面する可能性があります。

一部のネットワークロードバランサーには、いくつかの理由でこの種制限があります。これは、NATループバックとして知られるiptablesルーティング設定を通して設定できます。

この問題に直面しているかどうかを確認するには

チャレンジのエンドポイントが一般にアクセス可能であることを確認します: curl <endpoint>
チャレンジエンドポイントがロードバランサーの内部からアクセスできないことを確認します。SSHを使用してLBの背後にあるノードでセッションを開き、以前と同じコマンドを起動します: curl <endpoint>

HTTP-01チャレンジのエンドポイントは、pre-checkが失敗したときにログに記録されます。ログに表示されない場合は、kubectlコマンドでチャレンジURLを確認できます。

<endpoint>は、証明書IssuerからHTTP-01をテストするために使用されるURLです。たとえば、Let's Encryptの場合、URLは<domain>/.well-known/acme-challenge/<hash>のように構成されます。

(マネージドKubernetesサービス外の)ロードバランサーを使用している場合は、ロードバランサープロトコルをHTTP、HTTPS、TCP、UDPとして構成できるはずです。現在、いくつかのロードバランサーはLet's Encryptによる無料のTLS証明書を提供しています。

ロードバランサーにHTTP(s)プロトコルを使用すると、チャレンジURLをインターセプトして、応答の検証ハッシュを自身のハッシュに置き換える可能性があります。

この場合、cert-managerはdid not get expected response when querying endpoint, expected 'xxxx' but got: yyyy (truncated)で失敗します。

この種のエラーは、複数の理由で発生する可能性があります。このケースでは、正しくフォーマットされた応答が表示されますが、期待される応答ではありません。解決策は、HTTPリクエストがホストによってインターセプトされないように、ロードバランサーをTCPプロトコルで構成することです。