上記の図のようにNodeのResourceにPodが3つあり、均等にリソースを使用している状態であると仮定する。
Pod1が追加でResourceが必要になった場合はどうなるか
NodeにはResourceがないため、Pod1はResource不足でダウンになってしまうか、それともKubernetesが他のPodをダウンさせてPod1に必要なResourceを割り当てるか
KubernetesはAppの重要度に応じてこの種の管理できるように3つの段階にQulity of Serviceをサポートしている。
この状態では、BestEffortに設定されたPodが一番最初にダウンされてResourceが返却され、Pod1は必要なResourceを使用できるようになる。
次はNodeにある程度のResourceが残っているが、Pod2からそれよりも多くのResourceを必要とする場合、Burstableに設定されたPodが
ダウンされてResourceが返却される。
Guaranteedが最後までPodを安全に維持させてくれるClassである。
QoSは特定のプロパティがあって設定するのはなく、ContainerにResource設定があり、ここでRequestsとLimitのMemoryとCPUをどのように設定するかによって決定される
Guaranteedは、Podに複数のContainerがある場合、全てのContainerにRequestsとLimitの設定が必要である。
そしてRequestsとLimitのmemory、cpuも設定をする必要があり、各Containerに設定されたMemoryとcpuの値は、RequestsとLimitが同じではないといけない。
このルールに一致すると、KubernetesがこのPodをGuaranteed Classに判断をする。
どのContainerにもRequestとLimitが設定されていない場合はBestEffortとして判断する。
BurstableはGuaranteedとBestEffortの特徴を持っていると考えれば良い。
すべてのContainerにRequestとLimitが設定されているが、Requestの値が小さいか、Requestだけ設定がされており、Limitは設定されていない場合、またはPodのContainerが2つなのに一つは、完全に設定されているが、他の1つが設定されていない場合はすべてBurstable Classになる。
このように3つのClassは、ContainerのRequestとLimitをどのように設定するかによって決定される。
Burstableに設定された複数Podの中でどのPodが最初に削除されるかと言うとOOM(Out Of Memory)Scoreによって決定される。
上の図の2つのPodのRequest Memoryが5Gと8Gに設定されているが、Appが実際に使っているMemoryが同じ4GだとするとPod2のMemory使用量は75％であり、Pod3は50％である。
OOM ScoreがPod2が75％で大きいので、KubernetesはPod2を最初に削除する。