Blogical

AWS/Salesforceを中心に様々な情報を配信していきます(/・ω・)/

Kubernetes の起動分析

こんにちは、ロジカル・アーツ 井上です。

今回は、Kubernetes 環境において起動状況の確認をすることで、コンテナリソースのモニタリングをする方法について書かせていただきます。

Kubernetes 環境を運用される方は、Podが利用するリソースの利用領域を最適化するためにどのような工夫が必要か考えたことがあると思います。

WhaTap モニタリングでは、Podの起動分析機能が用意されています。

起動分析では、Podが安定的に動作するまでの性能を分析し、リソースの安定運用を目指すことができます。

Podの優先順位の確認

Kubernetes クラスタ環境において、Quality of Service(QoS)クラスをPodに割り当てることで、

リソースモニタリングを実施する運用について記載します。

WhaTap モニタリングでは、Podのリソース状況を判断して優先順位を設定します。

Kubernetes はPod起動時に、QoSクラスがPodに割りあてられます。 ・Guaranteed ・Burstable ・BestEffort

GuaranteedのPodが作成されるのは、

 ・Pod内のすべてのコンテナにメモリーの制限と要求が与えられており、同じ値であること。

 ・Pod内のすべてのコンテナにCPUの制限と要求が与えられており、同じ値であること。

となっております。

BurstableのPodが作成されるのは、

 ・PodがGuaranteed QoSクラスの基準に満たない場合。

 ・Pod内の1つ以上のコンテナがメモリーまたはCPUの要求を与えられている場合。

BestEffortのPodが作成されるのは、

 ・Podのすべてのコンテナに対して、CPU及びメモリの上限値の要求がない場合。

となっており、リソースの上限値が設定されていないことにより優先度が低くなり、最初に終了します。

Kubernetes の環境において、Burstableのものが多くなっている状況では、リソースが不足していることが読み取れます。

逆に、Guaranteedだけになっている場合には、ノード側のリソースが豊富すぎる場合を検討しなければならないかもしれません。

全体のPod量に対してのGuaranteed、Burstableの割合アプリのパフォーマンスに対して定義しておくのがよいかと思います。

#コンテナの再起動回数による分析

WhaTap モニタリングのPod起動分析では、コンテナの起動時の詳細情報が参照できます。

状態の遷移として、Pending→Running→Stable Runnigが表示されます。

Pending区間が長い場合には、リソース不足がノード側とポート重複がしているかもしれません。

Wating状態になっている場合には、「イメージ名が正しいか」「イメージをレジストリにプッシュされているか」「イメージがプルできるか」などを確認する必要があります。

また、コンテナの再起動回数も表示されます。

再起動回数が多い場合には、起動されたコンテナが正常に動作しているか確認をしてみてください。