序章

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

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

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

  • サービスディスカバリ
  • ルーティングとトラフィックの構成
  • 暗号化と認証/承認
  • 指標とモニタリング

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

なぜサービスメッシュなのか？

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

これらのアーキテクチャは、アプリケーションをWeb層、アプリケーション層、およびデータベース層に分割する3層アプリケーションモデルから発展しました。 大規模な場合、このモデルは、急速な成長を遂げている組織にとっては困難であることが証明されています。 モノリシックアプリケーションのコードベースは扱いにくくなる可能性があり「大きな泥だんご」、開発と展開に課題をもたらします。

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

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

  • チームはさまざまなアプリケーション機能に個別に取り組み、展開できるため、開発と展開の俊敏性が向上します。
  • 個々のマイクロサービスを個別にテストおよび再デプロイできるため、CI/CDのオプションが向上します。
  • 言語とツールのその他のオプション。 開発者は、特定の言語やツールセットに制限されることなく、目前のタスクに最適なツールを使用できます。
  • スケーリングが簡単。
  • 稼働時間、ユーザーエクスペリエンス、および安定性の向上。

同時に、マイクロサービスも課題を生み出しました。

  • 分散システムには、遅延、ルーティング、非同期ワークフロー、および障害についてさまざまな考え方が必要です。
  • マイクロサービスのセットアップは、モノリシックセットアップと同じデータ整合性の要件を必ずしも満たすことができません。
  • 配布のレベルが高くなると、特にサービス間の通信に関しては、より複雑な運用設計が必要になります。
  • サービスの配布により、セキュリティの脆弱性の表面積が増加します。

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

サービスディスカバリ

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

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

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

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

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

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

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

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

ルーティングとトラフィックの構成

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

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

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

Istioは、IstioゲートウェイおよびVirtualServicesを使用してKubernetesコントローラー/リソースパターンを反復処理します。 Ingress Controllerと同様に、Gatewayは、使用する公開ポートとプロトコルを指定して、着信トラフィックの処理方法を定義します。 これは、メッシュ内のサービスへのルートを定義するVirtualServiceと連携して機能します。 これらのリソースは両方ともパイロットに情報を伝達し、パイロットはその情報をエンボイプロキシに転送します。 ゲートウェイと仮想サービスは、Ingressコントローラーとリソースに似ていますが、トラフィックに対して異なるレベルの制御を提供します。オープンシステム相互接続（OSI）レイヤーとプロトコルを組み合わせる代わりに、ゲートウェイと仮想サービスを使用すると、OSIを区別できます。設定のレイヤー。 たとえば、VirtualServicesを使用することで、アプリケーション層の仕様を扱うチームは、さまざまな層の仕様を扱うセキュリティ運用チームから関心の分離を行うことができます。 VirtualServicesを使用すると、個別のアプリケーション機能または異なる信頼ドメイン内で作業を分離でき、カナリアテスト、段階的なロールアウト、A/Bテストなどに使用できます。

サービス間の関係を視覚化するには、Istioの Servicegraphアドオンを使用できます。これにより、リアルタイムの交通データを使用してサービス間の関係を動的に表現できます。 Bookinfoアプリケーションは、カスタムルーティングを適用しないと次のようになります。

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

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

暗号化と認証/承認

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

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

  • 認証：KubernetesのAPIリクエストは、認証が必要なユーザーアカウントまたはサービスアカウントに関連付けられています。 必要な資格情報を管理する方法はいくつかあります。静的トークン、ブートストラップトークン、X509クライアント証明書、および OpenIDConnectなどの外部ツールです。
  • 承認：Kubernetesには、役割、属性、その他の特殊な機能などに基づいてアクセスを決定できるさまざまな承認モジュールがあります。 APIサーバーへのすべてのリクエストはデフォルトで拒否されるため、APIリクエストの各部分は承認ポリシーで定義する必要があります。
  • 暗号化：これは、エンドユーザーとサービス間の接続、シークレットデータ、Kubernetesコントロールプレーン内のエンドポイント、ワーカークラスターコンポーネントとマスターコンポーネント間の通信のいずれかを指します。 Kubernetesには、これらのそれぞれに対して異なるソリューションがあります。

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

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

  • Citadel ：キーと証明書を管理します。
  • Pilot ：認証および命名ポリシーを監視し、この情報をEnvoyプロキシと共有します。
  • Mixer ：承認と監査を管理します。

たとえば、サービスを作成すると、Citadelはその情報を kube-apiserver このサービスのSPIFFE証明書とキーを作成します。 次に、この情報をポッドとエンボイのサイドカーに転送して、サービス間の通信を容易にします。

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

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

指標とモニタリング

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

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

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

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

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

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

結論

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

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

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