Kubernetesのサービス品質保証(QoS)
6236 ワード
本文はKubernetesのサービス品質保証(QoS)【編集者の話】Kubernetesが現在主流の容器クラスタ管理プラットフォームとして、プラットフォームの資源使用状況を全体的に統一し、公平かつ合理的に資源を関連pod容器に分配して使用し、容器のライフサイクル内に十分な資源が運行を保証する必要がある.同時に、資源の配布の独占性、すなわち資源がすでにある容器に割り当てられているため、同じ資源が他の容器に割り当てられていないため、資源の利用率が比較的低い容器にとって、資源を占有して実際に使用していない(例えばCPU、メモリ)は厳しい資源の浪費をもたらし、Kubernetesは優先度と公平性などの角度から資源の利用率を高める必要がある.リソースの効率的なスケジューリングと割り当てを実現しながらリソースの利用率を向上させるため、Kubernetesは異なるサービス品質の予想に対して、QoS(Quality of Service)を通じてpodに対してサービス品質管理を行い、採用を提供した.
requests
および
limits
2つのタイプは、リソースの割り当てと使用制限を行います.1つのpodにとって、サービス品質は2つの具体的な指標であるCPUとメモリに現れている.実際のプロセスでは,NODEノード上のメモリリソースが不足している場合,kubernetesは予め設定された異なるQoSカテゴリに従って対応する処理を行う.
リソース制限の設定理由
ノードnodeSelector、親和性(node affinity)またはpod親和性、反親和性(pod affinity/anti-affinity)などのPod高度なスケジューリングポリシーを行ったことがない場合
設定により、指定したマシンにサービスを配置することはできません.これにより、cpuやメモリなどの密集型podが同じノードに同時に割り当てられ、リソース競合を引き起こす可能性があります.一方、リソースを制限していない場合、一部の重要なサービスは、OOM(Out of Memory)などの理由でリソース競合がkillされたり、CPUの使用が制限されたりする可能性がある.
リソース要件(Requests)と制限(Limits)
各リソースについてcontainerは、特定のリソース要件(requests)と制限(limits)を指定します.
requests
申請範囲は0～nodeノードの最大構成であり、
limits
申請範囲は
requests
無限、すなわち0<=requests<=Node Allocatable、requests<=limits<=Infinityまで.
CPUの場合、podのサービスでCPUが設定を超えた場合
limits
あ、podはkillに落ちませんが制限されます.設定されていない場合
limits
,podはすべての空きcpuリソースを使用することができる.
メモリの場合、podが設定を超えた場合
limits
、podのcontainerのプロセスはkernelがOOM killで削除されます.containerがOOMのためにkillによって削除されると、システムは、元のマシン上でcontainerまたはネイティブまたは他のpodを再起動する傾向があります.
QoS分類
KubeletはQoSサービス品質管理を提供し、システムレベルのOOM制御をサポートする.KubernetesではpodのQoSレベル:
Guaranteed
,
Burstable
と
Best-Effort
.各レベルについて説明します.
Guaranteed
:pod内のすべてのコンテナを統一的に設定する必要があります
limits
を選択し、設定パラメータが一致している場合は、コンテナを設定します.
requests
では、すべてのコンテナを設定し、パラメータを同じに設定します.
limits
一致して、それではこのpodのQoSは
Guaranteed
レベル.
注意:コンテナが1つだけ指定されている場合
limit
設定されていません
request
を選択します.
request
の値が等しい
limit
値を入力します.
Guaranteed例1:コンテナは
limits
指定されていません
requests
).
Guaranteedの例2:
requests
と
limit
いずれも指定され、値は等しい.
Burstable
:podには容器が1つしかない
requests
および
limits
の設定が異なり、このpodのQoSは
Burstable
.例を次に示します.
Container barが指定されていません
resources
Burstable
例2:Container fooとbarが異なる
resources
(fooはmemory、barはcpu)が設定されています
limits
.
Burstable
例3:Container fooが設定されていない
limits
で、bar
requests
と
limits
いずれも設定されていません.
Best-Effort
:すべてのresourcesにとって
requests
と
limits
いずれも設定されておらず、このpodのQoSは
Best-Effort
.例を次に示します.
圧縮可能リソースと非圧縮リソース
Kubernetesは,資源が伸縮できるか否かによって分類され,圧縮可能資源と非圧縮可能資源の2種類に分類される.CPUリソースは現在サポートされている圧縮可能なリソースであり、メモリリソースとディスクリソースは現在サポートされている非圧縮リソースである.
QoS優先度
3種類のQoS優先度が低いから高い(左から右へ):
静的pod
Kubernetesには、api serverの介入を必要とせずにノード上のkubeletサービスによって直接管理されるノードに常駐して実行できるDaemonSetタイプpodがあります.静的podはRCを関連付ける必要もなく、完全にkubeletサービスによって監視され、kubeletが静的podの停止を発見すると、kubeletは静的podを再起動します.
リソース回収ポリシー
kubernetesクラスタ内のノードで使用可能なリソースが比較的小さい場合、kubernetesは、ノードpodサービスが正常に動作するようにスケジューリングされることを保証するリソース回収ポリシーを提供します.ノード上のメモリまたはCPUリソースが消費されると、ノード上で動作しているpodサービスが不安定になる可能性があります.Kubernetesはkubeletによって回収ポリシー制御を行い,ノード上のpodがノードリソースの比較時間に安定して動作することを保証する.
圧縮可能リソース:CPU
圧縮リソース部では、podが設定を超えて使用される場合、CPUは圧縮可能なリソースに属すると述べている.
limits
値、podのプロセスでcpuを使用すると制限されますが、killは使用されません.
非圧縮リソース:メモリメモリ
Kubernetesは、cgroupによってpodにQoSレベルを設定し、リソースが不足している場合にkill優先度の低いpodを先に設定し、実際の使用中にOOMスコアで実現し、OOMスコアは0-1000からである.
OOMスコアはOOM_によるADJパラメータ計算により、Guaranteedレベルのpodに対して、OOM_ADJパラメータは-998に設定され、BestEffortレベルのpodに対してOOM_ADJパラメータは1000に設定され、BurstableレベルのPODに対してOOM_ADJパラメータは2から999までの値をとる.kubelet,docker,OOM_などのkuberntes保存リソースADJパラメータは-999に設定されており、OOM killに落とされないことを示しています.OOM_ADJパラメータ設定が大きいほど、OOM_ADJパラメータから算出されるOOMスコアが高いほど、pod優先度が低くなり、リソース競合が発生するとkillによって早く落ちることを示し、OOM_ADJパラメータは-999のkubernetesがOOMのためにkillされることはありません.
QoS podsはkillにシーンと順序を落とされる
Best-Effortタイプのpods:システムがすべてのメモリを使い切った場合、このタイプのpodsは最初にkillに落ちます.
Burstableタイプpods:システムがすべてのメモリを使い切っており、Best-Effort containerがkillされていない場合、このタイプのpodsはkillされます.
Guaranteed pods:システムはすべてのメモリを使い果たし、BurstableとBest-Effort containerがkillされず、このタイプのpodsはkillされます.注意:podプロセスがノードリソースではなく予め設定されたlimitesを超えるために緊張している場合、システムは元のマシンでcontainerまたはネイティブまたは他のpodを再作成する傾向があります.使用推奨リソースが十分な場合は、QoS podsタイプをGuaranteedに設定できます.コンピューティング・リソースでビジネス・パフォーマンスと安定性を向上させ、問題のトラブルシューティング時間とコストを削減します.
リソースの使用率を向上させるには、ビジネス・サービスをGuaranteedに設定し、他のサービスは重要度に応じてBurstableまたはBest-Effort、例えばfilebeatに設定します.
既知の問題
swapはサポートされていません.現在のQoSポリシーは、swapが禁止されていると仮定します.
参考資料
Resource Quality of Service in Kubernetes: https://github.com/kubernetes/... os.md
Introduction to Quality Of Service and Service Level Agreement: http://www.loriotpro.com/Produ ... N.htm
Kubelet pod level resource management: https://github.com/kubernetes/... nt.md
Kubelet - Eviction Policy: https://github.com/kubernetes/... on.md
転載を歓迎して、作者の出所を明記してください:張夏、FreeWheel Lead Engineer、DockOneコミュニティ
原文発表時間:2017-08-16
著者:張夏
この記事は、クラウドコミュニティのパートナーDockeroneから来ています.io、関連情報を知るにはDockeroneに注目することができます.io.
原文タイトル:Kubernetesのサービス品質保証(QoS)
requests
および
limits
2つのタイプは、リソースの割り当てと使用制限を行います.1つのpodにとって、サービス品質は2つの具体的な指標であるCPUとメモリに現れている.実際のプロセスでは,NODEノード上のメモリリソースが不足している場合,kubernetesは予め設定された異なるQoSカテゴリに従って対応する処理を行う.
リソース制限の設定理由
ノードnodeSelector、親和性(node affinity)またはpod親和性、反親和性(pod affinity/anti-affinity)などのPod高度なスケジューリングポリシーを行ったことがない場合
設定により、指定したマシンにサービスを配置することはできません.これにより、cpuやメモリなどの密集型podが同じノードに同時に割り当てられ、リソース競合を引き起こす可能性があります.一方、リソースを制限していない場合、一部の重要なサービスは、OOM(Out of Memory)などの理由でリソース競合がkillされたり、CPUの使用が制限されたりする可能性がある.
リソース要件(Requests)と制限(Limits)
各リソースについてcontainerは、特定のリソース要件(requests)と制限(limits)を指定します.
requests
申請範囲は0～nodeノードの最大構成であり、
limits
申請範囲は
requests
無限、すなわち0<=requests<=Node Allocatable、requests<=limits<=Infinityまで.
CPUの場合、podのサービスでCPUが設定を超えた場合
limits
あ、podはkillに落ちませんが制限されます.設定されていない場合
limits
,podはすべての空きcpuリソースを使用することができる.
メモリの場合、podが設定を超えた場合
limits
、podのcontainerのプロセスはkernelがOOM killで削除されます.containerがOOMのためにkillによって削除されると、システムは、元のマシン上でcontainerまたはネイティブまたは他のpodを再起動する傾向があります.
QoS分類
KubeletはQoSサービス品質管理を提供し、システムレベルのOOM制御をサポートする.KubernetesではpodのQoSレベル:
Guaranteed
,
Burstable
と
Best-Effort
.各レベルについて説明します.
Guaranteed
:pod内のすべてのコンテナを統一的に設定する必要があります
limits
を選択し、設定パラメータが一致している場合は、コンテナを設定します.
requests
では、すべてのコンテナを設定し、パラメータを同じに設定します.
limits
一致して、それではこのpodのQoSは
Guaranteed
レベル.
注意:コンテナが1つだけ指定されている場合
limit
設定されていません
request
を選択します.
request
の値が等しい
limit
値を入力します.
Guaranteed例1:コンテナは
limits
指定されていません
requests
).
containers:
name: foo
resources:
limits:
cpu: 10m
memory: 1Gi
name: bar
resources:
limits:
cpu: 100m
memory: 100Mi
Guaranteedの例2:
requests
と
limit
いずれも指定され、値は等しい.
containers:
name: foo
resources:
limits:
cpu: 10m
memory: 1Gi
requests:
cpu: 10m
memory: 1Gi
name: bar
resources:
limits:
cpu: 100m
memory: 100Mi
requests:
cpu: 100m
memory: 100Mi
Burstable
:podには容器が1つしかない
requests
および
limits
の設定が異なり、このpodのQoSは
Burstable
.例を次に示します.
Container barが指定されていません
resources
containers:
name: foo
resources:
limits:
cpu: 10m
memory: 1Gi
requests:
cpu: 10m
memory: 1Gi
name: bar
Burstable
例2:Container fooとbarが異なる
resources
(fooはmemory、barはcpu)が設定されています
limits
.
containers:
name: foo
resources:
limits:
memory: 1Gi
name: bar
resources:
limits:
cpu: 100m
Burstable
例3:Container fooが設定されていない
limits
で、bar
requests
と
limits
いずれも設定されていません.
containers:
name: foo
resources:
requests:
cpu: 10m
memory: 1Gi
name: bar
Best-Effort
:すべてのresourcesにとって
requests
と
limits
いずれも設定されておらず、このpodのQoSは
Best-Effort
.例を次に示します.
containers:
name: foo
resources:
name: bar
resources:
圧縮可能リソースと非圧縮リソース
Kubernetesは,資源が伸縮できるか否かによって分類され,圧縮可能資源と非圧縮可能資源の2種類に分類される.CPUリソースは現在サポートされている圧縮可能なリソースであり、メモリリソースとディスクリソースは現在サポートされている非圧縮リソースである.
QoS優先度
3種類のQoS優先度が低いから高い(左から右へ):
Best-Effort pods -> Burstable pods -> Guaranteed pods
静的pod
Kubernetesには、api serverの介入を必要とせずにノード上のkubeletサービスによって直接管理されるノードに常駐して実行できるDaemonSetタイプpodがあります.静的podはRCを関連付ける必要もなく、完全にkubeletサービスによって監視され、kubeletが静的podの停止を発見すると、kubeletは静的podを再起動します.
リソース回収ポリシー
kubernetesクラスタ内のノードで使用可能なリソースが比較的小さい場合、kubernetesは、ノードpodサービスが正常に動作するようにスケジューリングされることを保証するリソース回収ポリシーを提供します.ノード上のメモリまたはCPUリソースが消費されると、ノード上で動作しているpodサービスが不安定になる可能性があります.Kubernetesはkubeletによって回収ポリシー制御を行い,ノード上のpodがノードリソースの比較時間に安定して動作することを保証する.
圧縮可能リソース:CPU
圧縮リソース部では、podが設定を超えて使用される場合、CPUは圧縮可能なリソースに属すると述べている.
limits
値、podのプロセスでcpuを使用すると制限されますが、killは使用されません.
非圧縮リソース:メモリメモリ
Kubernetesは、cgroupによってpodにQoSレベルを設定し、リソースが不足している場合にkill優先度の低いpodを先に設定し、実際の使用中にOOMスコアで実現し、OOMスコアは0-1000からである.
OOMスコアはOOM_によるADJパラメータ計算により、Guaranteedレベルのpodに対して、OOM_ADJパラメータは-998に設定され、BestEffortレベルのpodに対してOOM_ADJパラメータは1000に設定され、BurstableレベルのPODに対してOOM_ADJパラメータは2から999までの値をとる.kubelet,docker,OOM_などのkuberntes保存リソースADJパラメータは-999に設定されており、OOM killに落とされないことを示しています.OOM_ADJパラメータ設定が大きいほど、OOM_ADJパラメータから算出されるOOMスコアが高いほど、pod優先度が低くなり、リソース競合が発生するとkillによって早く落ちることを示し、OOM_ADJパラメータは-999のkubernetesがOOMのためにkillされることはありません.
QoS podsはkillにシーンと順序を落とされる
Best-Effortタイプのpods:システムがすべてのメモリを使い切った場合、このタイプのpodsは最初にkillに落ちます.
Burstableタイプpods:システムがすべてのメモリを使い切っており、Best-Effort containerがkillされていない場合、このタイプのpodsはkillされます.
Guaranteed pods:システムはすべてのメモリを使い果たし、BurstableとBest-Effort containerがkillされず、このタイプのpodsはkillされます.注意:podプロセスがノードリソースではなく予め設定されたlimitesを超えるために緊張している場合、システムは元のマシンでcontainerまたはネイティブまたは他のpodを再作成する傾向があります.使用推奨リソースが十分な場合は、QoS podsタイプをGuaranteedに設定できます.コンピューティング・リソースでビジネス・パフォーマンスと安定性を向上させ、問題のトラブルシューティング時間とコストを削減します.
リソースの使用率を向上させるには、ビジネス・サービスをGuaranteedに設定し、他のサービスは重要度に応じてBurstableまたはBest-Effort、例えばfilebeatに設定します.
既知の問題
swapはサポートされていません.現在のQoSポリシーは、swapが禁止されていると仮定します.
参考資料
Resource Quality of Service in Kubernetes: https://github.com/kubernetes/... os.md
Introduction to Quality Of Service and Service Level Agreement: http://www.loriotpro.com/Produ ... N.htm
Kubelet pod level resource management: https://github.com/kubernetes/... nt.md
Kubelet - Eviction Policy: https://github.com/kubernetes/... on.md
転載を歓迎して、作者の出所を明記してください:張夏、FreeWheel Lead Engineer、DockOneコミュニティ
原文発表時間:2017-08-16
著者:張夏
この記事は、クラウドコミュニティのパートナーDockeroneから来ています.io、関連情報を知るにはDockeroneに注目することができます.io.
原文タイトル:Kubernetesのサービス品質保証(QoS)