Kubernetes クラスター安定稼働の実現に向けたモニタリングのポイント
Author : 会澤 康二 (New Relic 株式会社)
近年はコンテナでアプリケーションを稼働させるケースが増えています。本番環境でコンテナアプリケーションを信頼性高く稼働させるためにはオーケストレーションサービスが欠かせません。
AWS から提供されているコンテナオーケストレーションサービスは Amazon Elastic Container Service (ECS) と Amazon Elastics Kubernetes Serivice (EKS) の 2 つがあります。Amazon ECS も Amazon EKS も、共にコントロールプレーンとデータプレーンと呼ばれるコンポーネントに別れます。さらに、AWS ではデータプレーンは Amazon EC2 と AWS Fargate という 2 種類のタイプに別れます。全部で 4 パターンになります。
この記事では、Amazon EKS on Amazon EC2 を例に、Kubernetes クラスターを安定に稼働させるために必要なモニタリングの観点を整理するとともに、New Relic を使って具体的に実現する手順について解説します。
ご注意
本記事で紹介する AWS サービスを起動する際には、料金がかかります。builders.flash メールメンバー特典の、クラウドレシピ向けクレジットコードプレゼントの入手をお勧めします。
Amazon EKS クラスターの安定稼働の実現に向けてみるべきポイント
前述した通り、Amazon EKS は、コントロールプレーン、データプレーンで構成され、データプレーンの上でコンテナが稼働しています。もうお気づきだと思いますが、本番環境でコンテナアプリケーションを監視するには、コンテナの監視だけでなく、クラスターを構成する各コンポーネントそれぞれの監視が必要になります。
ここからは、各コンポーネントでどのような観点で監視していけば良いかを、もう少し深掘りしていきます。
1. コントロールプレーンの監視
Amazon EKS の場合、コントロールプレーンはマネージドで提供されるため、可溶性や信頼性に関しては利用者が管理する必要がありません。素の Kubernetes はコントロールプレーンの管理負荷が高いため、Amazon EKS のようにコントロールプレーンの管理を AWS にオフロードできるのは大きなメリットになります。コントロールプレーンが安定的なパフォーマンスで動いているのか (*1) だけをみていけば良いことになります、
2. データプレーンの監視
ここは通常のサーバー監視と同様の観点で監視を行います。CPU やメモリの使用状況、ディスク使用状況やネットワーク IO などです。また、個々のサーバーだけでなく、サーバー全体のキャパシティがどの程度あり、コンテナ側からどの程度の使用要求があり、実際どの程度使用されているのか、という観点で監視することが大切になります。なお、AWS では、このデータプレーンのオプションとして、AWS Fargate というサービスを提供しています。AWS Fargate を選択することで、データプレーンの管理からも解放できます。必要に応じてこちらも選択するのも良いでしょう。
3. コンテナ (Pod) の監視
コンテナの実態はサーバー内の実際の 1 つのプロセスになります。ですので、サーバー監視をしている方からすると、プロセス監視を行う観点と似ています。コンテナがいくつ稼働しているか、そのコンテナが要求する最低限のリソース量はどのくらいか、要求したリソース量に対して、実際どの程度のリソースを使用しているか、などです。基本的にはコンテナのリソース使用量が適切であるかどうかを監視します。これに加えて、Kubernetes を使用していることでコンテナはダイナミックにステータスが変化するケースがあるので、そこも捉えていきます。
*1 : API Server や DNS クエリのスループットやレスポンスタイムなど
コンテナ (Pod) の状態変化を継続的に把握する重要性
Kubernetes 上で動く Pod やコンテナ独自の監視ポイントとしてピックアップしたいのは「コンテナの状態変化を継続的に把握すること」です。
コンテナは、要求したリソース量が確保できない、コンテナ起動時の初期処理に失敗した、などの理由で、正常にクラスターに配置できない場合があります。この場合、コントロールプレーンは、自己修復性の一環でなんとかそのコンテナを正常に稼働させようと、コンテナの再作成や再起動を試みます。また、コンテナのリソース使用量が要求量に比べて過剰な場合には、コントロールプレーンによってコンテナが強制停止され、コンテナを再起動するケースもあります。
いずれの場合でも、クラスターの自己修復性によって自動的に回復され、事なきを得ることが多いです。それがオーケストレーションを利用するメリットでもあります。しかしながら、これらの事象が継続的に発生しているとなると話は別です。何か別の問題で再作成や再起動が繰り返されていると、最悪の場合、致命的な問題に発展する可能性もあります。
クラスターの管理者としては、コンテナの予期せぬ停止や再作成、再起動が継続的に発生していないかをしっかりと捉えることが重要になります。
ここからは、これらの状態をNew Relicで捉えていくための具体的な設定方法について解説します。
Amazon EKS on Amazon EC2 環境の各種データを New Relic に取り込む手順
本記事では、以下の作業を行います。
- AWS Integration の有効化
Amazon CloudWatch メトリクスのデータを New Relic に連携します。 - Kubernetes Integration の有効化
Kubernetes クラスターに Daemon Set を配置して、クラスター上の各種メトリクス、ログ、イベントなどのデータを収集します。
それでは始めましょう。
Step 1 : AWS Integration の有効化
まず、New Relic の画面から Add more data をクリックして AWS 連携を選択します。基本的にはこのガイドに沿って操作するだけです。具体的な流れを見ていきます。
1. IAM Role の作成
AWS マネジメントコンソール にログインし、画面に表示されている通りの手順で IAM Role を作成します。
- Another AWS Account というタイプを選択します
- Account ID に 754728514883 を入力します
- Require external ID にチェックを入れます
- External ID に 2528582 と入力します
ここまで入力できたら、New Relic 画面の Next をクリックします。
次に、この IAM Role にアタッチするポリシーを選択します。たくさんのポリシーがありますので、ReadOnlyAccess を選択します。そして New Relic 側で Next をクリックします。
IAM Role 名を入力します。New Relic 連携用であることをはっきりさせる為に、NewRelicInfrastructure-Integrations というような名前を推奨しています。
作成された IAM Role の ARN を控えておきます。
(Option) AWS Budget の情報も連携させる場合は、以下のインラインポリシーを追加します。
{
"Statement": [
{
"Action": [
"budgets:ViewBudget"
],
"Effect": "Allow",
"Resource": "*"
}
],
"Version": "2012-10-17"
}最後に、New Relic 側の画面で、New Relic 側で一意になる名前と控えておいた ARN をコピー & ペーストします。
以上で AWS 連携設定は完了です。
2. データを確認する
数分後には New Relic 側の画面で各種メトリクスが確認できるようになります。
クリックすると拡大します
利用している AWS リソースのダッシュボードをみてデータが来ていることを確認してみましょう。例えば EC2 であれば、リージョンごとの EC2 台数やステータス状況、タイプごとの起動台数などが確認できます。
クリックすると拡大します
Step 2 : Kubernetes Integration の有効化
次は Kubernetes クラスターに New Relic へデータを送信するエージェント群をデプロイします。こちらも、New Relic の画面から Add more data をクリックして設定を開始し、ガイドに沿って操作するだけです。具体的な流れを見ていきます。
データ送信先の New Relic アカウント、クラスター名、kubernetes integration をデプロイする namespace を指定して Continue をクリックします。
Kubernetes integration で有効化する機能を選択します。基本的にはデフォルトのままで良いですが、必要に応じてチェックしましょう。
すると、デプロイする Helm コマンドが表示されますので、これをターミナルから実行します。
※マニフェストとしてダウンロードすることも可能です。
クリックすると拡大します
数分待つとクラスター内からデータが送信され、New Relic 上でデータを確認できるようになります。
New Relic の Kubernetes Integration で収集されるデータは 公式ドキュメント を参照してください。
クリックすると拡大します
New Relic Kubernetes Cluster Explorer を開くと、ノードと Pod の負荷状況やステータスが一目でわかり、クラスター全体の状況を確認することができます。
クリックすると拡大します
収集したデータは NRQL という強力なクエリ言語を使って、独自のダッシュボードを作成することができます。よりワークロードに特化した情報を整理して 1 つの画面にまとめて表示することも可能になります。また、下図のように、コンテナ (Pod) のステータスや再起動状況、致命的なステータスとなっているコンテナ (Pod) の発生推移なども見ることができます。
まとめ
いかがでしたでしょうか ? New Relic を使うと、Amazon EKS on Amazon EC2 環境におけるクラスター全体の情報を簡単に収集し、可視化することができます。また、本記事ではご紹介しなかった New Relic APM や New Relic Browser を利用すると、インフラの情報だけでなくアプリケーションパフォーマンスの状況やユーザー体験も可視化することができます。サービス全体を End to End で Full-stack に観測し続けることで、より迅速なトラブルの検知・対応が可能になります。これを機会にぜひ New Relic をご活用ください。
筆者紹介
会澤 康二
New Relic 株式会社 Solutions Consultant
SIer にてシステム開発プロジェクトの PM やインフラ設計・構築などを歴任。その後、クラウドインテグレーション組織の立ち上げを行い、多くのお客様システムのクラウド移行を支援。近年は DevOps やクラウドネイティブ化へ向けたコンテナや Kubernetes、CI/CD などの技術要素の導入支援を行い、現職。現在は DevRel を通じた文化醸成に興味を持っている。
AWS を無料でお試しいただけます