🥇Kubernetes: システムリソース管理を構成することがなぜそれほど重要なのでしょうか?

原則として、アプリケーションが正しく安定して動作するためには、アプリケーションに専用のリソースプールを提供する必要が常にあります。しかし、複数のアプリケーションが同じ電源で実行されている場合はどうなるでしょうか? それぞれに必要最小限のリソースを提供するにはどうすればよいでしょうか? リソースの消費をどのように制限できるでしょうか? ノード間で負荷を正しく分散するにはどうすればよいでしょうか? アプリケーションの負荷が増加した場合に水平スケーリングメカニズムが確実に機能するようにするにはどうすればよいでしょうか?

システムに存在する主なリソースの種類から始める必要があります。これは、もちろん、プロセッサ時間と RAM です。 k8s マニフェストでは、これらのリソースタイプは次の単位で測定されます。

CPU - コア内
RAM - バイト単位

さらに、リソースごとに XNUMX 種類の要件を設定できます。 リクエスト и 制限。リクエスト - コンテナー (およびポッド全体) を実行するためのノードの空きリソースの最小要件を記述します。一方、制限は、コンテナーで使用できるリソースに対するハード制限を設定します。

マニフェストで両方のタイプを明示的に定義する必要はないことを理解することが重要ですが、動作は次のようになります。

リソースの制限のみが明示的に指定されている場合、このリソースに対するリクエストは自動的に制限に等しい値を取得します (これは、エンティティの記述を呼び出すことで確認できます)。それらの。実際、コンテナは実行に必要なリソースと同じ量に制限されます。
リソースに対してリクエストのみが明示的に指定されている場合、このリソースには上限は設定されません。コンテナはノード自体のリソースによってのみ制限されます。

特定のコンテナーのレベルだけでなく、次のエンティティを使用して名前空間レベルでもリソース管理を構成することもできます。

制限範囲 — コンテナ/ポッドレベルでの制限ポリシーを ns で記述します。これは、コンテナ/ポッドのデフォルトの制限を記述するだけでなく、明らかに太いコンテナ/ポッド (またはその逆) の作成を防止し、その数を制限するために必要です。そして、制限とリクエストの値に起こり得る差異を判断します
リソースクォータ — ns 内のすべてのコンテナに対する一般的な制限ポリシーを記述し、原則として環境間のリソースを区切るために使用されます (環境がノードレベルで厳密に区切られていない場合に役立ちます)

以下は、リソース制限を設定するマニフェストの例です。

特定のコンテナーレベルでは次のようになります。
```
containers:
- name: app-nginx
  image: nginx
  resources:
    requests:
      memory: 1Gi
    limits:
      cpu: 200m
```
それらの。この場合、nginx でコンテナを実行するには、ノード上に少なくとも 1G の空き RAM と 0.2 CPU が必要ですが、コンテナが消費できるのは最大でも 0.2 CPU とノード上のすべての利用可能な RAM です。
整数レベル ns では、次のようになります。
```
apiVersion: v1
kind: ResourceQuota
metadata:
  name: nxs-test
spec:
  hard:
    requests.cpu: 300m
    requests.memory: 1Gi
    limits.cpu: 700m
    limits.memory: 2Gi
```
それらの。デフォルトの ns 内のすべてのリクエストコンテナの合計は、CPU で 300m、OP で 1G を超えることはできません。すべての制限の合計は、CPU で 700m、OP で 2G です。
ns 単位のコンテナのデフォルト制限:
```
apiVersion: v1
kind: LimitRange
metadata:
  name: nxs-limit-per-container
spec:
 limits:
   - type: Container
     defaultRequest:
       cpu: 100m
       memory: 1Gi
     default:
       cpu: 1
       memory: 2Gi
     min:
       cpu: 50m
       memory: 500Mi
     max:
       cpu: 2
       memory: 4Gi
```
それらの。すべてのコンテナーのデフォルトの名前空間では、リクエストは CPU に 100m、OP に 1G に設定され、制限は 1 CPU と 2G に設定されます。同時に、CPU (50m < x < 2) および RAM (500M < x < 4G) のリクエスト/制限の可能な値にも制限が設定されます。
ポッドレベルの制限 ns:
```
apiVersion: v1
kind: LimitRange
metadata:
 name: nxs-limit-pod
spec:
 limits:
 - type: Pod
   max:
     cpu: 4
     memory: 1Gi
```
それらの。デフォルトの ns の各ポッドには、4 vCPU と 1G の制限があります。

ここで、これらの制限を設定することでどのようなメリットが得られるのかを説明したいと思います。

ノード間の負荷分散メカニズム

ご存知のとおり、k8s コンポーネントはノード間のポッドの分散を担当します。 スケジューラ、特定のアルゴリズムに従って動作します。このアルゴリズムは、起動する最適なノードを選択する際に XNUMX つの段階を経ます。

フィルタリング
レンジング

それらの。説明されたポリシーに従って、セットに基づいてポッドを起動できるノードが最初に選択されます。述語 (ノードにポッドを実行するのに十分なリソースがあるかどうかの確認 (PodFitsResources を含む))、次に、これらのノードごとに、次のようにします。 優先順位 ポイントが付与され (ノードの空きリソースが多いほど、より多くのポイントが割り当てられます - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation)、最も多くのポイントを持つノードでポッドが起動されます (複数のノードが一度にこの条件を満たした場合、ランダムに選択されます)。

同時に、スケジューラは、ノードの利用可能なリソースを評価するときに、etcd に保存されているデータによってガイドされることを理解する必要があります。このノードで実行されている各ポッドの要求/制限リソースの量ではなく、実際のリソース消費量ではありません。この情報はコマンド出力から取得できます。 kubectl describe node $NODEたとえば、次のようになります。

# kubectl describe nodes nxs-k8s-s1
..
Non-terminated Pods:         (9 in total)
  Namespace                  Name                                         CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGE
  ---------                  ----                                         ------------  ----------  ---------------  -------------  ---
  ingress-nginx              nginx-ingress-controller-754b85bf44-qkt2t    0 (0%)        0 (0%)      0 (0%)           0 (0%)         233d
  kube-system                kube-flannel-26bl4                           150m (0%)     300m (1%)   64M (0%)         500M (1%)      233d
  kube-system                kube-proxy-exporter-cb629                    0 (0%)        0 (0%)      0 (0%)           0 (0%)         233d
  kube-system                kube-proxy-x9fsc                             0 (0%)        0 (0%)      0 (0%)           0 (0%)         233d
  kube-system                nginx-proxy-k8s-worker-s1                    25m (0%)      300m (1%)   32M (0%)         512M (1%)      233d
  nxs-monitoring             alertmanager-main-1                          100m (0%)     100m (0%)   425Mi (1%)       25Mi (0%)      233d
  nxs-logging                filebeat-lmsmp                               100m (0%)     0 (0%)      100Mi (0%)       200Mi (0%)     233d
  nxs-monitoring             node-exporter-v4gdq                          112m (0%)     122m (0%)   200Mi (0%)       220Mi (0%)     233d
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests           Limits
  --------           --------           ------
  cpu                487m (3%)          822m (5%)
  memory             15856217600 (2%)  749976320 (3%)
  ephemeral-storage  0 (0%)             0 (0%)

ここでは、特定のノードで実行されているすべてのポッドと、各ポッドが要求するリソースが表示されます。 cronjob-cron-events-1573793820-xt6q9 ポッドが起動されたときのスケジューラーログは次のようになります (この情報は、起動コマンド -v=10 の引数に 10 番目のログレベルが設定されている場合にスケジューラーログに表示されます) ):

カモメ

I1115 07:57:21.637791       1 scheduling_queue.go:908] About to try and schedule pod nxs-stage/cronjob-cron-events-1573793820-xt6q9                                                                                                                                           
I1115 07:57:21.637804       1 scheduler.go:453] Attempting to schedule pod: nxs-stage/cronjob-cron-events-1573793820-xt6q9                                                                                                                                                    
I1115 07:57:21.638285       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s5 is allowed, Node is running only 16 out of 110 Pods.                                                                               
I1115 07:57:21.638300       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s6 is allowed, Node is running only 20 out of 110 Pods.                                                                               
I1115 07:57:21.638322       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s3 is allowed, Node is running only 20 out of 110 Pods.                                                                               
I1115 07:57:21.638322       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s4 is allowed, Node is running only 17 out of 110 Pods.                                                                               
I1115 07:57:21.638334       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s10 is allowed, Node is running only 16 out of 110 Pods.                                                                              
I1115 07:57:21.638365       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s12 is allowed, Node is running only 9 out of 110 Pods.                                                                               
I1115 07:57:21.638334       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s11 is allowed, Node is running only 11 out of 110 Pods.                                                                              
I1115 07:57:21.638385       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s1 is allowed, Node is running only 19 out of 110 Pods.                                                                               
I1115 07:57:21.638402       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s2 is allowed, Node is running only 21 out of 110 Pods.                                                                               
I1115 07:57:21.638383       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s9 is allowed, Node is running only 16 out of 110 Pods.                                                                               
I1115 07:57:21.638335       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s8 is allowed, Node is running only 18 out of 110 Pods.                                                                               
I1115 07:57:21.638408       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s13 is allowed, Node is running only 8 out of 110 Pods.                                                                               
I1115 07:57:21.638478       1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s10 is allowed, existing pods anti-affinity terms satisfied.                                                                         
I1115 07:57:21.638505       1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s8 is allowed, existing pods anti-affinity terms satisfied.                                                                          
I1115 07:57:21.638577       1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s9 is allowed, existing pods anti-affinity terms satisfied.                                                                          
I1115 07:57:21.638583       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s7 is allowed, Node is running only 25 out of 110 Pods.                                                                               
I1115 07:57:21.638932       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: BalancedResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 2343 millicores 9640186880 memory bytes, score 9        
I1115 07:57:21.638946       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: LeastResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 2343 millicores 9640186880 memory bytes, score 8           
I1115 07:57:21.638961       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: BalancedResourceAllocation, capacity 39900 millicores 66620170240 memory bytes, total request 4107 millicores 11307422720 memory bytes, score 9        
I1115 07:57:21.638971       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: BalancedResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 5847 millicores 24333637120 memory bytes, score 7        
I1115 07:57:21.638975       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: LeastResourceAllocation, capacity 39900 millicores 66620170240 memory bytes, total request 4107 millicores 11307422720 memory bytes, score 8           
I1115 07:57:21.638990       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: LeastResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 5847 millicores 24333637120 memory bytes, score 7           
I1115 07:57:21.639022       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: TaintTolerationPriority, Score: (10)                                                                                                        
I1115 07:57:21.639030       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: TaintTolerationPriority, Score: (10)                                                                                                         
I1115 07:57:21.639034       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: TaintTolerationPriority, Score: (10)                                                                                                         
I1115 07:57:21.639041       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: NodeAffinityPriority, Score: (0)                                                                                                            
I1115 07:57:21.639053       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: NodeAffinityPriority, Score: (0)                                                                                                             
I1115 07:57:21.639059       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: NodeAffinityPriority, Score: (0)                                                                                                             
I1115 07:57:21.639061       1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: InterPodAffinityPriority, Score: (0)                                                                                                                   
I1115 07:57:21.639063       1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: SelectorSpreadPriority, Score: (10)                                                                                                                   
I1115 07:57:21.639073       1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: InterPodAffinityPriority, Score: (0)                                                                                                                    
I1115 07:57:21.639077       1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: SelectorSpreadPriority, Score: (10)                                                                                                                    
I1115 07:57:21.639085       1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: InterPodAffinityPriority, Score: (0)                                                                                                                    
I1115 07:57:21.639088       1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: SelectorSpreadPriority, Score: (10)                                                                                                                    
I1115 07:57:21.639103       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: SelectorSpreadPriority, Score: (10)                                                                                                         
I1115 07:57:21.639109       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: SelectorSpreadPriority, Score: (10)                                                                                                          
I1115 07:57:21.639114       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: SelectorSpreadPriority, Score: (10)                                                                                                          
I1115 07:57:21.639127       1 generic_scheduler.go:781] Host nxs-k8s-s10 => Score 100037                                                                                                                                                                            
I1115 07:57:21.639150       1 generic_scheduler.go:781] Host nxs-k8s-s8 => Score 100034                                                                                                                                                                             
I1115 07:57:21.639154       1 generic_scheduler.go:781] Host nxs-k8s-s9 => Score 100037                                                                                                                                                                             
I1115 07:57:21.639267       1 scheduler_binder.go:269] AssumePodVolumes for pod "nxs-stage/cronjob-cron-events-1573793820-xt6q9", node "nxs-k8s-s10"                                                                                                               
I1115 07:57:21.639286       1 scheduler_binder.go:279] AssumePodVolumes for pod "nxs-stage/cronjob-cron-events-1573793820-xt6q9", node "nxs-k8s-s10": all PVCs bound and nothing to do                                                                             
I1115 07:57:21.639333       1 factory.go:733] Attempting to bind cronjob-cron-events-1573793820-xt6q9 to nxs-k8s-s10

ここでは、最初にスケジューラがフィルタリングを行い、起動できる 3 つのノード (nxs-k8s-s8、nxs-k8s-s9、nxs-k8s-s10) のリストを生成していることがわかります。次に、これらの各ノードのいくつかのパラメーター (BalancedResourceAllocation、LeastResourceAllocation など) に基づいてスコアを計算し、最適なノードを決定します。最終的に、ポッドは最も高いポイント数を持つノードにスケジュールされます (ここでは、100037 つのノードが同時に同じポイント数 8 を持っているため、ランダムな 10 つ (nxs-kXNUMXs-sXNUMX) が選択されます)。

出力: ノードが制限が設定されていないポッドを実行する場合、k8s の場合 (リソース消費の観点から)、このノードにはそのようなポッドがまったく存在していないかと同じになります。したがって、条件付きで大食いプロセス (wowza など) を持つポッドがあり、それに制限が設定されていない場合、このポッドが実際にノードのすべてのリソースを消費する状況が発生する可能性がありますが、k8s の場合はこのノードがはアンロードされているとみなされ、ランク付け時に (正確には利用可能なリソースを評価するポイントで) 動作中のポッドを持たないノードと同じポイントが付与されます。これにより、最終的にノード間で負荷が不均等に分散される可能性があります。

ポッドのエビクション

ご存知のとおり、各ポッドには 3 つの QoS クラスのいずれかが割り当てられます。

保証された — ポッド内の各コンテナーでメモリと CPU のリクエストと制限が指定され、これらの値が一致する必要がある場合に割り当てられます。
破裂しやすい — ポッド内の少なくとも XNUMX つのコンテナーにリクエストと制限があり、リクエスト < 制限です。
ベストエフォート — ポッド内のリソースが制限されているコンテナーが XNUMX つもない場合

同時に、ノードでリソース (ディスク、メモリ) の不足が発生すると、kubelet はポッドの優先順位とその QoS クラスを考慮した特定のアルゴリズムに従ってポッドのランク付けと削除を開始します。たとえば、RAM について話している場合、QoS クラスに基づいて、次の原則に従ってポイントが付与されます。

保証された：-998
最大限の努力：００７
破裂性: min(max(2, 1000 - (1000 * メモリリクエストバイト) / マシンメモリ容量バイト), 999)

それらの。同じ優先順位で、kubelet は最初にベストエフォート QoS クラスのポッドをノードから削除します。

出力: リソースが不足した場合に、目的のポッドがノードから削除される可能性を減らしたい場合は、優先順位とともに、リクエスト/制限の設定にも注意する必要があります。

アプリケーションポッドの水平自動スケーリングのメカニズム (HPA)

タスクが、k8s エンティティなどのリソース (システム - CPU/RAM またはユーザー - RPS) の使用状況に応じてポッドの数を自動的に増減することである場合。 HPA (水平ポッドオートスケーラー)。そのアルゴリズムは次のとおりです。

監視されているリソースの現在の読み取り値が決定されます (currentMetricValue)
リソースの望ましい値 (desiredMetricValue) が決定されます。システムリソースの値は、リクエストを使用して設定されます。
現在のレプリカ数が決定されます (currentReplicas)
次の式は、必要なレプリカ数 (desiredReplicas) を計算します。
望ましいレプリカ = [ 現在のレプリカ * ( 現在のメトリック値 / 望ましいメトリック値 )]

この場合、係数 (currentMetricValue /desiredMetricValue) が 1 に近い場合、スケーリングは発生しません (この場合、許容誤差を自分で設定できます。デフォルトでは 0.1 です)。

アプリテストアプリケーション (デプロイメントとして説明) の例を使用して、hpa がどのように機能するかを見てみましょう。ここでは、CPU 消費量に応じてレプリカの数を変更する必要があります。

アプリケーションマニフェスト

kind: Deployment
apiVersion: apps/v1beta2
metadata:
name: app-test
spec:
selector:
matchLabels:
app: app-test
replicas: 2
template:
metadata:
labels:
app: app-test
spec:
containers:
- name: nginx
image: registry.nixys.ru/generic-images/nginx
imagePullPolicy: Always
resources:
requests:
cpu: 60m
ports:
- name: http
containerPort: 80
- name: nginx-exporter
image: nginx/nginx-prometheus-exporter
resources:
requests:
cpu: 30m
ports:
- name: nginx-exporter
containerPort: 9113
args:
- -nginx.scrape-uri
- http://127.0.0.1:80/nginx-status

それらの。アプリケーションポッドが最初に XNUMX つのインスタンスで起動され、それぞれのインスタンスに XNUMX つの nginx コンテナーと nginx-exporter コンテナーが含まれていることがわかります。 リクエスト CPU用。

HPAマニフェスト

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: app-test-hpa
spec:
maxReplicas: 10
minReplicas: 2
scaleTargetRef:
apiVersion: extensions/v1beta1
kind: Deployment
name: app-test
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 30

それらの。デプロイメントのアプリテストを監視し、CPU インジケーターに基づいてアプリケーションのポッド数を調整する hpa を作成しました (ポッドは要求する CPU の 30% を消費すると予想されます)。レプリカの数は次のとおりです。 2～10の範囲で。

ここで、炉床の XNUMX つに負荷を加えた場合の HPA 動作のメカニズムを見てみましょう。

 # kubectl top pod
NAME                                                   CPU(cores)   MEMORY(bytes)
app-test-78559f8f44-pgs58            101m         243Mi
app-test-78559f8f44-cj4jz            4m           240Mi

合計すると次のとおりです。

望ましい値 (desiredMetricValue) - hpa 設定によれば、30% です。
現在の値 (currentMetricValue) - 計算のために、コントローラーマネージャーはリソース消費の平均値を % で計算します。条件付きで次のことを行います。
1. メトリクスサーバーからポッドメトリクスの絶対値を受け取ります。 101mと4m
2. 平均絶対値を計算します。 (101m + 4m) / 2 = 53m
3. 必要なリソース消費の絶対値を取得します (このために、すべてのコンテナのリクエストが合計されます) 60m + 30m = 90m
4. リクエストポッドに対する CPU 消費の平均パーセンテージを計算します。 53m / 90m * 100% = 59%

これで、レプリカの数を変更する必要があるかどうかを判断するために必要なものがすべて揃ったので、そのために係数を計算します。

ratio = 59% / 30% = 1.96

それらの。レプリカの数は約 2 倍に増加し、[2 * 1.96] = 4 になります。

結論： ご覧のとおり、このメカニズムが機能するために必要な条件は、監視対象のポッド内のすべてのコンテナーに対するリクエストが存在することです。

ノードの水平自動スケーリングのメカニズム (クラスターオートスケーラー)

負荷サージ時にシステムへの悪影響を中和するには、hpa を設定するだけでは十分ではありません。たとえば、hpa コントローラーマネージャーの設定に従って、レプリカの数を 2 倍に増やす必要があると判断しますが、ノードにはそのような数のポッドを実行するための空きリソースがありません (つまり、ノードは要求されたリソースをリクエストポッドに送信し、これらのポッドは保留状態に切り替わります。

この場合、プロバイダーが対応する IaaS/PaaS (GKE/GCE、AKS、EKS など) を持っている場合、次のようなツール ノードオートスケーラー。これにより、クラスター内のノードの最大数と最小数を設定し、クラスターとポッドにリソースが不足している場合に (クラウドプロバイダー API を呼び出してノードを注文/削除することで) 現在のノード数を自動的に調整できます。スケジュールできません (保留状態になっています)。

結論： ノードを自動スケールできるようにするには、k8s がノードの負荷を正しく評価し、それに応じて次のポッドを起動するためのリソースがクラスター内にないことを報告できるように、ポッドコンテナーにリクエストを設定する必要があります。

まとめ

コンテナーのリソース制限を設定することは、アプリケーションを正常に実行するための要件ではありませんが、次の理由により、設定することをお勧めします。

k8s ノード間の負荷分散に関するスケジューラのより正確な動作のため
「ポッドのエビクション」イベントが発生する可能性を減らすため
アプリケーションポッド (HPA) の水平自動スケーリングが機能するには
クラウドプロバイダー向けのノードの水平自動スケーリング (クラスター自動スケーリング) 用

私たちのブログの他の記事もお読みください。

出所： habr.com

Kubernetes: システム リソース管理を構成することがなぜそれほど重要なのでしょうか?

ノード間の負荷分散メカニズム

ポッドのエビクション

アプリケーション ポッドの水平自動スケーリングのメカニズム (HPA)

ノードの水平自動スケーリングのメカニズム (クラスター オートスケーラー)

まとめ

私たちのブログの他の記事もお読みください。

コメントを追加します 返信をキャンセル

Kubernetes: システムリソース管理を構成することがなぜそれほど重要なのでしょうか?

アプリケーションポッドの水平自動スケーリングのメカニズム (HPA)

ノードの水平自動スケーリングのメカニズム (クラスターオートスケーラー)

コメントを追加します返信をキャンセル