KubernetesのCPU limits設定時における「不要なスロットリング」を回避する方法とは？

Kubernetesを使った大規模なコンテナ管理を行う場合は、コンテナがノードのリソースを使い切ってしまうのを防ぐために、Podのオプションとして「requests」と「limits」を記述しておくのがベストプラクティスとされています。しかし、SNS管理サービスのBufferのエンジニアであるEric Khun氏は、CPUのlimitsを使わずにKubernetesを運用し、サービスの高速化に成功したと語っています。

Kubernetes: Make your services faster by removing CPU limits · Eric Khun
https://erickhun.com/posts/kubernetes-faster-services-no-cpu-limits/

Kubernetesを利用したコンテナ管理を行う場合、ノードのリソース不足によってkubeletといったKubernetesの主要プロセスが応答不能になることを防ぐために、Podの構成ファイルに「requests」と「limits」を指定することが推奨されています。requestsはコンテナに割り当てる最低限のリソースを、limitsはコンテナに割り当てる最大リソースを設定するもので、CPUの制限値はミリコア(1000ミリコア＝1コア)単位で指定します。

KubernetesはCFSクォータという仕組みを使って、コンテナの使用するCPUリソースがlimitsの値を超えないようにコンテナに割り当てるリソースを減少させます。この調整はスロットリングと呼ばれますが、BufferはコンテナのCPU使用量がlimitsに達していないにもかかわらず、コンテナがスロットリングされているのを発見したとのこと。グラフを確認すると、コンテナのCPU使用量は200ミリコア程度で、limits値の800ミリコアに達していないにもかかわらず、Pod内でスロットリングが発生していることがわかります。この問題はLinuxカーネルのバグに起因するもので、GitHubのKubernetesリポジトリにもIssueが作成されていました。

コンテナに対する不要なスロットリングは、サービスの応答速度を遅延させる原因です。Bufferでは検討を重ねた結果、CPUのlimitsを撤廃することにしたとのこと。しかし、単純にCPUのlimitsを撤廃するだけでは、安定性の観点からは望ましいとは言えません。Bufferでも過去にCPUのlimits撤廃をテストしたことがあったそうですが、コンテナの過剰なリソース消費によってkubeletが応答不能に陥り、ノードのステータスがNotReadyになった結果、別のノードでPodが再スケジューリングされ、そのノードでまた問題が発生するという悪循環が起こったとのこと。

そこでBufferは、応答速度の確保が最優先のサービスを特定のノードで稼働させ、そのノード内のPodのみCPUのlimitsを撤廃したとKhun氏は説明。具体的には、CPUのlimits未設定のPodにTaintを付与することで、CPUのlimitsを設定しているPodが稼働するノード群にlimits未設定のPodがスケジューリングされないようにしているとのこと。

これでサービス全体が不安定になることは避けられましたが、CPUのlimits未設定のPodが稼働するノード群では、依然としてリソースの過剰消費は起こりえます。Khun氏はこの問題に対し、想定されるコンテナの最大CPU使用量に20％の余裕を持たせた値をPodのrequestsに設定し、ノードのリソースがコンテナに割り当てるリソースに対して余裕を持つようにしたとのこと。これでノード内のコンテナ群がリソースを使い切ってしまうことは避けられますが、「コンテナ密度」、つまり単一ノード内で稼働させることができるコンテナ数が減少してしまうのが欠点だとKhun氏は説明。

CPUのlimitsを撤廃する前後のサービス応答速度を比較した結果が以下。1列目は撤廃前の応答速度、2列は撤廃後の応答速度、3列目は撤廃前と比較して撤廃後に応答速度がどれほど改善したかを表しており、ほぼすべてのサービスで応答速度の改善が見られます。

特に、Bufferの主要ページである「buffer.com」では、応答を22倍高速化できたとのこと。

なお、不要なスロットリングを引き起こしていたLinuxカーネルのバグは、DebianやUbuntu、EKSの最新バージョンで修正済み。GKEでも修正が行われたそうですが、まだ不要なスロットリングが報告されています。