短命のコンテナを監視するため、Kubernetesは、アプリケーションのパフォーマンスを理解しやすくするビルトインツールとAPIを備えています。Kubernetesの組み込み監視ツールを活用した監視戦略では、アプリケーションを実行するコンテナが絶えずホスト間を移動したり、スケールアップ/スケールダウンしても、アプリケーション全体のパフォーマンスを俯瞰的に把握することが重要です。
ここでは、Kubernetes環境をインフラストラクチャに組み込む場合に考慮すべきベストプラクティスをいくつかご紹介します。
インフラストラクチャ全体のオブザーバビリティのためのKubernetes監視シリーズ その1
このブログ記事では、Kubernetesの監視方法と、完全なオブザーバビリティのために必要なコンポーネントについて解説します。Kubernetesの機能と、Kubernetesを活用してより効果的な監視戦略を構築するためのベストプラクティスを詳細に説明します。これは「Kubernetes監視」シリーズの第1回目です。
Kubernetes監視とは？
Kubernetes監視は、Kubernetesクラスタ内のパフォーマンスとリソースを最適化し、問題を迅速に診断するためのデータを収集して分析するのに役立ちます。これらのクラスタはKubernetesのバックボーンを形成し、コンテナ化されたアプリケーションの実行を担うさまざまなマシン（ノード）で構成されています。
少し話を戻しましょう。Kubernetesとは？「K8s」と略されることの多いKubernetesは、コンテナオーケストレーションの事実上のスタンダードとしての地位を確立している、オープンソースのプラットフォームです。CNCFの2021年の報告書によると、Kubernetesの使用は世界的に、特に大規模組織で増加しており、世界中で560万人の開発者がKubernetesを使用しており、これはバックエンド開発者全体の31%に相当します。
コンテナオーケストレーションシステムとして、あらゆるモダンアプリケーションのインフラストラクチャを構成するコンテナのスケジューリング、スケーリング、管理を自動的に行います。これはクラウドネイティブ・コンピューティング・ファウンデーション（CNCF）の代表的プロジェクトです。GoogleやAWS、Microsoft、IBM、Intel、Cisco、Red Hatなどの主要企業のサポートを受けています。
Kubernetesの監視方法
Kubernetesは、アプリケーション実行に必要なソフトウェアを構成するコンテナ管理の日常的な運用タスクを自動化します。アプリケーションをデプロイするビルトインコマンドで、Kubernetesはアプリケーションの変更を展開したり、変化するニーズに合わせてスケールアップ/スケールダウンしたり、監視を行ったり、さらにさまざまなことを実行します。Kubernetesはコンテナの運用場所に関わらずオーケストレーションを行い、マルチクラウドのデプロイメントやインフラストラクチャプラットフォーム間の移行を促進します。つまり、Kubernetesで、アプリケーション管理がより容易になります。
Kubernetes監視が重要である理由
Kubernetesは、サービスに対する健全性チェックを実行し続けます。クラウドネイティブのアプリケーションにとって、これは一貫性あるコンテナ管理を意味します。自動化された健全性チェックを使用して、Kubernetesは失敗したり停滞しているコンテナを再起動させます。
Kubernetesには、アプリケーション管理の手間のかかる部分の多くを引き受けるコマンドが組み込まれているため、システム管理作業を自動化することができます。Kubernetesにより、アプリケーションは設定の通りに、確実に実行することができます。
Kubernetesは、ワークロードの代わりに、コンピューティング、ネットワーク、ストレージを管理します。このため、開発者は基盤となる環境について心配することなく、アプリケーションに集中できます。
Kubernetes監視のベストプラクティス
短命のコンテナを監視するため、Kubernetesは、アプリケーションのパフォーマンスを理解しやすくするビルトインツールとAPIを備えています。Kubernetesの組み込み監視ツールを活用した監視戦略では、アプリケーションを実行するコンテナが絶えずホスト間を移動したり、規模が変化しても、アプリケーションパフォーマンス全体を俯瞰的に把握することが重要です。
ここでは、Kubernetes環境をインフラストラクチャに組み込む場合に考慮すべきベストプラクティスをいくつかご紹介します。
- ネームスペースを使用してクラスタ内のリソースを整理および分離
- ネームスペースにラベルとアノテーションを付けることで、簡単に識別および監視
- リソース要求と制限を設定して過負荷を防止
- コンテナの健全性と可用性を監視
- Prometheus、Grafanaなどのツールを使用して、ロギングと監視を一元管理
- デプロイの自動化
- クラスタとコンテナの定期的な監査を実施
- 最高のパフォーマンスとセキュリティを確保するには、Kubernetesの最新バージョンを使用していることを確認してください。
Kubernetesがいかに監視戦略を変えるか
もし「Kubernetesを理解するのは簡単だよ」という人がいたら、それは嘘だ！と思うかもしれません。
Kubernetesは、特にVMやオンプレミスサーバーのような従来のホストから移行する場合、監視に新しいアプローチを必要とします。
コンテナは、使用状況に応じてデプロイされ、再デプロイされるため、一度に数分しか使用できません。存在しなくなったものを、どうやってトラブルシューティングできるのでしょうか？
また、これらのコンテナは、世界各地の物理的なサーバーで複数のホストに拡がっています。収集するメトリクスに適切なコンテキストがないと、失敗したプロセスと影響を受けるアプリケーションを関連付けることは難しい場合があります。
短命のコンテナを監視するため、Kubernetesは、アプリケーションのパフォーマンスを理解しやすくするビルトインツールとAPIを備えています。Kubernetesを活用した監視では、アプリケーションを実行するコンテナが絶えずホスト間を移動したり、規模が変化しても、アプリケーションパフォーマンス全体を俯瞰的に把握することが重要です。
監視責任の拡大
スタックに対する十分な可視性を得るためには、インフラストラクチャの監視が必要です。最新技術のスタックは、アプリケーションとインフラストラクチャの関係性を以前よりさらに複雑なものにしています。
従来のインフラストラクチャ
従来のインフラストラクチャ環境では、監視すべきものは2つでした。アプリケーションとそれを実行しているホスト（サーバーもしくはVM）です。
コンテナの登場
2013年、Dockerはコンテナ技術を世の中に送り出しました。コンテナは、アプリケーションとその依存関係を分離し、予測可能で反復可能な方法でパッケージ化して実行するために使用されます。これにより、インフラストラクチャとアプリケーション間の抽象レイヤーが増えます。コンテナは、アプリケーションに代わってワークロードを実行するという点で、従来型のホストと似ています。
Kubernetes
Kubernetesにおいて、スタックに対する完全な可視性とは、自動的に起動と終了を繰り返すコンテナのテレメトリデータの収集と、Kubernetes自体のテレメトリデータの収集を意味します。ガレージにこもって、サーバーのいくつかのライトをチェックしているような日々はもう終わりです！
Kubernetes環境で監視されるべき以下の4つの主な要素には、それぞれに特徴と課題があります。
- インフラストラクチャ（*ワーカーノード）
- コンテナ
- アプリケーション
- Kubernetesクラスタ（*コントロールプレーン）
*これらの概念は本ガイドのその2で扱います。
アプリケーションメトリクスとインフラストラクチャメトリクスをメタデータで相関させる
スケーラブルなアプリケーションの構築がより容易になった一方で、Kubernetesによりアプリケーションとインフラストラクチャの境界線は曖昧になっています。開発者であれば、主に注目するのはアプリケーションでありクラスターのパフォーマンスではありませんが、クラスターの基礎となるコンポーネントはアプリケーションの良好な動作に直接的な影響を与えることがあります。たとえば、Kubernetesのアプリケーションの不具合は、物理的なインフラストラクチャの問題によるものかもしれませんが、もしかしたら設定ミスやコーディングの問題が原因の可能性もあります。
Kubernetesを使用する場合、アプリケーションの監視はオプションではなく必須なのです！
多くのアプリケーションパフォーマンスモニタリング（APM）の言語エージェントは、アプリケーションが実行されている場所には関係がありません。古い棚に置かれた旧式のLinuxサーバーで実行されているかもしれないし、最新のAmazon Elastic Compute Cloud（Amazon EC2）のインスタンス内かもしれません。ただし、オーケストレーションレイヤーによって管理されているアプリケーションを監視する際、インフラストラクチャのコンテクストがあると、デバッグやトラブルシューティングに非常に有用な可能性があります。たとえば、アプリケーションのエラートレースを、それが動作しているコンテナ、Pod、またはホストに関連付けることができます。
Kubernetesの設定ラベル
Kubernetesは寿命が異なるコンテナの作成と削除を自動化します。このプロセス全体が監視される必要があります。変動要素が非常に多いため、メトリクスを対応するアプリケーション、Pod、ネームスペース、ノードなどに相関させるには、組織全体での明確なラベル付けのポリシーを実施する必要があります。
さまざまなオブジェクトに一貫性のあるラベルを付与することで、これらのオブジェクトに関するKubernetesへのクエリが容易になります。たとえば、チームの開発者から本番環境が停止しているかどうかの問い合わせを受けたとします。もし本番Podに「prod」のラベルがついていれば、以下のkubectlコマンドを実行してそのログのすべてを入手できます。
kubectl get pods -l name=prod:
NAME READY STATUS RESTARTS AGE
router-worker-6db6999875-b8t8m 0/1 ErrImagePull 0 1d4hrouter-worker-6db6999875-7fn7z 1/1 Running 0 47s
router-worker-6db6999875-8rl9b 1/1 Running 3 10h router-worker-6db6999875-b8t8m 1/1 Running 2 11hこの例では、本番Podのひとつにイメージのpullに関する問題があることを発見し、その情報を本番Podを使用する開発者に伝えるかもしれません。もしラベルがなければ、Podを得るためkubectlの出力を手動で検索しなければならないでしょう。
一般的なラベル付けの慣例
上記の例では、Podに環境別の使用を特定する「prod」のラベルが付いている場合を想定しました。チームでの運用方法はそれぞれ異なるものの、以下のラベル付けの慣例は、どんなチームでの業務かにかかわらず一般的に使用されているものです。
環境別のラベル
属する環境に対してエンティティを作成することができます。以下にその例を挙げます。
env: production
env: qa
env: development
env: stagingチーム別のラベル
チーム名のタグを作成すると、パフォーマンスの問題につながった変更に関与したチーム、グループ、部門、または地域を把握するのに役立ちます。
### Team tags
team: backend
team: frontend0
team: db
### Role tags
roles: architecture
roles: devops
roles: pm
### Region tags
region: emea
region: america
region: asiaKubernetesの推奨ラベルによるラベル
Kubernetesは、リソースのオブジェクトのベースラインとなるグループ分けができる推奨ラベルの一覧を提供しています。app.kubernetes.ioの接頭コードにより、Kubernetesの推奨ラベルと、company.com prefixを使用して別個に追加したいカスタムラベルを区別します。もっとも使用されているKubernetesの推奨ラベルの一覧は、以下の通りです。
| キー | 説明 |
app.kubernetes.io/name | アプリケーション名（redisなど） |
app.kubernetes.io/instance | アプリケーションの特定のインスタンスに固有の名称（redis-department-aなど） |
app.kubernetes.io/component | 何のためのコンポーネントかを示す識別子（login-cacheなど） |
app.kubernetes.io/part-of | リソースを使用したより高次レベルのアプリケーション（company-authなど） |
すべてのKubernetesオブジェクトをラベル付けすることで、インフラストラクチャとアプリケーションに関する俯瞰的視点を得るためのオブザーバビリティデータのクエリが可能になります。メトリクスをフィルタリングして、スタックのすべてのレイヤーを確認することができます。さらに、問題の根本原因を発見するために、より細かい詳細を掘り下げることも可能です。
理解しやすいラベルとセレクタの作成について、明確な、標準化された戦略を持つことは、Kubernetesの監視およびアラート戦略の重要です。最終的には、健全性とパフォーマンスのメトリクスは、自分が設定したラベル別にのみ集計が可能なのです。
New RelicでのKubernetes監視とオブザーバビリティ
ここまで、Kubernetesとは何なのか、また何ができ、なぜ監視を必要とするのか、さらに適切なKubernetes監視の設定方法のベストプラクティスを見てきました。
この複数回シリーズのその2では、Kubernetesのアーキテクチャーについて詳しく見ていきます。
次のステップ
また、実際に試してみたい方のために、あらかじめ構築されたダッシュボードやKubernetesの一連のアラームをご用意しました。New Relicのアカウントにご登録いただくと、すぐにご利用いただけます。無料のアカウントには、New Relicのすべてにフルアクセスできるユーザー1名と、そのレポートを閲覧できる基本ユーザー5名、さらに毎月100GBの無料データ取り込みが含まれています。
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
