K8S のアプリケーションのサービス品質 (QoS) の概要
Quality of Service (QoS) クラスは、Pod のスケジューリングとエビクションの優先順位を決定する Kubernetes の概念です。
Kubelet はこれを使用して、ポッドが削除される順序を管理するだけでなく、高度な CPU 管理戦略を使用してより複雑なポッドのスケジューリング決定を可能にします。
QoS は Kubernetes 自体によって Pod に割り当てられます。ただし、DevOps は、ポッド内の個々のコンテナに対するリソースのリクエストと制限を処理することで、コンテナに割り当てられた QoS クラスを制御できます。
QoSクラスの分類
保証: POD 内のすべてのコンテナー (初期化コンテナーを含む) には制限が均一に設定されている必要があり、設定パラメーターは一貫しています。
バースタブル: POD 内にメモリまたは CPU リクエストが設定されたコンテナがあります。
BestEffort: POD 内のすべてのコンテナーでは、CPU とメモリのリクエストと制限が指定されていません。
Guaranteed
对于 QoS 类为 Guaranteed 的 Pod：
Pod 中的每个容器，包含初始化容器，必须指定内存 请求和 内存 限制，并且两者要相等。
Pod 中的每个容器，包含初始化容器，必须指定 CPU 请求和 CPU 限制，并且两者要相等。
举例：
apiVersion: v1
kind: Pod
metadata:
name: qos-demo
spec:
containers:
- name: qos-demo
image: nginx
resources:
limits:
memory: "500Mi"
cpu: "700m"
requests:
memory: "500Mi"
cpu: "700m"
注意点：
如果容器指定了自己的内存limits，但没有指定内存requests，Kubernetes 会自动为它指定与内存limits匹配的内存requests。 同样，如果容器指定了自己的 CPU limits，但没有指定 CPU requests，Kubernetes 会自动为它指定与 CPU limits匹配的 CPU requests；
------------------------------------------------------------------------------
Burstable
如果满足下面条件，将会指定 Pod 的 QoS 类为 Burstable：
Pod 不符合 Guaranteed QoS 类的标准；
Pod 中至少一个容器具有内存 或 CPU requests；
举例：
apiVersion: v1
kind: Pod
metadata:
name: qos-demo2
spec:
containers:
- name: qos-demo2
image: nginx
resources:
limits:
memory: "500Mi"
requests:
memory: "200Mi"
--------------------------------------------------------------------------
BestEffort
对于 QoS 类为 BestEffort 的 Pod，Pod 中的容器必须没有设置内存和 CPU 限制或请求。
举例：
apiVersion: v1
kind: Pod
metadata:
name: qos-demo3
spec:
containers:
- name: qos-demo3
image: nginx
如何查看Qos
kubectl describe po qos-demoQoS優先度
3 つの QoS 優先順位 (左から右):
BestEffort ポッド -> バースト可能なポッド -> 保証されたポッド
追放の原則
圧縮可能なリソース: CPU
圧縮リソースのセクションで説明したように、CPU は圧縮可能なリソースであり、ポッドの使用率が設定された制限値を超えると、ポッド内のプロセスの CPU 使用率は制限されますが、強制終了されることはありません。
非圧縮リソース:メモリ
ノードが OOM の場合、保証型ポッド、バースタブル ポッド、ベストエフォート ポッドに対処するにはどうすればよいですか?
Kubelet がリサイクルできる前にノードのメモリが不足した場合、つまりノード oom が発生した場合、oom_killer はその oom_score に従ってコンテナを終了します。
「保証された」ポッド内のコンテナの oom_score_adj は「-998」です。
「BestEffort」ポッド内のコンテナーの場合、これは「1000」です。
「min(max(2, 1000-(1000*memoryRequestBytes)/machineMemoryCapacityBytes), 999」) の値を持つ Burstable Pod 内のコンテナー。
oom_killer はまず、QoS レベルが最も低く、最も要求されたリソースを超えるコンテナを終了します。これは、あまりにも多くのリソース リクエストを占有するコンテナが、エビクションのために最初に Burstable から選択されることを意味します。
ベストプラクティス
1. アプリケーションの種類による分類: コアアプリケーション (core) / 従来アプリケーション (nomarl) / 追加アプリケーション (extral)
2. コアアプリケーション: 保証型 / 通常アプリケーション: Burstable / 追加アプリケーション: BestEffort
3. クラスタ ノードは、コア アプリケーション ノード/通常のアプリケーション ノード/追加アプリケーション ノードに分割されます。
4. スケジュール戦略:
コア アプリケーション:nodeAffinity の優先スケジューリング戦略を採用することで、コア ノードにスケジュールできます。
通常のアプリケーション:nodeAffinity のハード アフィニティ スケジューリング戦略を使用して、通常のノードにスケジュールできます。
追加のアプリケーション:nodeAffinity のハード アフィニティ スケジューリング戦略を使用して、追加のノードにスケジュールできます。