Linkerd 2.10 チュートリアルシリーズ
- Linkerd v2.10 Service Mesh の基礎から始める
- 腾訊クラウド Kubernetes クラスターでの Service Mesh 実装例（Linkerd2 & Traefik2）
- Linkerd 2.10 の基本機能を深く理解する
- サービスを Linkerd に登録する方法
- 自動化されたカナリヤリリースの実装
- コントロールプレーンのTLS証明書自動更新とWebhook設定
- 外部Prometheusインスタンスの設定方法
- 代理サーバーの並列処理設定
- リトライポリシーの構成
- タイムアウト設定の最適化
- コントロールプレーンのデバッグエンドポイント
- KustomizeでLinkerd設定をカスタマイズする
- Linkerdによる分散トレーサビリティの実装
- 502エラーのデバッグ手順
- HTTPアプリケーションのルートごとのメトリクス分析
- gRPCアプリケーションのリクエストトレースによるデバッグ
- メトリクスデータのエクスポート
- ダッシュボードの公開方法
- 自作のmTLSルート証明書生成
- ルートごとのメトリクス取得
- チャオスエンジニアリングによる障害注入
- ポッドのスムーズな終了処理
- イングラストラフィックの管理
- マルチクラスター構成の導入
- Linkerdのインストール手順
- HelmによるLinkerdのインストール方法
- LinkerdとPodセキュリティポリシー(PSP)の連携
- コントロールプレーンTLS証明書の手動更新
- 代理サーバーのログレベル変更
- マルチクラスター間通信の構築
- GitOpsとLinkerd/Argo CDの統合
Linkerd 2.10 中文マニュアルは以下より入手可能です：
サービスメッシュのデバッグは複雑なプロセスです。何かが動作しない場合、問題はプロキシ、アプリケーション、クライアント、またはネットワーク側にある可能性があります。このような状況では、原始的なネットワークデータの確認が有効です。
アプリケーションの入出力パケットに対するネットワークレベルの可視性が必要な場合は、Linkerdはdebug sidecarというユーティリティを提供しています。proxy sidecar injectionと同様の仕組みで、podの作成時にconfig.linkerd.io/enable-debug-sidecar: "true"というアノテーションを設定することで、debug sidecarを注入できます。linkerd injectコマンドには--enable-debug-sidecarオプションがあり、このアノテーションを自動で付与できます。
（注意：KubernetesのPod内のコンテナは変更不可能なため、既存のPodにこのアノテーションを追加しても効果はありません。Pod作成時にアノテーションを含める必要があります。）
debug sidecarイメージにはtshark、tcpdump、lsof、iproute2などのツールが含まれています。起動後、自動的にtsharkを使用してすべての入出力トラフィックを記録し、kubectl logsで確認できます。またはkubectl execでコンテナに接続し、直接コマンドを実行することも可能です。
例えば、Linkerdの入門ガイドを参照し、emojivotoアプリケーションをインストールした後、votingサービスのトラフィックをデバッグしたい場合、以下のコマンドを実行します：
kubectl -n emojivoto get deploy/voting -o yaml \
| linkerd inject --enable-debug-sidecar - \
| kubectl apply -f -
このコマンドにより、votingサービスのすべてのPodにdebug sidecarコンテナがデプロイされます。（注意：このデプロイでは1つのPodしか存在しないため、再作成される点にご注意ください。）
voting-svcタグを持つPodにデバッグコンテナが正常に動作しているかは、以下のコマンドで確認できます：
kubectl get pods -n emojivoto -l app=voting-svc \
-o jsonpath='{.items[*].spec.containers[*].name}'
リアルタイムでtsharkの出力を確認するには以下を実行します：
kubectl -n emojivoto logs deploy/voting linkerd-debug -f
さらに、execコマンドでコンテナに接続し、独自のネットワークコマンドを実行することも可能です。例えば、HTTPリクエストヘッダーを確認するには：
kubectl -n emojivoto exec -it \
$(kubectl -n emojivoto get pod -l app=voting-svc \
-o jsonpath='{.items[0].metadata.name}') \
-c linkerd-debug -- tshark -i any -f "tcp" -V -Y "http.request"
プロキシによって生成されるdebug sidecarは、トラブルシューティングにおいて実際的なエラーメッセージとしてConnection Refusedが発生することがあります。以下のようなエラーメッセージが表示された場合：
ERR! [<time>] proxy={server=in listen=0.0.0.0:4143 remote=some.svc:50416}
linkerd2_proxy::app::errors unexpected error: error trying to connect:
Connection refused (os error 111) (address: 127.0.0.1:8080)
この場合、特定のポート間のトラフィックを監視するようにtsharkコマンドを変更します：
kubectl -n emojivoto exec -it \
$(kubectl -n emojivoto get pod -l app=voting-svc \
-o jsonpath='{.items[0].metadata.name}') \
-c linkerd-debug -- tshark -i any -f "tcp" -V \
-Y "(tcp.srcport == 4143 and tcp.dstport == 50416) or tcp.port == 8080"
また、Connection reset by peerというエラーも同様のパターンです。アプリケーションログに該当するエラーメッセージが見られない場合は、このエラーは通常無害です。そのような場合、デバッグコンテナはエラーメッセージの解消には役立たない可能性があります。
ERR! [<time>] proxy={server=in listen=0.0.0.0:4143 remote=some.svc:35314}
linkerd2_proxy::app::errors unexpected error: connection error:
Connection reset by peer (os error 104)
当然ながら、これらの例はKubernetesクラスター内の任意のコンテナにexecできる環境でのみ有効です。この方法の代替としてlinkerd tapコマンドも利用可能です。