Kubernetesモニタリングのベ ストプラクティス Koji Aizawa(@kaojiri) | 2021/03/20

会澤 康二 - Solutions Consultant at New Relic 国産SIerに新卒入社し、プロジェクトマネジメントを叩き込まれる その後、自社サービスビジネス立ち上げ支援、クラウドネイティブ開発、基盤の設計・ 構築などの案件支援に従事し、 New RelicにJoin 趣味: ランニング、登山、サッカー観戦、畑 AWS Solutions Architect Pro Certified Kubernetes Administrator ● facebook: https://www.facebook.com/koji.aizawa.7 ● Twitter : @kaojiri ● speakerdeck: https://speakerdeck.com/kaojiri ● New Relic ブログ: https://blog.newrelic.co.jp/author/kaizawa/

本セッションのゴール ● なんとなくKubernetesを使い始めちゃった、ということがないように、 Kubernetesって何？から理解する ● よくある課題を理解することで、なぜそんなことやるのか？の本質を理解できるようになる ○ 具体的にどうやるかは置いておいて ● オブザーバビリティ！！ ※本セッションでお話しないこと ● ECS / EKSの違い。どちらを使うべき？ ● どんなサービス・機能をどのように使えばいいか、という類の話 ○ そのままコピペすればいい、レベルの情報

Agenda 1. Kubernetesとは？ a. コンテナの課題とオーケストレーションの必要性 b. KubernetesアーキテクチャとEKS c. Kubernetes運用でよくある課題 2. Kubernetesのオブザーバビリティを実現するために抑えるべきポイント 3. Kubernetesモニタリングで利用するサービス群 4. まとめ

Kubernetesとは？

仮想マシンとコンテナの違い 出典：『Kubernetes on AWS』（リックテレコム刊　 2020年）

コンテナのメリット（可搬性） 出典：『Kubernetes on AWS』（リックテレコム刊　 2020年）

コンテナの課題 本番環境では各コンポーネントを冗長化するのが基 本 ● コンテナの障害対策 ○ 複数台のコンテナを起動 ○ ロードバランサーでアクセス分散 ● サーバの障害対策 ○ 各コンテナは別々のサーバで起動 出典：『Kubernetes on AWS』（リックテレコム刊　 2020年）

コンテナオーケストレーションとは？ 複数のコンテナ（サービス）を”よしな”に配置し、可用性、負荷分散、 認証認可、アクセス制御などのガバナンス統制を効かせることが可能 結構たくさんある（あった） ● Docker Swarm ● CoreOS fleet ● Rancher Labs Rancher ● Mesos Marathon ● Google Borg -> CNCF kubernetes　等 主導権争いの末、kubernetesが事実上のデファクトに CNCFもk8sをGraduateに

No content

Kubernetesアーキテクチャ（概要） 出典：『Kubernetes on AWS』（リックテレコム刊　 2020年）

EKSはKubernetesコントロールプレーンをマネージドに 出典：『Kubernetes on AWS』（リックテレコム刊　 2020年）

データプレーンはどうするの？ 出典：『Kubernetes on AWS』（リックテレコム刊　 2020年）

kubectl テキストベースで豊富な情報取得、可視化。

Kubernetes運用でよくある課題 使う側からすると結構簡単 VS 運用する側からすると結構難しい 1. Podが乱立してクラスターリソースが枯渇する 2. マイクロサービス間のパフォーマンス状況がわからない 3. 何を異常と見なすべきかわかりづらい ■ ノードの状態、Podの状態がわかりづらい

オブザーバビリティ（可観測性） システムのメトリクス・イベント・ ログ・トレースのデータを リアルタイムに取得し続け、 常にシステム全容の 状態把握と改善ができる状態 by New Relic

Kubernetesのオブザーバビリティを 実現するために抑えるべきポイント

Kubernetes運用でよくある課題 使う側からすると結構簡単 VS 運用する側からすると結構難しい 1. Podが乱立してクラスターリソースが枯渇する 2. マイクロサービス間のパフォーマンス状況がわからない 3. 何を異常と見なすべきかわかりづらい ■ ノードの状態、Podの状態がわかりづらい 再掲

1. Podが乱立してクラスターリソースが枯渇する クラスター全体だけでなく、ノードやPod(Container) の負荷状況とキャパシティを把握する Requests/Limitsを確実に設定することでノードキャ パシティを正確に把握できるようにする 参考（ブログ）：Kubernetesクラスターのキャパシティ管理を行うためにRequestsとLimitsを確実に設定する方法

2. サービス間のパフォーマンス状況がわからない マイクロサービスになればなるほど、ひとつのトランザクションに関わるサービス数が増える ボトルネックはどこ？いちいち調べるの辛い・・・ 分散トレーシングでしっかり可視化する 合わせてノードレベルのパフォーマンス（ Network performance / DiscIO等）傾向を把握する 実測値で何かを見るのではなく、頭打ちになっているかどうかを確認 する 境界となるメトリクスを可視化し、問題切り分けを効率化する ● AWSのELB関連のメトリクス etc... Application Performance

3. 何を異常と見なすべきかわかりづらい Kubernetesはダイナミックにステータスが変更していくため、単体のメトリクスだけで発砲するとノ イズとなりやすい 問題が継続していることを検知する、かつ、継続時間をどの程度とするかが重要 検知する観点は「キャパシティ・リソース」と「異常検知」に関連するものがメ イン サービス全体にどの程度の影響が出ているかの相関関係を把握することがもっとも重要 This is Observability とはいえ、Podの異常ステータスは正確に検知する CrashLoopBackOff / OOMKilledなど、クリティカルになりやすいものをピックアップ

Kubernetesモニタリングで 利用するAWSサービス

利用するAWSサービス群 No. ポイント 利用サービス 1 Podが乱立してクラスターリソースが枯渇する ・CloudWatch - Dashboard ・CloudWatch - Metrics ・CloudWatch - Logs ・CloudWatch - Container Insights ・CloudWatch - Alarm 2 マイクロサービス間のパフォーマンス状況が わからない ・AWS X-Ray ・CloudWatch - ServiceLends - Service Map, Traces ・AWS Distro for OpenTelemetry 3 何を異常と見なすべきかわかりづらい No1と同じ

Prometheus/Grafanaもマネージドに！選択肢が広がる！ https://aws.amazon.com/jp/prometheus/ https://aws.amazon.com/jp/grafana/

ちょっとだけ宣伝

Kubernetes管理もNew Relicで Kubernetes Cluster Explorer ● 色分けによる異常を視覚化 ● リソース使用量を可視化 ● Kubernetesだけでなく、アプリケー ションまで一気通貫な原因追求 ○ APM連携 ○ ログ連携 ○ Distributed Tracing連携 kubectlコマンドを叩かなくても、ノードやPodの状況がひ と目で分かります。問題箇所から深掘りしていくことで、 アプリケーションレベルでの問題までトレース可能

まとめ

まとめ 1. Kubernetesとは？ 2. Kubernetesのオブザーバビリティを実現するために抑えるべきポイント a. Podが乱立してクラスターリソースが枯渇することを防止しよう b. マイクロサービス間のパフォーマンス状況を可視化しよう c. 単体の事象にこだわりすぎず、相関関係をみながら一定時間異常な状態が継続した場合にア ラートしよう 3. Kubernetesモニタリングで利用するサービス群 a. CloudWatchフル活用 b. Prometheus / Grafanaも待ち遠しい c. New Relicもよろしくね

Kubernetesはサービスのイチ構成要素 サービス全体状況を把握しつつ Kubernetesクラスター状態 ”も” 把握・管理することが最も重要

This is “Observability” of Kubernetes

No content