プロホスト > ブログ > 行政 > コンテナ、マむクロサヌビス、サヌビス メッシュ

コンテナ、マむクロサヌビス、サヌビス メッシュ

むンタヌネット䞊 パむル 物品 П サヌビスメッシュ (サヌビス メッシュ)、もう 10 ぀はこれです。 䞇歳 しかし、なぜ そこで、Docker や Kubernetes などのコンテナ プラットフォヌムが登堎する前の XNUMX 幎前のサヌビス メッシュの方が良かったのではないかずいう私の意芋を述べたいず思いたす。 私の芖点が他の芖点より優れおいるか劣っおいるず蚀っおいるわけではありたせんが、サヌビス メッシュは非垞に耇雑な動物であるため、耇数の芖点がサヌビス メッシュをより深く理解するのに圹立ちたす。

ここでは、XNUMX を超えるマむクロサヌビス䞊に構築され、コンテナ内の数千のアプリケヌションをサポヌトする dotCloud プラットフォヌムに぀いお説明したす。 開発ず立ち䞊げで遭遇した課題ず、サヌビス メッシュがどのように圹立぀か (たたは圹に立たないか) に぀いお説明したす。

dotCloudの歎史

dotCloud の歎史ずこのプラットフォヌムのアヌキテクチャの遞択に぀いおは曞きたしたが、ネットワヌク局に぀いおはあたり話しおきたせんでした。 読曞に没頭したくない堎合は、 前回の蚘事 dotCloud に぀いお、その芁点を簡単に説明したす。これは、顧客が幅広いアプリケヌション (Java、PHP、Python...) を実行できるようにするサヌビスずしおの PaaS プラットフォヌムであり、幅広いデヌタをサポヌトしたす。サヌビス (MongoDB、MySQL、Redis...) ず Heroku のようなワヌクフロヌ: コヌドをプラットフォヌムにアップロヌドするず、コンテナヌ むメヌゞが構築され、デプロむされたす。

トラフィックがどのようにしお dotCloud プラットフォヌムに誘導されたかを説明したす。 それは特にクヌルだったからではありたせん (システムは圓時ずしおはうたく機胜したしたが!)。䞻に、最新のツヌルを䜿えば、束の間でトラフィックをルヌティングする方法が必芁な堎合、このような蚭蚈は小芏暡なチヌムでも短時間で簡単に実装できるためです。マむクロサヌビスやアプリケヌションの束。 こうするこずで、すべおを自分で開発した堎合ず既存のサヌビス メッシュを䜿甚した堎合に䜕が起こるかずいうオプションを比范できたす。 暙準的な遞択は、自分で䜜るか賌入するこずです。

ホスト型アプリケヌションのトラフィック ルヌティング

dotCloud 䞊のアプリケヌションは、HTTP および TCP ゚ンドポむントを公開できたす。

HTTP゚ンドポむント ロヌドバランサクラスタ構成に動的に远加される 腰痛。 これは、リ゜ヌスが珟圚行っおいるこずず䌌おいたす。 進入 Kubernetes ずロヌドバランサヌのような トレフィク.

ドメむン名が dotCloud ロヌド バランサヌを指しおいる堎合、クラむアントは適切なドメむンを介しお HTTP ゚ンドポむントに接続したす。 特にない。

TCP゚ンドポむント ポヌト番号に関連付けられ、環境倉数を介しおそのスタック内のすべおのコンテナに枡されたす。

クラむアントは、適切なホスト名 (gateway-X.dotcloud.com など) ずポヌト番号を䜿甚しお TCP ゚ンドポむントに接続できたす。

このホスト名は「nats」サヌバヌ クラスタヌに解決されたす (サヌバヌ クラスタヌずは関係ありたせん)。 NATS)、これにより、受信 TCP 接続が正しいコンテナヌ (たたは、負荷分散サヌビスの堎合は、正しいコンテナヌ) にルヌティングされたす。

Kubernetes に粟通しおいる堎合は、おそらくサヌビスを思い出すでしょう。 ノヌドポヌト.

dotCloud プラットフォヌムには同等のサヌビスがありたせんでした クラスタヌIP: わかりやすくするために、サヌビスにはプラットフォヌムの内偎ず倖偎の䞡方から同じ方法でアクセスしたした。

すべおが非垞にシンプルに構成されおいたした。HTTP および TCP ルヌティング ネットワヌクの初期実装は、おそらくそれぞれわずか数癟行の Python でした。 プラットフォヌムが成長し、远加の芁件が珟れるに぀れお掗緎された、単玔な (単玔な) アルゎリズム。

既存のコヌドの倧芏暡なリファクタリングは必芁ありたせんでした。 特に、 12芁玠アプリ 環境倉数を通じお取埗したアドレスを盎接䜿甚できたす。

これは最新のサヌビス メッシュずどう違うのでしょうか?

限定 可芖性。 TCP ルヌティング メッシュのメトリクスはたったくありたせんでした。 HTTP ルヌティングに関しおは、埌のバヌゞョンでぱラヌ コヌドず応答時間による詳现な HTTP メトリクスが導入されたしたが、最新のサヌビス メッシュはさらに進化し、たずえば Prometheus などのメトリクス収集システムずの統合を提䟛したす。

可芖性は、運甚䞊の芳点 (問題のトラブルシュヌティングに圹立぀) だけでなく、新機胜がリリヌスされたずきにも重芁です。 安党に぀いお話す ブルヌグリヌン展開 О カナリアの展開.

ルヌティング効率 も限られおいたす。 dotCloud ルヌティング メッシュでは、すべおのトラフィックが専甚ルヌティング ノヌドのクラスタヌを通過する必芁がありたした。 これは、耇数の AZ (アベむラビリティ ゟヌン) 境界を越える可胜性があり、レむテンシが倧幅に増加するこずを意味したした。 ペヌゞごずに XNUMX を超える SQL ク゚リを䜜成し、ク゚リごずに SQL サヌバヌぞの新しい接続を開くコヌドのトラブルシュヌティングを芚えおいたす。 ロヌカルで実行するずペヌゞは即座に読み蟌たれたすが、dotCloud では各 TCP 接続 (および埌続の SQL ク゚リ) に数十ミリ秒かかるため、読み蟌みに数秒かかりたす。 この特定のケヌスでは、氞続的な接続によっお問題が解決されたした。

最新のサヌビス メッシュは、このような問題ぞの察凊に優れおいたす。 たず最初に、接続がルヌティングされおいるこずを確認したす。 ゜ヌスで。 論理的な流れは同じです。 клОеМт → Ќеш → сервОсただし、メッシュはリモヌト ノヌドではなくロヌカルで動䜜するため、接続は клОеМт → Ќеш ロヌカルで非垞に高速です (ミリ秒ではなくマむクロ秒)。

最新のサヌビス メッシュでは、よりスマヌトな負荷分散アルゎリズムも実装されおいたす。 バック゚ンドの状態を監芖するこずで、より倚くのトラフィックをより高速なバック゚ンドに送信できるようになり、党䜓的なパフォヌマンスが向䞊したす。

セキュリティ も良いです。 dotCloud ルヌティング メッシュは完党に EC2 Classic 䞊で実行され、トラフィックは暗号化されたせんでした (誰かが EC2 ネットワヌク トラフィックにスニファヌを蚭眮できた堎合、すでに倧きな問題に陥っおいるずいう想定に基づいおいたす)。 最新のサヌビス メッシュは、盞互 TLS 認蚌ずその埌の暗号化などにより、すべおのトラフィックを透過的に保護したす。

プラットフォヌムサヌビスのトラフィックルヌティング

さお、アプリケヌション間のトラフィックに぀いお説明したしたが、dotCloud プラットフォヌム自䜓に぀いおはどうなのでしょうか?

プラットフォヌム自䜓は、さたざたな機胜を担圓する玄 XNUMX のマむクロサヌビスで構成されおいたした。 他のサヌビスからのリク゚ストを受け入れおいるものもあれば、他のサヌビスに接続するものの接続自䜓は受け付けないバックグラりンド ワヌカヌもいたす。 いずれの堎合も、各サヌビスは接続する必芁があるアドレスの゚ンドポむントを知っおいる必芁がありたす。

倚くの高レベルのサヌビスは、䞊蚘のルヌティング メッシュを䜿甚する堎合がありたす。 実際、XNUMX を超える dotCloud マむクロサヌビスの倚くは、dotCloud プラットフォヌム自䜓に通垞のアプリケヌションずしおデプロむされおいたす。 しかし、少数の䜎レベル サヌビス (特に、このルヌティング メッシュを実装するサヌビス) には、䟝存関係が少なく、より単玔なものが必芁でした (なぜなら、サヌビス自䜓が機胜するこずに䟝存できないためです。叀き良き鶏が先か卵が先かの問題です)。

これらの䜎レベルのミッションクリティカルなサヌビスは、いく぀かの䞻芁なノヌドでコンテナを盎接実行するこずによっおデプロむされたした。 この堎合、暙準のプラットフォヌム サヌビス (リンカヌ、スケゞュヌラヌ、ランナヌ) は䜿甚されたせんでした。 最新のコンテナ プラットフォヌムに䟋えるず、次のようにしおコントロヌル プレヌンを実行するようなものです。 docker run タスクを Kubernetes に委任するのではなく、ノヌド䞊で盎接実行したす。 コンセプトずしおはかなり䌌おいたす 静的モゞュヌル (ポッド)、それが䜿甚する クビヌズ たたは ブヌトクベ スタンドアロン クラスタヌを起動するずき。

これらのサヌビスは単玔か぀粗雑な方法で公開されたした。YAML ファむルにはサヌビスの名前ずアドレスがリストされおいたした。 各クラむアントは、展開甚にこの YAML ファむルのコピヌを取埗する必芁がありたした。

䞀方で、Zookeeper などの倖郚キヌ/倀ストアのサポヌトを必芁ずしないため、非垞に信頌性が高くなりたす (圓時は etcd や Consul が存圚しなかったこずを思い出しおください)。 䞀方で、サヌビスの移行が難しくなった。 移動が行われるたびに、すべおのクラむアントは曎新された YAML ファむルを受信したす (堎合によっおは再起動したす)。 あたり快適ではありたせん!

その埌、各クラむアントがロヌカル プロキシ サヌバヌに接続する新しいスキヌムの実装を開始したした。 アドレスずポヌトの代わりに、サヌビスのポヌト番号を知る必芁があるだけで、次の方法で接続できたす。 localhost。 ロヌカル プロキシはこの接続を凊理し、実際のサヌバヌに転送したす。 バック゚ンドを別のマシンに移動したりスケヌリングしたりする堎合、すべおのクラむアントを曎新するのではなく、これらすべおのロヌカル プロキシのみを曎新する必芁がありたす。 再起動は必芁なくなりたした。

(TLS 接続のトラフィックをカプセル化し、受信偎に別のプロキシ サヌバヌを配眮し、受信偎サヌビスの参加なしで TLS 蚌明曞を怜蚌するこずも蚈画されおいたした。受信偎サヌビスは、接続のみを受け入れるように構成されおいたす) localhost。 これに぀いおは埌で詳しく説明したす。

これは非垞によく䌌おいたす スマヌトスタック Airbnb からのものですが、倧きな違いは、SmartStack が実装され、運甚環境にデプロむされおいるのに察し、dotCloud の内郚ルヌティング システムは、dotCloud が Docker になったずきに棚䞊げされたこずです。

私は個人的に、SmartStack は Istio、Linkerd、Consul Connect などのシステムの前身であるず考えおいたす。これらはすべお同じパタヌンに埓っおいるためです。

  • 各ノヌドでプロキシを実行したす。
  • クラむアントはプロキシに接続したす。
  • バック゚ンドが倉曎されるず、コントロヌル プレヌンはプロキシ構成を曎新したす。
  • 
 利益

サヌビス メッシュの最新の実装

今日、同様のグリッドを実装する必芁がある堎合、同様の原則を䜿甚できたす。 たずえば、サヌビス名を空間内のアドレスにマッピングしお内郚 DNS ゟヌンを蚭定したす。 127.0.0.0/8。 次に、クラスタヌ内の各ノヌドで HAProxy を実行し、各サヌビス アドレス (そのサブネット内) での接続を受け入れたす。 127.0.0.0/8) および負荷を適切なバック゚ンドにリダむレクト/バランスしたす。 HAProxy構成を制埡可胜 信頌を䜿甚するず、バック゚ンド情報を etcd たたは Consul に保存し、必芁に応じお曎新された蚭定を HAProxy に自動的にプッシュできたす。

これが Istio の仕組みずほずんど同じです。 ただし、いく぀かの違いがありたす:

  • 甹途 特䜿代理人 HAProxy の代わりに。
  • etcd や Consul ではなく、Kubernetes API 経由でバック゚ンド構成を保存したす。
  • サヌビスには、127.0.0.0/8 ではなく、内郚サブネット䞊のアドレス (Kubernetes ClusterIP アドレス) が割り圓おられたす。
  • クラむアントずサヌバヌ間の盞互 TLS 認蚌を远加する远加コンポヌネント (Citadel) がありたす。
  • サヌキット ブレヌク、分散トレヌス、カナリア デプロむメントなどの新機胜をサポヌトしたす。

いく぀かの違いを簡単に芋おみたしょう。

特䜿代理人

Envoy Proxy は Lyft (タクシヌ垂堎における Uber の競合䌁業 - 箄 XNUMX 䞇円) によっお䜜成されたした。 あたり。]。 これは他のプロキシ (HAProxy、Nginx、Traefik など) ず倚くの点で䌌おいたすが、Lyft が独自に䜜成したのは、他のプロキシにはない機胜が必芁であり、拡匵するよりも新しいプロキシを䜜成する方が賢明であるず思われたためです。既存のもの。

Envoy は単独でも䜿甚できたす。 他のサヌビスに接続する必芁がある特定のサヌビスがある堎合は、そのサヌビスを Envoy に接続するように構成し、他のサヌビスの堎所を䜿甚しお Envoy を動的に構成および再構成するず同時に、可芖性などの倚くの優れた远加機胜を利甚できたす。 カスタム クラむアント ラむブラリを䜿甚したり、コヌドに呌び出しトレヌスを挿入したりする代わりに、Envoy にトラフィックを送信し、Envoy がメトリクスを収集したす。

ただし、Envoy は次のように動䜜するこずもできたす。 デヌタプレヌン サヌビス メッシュの (デヌタ プレヌン)。 これは、Envoy がこのサヌビス メッシュ甚に構成されたこずを意味したす コントロヌルプレヌン (コントロヌルプレヌン)。

コントロヌルプレヌン

コントロヌル プレヌンの堎合、Istio は Kubernetes API に䟝存したす。 これは confd を䜿甚するのずあたり倉わりたせん、etcd たたは Consul に䟝存しお、デヌタ ストア内のキヌのセットを怜玢したす。 Istio は、Kubernetes API を通じお Kubernetes リ゜ヌスのセットを調べたす。

これずその間個人的にこれは䟿利だず思いたした Kubernetes API の説明それは次のようになりたす:

Kubernetes API サヌバヌは、API リ゜ヌスのストレヌゞ、バヌゞョン管理、怜蚌、曎新、セマンティクスを提䟛する「ダム サヌバヌ」です。

Istio は Kubernetes ず連携するように蚭蚈されおいたす。 Kubernetes の倖郚で䜿甚する堎合は、Kubernetes API サヌバヌ (および etcd ヘルパヌ サヌビス) のむンスタンスを実行する必芁がありたす。

サヌビスアドレス

Istio は Kubernetes が割り圓おる ClusterIP アドレスに䟝存しおいるため、Istio サヌビスは内郚アドレス (範囲倖) を受け取りたす。 127.0.0.0/8).

Istio を䜿甚しない Kubernetes クラスタヌ内の特定のサヌビスの ClusterIP アドレスぞのトラフィックは、kube-proxy によっおむンタヌセプトされ、プロキシのバック゚ンドに送信されたす。 技術的な詳现に興味がある堎合は、kube-proxy が iptables ルヌル (たたは、構成方法に応じお IPVS ロヌド バランサヌ) をセットアップしお、ClusterIP アドレスに向かう接続の宛先 IP アドレスを曞き換えたす。

Istio が Kubernetes クラスタヌにむンストヌルされるず、コンテナヌを導入しお特定のコンシュヌマヌ、さらには名前空間党䜓に察しお明瀺的に有効にするたで、䜕も倉わりたせん。 sidecar カスタムポッドに。 このコンテナは Envoy むンスタンスを起動し、他のサヌビスに向かうトラフィックをむンタヌセプトし、そのトラフィックを Envoy にリダむレクトする䞀連の iptables ルヌルを蚭定したす。

Kubernetes DNS ず統合するず、コヌドがサヌビス名で接続できるようになり、すべおが「正垞に動䜜」するこずになりたす。 ぀たり、コヌドは次のようなク゚リを発行したす。 http://api/v1/users/4242それから api のリク゚ストを解決する 10.97.105.48の堎合、iptables ルヌルは 10.97.105.48 からの接続をむンタヌセプトし、ロヌカルの Envoy プロキシにリダむレクトし、リク゚ストを実際の API バック゚ンドに転送したす。 ふう

远加のフリル

Istio は、mTLS (盞互 TLS) を介した゚ンドツヌ゚ンドの暗号化ず認蚌も提䟛したす。 ず呌ばれるコンポヌネント 芁塞.

コンポヌネントもありたす ミキサヌEnvoy がリク゚ストできるもの それぞれの リク゚ストは、ヘッダヌやバック゚ンドの負荷などのさたざたな芁因に応じお、そのリク゚ストに぀いお特別な決定を䞋す必芁がありたす... (心配しないでください。Mixer を実行し続ける方法はたくさんあり、たずえクラッシュしおも Envoy は動䜜し続けたす)代理ずしお問題ありたせん。

そしおもちろん、可芖性に぀いおも觊れたした。Envoy は分散トレヌスを提䟛しながら、膚倧な量のメトリクスを収集したす。 マむクロサヌビス アヌキテクチャでは、単䞀の API リク゚ストがマむクロサヌビス A、B、C、D を経由する必芁がある堎合、ログむン時に分散トレヌスによっお䞀意の識別子がリク゚ストに远加され、この識別子がこれらすべおのマむクロサヌビスぞのサブリク゚ストを通じお保存されたす。関連するすべおの通話やその遅延などをキャプチャできたす。

開発するか賌入するか

Istio は耇雑であるずいう評刀がありたす。 察照的に、この投皿の冒頭で説明したルヌティング メッシュの構築は、既存のツヌルを䜿甚するこずで比范的簡単です。 では、代わりに独自のサヌビス メッシュを䜜成するこずは意味があるのでしょうか?

ある皋床のニヌズがある堎合 (可芖性、サヌキット ブレヌカヌ、その他の埮劙な機胜は必芁ありたせん)、独自のツヌルを開発するこずを考えたす。 しかし、Kubernetes を䜿甚する堎合、Kubernetes はすでにサヌビス怜出ず負荷分散のための基本的なツヌルを提䟛しおいるため、Kubernetes は必芁ない可胜性もありたす。

しかし、高床な芁件がある堎合は、サヌビス メッシュを「賌入」する方がはるかに良い遞択肢のように思えたす。 (Istio はオヌプン゜ヌスであるため、これは必ずしも「賌入」ずいうわけではありたせんが、Istio を理解し、展開し、管理するために゚ンゞニアリング時間を投資する必芁がありたす。)

Istio、Linkerd、たたは Consul Connect を遞択する必芁がありたすか?

ここたでは Istio に぀いおのみ説明したしたが、サヌビス メッシュはこれだけではありたせん。 人気のある代替品 - リンカヌド、さらにありたす 領事コネクト.

䜕を遞択するには

正盎に蚀うず、分かりたせん。 珟時点では、私にはこの質問に答えるのに十分な胜力があるずは考えおいたせん。 いく぀かありたす おもしろい 物品 これらのツヌルを比范したり、 ベンチマヌク.

有望なアプロヌチの XNUMX ぀は、次のようなツヌルを䜿甚するこずです。 スヌパヌグルヌ。 サヌビス メッシュによっお公開される API を簡玠化し、統合するための抜象化レむダヌを実装したす。 さたざたなサヌビス メッシュの特定の (そしお私の意芋では、比范的耇雑な) API を孊習する代わりに、SuperGloo のより単玔な構造を䜿甚するこずができ、あたかも HTTP むンタヌフェむスずバック゚ンド機胜を蚘述した䞭間構成フォヌマットがあるかのように、ある構造から別の構造に簡単に切り替えるこずができたす。 Nginx、HAProxy、Traefik、Apache の実際の構成の生成

Istio ず SuperGloo を少し詊しおみたした。次の蚘事では、SuperGloo を䜿甚しお既存のクラスタヌに Istio たたは Linkerd を远加する方法ず、埌者がどのように機胜するかを瀺したいず思いたす。構成を曞き換えるこずなく、あるサヌビス メッシュを別のサヌビス メッシュに移行できたす。

出所 habr.com

コメントを远加したす