OpenShift Service Mesh – セットアップとサービス間のトラフィックの可視化

こんにちは。サイオステクノロジーの塙です。

前回の続きとなるRed Hat OpenShift Service Mesh（以下、OSM）のセットアップ方法とサービス間のトラフィックの可視化までを行いたいと思います。

本書では、OCPのインストール方法まで前提としており割愛しています。

■前回の記事はこちら

OpenShift Service Mesh とは？ – アーキテクチャのご紹介

サービス間トラフィックについて

マイクロサービス化を進めていくと、小さな機能単位で個別化されたアプリケーションが増えていきます。それら一つ一つがコンテナやKubernetesでいうPod単位でデプロイしていったりします。

（以下、登場するPodやコンテナではアプリケーションが個別化されて実装されているという要素を含みます）

以前のレガシーシステムと比較すると、Pod間（アプリケーション間）ではトラフィック量も増え、よりシステムの関係性が複雑になっていきます。

通信に関するトラブルシュートも以前より複雑になってくるでしょう。システム全体でどの部分がボトルネックになっているのか運用者にとって判別することは困難になっていきます。

ここで、Pod間にどのようなトラフィックが流れているのか分かる事は、システム運用の観点でとても便利に働いてくれ、運用の手間が軽減されます。

OSMでは、分散トレーシングツールが内包されているため、その点では安心して活用出来ます。

それでは実際にセットアップから試していきたいと思います。

Service Meshのセットアップ

OSMをセットアップするには、OCPが構成されていないといけません。

別途OCPインストールについては参考として以下にドキュメントを載せておきます。ご利用の環境に応じてインストールを行って下さい。

本書記載にあたっては、IPIでAWS上にOCPv4.11 クラスターを事前に構築しています。

https://docs.openshift.com/container-platform/4.12/installing/index.html

OSMはGUI, CLI, および Kubernetes Operator を使用してインストールされます。

順番としては、Operatorのインストール -> ControlPlaneのデプロイ -> ServiceMesh MemberRollの作成

という流れになります。

Operatorは前回の記事に記載のある構成要素も参考に、以下が必要となります。

• • Elasticsearch

• Jaeger (Red Hat OpenShift distributed tracing platform)
• Kiali
• OpenShift ServiceMesh

■ Operatorのインストール

クラスター管理者権限のあるユーザーでWebコンソールにログインし、

左タブにあるOperator -> OperatorHubをクリックします。

検索欄でelasticsearchと入力し、「OpenShift Elasticsearch」を選択します。

Operatorにはそれぞれ提供元がありますが、今回はRH認定のOperatorを使用します。

Operatorの詳細が表示されるので、インストールをクリックします。

バージョンやデプロイ先のnamespaceなどを選択しますが、今回はデフォルトのままインストールをクリックします。インストールが完了するまで待機します。

インストールが完了すると、左タブのインストール済みのOperator から詳細が確認できます。

提供されるAPIや現在の状態などが確認出来るようになります。

Jaeger Operatorも同じようにインストールまで完了します。

再度OperatorHubに戻り、検索欄でjaegerと入力し、「Red Hat OpenShift distributed tracing platform」を選択します。RH認定のものはコミュニティ版と名前が変わっています..

kiali Operatorも同じようにインストールまで完了します。

OpenShift ServiceMeshも同じようにインストールまで完了します。

■ ControlPlaneのデプロイ -> ServiceMesh MemberRollの作成

Developユーザーとしてログインし、プロジェクトを作成します。名前は istio-system として作成します。

左タブから、インストール済みのOperatorでRed Hat OpenShift Service Meshを選択します。プロジェクトで istio-system であることを確認します。

Istio Service Mesh Control Plane タブをクリックします。次に、Create ServiceMeshControlPlane をクリックします。

ControlPlane をデフォルトのオプションで作成します。

先ほどの画面に戻り、Istio Service Mesh Member Roll タブをクリックします。次に、Create ServiceMeshMemberRoll をクリックします。

設定方法で、YAMLビューを選択します。デフォルトでは、`spec.members` にサンプルが定義されているので、それを削除します。

ControlPlane が正常に作成されているか確認します。

アドオンやステータスが確認出来ます。

トラフィックの可視化

ここまでOSMのセットアップが出来たら、実際にアプリケーションをデプロイしてトラフィックを見ていきます。

■ 事前準備

Developユーザーとしてログインします。ユーザーは事前に作成しています。

$ oc login -u testuser -p xxx

$ oc new-project tracing

tracing プロジェクトを、ServiceMeshMemberRoll 内のメンバーに追加します。

$ oc patch servicemeshmemberroll/default -n istio-system --type=merge -p '{"spec": {"members": ["tracing"]}}'

■ アプリケーションのデプロイ

２種類のアプリケーションserviea, servicebとingress gateway, virtual serviceをデプロイします。

$ oc create -f serviea.yaml
---
kind: Deployment
..(snip)..
spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: "true"
..(snip)..

$ oc create -f servieb.yaml
$ oc create -f gateway.yaml
---
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: observe-jaeger-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
    number: 80
    name: http
    protocol: HTTP
    hosts:
    - "*"

$ oc create -f virtual-service.yaml
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: observe-jaeger-vs
spec:
  hosts:
  - "*"
  gateways:
  - observe-jaeger-gateway
  http:
  - match:
    - uri:
        exact: /trace
    rewrite:
      uri: /
    route:
    - destination:
       host: servicea
       port:
       number: 8080

• アプリケーション
  • 構成は、servicea -> serviceb のフローとしています。
  • トレースの設定、jaeger関連の環境変数などを実装しています。
  • それぞれ、Envoyプロキシを追加するために`sidecar.istio.io/inject: “true”`を記述します。
• ingress gateway は、Service mesh へのインバウンドトラフィックのgateway設定です。
• virtual service は、ingressトラフィックを serviceaにルーティングするための設定です。

ingress gateway のURLを確認し、アプリケーションで実装されているエンドポイントにアクセスしてみます。

$ oc get route istio-ingressgateway -n istio-system -o template --template '{{ "http://" }}{{ .spec.host }}'
$ curl <gateway url>/trace
Hello! from servicea!

■ Jaegerで確認

Jaeger URLを取得します。

$ oc get route jaeger -n istio-system -o template --template '{{ "https://" }}{{ .spec.host }}'

webブラウザでURLにアクセスします。

OpenShiftのログイン画面へ遷移します。別途アカウントへのサービスアカウントのアクセスを許可するか尋ねられますが、許可して先に進みます。

Jaegerのホーム画面です。とてもシンプルなUIとなっています。

左パネルより、目的のサービスを選択します。今回はserviceaというサービスでPodを起動しているのでこれを選択し、Find Traces をクリックします。

クエリの数に応じてトレースが表示されていることが分かります。

任意のトレースを選択して、内容を確認してみましょう。各スパンをクリックすると詳細が表示されます。

トラフィックに掛かったDurationや、情報としてどんなものが伝搬されたのか確認出来ます。

Envoyプロキシ（xxx.tracingで表示）を確認してみましょう。component proxyとなっています。

これはPod間で通信をする際に、Envoyプロキシを介して（serviceaのEnvoyプロキシ -> servicebのEnvoyプロキシ）通信が行われているということを意味します。

まとめ

今回は、OSMのセットアップとサービス間のトラフィックの可視化について紹介させていただきました。

トラフィックの可視化については、アプリケーションごとにトラフィックの掛かった時間が分かるので、どこにボトルネックがあるのかと調査するのにはとても便利だなと思いました。

また、それに伴い改善活動を行っていくと、システム全体の可用性の向上に繋がりますね。

本書の記載が読者のお役に立てれば幸いです。

About nha 9 Articles

2023年にSIOSへ入社。前職では、インフラでOSS系をメインとしたシステム構築や自動化系(CI/CD)のタスクに従事。コードもたまに書いてます。コンテナを中心とした対応を行っています。