minikube がプライベート API に届かない？まずドライバーを確認

ホスト、ノード、Pod はそれぞれ独自のルートとリゾルバーを持ちます。ドライバーを特定し、同じエンドポイントを 三か所から試し、失敗したコンテキストを直します。

プライベート API はノート PC からは応答するのに、minikube 内の Pod からは到達できません。ホスト側を変更する前に、アクティブなプロファイルの背後にあるドライバーを特定してください、なぜならこの事実だけがリクエストの実際の出口ネットワークを決めるからです。次に同じエンドポイントをホスト、ノード、Pod の三か所から試します。そのうち失敗しているのは一つだけであり、見当違いの推測は半日を無駄にします。

ステップ 0：ドライバーと送信元を特定する

minikube にどのプロファイルがアクティブで、どう動いているかを尋ねます。コンテナドライバーはノードをあなたのマシン上のコンテナに入れ、VM ドライバーは仮想マシンに入れ、リモートドライバーはまったく別の場所に置きます。

minikube profile list
minikube status
kubectl config current-context

そこから、リクエストがどこから出るのかを書き留めます。答えによって、どのリゾルバーとどのルートが重要かが決まり、それは常にホストのものとは限りません。同じノート PC 上の二つのプロファイルが、同じ URL に対してまったく違う振る舞いをすることもあります。

ContextWhat has to work
Host processHost resolver and host route to the private destination
minikube nodeThe node's own resolver and its outbound path
PodPod DNS through cluster services plus the cluster network path

ステップ 1：同じエンドポイントを三回試す

無害なエンドポイントを一つ選び、三回のテストすべてでホスト名、ポート、アドレスファミリーを同じに保ちます。実行の合間にどれか一つでも変えると、結果は比較できなくなります。

curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
minikube ssh -- curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
kubectl run probe --rm -it --image=curlimages/curl --restart=Never -- \
  curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health

ノードがイメージの取得に成功しても、プライベートホストの名前解決については何も証明できません。公開リクエストの成功なら、なおさらです。結果はコンテキストごとに分けて記録してください、なぜなら三行にまたがるパターンが診断であり、単発の失敗は手がかりにすぎないからです。

ホストの行も失敗するなら、そこで止まります。ホスト側のネットワーク問題であり、クラスタは関係ありません。

ステップ 2：ホストからクラスタへの経路を保つ

見落とされがちな二つ目の方向があります：ホストはクラスタ自身の API とサービスに到達し続けなければなりません。VPN クライアントは、minikube がノードネットワーク、サービス範囲、Pod 範囲に使うプレフィックスと競合するルートをインストールすることがあります。

そうなると症状は紛らわしくなります：トンネルは通っているのに kubectl が応答しなくなったり、NodePort が接続を拒否したりします。クラスタの障害に見えて、実はノート PC のルーティング障害です。

トンネルを疑う前に、ホストのルーティングテーブルと minikube の範囲を突き合わせてください。重複は通常、クラスタが自分のものと想定しているプレフィックスに対して、より具体的なルートがトンネルインターフェースを指す形で現れます。

ステップ 3：VPN を切らずに重複を解消する

minikube 自身の VPN とプロキシの手引きはこの競合を扱っており、例示されている範囲は普遍的な一覧ではなく、確認すべき対象として扱っています。実際に使っているプロファイルと併せて読んでください。

本当に重複がある場合、サポートされる答えは重複しない範囲にするか、VPN の所有者が承認した意図的なローカルアクセス方針です。サービス範囲の変更は Pod 範囲の変更とは別であり、どちらもノードネットワークの変更とは同じではありません。

ローカルクラスタを動かすために社内トンネルを切るのは回避策ではなく、他の誰かが下すべき方針判断です。全員が帰宅してからこっそりやるのではなく、その担当者に相談してください。すでに切ってしまったなら、尋ねる前に元に戻してください。

ステップ 4：プロキシ、DNS、四つの故障形態を切り分ける

プロキシが必要なら、どのコンテキストに必要かを特定します。ホストのブラウザー設定はノード内のプロセスを構成しませんし、Pod には環境変数かクラスタレベルのプロキシ設定が必要です。

次に、故障を説明するのではなく分類します。解決できない名前は DNS です。解決できて接続を拒否するのはルーティングかリスナーです。接続が確立して身元で失敗するのは TLS です。接続が成功してエラー本文が返るのはアプリケーションです。

この四つはそれぞれ別の対処に属し、VPN に関係するのは一つだけです。各コンテキストで何を観察したかを書き残せば、次の人は物語ではなく証拠を引き継げます。

関連記事