Kubernetes の可視性を向上させる方法

編集者– この投稿は10 部構成のシリーズの一部です。

1. プロダクショングレードのKubernetesで複雑さを軽減
2. 高度なトラフィック管理で Kubernetes の回復力を向上させる方法
3. Kubernetes の可視性を向上させる方法 (この投稿)
4. トラフィック管理ツールを使用して Kubernetes を保護する 6 つの方法
5. Ingress コントローラーの選択ガイド、パート 1: 要件を特定する
6. Ingress コントローラーの選択ガイド、パート 2: リスクと将来への備え
7. Ingress コントローラーの選択ガイド、パート 3: オープンソース vs. デフォルト vs. コマーシャル
8. Ingress コントローラーの選択ガイド、パート 4: NGINX Ingress コントローラー オプション
9. サービスメッシュの選択方法
10. 動的 Kubernetes クラウド環境での NGINX Ingress コントローラーのパフォーマンス テスト

また、ブログの完全セットを無料の電子書籍「 Taking Kubernetes from Test to Production」としてダウンロードすることもできます。
マイクロサービスの導入によりデジタル エクスペリエンスは加速しますが、マイクロサービス アーキテクチャによってそれらのエクスペリエンスがより脆弱になる可能性もあります。 開発者が新しいアプリをリリースするために急いでいる間に、アーキテクチャのせいで、停止やセキュリティの露出のリスクが高まり、非効率的なトラブルシューティングや予防可能な問題の修正に時間が浪費される可能性があります。 本番環境レベルの Kubernetes に関するシリーズの 2 番目のブログでは、トラフィックの可視性を提供するコンポーネントが、マイクロサービス環境の複雑さを軽減し、セキュリティを向上させる方法について検討します。

可視性を高めて洞察を得る

まず、いくつかの定義を見てみましょう。

• 可視性 – 見ることができる、または見られることができる状態
• 洞察力 – 人や物に対する深い理解

StackRox の 2020 年の調査では、Kubernetes ユーザーの 75% が可視性を「必須」機能と認識しています。 何がデプロイされているかを把握することが特に難しいため、Kubernetes では可視性が重要であることに同意します。 しかし、F5 の 2021 年のアプリケーション戦略の現状(SOAS) の回答者の 95% は、豊富なデータがあるにもかかわらず、インフラストラクチャとビジネスを保護し、進化させるために必要なアプリのパフォーマンス、セキュリティ、可用性に関する洞察が不足していると報告しています。 では、洞察力はなぜ重要で、どうすれば得られるのでしょうか?

洞察力があれば、次のことが可能になります。

• 脆弱性と攻撃の可能性のあるベクトルを検出してセキュリティとコンプライアンスを強化する
• 顧客より先に問題を発見することで、停止やダウンタイムを削減します。
• アプリの問題の根本原因を見つけることでトラブルシューティングの効率を向上
• トラフィックが目的の場所にのみ送信されていることを確認します
• Kubernetes環境で何が実行されているか、それが適切に構成され、保護されているかどうかを正確に把握する
• レイテンシとパフォーマンス履歴に基づいて、適切な量のリソースを使用しているかどうかを確認します。
• 過去の交通パターンに基づいて季節的なニーズを予測する
• 応答時間の観点からパフォーマンスを測定し、サービス レベル契約 (SLA) に対するパフォーマンスを追跡し、問題がユーザー エクスペリエンスに影響を与える前に早期警告システムとして機能します。

洞察を得るには、リアルタイムと履歴の 2 種類の可視性データが必要です。 リアルタイム データを使用すると、現在発生している問題の原因を診断できます。一方、履歴データを使用すると、「正常」なものと外れ値に関する視点が得られます。 これら 2 種類の可視性ソースを組み合わせることで、アプリと Kubernetes のパフォーマンスに関する重要な洞察が得られます。

他のテクノロジー投資と同様に、利益を享受するための戦略も必要です。 SOAS レポートでは、採用や従業員の育成、戦略やプロセス、そしてデータを何のために、いつ、誰が使用すべきかについての合意など、組織的な要因が原因で、人々が貴重な洞察を得られないことも示されています。 調査結果には以下が含まれます。

• 関連スキルセット– 熟練した技術専門家が不足していることは周知の事実であり、回答者の 47% が必要な人材を見つけるのに苦労していると報告していることからもそれが裏付けられます。
• データ共有の取り組み– 回復力のあるテクノロジー (またはその欠如) がビジネスに与える影響をビジネス上の意思決定者に認識してもらうために、データをビジネス上の意思決定者に報告するためのプロセスと戦略を導入している回答者はわずか 12% でした。
• 可視性の目的– 回答者の大半はテレメトリをリアクティブに（つまりトラブルシューティングのために）使用していますが、潜在的なパフォーマンス低下を監視するためにデータと分析情報をプロアクティブに使用している回答者はわずか 24% で、SLA パフォーマンスを追跡している回答者は 16% です。

この投稿の残りの部分では、洞察の技術的な側面に焦点を当てます。 戦略、プロセス、その他のトピックに関する今後のブログに注目してください。

NGINX がどのように役立つか

ほとんどの Kubernetes デプロイメントではすでに監視ツールが使用されており、さらに別のツールは必要ないということはわかっています。 そこで、メトリックを簡単にエクスポートできるようにNGINX Plus API を組み込み、 OpenTracing 、 Grafana、Prometheusなどの一般的なツールとの統合を提供することで、クラスター内のパフォーマンスの全体像を把握できるようにしました。 詳細なトレースにより、アプリのパフォーマンスと可用性に関する的を絞った分析情報を取得できるため、マイクロサービス アプリ全体でリクエストがどのように処理されるかを理解できます。

• 入口-出口（南北）トラフィックの洞察
  NGINX Ingress Controller は、Kubernetes クラスターに出入りするトラフィックに関する洞察を提供します。

  NGINX をベースにした人気の Ingress コントローラーが 3 つあることをご存知ですか? すべてが本番環境に対応しているわけではなく、間違った選択をすると、マイクロサービス戦略が改善されるどころか、むしろ複雑化してしまう可能性があります。 弊社のブログ記事「待ってください、Kubernetes 用のどの NGINX Ingress コントローラーを使用していますか?」では、オプションの比較が提供されており、ニーズに最適な決定を下すことができます。

• 東西の交通に関する洞察
  NGINX Service Mesh は、コンテナ化されたアプリ間で流れるトラフィックに関する洞察を提供します。

よくある 2 つの問題に対して当社がどのようにサポートできるかについては、以下をお読みください。

• アプリの動作が遅い（またはダウンしている）
• クラスターまたはプラットフォームのリソースが不足しています

テクノロジーの実際の動作を確認する準備ができたら、NGINX と Grafana の専門家によるライブ ストリーム デモと AMA をご覧ください。 主要な負荷分散とパフォーマンス メトリックのライブ監視を取得し、メトリックを Prometheus にエクスポートし、累積パフォーマンスを表示するための Grafana ダッシュボードを作成する方法を紹介します。

問題： アプリの動作が遅い（またはダウンしている）

DDoS 攻撃を疑っていますか? ユーザーはあなたのウェブサイトからエラーを報告していますか? 問題がどこにあるのかを正確に把握するまで、その解決を始めることはできません。

• NGINX Ingress Controller によるライブ監視
  NGINX Plus では、 NGINX Plus APIを搭載したライブ アクティビティ監視ダッシュボードに、数百もの主要な負荷とパフォーマンスのメトリックが表示されます。 単一のポッドレベルまできめ細かい詳細を取得できるため、アプリへの応答時間を迅速かつ簡単に測定し、問題の原因を診断できます。 Kubernetes 環境が拡大すると、追加の NGINX Ingress Controller インスタンスごとにダッシュボードが自動的に提供されます。

  たとえば、 [HTTP アップストリーム]タブの 2 つの列では、アプリケーションとインフラストラクチャのステータスをすぐに確認できます。

  • リクエスト– 1 秒あたりのリクエスト数 ( Req/s ) が特定のアプリケーションの標準値を下回っている場合 (たとえば、1 秒あたり 40 が標準であるのに 5 リクエストになっている場合)、Ingress コントローラーまたはアプリケーションの構成が間違っている可能性があります。
  • 応答時間– 応答時間が 10 ミリ秒 (ms) 以下であれば、良好な状態です。 30～40 ミリ秒を超えるレイテンシは、アップストリーム アプリケーションに問題があることを示しています。

  

• NGINX Ingress Controller のスタブ ステータス
  NGINX Open Source では、NGINX Ingress Controller に 8 つの基本メトリックを報告するステータス ページが含まれています。
• NGINX サービス メッシュを使用した OpenTracing
  NGINX Service Mesh は、NGINX OpenTracing モジュールを使用して OpenTracing をサポートします。 この記事の執筆時点では、このモジュールは Datadog、LightStep、Jaeger、Zipkin をサポートしています。

問題： クラスターまたはプラットフォームのリソースが不足しています

HTTP エラーが発生しましたか?503そして40xエラーはリソースに問題があることを示していますが、502設定の変更が機能しなかったことを意味します。 履歴データを使用して、リソースが不足している可能性がある場所を診断します。

• NGINX Ingress Controller によるログ記録
  ネットワークの問題を診断する最初のステップは、 NGINX Ingress Controller ログを確認することです。ログ内のすべてのエントリには、関連する Kubernetes サービスが注釈として付けられています。 エラーに関するエントリは、関連するサービスを識別します。 ログには、タイムスタンプ、送信元 IP アドレス、応答ステータス コードなど、Ingress Controller を通過したすべてのトラフィックに関する詳細情報が含まれます。 また、Datadog、Grafana、Splunk などの一般的なアグリゲータにログをエクスポートすることもできます。

• プロメテウスメトリクス
  NGINX Ingress Controller の最も人気のある機能の 1 つは、ネットワーク パフォーマンスと Ingress コントローラー トラフィックに関するメトリックを含む、拡大し続けるPrometheus メトリックのリストです。 NGINX Plus を使用すると、NGINX Ingress Controller は、接続、キャッシュ、メモリゾーンでデータを共有するNGINX ワーカーのグループによって処理される HTTP および TCP/UDP トラフィック、バックエンド サーバーのグループによって処理される HTTP および TCP/UDP トラフィックなどに関するメトリックをエクスポートします。

  NGINX Service Mesh は、NGINX Plus API を使用して NGINX Service Mesh サイドカーと NGINX Ingress Controller ポッドからメトリックをスクレイピングするPrometheus サーバーをデプロイします。 既存の Prometheus デプロイメントを使用する場合は、Prometheus 構成ファイルに追加するスクレイプ構成も提供されます。

• Grafanaダッシュボード
  私たちは、Prometheus Exporter によって公開されたメトリックを視覚化する、NGINX Ingress Controller およびNGINX Service Mesh用の公式 Grafana ダッシュボードを提供しています。 ユーザーは、ミリ秒単位の詳細、日ごとのオーバーレイ、トラフィックの急増などを含むデータの粒度を重視します。 たとえば、NGINX Service Mesh ダッシュボードでは、1 つのサービスまたはポッドのトラフィックの量と、監視されているアクティブなポッドの数を表示することで、ポッドが容量に達しているかどうかを示すことができます。

NGINX で本番環境の準備を整える

実稼働対応の NGINX Ingress Controller (NGINX Plus ベース) は、コンテナ化されたアプリを保護するNGINX App Protectを含む30 日間の無料トライアルでご利用いただけます。 常に無料の NGINX Service Mesh は、 f5.comからダウンロードできます。