サービスメッシュの概要

サービスメッシュは、アプリケーションのマイクロサービス間の通信を管理できるインフラストラクチャレイヤーです。 より多くの開発者がマイクロサービスを使用するにつれて、サービスメッシュが進化し、分散セットアップで一般的な管理タスクと管理タスクを統合することにより、その作業がより簡単かつ効果的になりました。

アプリケーションアーキテクチャにマイクロサービスアプローチを採用するには、アプリケーションを疎結合サービスのコレクションに分割する必要があります。 このアプローチには特定の利点があります。チームは、より広範なツールと言語を使用して、設計を反復し、迅速に拡張できます。 一方、マイクロサービスは、運用の複雑さ、データの一貫性、およびセキュリティに関して新たな課題をもたらします。

サービスメッシュは、サービスが相互に通信する方法をきめ細かく制御することにより、これらの課題のいくつかに対処するように設計されています。 具体的には、開発者に以下を管理する方法を提供します。

これらのタスクはKubernetesなどのコンテナオーケストレータを使用してネイティブに実行できますが、このアプローチでは、Istioや％（（t1）sなどのサービスメッシュソリューションと比較して、事前の意思決定と管理が多くなります。 t2）sは箱から出して提供します。 この意味で、サービスメッシュは、マイクロサービスアーキテクチャの一般的なコンポーネントを使用するプロセスを合理化および簡素化できます。 場合によっては、これらのコンポーネントの機能を拡張することもできます。

サービスメッシュは、分散アプリケーションアーキテクチャに固有のいくつかの課題に対処するように設計されています。

これらのアーキテクチャは、アプリケーションをWeb層、アプリケーション層、およびデータベース層に分割する3層アプリケーションモデルから発展しました。 大規模に、このモデルは急速な成長を経験している組織にとって挑戦的であることが証明されています。 モノリシックアプリケーションのコードベースは扱いにくい“big balls of mud”に成長する可能性があり、開発と展開に課題をもたらします。

この問題に対応して、Google、Netflix、Twitterなどの組織は、サービス全体のランタイム操作を標準化するための内部「脂肪クライアント」ライブラリを開発しました。 これらのライブラリは、サービスメッシュ機能の前兆であるロードバランシング、サーキットブレイク、ルーティング、およびテレメトリを提供しました。 ただし、開発者が使用できる言語に制限を課し、サービス自体が更新または変更された場合、サービス全体で変更を必要としました。

マイクロサービス設計により、これらの問題の一部が回避されます。 大規模な一元化されたアプリケーションコードベースを使用する代わりに、アプリケーションの機能を表す個別に管理されたサービスのコレクションがあります。 マイクロサービスアプローチの利点は次のとおりです。

同時に、マイクロサービスには課題もあります。

サービスメッシュは、サービスの通信方法を調整してきめ細かく制御することにより、これらの問題に対処するように設計されています。 以下のセクションでは、サービスメッシュが、サービスの検出、ルーティングと内部負荷分散、トラフィックの構成、暗号化、認証と承認、およびメトリックと監視を通じてサービス間の通信を促進する方法を見ていきます。 サービスメッシュがどのように機能するかを示す具体的な例として、IstioのBookinfo sample application（特定の書籍に関する情報を一緒に表示する4つのマイクロサービス）を使用します。

分散フレームワークでは、サービスに接続する方法と、サービスが利用可能かどうかを知る必要があります。 サービスインスタンスの場所はネットワーク上で動的に割り当てられ、コンテナに関する情報は絶えず変化します。コンテナは自動スケーリング、アップグレード、および障害によって作成および破棄されます。

歴史的に、マイクロサービスフレームワークでサービスを検出するためのツールがいくつかありました。 etcdのようなKey-Valueストアは、Registratorのような他のツールと組み合わせて、サービス検出ソリューションを提供しました。 Consulのようなツールは、キー値ストアをDNSインターフェイスと組み合わせて、ユーザーがDNSサーバーまたはノードを直接操作できるようにすることでこれを繰り返しました。

同様のアプローチで、KubernetesはデフォルトでDNSベースのサービス検出を提供します。 これを使用すると、サービスとサービスポートを検索し、一般的なDNS命名規則を使用して逆IPルックアップを実行できます。 一般に、KubernetesサービスのAレコードは次のパターンに一致します：service.namespace.svc.cluster.local。 Bookinfoアプリケーションのコンテキストでこれがどのように機能するかを見てみましょう。 たとえば、Bookinfoアプリのdetailsサービスに関する情報が必要な場合は、Kubernetesダッシュボードの関連するエントリを確認できます。

これにより、サービス名、名前空間、およびClusterIPに関する関連情報が提供されます。これらの情報を使用して、個々のコンテナーが破棄されて再作成された場合でも、サービスに接続できます。

Istioのようなサービスメッシュは、サービス検出機能も提供します。 サービス検出を行うために、Istioは、トラフィック管理コンポーネントPilotによって管理されるIstio独自のコントロールプレーンであるKubernetes APIと、Envoyサイドカープロキシによって管理されるそのデータプレーンとの間の通信に依存しています。 パイロットはKubernetes APIサーバーからのデータを解釈して、ポッドの場所の変更を登録します。 次に、そのデータを標準的なIstio表現に変換し、サイドカープロキシに転送します。

これは、Istioでのサービス検出がプラットフォームに依存しないことを意味します。これは、IstioのGrafana add-onを使用して、Istioのサービスダッシュボードでdetailsサービスを再度確認することで確認できます。

アプリケーションはKubernetesクラスターで実行されているため、detailsサービスに関連するDNS情報とその他のパフォーマンスデータをもう一度確認できます。

分散アーキテクチャでは、サービスに関する最新の、正確で、見つけやすい情報を保持することが重要です。 KubernetesとIstioのようなサービスメッシュの両方は、DNS規則を使用してこの情報を取得する方法を提供します。

分散フレームワークでトラフィックを管理することは、クラスターへのトラフィックの到達方法とサービスへの誘導方法を制御することを意味します。 外部および内部トラフィックを構成する際の制御と特異性が高いほど、セットアップでより多くのことができるようになります。 たとえば、カナリアデプロイメントで作業している場合、アプリケーションを新しいバージョンに移行する場合、またはフォールトインジェクションを使用して特定のサービスのストレステストを行う場合、サービスが取得するトラフィックの量と送信元を決定することが重要ですあなたの目的の成功。

Kubernetesは、開発者がクラスタへの外部トラフィックを制御できるようにするさまざまなツール、オブジェクト、およびサービスを提供します：kubectl proxy、NodePort、Load Balancers、およびIngress Controllers and Resources。 kubectl proxyとNodePortはどちらも、サービスを外部トラフィックにすばやく公開できます。kubectl proxyは、HTTPパスを使用して静的コンテンツにアクセスできるプロキシサーバーを作成し、NodePortは公開します。各ノードにランダムに割り当てられたポート。 これにより迅速なアクセスが可能になりますが、kubectl proxyの場合は認証済みユーザーとしてkubectlを実行する必要があり、NodePortの場合はポートとノードIPの柔軟性が不足するという欠点があります。 s。 また、ロードバランサーは特定のサービスにアタッチすることで柔軟性を最適化しますが、各サービスには独自のロードバランサーが必要であり、コストがかかる可能性があります。

IngressリソースとIngress Controllerを組み合わせることで、これらの他のオプションよりも高い柔軟性と設定可能性が得られます。 入力コントローラを入力リソースとともに使用すると、外部トラフィックをサービスにルーティングし、内部ルーティングと負荷分散を構成できます。 Ingressリソースを使用するには、サービス、IngressコントローラーとLoadBalancer、およびサービスへの目的のルートを指定するIngressリソース自体を構成する必要があります。 現在、Kubernetesは独自のNginx Controllerをサポートしていますが、Nginx、Kongなどによって管理される他のオプションも選択できます。

Istioは、Istio GatewaysとVirtualServicesを使用してKubernetesコントローラー/リソースパターンを反復処理します。 入口コントローラーと同様に、ゲートウェイは、使用する公開ポートとプロトコルを指定して、着信トラフィックの処理方法を定義します。 これは、メッシュ内のサービスへのルートを定義するVirtualServiceと連携して機能します。 これらのリソースは両方とも情報をPilotに伝達し、Pilotはその情報をEnvoyプロキシに転送します。 ゲートウェイとVirtualServicesは、Ingress Controllers and Resourcesに似ていますが、トラフィックに対して異なるレベルの制御を提供します。ゲートウェイとVirtualServicesを使用すると、Open Systems Interconnection (OSI) layers and protocolsを組み合わせる代わりに、設定でOSIレイヤーを区別できます。 たとえば、VirtualServicesを使用することで、アプリケーション層の仕様を扱うチームは、さまざまな層の仕様を扱うセキュリティ運用チームから懸念事項を分離できます。 VirtualServicesは、個別のアプリケーション機能または異なる信頼ドメイン内で作業を分離することを可能にし、カナリアテスト、段階的なロールアウト、A / Bテストなどの用途に使用できます。

サービス間の関係を視覚化するには、IstioのServicegraph add-onを使用できます。これにより、リアルタイムのトラフィックデータを使用してサービス間の関係を動的に表現できます。 Bookinfoアプリケーションは、カスタムルーティングが適用されていない場合、次のようになります。

同様に、Weave Scopeなどの視覚化ツールを使用して、特定の時点でのサービス間の関係を確認できます。 高度なルーティングのないBookinfoアプリケーションは次のようになります。

分散フレームワークでアプリケーショントラフィックを構成する場合、KubernetesネイティブオプションからIstioなどのサービスメッシュまで、さまざまなソリューションがあり、外部トラフィックがアプリケーションリソースに到達する方法と、これらのリソースがどのように通信するかを決定するためのさまざまなオプションを提供します別の。

分散フレームワークは、セキュリティの脆弱性の機会を提供します。 モノリシックセットアップの場合のように、ローカル内部コールを介して通信する代わりに、マイクロサービスアーキテクチャのサービスは、ネットワークを介して特権情報を含む情報を通信します。 全体として、これは攻撃のためのより大きな表面積を作成します。

Kubernetesクラスターを保護するには、さまざまな手順が必要です。認証、承認、暗号化に焦点を当てます。 Kubernetesは、これらのそれぞれに対してネイティブアプローチを提供します。

Kubernetesで個別のセキュリティポリシーとプロトコルを構成するには、管理投資が必要です。 Istioのようなサービスメッシュは、これらのアクティビティの一部を統合できます。

Istioは、サービスを保護する作業の一部を自動化するように設計されています。 そのコントロールプレーンには、セキュリティを処理するいくつかのコンポーネントが含まれています。

たとえば、サービスを作成すると、Citadelはその情報をkube-apiserverから受信し、このサービスのSPIFFE証明書とキーを作成します。 次に、この情報をPodsおよびEnvoyサイドカーに転送して、サービス間の通信を促進します。

Istioのインストール中にenabling mutual TLSでいくつかのセキュリティ機能を実装することもできます。 これには、クラスター間およびクラスター間の通信、サービス間およびユーザー間の安全な通信のための強力なサービスID、およびキーと証明書の作成、配布、ローテーションを自動化できるキー管理システムが含まれます。

Kubernetesが認証、承認、暗号化を処理する方法を繰り返すことにより、Istioのようなサービスメッシュは、安全なKubernetesクラスターを実行するための推奨ベストプラクティスの一部を統合および拡張できます。

分散環境により、メトリックと監視の要件が変更されました。 監視ツールは、サービスとネットワークアドレスへの頻繁な変更に対応し、包括的で、サービス間でやり取りされる情報の量と種類を考慮して、適応性が必要です。

Kubernetesには、デフォルトでいくつかの内部監視ツールが含まれています。 これらのリソースはそのresource metrics pipelineに属し、クラスターが期待どおりに実行されることを保証します。 cAdvisorコンポーネントは、個々のコンテナとノードからネットワーク使用量、メモリ、およびCPU統計を収集し、その情報をkubeletに渡します。 kubeletは、RESTAPIを介してその情報を公開します。 Metrics Serverは、APIからこの情報を取得し、それをkube-aggregatorに渡してフォーマットします。

これらの内部ツールと監視機能を完全なメトリックソリューションで拡張できます。 Prometheusなどのサービスをメトリクスアグリゲーターとして使用すると、Kubernetesリソースメトリクスパイプラインの上に直接構築できます。 Prometheusは、ノード上にある独自のエージェントを介してcAdvisorと直接統合します。 メインの集約サービスは、ノードからデータを収集して保存し、ダッシュボードとAPIを通じて公開します。 メインの集約サービスをバックエンドストレージ、ロギング、およびInfluxDB、Grafana、ElasticSearch、Logstashなどの視覚化ツールと統合することを選択した場合は、追加のストレージおよび視覚化オプションも利用できます。 、Kibana、その他。

Istioのようなサービスメッシュでは、完全なメトリックパイプラインの構造はメッシュの設計の一部です。 ポッドレベルで動作するエンボイサイドカーは、ポリシーとテレメトリを管理するMixerにメトリックを伝達します。 さらに、PrometheusおよびGrafanaサービスはデフォルトで有効になっています（ただし、Helmを使用してIstioをインストールする場合は、インストール中にspecify granafa.enabled=trueにする必要があります）。 完全なメトリックパイプラインの場合と同様に、ログと表示のオプションにconfigure other services and deploymentsを使用することもできます。

これらのメトリックツールと視覚化ツールを使用すると、サービスとワークロードに関する現在の情報に一元的にアクセスできます。 たとえば、BookInfoアプリケーションのグローバルビューは、Istio Grafanaダッシュボードでは次のようになります。

Kubernetesの完全なメトリックパイプラインの構造を複製し、その一般的なコンポーネントへのアクセスを簡素化することにより、Istioのようなサービスメッシュは、クラスターで作業する際のデータ収集と視覚化のプロセスを合理化します。

マイクロサービスアーキテクチャは、アプリケーションの開発と展開を高速で信頼性の高いものにするように設計されています。 しかし、サービス間通信の増加により、特定の管理タスクのベストプラクティスが変わりました。 この記事では、これらのタスクの一部、Kubernetesネイティブコンテキストでの処理方法、サービスメッシュ（この場合はIstio）を使用した管理方法について説明します。

ここで取り上げるKubernetesのトピックの詳細については、次のリソースを参照してください。

さらに、KubernetesおよびIstioドキュメントハブは、ここで説明するトピックに関する詳細情報を見つけるのに最適な場所です。