VPN サイドカーには起動ルールと失敗ルールが必要です

Pod がアプリの前にトンネルコンテナを起動し、最初のリクエストが成功する。これはまさに問題を隠すケースです。起動順序は 一つの競合を解決するだけで、トンネルが落ちた 四時間後にアプリが始める通信については何も語りません。これは 二つの別の決定です。ふつうは片方しか設計されません。

順序が制御するのは最初のリクエストだけです

Kubernetes は再起動可能な init コンテナで組むサイドカー・ライフサイクルをサポートします。そのモデルでは、起動プローブが次の初期化ステップを、トンネルが準備完了を報告するまで止められます。これは本物の改善であり、エントリポイントのスクリプトに sleep を足すのではなく、意図して使う価値があります。ゲートは、それが検査する条件と同じだけしか信用できません。

そのモデルの外では、順序の意味論は使っているランタイムや依存関係システムに属し、一致する必要はありません。別のプラットフォームからコピーしたデプロイは、アプリがたまたま遅く起動するためにトンネルを待っているように見えることがあります。同じ保証ではなく、負荷がかかると破綻します。

ゲートが何を見ているかを明示してください。プロセスがある、インターフェースがある、ハンドシェイクが完了した。どれも「この Pod が必要とする宛先へのデータ経路が機能している」より弱い主張です。

データ経路を前提にせず、強制してください

プローブはある瞬間の検査であり、ファイアウォールは瞬間と瞬間の間に成立する性質です。アプリの通信がトンネルの外に出ないことが要件なら、共有ネットワーク名前空間で「受け入れるか捨てるか」のルールとして表現する必要があります。コンテナの起動順序はその要件を担えません。ルールだけが担えます。

同じ Pod のコンテナはその名前空間を共有します。だから強制点は名前空間そのものです。何を書くにしても、トンネル自身の外側の接続は利用可能なままにしなければなりません。アプリを守るためにそれを遮断すると、アプリが必要とする経路が切れるからです。

失敗時の扱いを明示的に決めてください。トンネルが不健全なとき、アプリの通信を完全に止めるのか、続行して未保護と印を付けるのか。どちらも筋は通っており、どちらもコンテナを特定の順序で起動して得られるものではありません。

言及していない通信を試験してください

制御されたトンネル障害の間に新しいリクエストを出し、外に出るかを見ます。次に、出口アドレスのテストが決して触れない経路についても同じ検査を繰り返します。クラスタ内の DNS 解決、IPv6 の宛先、そして公開インターネットではなくクラスタ内部のアドレスで到達するサービスです。トンネルが死んだ後も静かに動き続けるのはこれらの経路です。

出口アドレスのページは、あるリクエストがその瞬間に期待どおりの場所へ行ったことを示します。ほかの経路を棚卸しすることはできず、試験した範囲と Pod が到達できる範囲の間の隙間こそ、興味深い障害が住む場所です。

きれいな起動の後だけでなく、サイドカーの再起動の後にも試験を繰り返してください。再起動したトンネルコンテナは、名前空間にルートとポリシーを中間状態で残すことがあります。

デプロイ記録を書いてください

デプロイの記録には 三つの事実を書きます。準備完了の試験とそれが見るもの、その試験が失敗したときの復旧操作、そして egress を統制する強制ルールです。サイドカーコンテナのドキュメントはライフサイクルの仕組みを扱い、そのポリシー判断はあなたに委ねています。この分担は正しく、だからこそポリシーがたいてい欠けています。

保護と取り違えられたヘルスチェックは、最も高価な種類の緑の指標です。人が質問するのを止めてしまうからです。ドキュメントで正確に名付けるのに 一文しかかからず、それを防げます。

最後に、アプリを動かしたまま復旧経路を 一度試験してください。egress を戻すために Pod の再作成を要する設計は判断であり、発見したものではなく、あなたが下した判断であるべきです。