Kubernetesデプロイメントのアンチパターン10選 第5章

今回はKubernetesデプロイメントのアンチパターンをご紹介します。長い記事なので、パターンを２つずつ５回に分けて投稿いたします。今回は5回目です。

9.デプロイが成功したかどうかを把握するためのメトリクスがない。(ヘルスチェックにはアプリケーションのサポートが必要)

ヘルスチェックにはアプリケーションのサポートが必要です。

コンテナオーケストレーションでは、Kubernetesを活用して多くのタスクを達成することができます。

• アプリケーションまたはチームによるリソース消費のコントロール（ネームスペース、CPU/メモリ、制限） アプリケーションが多くのリソースを消費しないようにする
• L異なるアプリケーションインスタンス間でロードバランシングを行い、リソースが不足している場合やホストが死んだ場合にアプリケーションインスタンスを1つのホストから別のホストに移動する
• セルフヒーリング — コンテナがクラッシュした場合の再起動
• 新しいホストがクラスタに追加された場合、追加リソースを自動的に活用する
• などなど

そのため、メトリクスやモニタリングのことを忘れてしまいがちになります。しかし、デプロイが成功したからといって、オペレーションの仕事が終わるわけではありません。積極的に行動し、予期せぬサプライズに備える方が良いのです。モニタリングすべきレイヤーはまだまだ多く、K8のダイナミックな性質のせいでトラブルシューティングが難しくなります。例えば、利用可能なリソースを注意深く監視していないと、ポッドの自動再スケジューリングによって容量の問題が発生し、アプリがクラッシュしたり、デプロイできなくなったりすることがあります。誰かがバグレポートを出したり、たまたまチェックしてみたりしないとわからないので、これは本番環境では特に難点になります。

モニタリングにはそれなりの課題があります。監視すべきレイヤーが多く、”エンジニアのメンテナンス負担を合理的に低く維持する必要があります”。Kubernetes上で実行されているアプリケーションに障害が発生した場合、調査すべき多くのログ、データ、コンポーネントがあり、特に問題に関与しているマイクロサービスが複数ある場合には、従来のモノリシックアーキテクチャではすべてがいくつかのログに出力されます。

アプリケーションの動作に関する知識（アプリケーションがどのように動作するかなど）は、継続的な改善をする際に役に立ちます。また、コンテナ、ポッド、サービス、クラスター全体的に見る必要があります。アプリケーションがリソースをどのように使用しているかを特定できれば、Kubernetesを使用してボトルネックをより良く検出して取り除くことができます。アプリケーションの全体像を把握するには、Prometheus, Grafana, New Relic、 Cisco AppDynamicsなどのアプリケーションパフォーマンス監視ソリューションを使用する必要があります。