Karpenterでメモリのオーバーヘッドを見抜く方法！
Karpenterを使ってKubernetesクラスタのノードをプロビジョニングする際、どれだけのメモリがシステムのオーバーヘッドとして消費されているか、気になったことはありませんか？そんなときに大活躍するのが、NodeClaimリソースのstatusフィールドです！
ここでは、capacityとallocatableのメモリ値を比較するだけで、事前に計算された静的なオーバーヘッドが分かります。
NodeClaimの基本をおさらい
Karpenterでは、各ノードのリソース情報がNodeClaimリソースに記録されています。特に注目すべきは以下の2点です：
- capacity: ノードが持つ総リソース量
- allocatable: Podに実際に割り当て可能なリソース
この2つの値の差が、システムやKubernetes自体の動作に必要なオーバーヘッドとなっています！
メモリのオーバーヘッドをYAML例で確認
以下のYAMLは、メモリにフォーカスしたNodeClaimの例です。
apiVersion: karpenter.sh/v1
kind: NodeClaim
status:
allocatable:
cpu: 95590m
ephemeral-storage: 88Gi
memory: 173400Mi
pods: "110"
vpc.amazonaws.com/pod-eni: "107"
capacity:
cpu: "96"
ephemeral-storage: 100Gi
memory: 181862Mi
pods: "110"
vpc.amazonaws.com/pod-eni: "107"
この例では、ノードのメモリ総量（capacity）は 181862Mi なのに対し、実際にPodに割り当て可能なメモリ（allocatable）は 173400Mi です。
つまり、181862Mi - 173400Mi = 8462Mi のメモリがオーバーヘッドとしてシステム用に確保されていることがわかります！
経緯
Karpenterの実装コードを読んだとき、EC2NodeClassでsystemReservedを省略すると単純に100Miのメモリのオーバーヘッドになると考えていました。
karpenter-provider-aws/pkg/providers/instancetype/types.go at eff767c9754db6af33fce191e3d23fde65d7d11b · aws/karpenter-provider-aws
しかし、実際に検証してみると予想を大きく上回るオーバーヘッドが発生していたのです！