NetOps 向けコンテナ口語翻訳ツール
コンテナ業界から出てくる専門用語に頭が混乱してしまう日もあります。 サービス メッシュ、オーケストレーター、レジストリなどの関連ソリューションによって提供される新しい機能や特徴ごとに、新しい用語やフレーズが必要になるようです。 このフレーズは DevOps にとっては意味をなすことが多いのですが、NetOps にとっては目を細めて困惑した表情を浮かべることになります。
一番近いバブラーがある場所を私が尋ねたときにあなたがするセリフと似ています。 それを噴水と呼ぶのです。 ウィスコンシン州ではこれをバブラーと呼びます。 同じことですが、用語が異なります。
結局のところ、内部およびマルチクラウド シナリオでのコンテナのスケーリングに関連する多くの「新しい」機能と特徴は、実際には DevOps がバブラーと呼んでいる噴水にすぎないことがわかりました。 コンテナが衰えることなく主流になり続けるにつれて、この口語表現の衝突が NetOps との摩擦を引き起こす可能性があります。 コンテナ クラスターが本番環境で分離されたミニクラウドのような存在を維持している場合でも、NetOps が引き続き支配する企業ネットワークとの接点が依然として存在します。 そして、マルチクラウドの世界でこれらのクラスターを安全に拡張するには、NetOps と DevOps が連携して動作する必要があります。
イングレス コントローラ
- すでに述べたように、「イングレス コントローラ」という用語は、レイヤー 7 の負荷分散 (コンテンツ スイッチング、コンテンツ ルーティングなど) に新たな意味を与えます。 イングレス コントローラーは、コンテナ クラスター内の適切なリソースにリクエストをルーティングするレイヤー 7 (HTTP) 対応プロキシです。 ネットワーク内で NetOps によって使用される HTTP プロキシと、コンテナ クラスターへのエントリ ポイントとして機能する HTTP プロキシとの大きな違いは、イングレス コントローラがコンテナを認識する必要があることです。 「コンテナ対応」とは、コンテナ環境で発生する変更、特にイングレスが受信リクエストをルーティングする方法を記述するリソース ファイルの変更に基づいて、自動的に構成および管理されることを意味します。
レイテンシを考慮した負荷分散
- クールで新鮮に聞こえませんか? しかし、実際にその秘密を解き明かすと、NetOps は、これが実際には「最速の応答」負荷分散アルゴリズムを活用しているに過ぎないことに気づき、力強くうなずくでしょう。 その目的は、「トラフィックを低速インスタンスからシフトする」ことでアプリのパフォーマンスを向上させることです。 これが指摘される理由は、一般的に言えば、コンテナ オーケストレーターが使用するネイティブの負荷分散アルゴリズムが無関心であるためです。 ラウンドロビンはほぼ標準であり、パフォーマンスを最適化しようとしている場合に選択する最後のアルゴリズムであることがわかっています。 単一のクライアント要求を満たすために行われるすべてのマイクロサービス間の呼び出しによって、独自のレイテンシが追加されることを考慮すると、最適なパフォーマンスに基づいて要求をルーティングできることは非常に重要です。
マルチクラスタイングレス
- まず最初に言っておきたいのは、この言葉は業界でここ 20 年近く使われてきた言葉よりもずっとクールに聞こえるということです。 本質的には、これは GSLB (グローバル サーバー負荷分散) です。 はい、がっかりしていることは承知していますが、マルチクラスター Ingress は内部的にはそれを行っています。 イングレス コントローラーを用意し、その周りにグローバル トラフィック管理の優れた機能を散りばめれば、出来上がりです。 マルチクラウド構成のコンテナ クラスター用の GSLB が利用可能になりました。 NetOps 側では、GSLB をこの用語に置き換えることに賛成します。より印象的な響きがあるからです。
これらは、出現する唯一の用語ではなく、また最後の用語でもありません。 これらは、DevOps に組み込まれる「ネットワーク内」の機能と能力の点で最も関連性が高いものです。 これらのうちいくつかは、実稼働環境に移行するときに NetOps の注意が必要になります (Multi-Cluster Ingress など)。その他は必要ありません。コンテナ環境内でのレイテンシを考慮した負荷分散は、DevOps の管轄範囲のままになる可能性がありますが、パフォーマンスや可用性の向上に関する議論の際には理解しておくとよいでしょう。
DevOps には、見落とされたり、完全に無視されたりすることが多い文化的な要素があります。 この動きが NetOps に影響を与え続け、従来のネットワーク運用がゆっくりと、しかし確実にその原則を採用して俊敏なネットワークを実現するにつれて、コミュニケーションが重要になります。 それは共通点を見つけることを意味します。 お互いの専門用語を理解することは、applicationの展開が配信と同様に高速、安全、信頼できることを保証するために必要な、より協力的な文化を構築するための良い第一歩となります。