Kubernetes のベスト プラクティス。 外部サービスのマッピング

Kubernetes のベスト プラクティス。 小さなコンテナの作成
Kubernetes のベスト プラクティス。 名前空間を使用した Kubernetes の構成
Kubernetes のベスト プラクティス。 Readiness および Liveness テストによる Kubernetes の Liveness の検証
Kubernetes のベスト プラクティス。 リソースのリクエストと制限の設定
Kubernetes のベスト プラクティス。 正しいシャットダウン 終了

あなたもほとんどの人と同じであれば、おそらくクラスターの外部で実行されるリソースを使用しているでしょう。 おそらく、Taleo API を使用してテキスト メッセージを送信したり、Google Cloud Vision API を使用して画像を分析したりすることがあるでしょう。

すべての環境で同じサーバー側リクエスト エンドポイントを使用しており、サーバーを Kubernetes に移行する予定がない場合は、コード内にサービス エンドポイントを含めてもまったく問題ありません。 ただし、イベントの発展には他にも多くのシナリオがあります。 この Kubernetes ベスト プラクティス シリーズでは、Kubernetes の組み込みメカニズムを使用してクラスター内外のサービスを検出する方法を学びます。

一般的な外部サービスの例としては、Kubernetes クラスターの外部で実行されるデータベースがあります。 すべてのアクセスに単一のエンドポイントを使用する Google Cloud Data Store や Google Cloud Spanner のようなクラウド データベースとは異なり、ほとんどのデータベースには状況に応じて個別のエンドポイントがあります。
MySQL や MongoDB などの従来のデータベースを使用する場合のベスト プラクティスは、通常、環境ごとに異なるコンポーネントに接続することを意味します。 本番データ用に大きなマシンを使用し、テスト環境用に小さなマシンを使用できます。 それぞれに独自の IP アドレスまたはドメイン名がありますが、ある環境から別の環境に移行するときにコードを変更したくないでしょう。 したがって、これらのアドレスをハードコーディングする代わりに、ネイティブ Kubernetes サービスと同じ方法で、Kubernetes の組み込み DNS ベースの外部サービス検出を使用できます。

Google Compute Engine で MongoDB データベースを実行しているとします。 クラスターに転送できるまで、このハイブリッドの世界から立ち往生することになります。

幸いなことに、静的 Kubernetes サービスを使用すると、作業を少し楽にすることができます。 この例では、Google Cloud Launcher を使用して MongoDB サーバーを作成しました。 同じネットワーク (または Kubernetes クラスター VPC) 上に作成されるため、高性能の内部 IP アドレスを使用してアクセスされます。

これは Google Cloud のデフォルト設定であるため、何も構成する必要はありません。 IP アドレスを取得したので、最初のステップはサービスを作成することです。 このサービスにはポッド セレクターがないことに気付くかもしれません。 つまり、トラフィックをどこに送信するかわからないサービスを作成しました。 これにより、このサービスからトラフィックを受信するエンドポイント オブジェクトを手動で作成できるようになります。

次のコード例は、エンドポイントがサービスと同じ mongo 名を使用してデータベースの IP アドレスを決定することを示しています。

Kubernetes は、通常の Kubernetes ポッドであるかのように、すべての IP アドレスを使用してエンドポイントを検索するため、上記の名前 mongodb://mongo への単純な接続文字列を使用してデータベースにアクセスできるようになります。 コード内で IP アドレスを使用する必要はまったくありません。

将来 IP アドレスが変更された場合は、エンドポイントを新しい IP アドレスで更新するだけでよく、アプリケーションを追加で変更する必要はありません。

サードパーティのホストでホストされているデータベースを使用している場合は、ホストの所有者から接続先の URI が提供されている可能性があります。 したがって、IP アドレスが与えられている場合は、前の方法をそのまま使用できます。 この例は、mLab ホスト上でホストされている XNUMX つの MongoDB データベースがあることを示しています。

XNUMX つは開発者データベース、もう XNUMX つは運用データベースです。 これらのデータベースの接続文字列は次のようになります。mLab は動的 URI と動的ポートを提供します。 ご覧のとおり、それらは異なります。

これを抽象化するために、Kubernetes を使用して開発者データベースに接続しましょう。 外部 Kubernetes サービス名を作成すると、トラフィックを外部サービスに転送する静的サービスが得られます。

このサービスは、パフォーマンスへの影響を最小限に抑えながら、カーネル レベルで単純な CNAME 転送を実行します。 これにより、より単純な接続文字列を使用できるようになります。

ただし、外部名は CNAME 転送を使用するため、ポート転送を実行できません。 したがって、このソリューションは静的ポートにのみ適用でき、動的ポートでは使用できません。 ただし、mLab 無料利用枠では、デフォルトで動的ポート番号がユーザーに与えられ、変更することはできません。 これは、dev と prod に異なる接続コマンド ラインが必要であることを意味します。 問題は、ポート番号をハードコーディングする必要があることです。 では、ポート転送を機能させるにはどうすればよいでしょうか?

最初のステップは、URI から IP アドレスを取得することです。 nslookup、ホスト名、または URI に対して ping を実行すると、データベースの IP アドレスを取得できます。 サービスが複数の IP アドレスを返した場合、これらのアドレスはすべてオブジェクトのエンドポイントで使用できます。

注意すべき点の XNUMX つは、IP URI は予告なく変更される可能性があるため、本番環境で使用するのは非常に危険であるということです。 この IP アドレスを使用すると、ポートを指定せずにリモート データベースに接続できます。 したがって、Kubernetes サービスはポート転送を非常に透過的に実行します。

マッピング、または外部リソースを内部リソースにマッピングすると、リファクタリングの労力を最小限に抑えながら、将来的にこれらのサービスをクラスター内で使用できる柔軟性が得られます。 また、会社がどのような外部サービスを使用しているかについての管理と洞察の提供も容易になります。

続きはまたすぐに…

いくつかの広告 🙂

いつもご宿泊いただきありがとうございます。 私たちの記事が気に入っていますか? もっと興味深いコンテンツを見たいですか? 注文したり、友人に勧めたりして私たちをサポートしてください。 開発者向けのクラウド VPS は 4.99 ドルから, 当社があなたのために発明した、エントリーレベルのサーバーのユニークな類似物です。 VPS (KVM) E5-2697 v3 (6 コア) 10GB DDR4 480GB SSD 1Gbps 19 ドルからの真実、またはサーバーを共有する方法? (RAID1 および RAID10、最大 24 コア、最大 40GB DDR4 で利用可能)。

アムステルダムのエクイニクス Tier IV データセンターでは Dell R730xd が 2 倍安い? ここだけ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV 199 ドルから オランダで！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 ドルから! について読む インフラストラクチャー企業を構築する方法730 ペニーで 5 ユーロの価値がある Dell R2650xd E4-9000 vXNUMX サーバーを使用したクラスですか?

出所： habr.com