Kubernetesとは？
「K8s」と略されることの多いKubernetesは、コンテナオーケストレーションの事実上のスタンダードとしての地位を確立している、オープンソースのプラットフォームです。CNCFの2021年の報告書によると、Kubernetesの使用は特に大規模組織において世界的に増加しており、現在、世界中でKubernetesを使用する開発者は、バックエンド開発者全体の31%を占める560万人となっています。
コンテナオーケストレーションシステムとして、あらゆるモダンアプリケーションのインフラストラクチャを構成するコンテナのスケジューリング、規模化、管理を自動的に行います。これはクラウドネイティブ・コンピューティング・ ファウンデーション（CNCF）の代表的プロジェクトです。GoogleやAWS、Microsoft、IBM、Intel、Cisco、Red Hatなどの主要企業のサポートを受けています。
Kubernetesでできること
Kubernetesは、アプリケーション実行に必要なソフトウェアを構成するコンテナ管理の日常的な運用タスクを自動化します。アプリケーションをデプロイするビルトインコマンドで、Kubernetesはアプリケーションの変更を展開したり、変化するニーズに合わせて規模を拡大・縮小したり、監視を行ったり、さらにさまざまなことを実行します。Kubernetesはコンテナの運用場所に関わらずオーケストレーションを行い、マルチクラウドのデプロイメントやインフラストラクチャプラットフォーム間の移行を促進します。つまり、Kubernetesで、アプリケーション管理がより容易になります。
自動化された健全性チェック
Kubernetesは、サービスに対する健全性チェックを実行し続けます。クラウドネイティブのアプリケーションにとって、これは一貫性あるコンテナ管理を意味します。自動化された健全性チェックを使用して、Kubernetesは失敗したり停滞しているコンテナを再起動させます。
運用の自動化
Kubernetesには、アプリケーション管理の手間のかかる部分の多くを引き受けるコマンドが組み込まれているため、システム管理作業を自動化することができます。Kubernetesにより、アプリケーションは設定の通りに、確実に実行することができます。
インフラストラクチャの抽象化
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）のインスタンス内かもしれません。しかし、オーケストレーションレイヤーによって管理されているアプリケーションを監視する際、インフラストラクチャのコンテクストがあると、たとえばそのアプリケーションが動作しているコンテナ、ポッド、またはホストなどのアプリケーションエラーのトレースと関連付けられるため、デバッグやトラブルシューティングに非常に有用な可能性があります。
Kubernetesの設定ラベル
Kubernetesは寿命が異なるコンテナの作成と削除を自動化します。このプロセス全体が監視される必要があります。変動要素が非常に多いため、メトリクスを対応するアプリケーション、ポッド、ネームスペース、ノードなどに相関させるには、組織全体での明確なラベル付けのポリシーを実施する必要があります。
さまざまなオブジェクトに一貫性のあるラベルを付与することで、これらのオブジェクトに関するKubernetesへのクエリが容易になります。たとえば、チームの開発者から本番環境が停止しているかどうかの問い合わせを受けたとします。もし本番ポッドに「prod」のラベルがついていれば、以下のkubectlコマンドを実行してそのログのすべてを入手できます。
kubectl get pods -l name=prod:NAME READY STATUS RESTARTS AGErouter-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 この例では、本番ポッドのひとつにイメージのプルに関する問題があることを発見し、その情報を本番ポッドを使用する開発者に伝えるかもしれません。もしラベルがなければ、ポッドを得るためkubectlの出力を手動で検索しなければならないでしょう。
一般的なラベル付けの慣例
上記の例では、ポッドに環境別の使用を特定する「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の監視およびアラート戦略の重要です。最終的には、健全性とパフォーマンスのメトリクスは、自分が設定したラベル別にのみ集計が可能なのです。
ここまで、Kubernetesとは何なのか、また何ができ、なぜ監視を必要とするのか、さらに適切なKubernetes監視の設定方法のベストプラクティスを見てきました。
この複数回シリーズの第2部では、Kubernetesのアーキテクチャーについて詳しく見ていこうと思います。
次のステップ
また、実際に試してみたい方のために、あらかじめ構築されたダッシュボードやKubernetesの一連のアラームをご用意しました。使用するには、今すぐNew Relicのアカウントにご登録ください。無料のアカウントには、New Relicのすべてにアクセスできる1ユーザーと、そのレポートを閲覧できる人数無制限の基本ユーザー、さらに毎月100GBの無料データが含まれます。
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
