序章

サービスメッシュは、管理者がサービス間の通信を処理するのに役立つ専用のインフラストラクチャレイヤーです。 多くの強力なツールを提供するこれらのサービスメッシュは、システムをより安全で信頼性が高く、より見やすくすることができます。

たとえば、 Linkerd のようなサービスメッシュは、接続を自動的に暗号化し、要求の再試行とタイムアウトを処理し、成功率や遅延などのテレメトリ情報を提供できます。

このチュートリアルでは、Linkerdサービスメッシュを Kubernetes クラスターにインストールし、サンプルアプリケーションをデプロイしてから、Linkerdのダッシュボードを探索します。 このダッシュボード情報のいくつかに精通した後、強制するようにLinkerdを構成します timeoutretry 特定のKubernetesポッドのポリシー。

または、DigitalOceanのワンクリックLinkerd/Kubernetesインストールオプションを検討することを検討してください。

前提条件

  • Kubernetes1.12+クラスター。 このチュートリアルでは、セットアップで3つのノードを持つ DigitalOcean Kubernetes クラスターを使用しますが、別の方法を使用してクラスターを自由に作成できます。

  • The kubectl 開発サーバーにインストールされ、クラスターに接続するように構成されたコマンドラインツール。 インストールについてもっと読むことができます kubectl その公式ドキュメントで。

ステップ1—アプリケーションのデプロイ

Linkerdの動作を確認するには、クラスターでアプリケーションを実行する必要があります。 このステップでは、と呼ばれるアプリケーションをデプロイします emojivoto、Linkerdチームがこの目的のために作成した

このリポジトリには、アプリケーションを構成する4つのサービスのコードと、これらのサービスをKubernetesクラスターにデプロイするために使用するマニフェストファイルが表示されます。

まず、このマニフェストファイルをローカルに保存します。

  1. curl https://run.linkerd.io/emojivoto.yml --output manifest.yaml

使用しています curl ファイルをフェッチしてから、 --output ファイルを保存する場所を指定するオプション。 この場合、あなたはというファイルを作成しています manifest.yaml.

このファイルが何を達成するかをよりよく理解するには、その内容を次のように調べます。 cat または、お気に入りのエディターで開きます。

  1. cat manifest.yaml | less

プレス SPACE ディレクティブをページングします。 あなたはそれを見るでしょう manifest.yaml と呼ばれるKubernetes名前空間を作成しています emojivoto このアプリケーションに関連するすべてのものが実行される場所と、いくつかのKubernetes DeploymentsServices.

次に、このマニフェストをKubernetesクラスターに適用します。

  1. kubectl apply -f manifest.yaml

繰り返しますが、あなたは使用しています kubectl apply とともに -f 適用するファイルを割り当てるフラグ。

このコマンドは、作成されたすべてのリソースのリストを出力します。

Output
namespace/emojivoto created serviceaccount/emoji created serviceaccount/voting created serviceaccount/web created service/emoji-svc created service/voting-svc created service/web-svc created deployment.apps/emoji created deployment.apps/vote-bot created deployment.apps/voting created deployment.apps/web created

次に、サービスが実行されていることを確認します。

  1. kubectl -n emojivoto get pods

使用しています kubectl すべてを一覧表示するには pods クラスタで実行してから、 -n 使用する名前空間を示すフラグ。 あなたは合格しています emojivoto 名前空間は、これらすべてのサービスを実行している場所だからです。

あなたがすべてを見るとき pods の中に Running 状態、あなたは行ってもいいです:

Output
NAME READY STATUS RESTARTS AGE emoji-566954596f-cw75b 1/1 Running 0 24s vote-bot-85c5f5699f-7dw5c 1/1 Running 0 24s voting-756995b6fc-czf8z 1/1 Running 0 24s web-7f7b69d467-2546n 1/1 Running 0 23s

最後に、ブラウザで実行されているアプリケーションを確認するには、 kubectl ローカルリクエストをリモートクラスタに転送する組み込み機能:

  1. kubectl -n emojivoto port-forward svc/web-svc 8080:80

注:ローカルマシンからこれを実行していない場合は、を追加する必要があります --address 0.0.0.0 だけでなく、すべてのアドレスでリッスンするフラグ localhost.

ここで再び使用しています kubectl の中に emojivoto 名前空間ですが、現在は port-forward サブコマンドを実行し、ポート上のすべてのローカル要求を転送するように指示します 8080 Kubernetesサービスへ web-svc、ポート上 80. これは、適切なロードバランサーを配置しなくても、アプリケーションにアクセスするための便利な方法です。

今すぐ訪問 http://localhost:8080 emojivotoアプリケーションが表示されます。

プレス CTRL + C あなたのターミナルで。 これで、クラスターでアプリケーションを実行して、Linkerdをインストールし、その動作を確認する準備が整いました。

ステップ2—Linkerdをインストールする

アプリケーションを実行しているので、Linkerdをインストールしましょう。 Kubernetesクラスタにインストールするには、最初にLinkerdCLIが必要です。 このコマンドラインインターフェイスを使用して、ローカルマシンからLinkerdと対話します。 その後、Linkerdをクラスターにインストールできます。

まず、Linkerdチームから提供されたスクリプトを使用してCLIをインストールしましょう。

  1. curl https://run.linkerd.io/install | sh

ここで使用しています curl インストールスクリプトをダウンロードし、出力をにパイプします sh、スクリプトを自動的に実行します。 または、LinkerdのリリースページからCLIを直接ダウンロードすることもできます。

スクリプトを使用すると、Linkerdが次の場所にインストールされます。 ~/.linkerd2/bin. ここで、CLIが正しく機能していることを確認します。

  1. ~/.linkerd2/bin/linkerd version

コマンドは次のようなものを出力します:

Output
Client version: stable-2.7.1 Server version: unavailable

次に、CLIの実行を容易にするために、このディレクトリを $PATH:

  1. export PATH=$PATH:$HOME/.linkerd2/bin

これで、前のコマンドと同様に、コマンドをより直接的に実行できます。

  1. linkerd version

最後に、LinkerdをKubernetesクラスターにインストールしましょう。 The linkerd install コマンドを使用して、必要なすべてを生成します yaml Linkerdを実行するにはマニフェストが必要ですが、これらのマニフェストはクラスターに適用されません。 次のコマンドを実行して、その出力を調べます。

  1. linkerd install

Linkerdが実行する必要のあるリソースのすべてのyamlマニフェストを一覧表示する長い出力が表示されます。 これらのマニフェストをクラスターに適用するには、次のコマンドを実行します。

  1. linkerd install | kubectl apply -f -

ランニング linkerd install 以前に見たすべてのマニフェストを出力します。 | 次に、この出力を直接パイプします kubectl apply、それらを適用します。

このコマンドを実行した後、 kubectl apply 作成されたすべてのリソースのリストを出力します。

クラスタですべてが実行されていることを確認するには、 linkerd check:

  1. linkerd check

これにより、クラスターに対していくつかのチェックが実行され、必要なすべてのコンポーネントが実行されていることを確認します。

Output
kubernetes-api -------------- √ can initialize the client √ can query the Kubernetes API [...] control-plane-version --------------------- √ control plane is up-to-date √ control plane and cli versions match Status check results are √

最後に、このコマンドを実行して、ブラウザーで組み込みのLinkerdダッシュボードを開きます( --address 0.0.0.0 ローカルマシンからこれを実行していない場合はフラグを立てます):

  1. linkerd dashboard

ダッシュボードに表示される情報のほとんどは、LinkerdCLIを使用して取得できます。 たとえば、次のコマンドを実行して、高レベルの統計情報の展開を確認します。

  1. linkerd stat deployments -n linkerd

ここでは、で実行されているデプロイメントの統計が必要であると言っています。 linkerd 名前空間。 これらはLinkerd独自のコンポーネントであり、興味深いことに、Linkerd自体を使用してそれらを監視できます。 1秒あたりのリクエスト数(RPS)、成功率、レイテンシーなどの統計情報を確認できます。 あなたはまた見ることができます Meshed 列は、いくつあるかを示します pods Linkerdは注入しました:

Output
NAME MESHED SUCCESS RPS LATENCY_P50 LATENCY_P95 LATENCY_P99 TCP_CONN linkerd-controller 1/1 100.00% 0.4rps 1ms 87ms 98ms 5 linkerd-destination 1/1 100.00% 0.3rps 1ms 2ms 2ms 13 linkerd-grafana 1/1 100.00% 0.3rps 2ms 3ms 3ms 2 linkerd-identity 1/1 100.00% 0.3rps 1ms 2ms 2ms 10 linkerd-prometheus 1/1 100.00% 0.7rps 35ms 155ms 191ms 9 linkerd-proxy-injector 1/1 100.00% 0.3rps 2ms 3ms 3ms 2 linkerd-sp-validator 1/1 100.00% 0.3rps 1ms 5ms 5ms 2 linkerd-tap 1/1 100.00% 0.3rps 1ms 4ms 4ms 6 linkerd-web 1/1 100.00% 0.3rps 1ms 2ms 2ms 2

今、あなたのでこのコマンドを試してみてください emojivoto 名前空間:

  1. linkerd stat deployments -n emojivoto

4つのサービスを確認できますが、これらの展開では以前に確認した統計情報はどれも利用できません。[メッシュ]列には、次のように表示されていることがわかります。 0/1:

Output
NAME MESHED SUCCESS RPS LATENCY_P50 LATENCY_P95 LATENCY_P99 TCP_CONN emoji 0/1 - - - - - - vote-bot 0/1 - - - - - - voting 0/1 - - - - - - web 0/1 - - - - - -

ここでの出力は、Linkerdをアプリケーションにまだ注入していないことを意味します。 これが次のステップになります。

ステップ3—アプリケーションにLinkerdを挿入する

これで、Linkerdがクラスターで実行されたので、Linkerdをクラスターに注入する準備が整いました。 emojivoto 応用。

Linkerdは、Kubernetesでサイドカーコンテナを実行することで機能します pods. つまり、リンカされたプロキシコンテナをすべてに注入します pod あなたは走っています。 あなたのすべての要求 pods 次に、送信または受信は、メトリック(成功率、1秒あたりのリクエスト数、遅延など)を収集し、ポリシー(タイムアウトや再試行など)を適用できるこの非常に軽量なプロキシを通過します。

次のコマンドを使用して、Linkerdのプロキシを手動で挿入できます。

  1. kubectl get deployments -n emojivoto -o yaml | linkerd inject - | kubectl apply -f -

このコマンドでは、最初に使用しています kubectl get すべてのKubernetesを取得するには deploymentsで実行している emojivoto 名前空間、次に出力が必要であることを指定します yaml フォーマット。 次に、その出力をに送信します linkerd inject 指図。 このコマンドは、 yaml 実行している現在のマニフェストを含むファイルを変更し、すべてのマニフェストと一緒にリンカプロキシを含めるように変更します deployment.

最後に、この変更されたマニフェストを受け取り、それをクラスターに適用します。 kubectl apply.

このコマンドを実行すると、4つすべてを示すメッセージが表示されます emojivoto サービス(emoji, vote-bot, voting、 と web)正常に注入されました。

今取得した場合 stats 為に emojivoto、あなたはすべてのあなたの deploymentこれでメッシュが作成され、数秒後に、 linkerd 名前空間:

  1. linkerd stat deployments -n emojivoto

ここでは、を構成する4つのサービスすべての統計を確認できます。 emojivoto アプリケーションは、それぞれの成功率、1秒あたりのリクエスト数、レイテンシーを備えており、アプリケーションコードを記述したり変更したりする必要はありません。

Output
NAME MESHED SUCCESS RPS LATENCY_P50 LATENCY_P95 LATENCY_P99 TCP_CONN emoji 1/1 100.00% 1.9rps 1ms 2ms 2ms 2 vote-bot 1/1 - - - - - - voting 1/1 85.96% 0.9rps 1ms 1ms 1ms 2 web 1/1 93.04% 1.9rps 8ms 27ms 29ms 2

The vote-bot サービスは、他のサービスにリクエストを送信するボットであり、トラフィックを受信していないため、統計情報は表示されません。これは、それ自体が貴重な情報です。

次に、サービスに関する追加情報をLinkerdに提供して、サービスの動作をカスタマイズする方法を見てみましょう。

ステップ4—サービスプロファイルを定義する

Linkerdをアプリケーションに挿入したので、各サービスの動作に関する貴重な情報の取得を開始できます。 さらに、カスタム構成を記述したり、アプリケーションのコードを変更したりすることなく、これを実現できました。 ただし、Linkerdに追加情報を提供すると、タイムアウトや再試行などの多数のポリシーを適用できます。 その後、ルートごとのメトリックを提供することもできます。

この情報は、サービスプロファイルを通じて提供されます。サービスプロファイルは、アプリケーション内のルートと各ルートの動作を説明できるカスタムLinkerdリソースです。

サービスプロファイルマニフェストがどのように見えるかの例を次に示します。

example-service-profile.yaml
apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
  name: my-service.my-namespace.svc.cluster.local
spec:
  routes:
  - name: My Route Name
    isRetryable: true # Define it's safe to retry this route
    timeout: 100ms # Define a timeout for this route
    condition:
      method: GET
      pathRegex: /my/route/path

サービスプロファイルはルートのリストを記述し、次に指定されたものと一致するリクエストがどのように一致するかを定義します condition 動作します。 この例では、 GET に送信されたリクエスト /my/route/path 100ミリ秒後にタイムアウトし、失敗した場合は再試行できます。

次に、サービスの1つにサービスプロファイルを作成しましょう。 取る voting-svc 例として、最初にLinkerd CLIを使用して、このサービスに定義したルートを確認します。

  1. linkerd routes svc/voting-svc -n emojivoto

ここでは、 linkerd routes サービスのすべてのルートを一覧表示するコマンド voting-svc、 の中に emojiovoto 名前空間:

Output
ROUTE SERVICE SUCCESS RPS LATENCY_P50 LATENCY_P95 LATENCY_P99 [DEFAULT] voting-svc 83.05% 1.0rps 1ms 1ms 2ms

ルートは1つだけですが、 [DEFAULT]. これは、サービスプロファイルを定義するまで、すべてのリクエストがグループ化される場所です。

次に、nanoまたはお気に入りのエディターを開いて、 service-profile.yaml ファイル:

  1. nano service-profile.yaml

次のサービスプロファイル定義をこのファイルに追加します。

service-profile.yaml
apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
  name: voting-svc.emojivoto.svc.cluster.local
  namespace: emojivoto
spec:
  routes:
  - name: VoteDoughnut
    isRetryable: true
    timeout: 100ms
    condition:
      method: POST
      pathRegex: /emojivoto.v1.VotingService/VoteDoughnut

次に、ファイルを保存してエディターを閉じます。

ここでは、のサービスプロファイルを宣言しています voting-svc サービス、 emojivoto 名前空間。 と呼ばれる1つのルートを定義しました VoteDoughnut、これは POST にリクエスト /emojivoto.v1.VotingService/VoteDoughnut 道。 これらの基準に一致するリクエストに100ミリ秒以上かかる場合、Linkerdはそれをキャンセルし、クライアントは 504 応答します。 また、このリクエストが失敗した場合は再試行できることをLinkerdに伝えています。

次に、このファイルをクラスターに適用します。

  1. kubectl apply -f service-profile.yaml

数秒後、このサービスのルートを再確認します。

  1. linkerd routes svc/voting-svc -n emojivoto

これで、新しく定義されたものが表示されます VoteDoughnut ルート:

Output
ROUTE SERVICE SUCCESS RPS LATENCY_P50 LATENCY_P95 LATENCY_P99 VoteDoughnut voting-svc 0.00% 0.2rps 1ms 1ms 1ms [DEFAULT] voting-svc 100.00% 0.8rps 1ms 4ms 4ms

この特定のルートの成功率、1秒あたりのリクエスト数、レイテンシーなど、いくつかのカスタム指標を確認できます。 に注意してください VoteDoughnut エンドポイントは意図的に構成され常にエラーを返し、成功率0%を出力している間、 [DEFAULT] ルートは100%出力しています。

これで、Linkerdにサービスに関する情報を少し提供した後、ルートごとにカスタムメトリックが設定され、タイムアウトと再試行の2つのポリシーが適用されます。

結論

この記事では、LinkerdをKubernetesクラスターにインストールし、それを使用してサンプルアプリケーションを監視しました。 成功率、スループット、遅延などの有用なテレメトリ情報を抽出しました。 また、ルートごとのメトリックを収集し、2つのポリシーを適用するようにLinkerdサービスプロファイルを構成しました。 emojivoto 応用。

Linkerdについて詳しく知りたい場合は、すばらしいドキュメントページを参照してください。ここでは、サービスを保護する分散トレースを構成する、[ X204X]カナリアリリースの自動化など。

ここから、 Istio をチェックアウトすることも検討できます。これは、異なる機能とトレードオフのセットを備えた別のサービスメッシュです。