🥇カスタムスケジューリングルールセットを使用して追加の kube-scheduler を作成する

Kube-scheduler は Kubernetes の不可欠なコンポーネントであり、指定されたポリシーに従ってノード間でポッドをスケジュールする役割を果たします。多くの場合、デフォルトの kube-scheduler のポリシーセットはほとんどの日常タスクに適しているため、Kubernetes クラスターの運用中にポッドのスケジュールにどのポリシーが使用されるかを考える必要はありません。ただし、ポッドを割り当てるプロセスを微調整することが重要な状況があり、このタスクを達成するには次の XNUMX つの方法があります。

カスタムのルールセットを使用して kube-scheduler を作成する
独自のスケジューラを作成し、API サーバーのリクエストを処理するように教えます。

この記事では、私たちのプロジェクトの XNUMX つにおける炉床の不均一なスケジュールの問題を解決するための最初のポイントの実装について説明します。

kube-scheduler の仕組みの簡単な紹介

kube-scheduler はポッドの直接のスケジューリングを担当せず、ポッドを配置するノードを決定することのみを担当するという事実に特に注目する価値があります。言い換えれば、kube-scheduler の作業の結果はノードの名前であり、スケジューリングリクエストのために API サーバーに返され、そこで作業が終了します。

まず、kube-scheduler は、述語ポリシーに従ってポッドをスケジュールできるノードのリストをコンパイルします。次に、このリストの各ノードは、優先順位ポリシーに従って特定の数のポイントを受け取ります。その結果、最大のポイント数を持つノードが選択されます。同じ最大スコアを持つノードが存在する場合、ランダムなノードが選択されます。述語 (フィルタリング) ポリシーと優先順位 (スコアリング) ポリシーのリストと説明は、次の場所にあります。ドキュメンテーション.

問題本体の説明

Nixys では多数の異なる Kubernetes クラスターが維持されていますが、ポッドのスケジュールの問題に初めて遭遇したのはつい最近のことで、プロジェクトの 100 つで多数の定期タスク (約 24 個の CronJob エンティティ) を実行する必要があったときでした。問題の説明をできるだけ簡単にするために、XNUMX つのマイクロサービスを例に挙げます。このマイクロサービスでは、cron タスクが XNUMX 分に XNUMX 回起動され、CPU に負荷がかかります。 cron タスクを実行するために、まったく同じ特性を持つ XNUMX つのノードが割り当てられました (それぞれに XNUMX 個の vCPU)。

同時に、入力データの量は常に変化するため、CronJob の実行にかかる時間を正確に言うことは不可能です。平均して、kube-scheduler の通常の動作中、各ノードは 3 ～ 4 個のジョブインスタンスを実行し、各ノードの CPU に最大 20 ～ 30% の負荷が生じます。

問題自体は、6 つのノードのうち 8 つで cron タスクポッドがスケジュールされなくなる場合があることです。つまり、ある時点で、いずれかのノードには単一のポッドが計画されておらず、他の 40 つのノードではタスクの 60 ～ XNUMX 個のコピーが実行されており、CPU 負荷の約 XNUMX ～ XNUMX% が生じています。

この問題は完全にランダムな頻度で再発し、場合によってはコードの新しいバージョンが公開された瞬間と相関関係がありました。

kube-scheduler のログレベルをレベル 10 (-v=10) に上げることで、評価プロセス中に各ノードが獲得したポイント数の記録を開始しました。通常の計画操作中に、次の情報がログに記録される可能性があります。

resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node03: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1387 millicores 4161694720 memory bytes, score 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node02: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1347 millicores 4444810240 memory bytes, score 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node03: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1387 millicores 4161694720 memory bytes, score 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node01: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1687 millicores 4790840320 memory bytes, score 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node02: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1347 millicores 4444810240 memory bytes, score 9
resource_allocation.go:78] cronjob-1574828880-mn7m4 -> Node01: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1687 millicores 4790840320 memory bytes, score 9
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node01: NodeAffinityPriority, Score: (0)                                                                                       
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node02: NodeAffinityPriority, Score: (0)                                                                                       
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node03: NodeAffinityPriority, Score: (0)                                                                                       
interpod_affinity.go:237] cronjob-1574828880-mn7m4 -> Node01: InterPodAffinityPriority, Score: (0)                                                                                                        
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node01: TaintTolerationPriority, Score: (10)                                                                                   
interpod_affinity.go:237] cronjob-1574828880-mn7m4 -> Node02: InterPodAffinityPriority, Score: (0)                                                                                                        
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node02: TaintTolerationPriority, Score: (10)                                                                                   
selector_spreading.go:146] cronjob-1574828880-mn7m4 -> Node01: SelectorSpreadPriority, Score: (10)                                                                                                        
interpod_affinity.go:237] cronjob-1574828880-mn7m4 -> Node03: InterPodAffinityPriority, Score: (0)                                                                                                        
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node03: TaintTolerationPriority, Score: (10)                                                                                   
selector_spreading.go:146] cronjob-1574828880-mn7m4 -> Node02: SelectorSpreadPriority, Score: (10)                                                                                                        
selector_spreading.go:146] cronjob-1574828880-mn7m4 -> Node03: SelectorSpreadPriority, Score: (10)                                                                                                        
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node01: SelectorSpreadPriority, Score: (10)                                                                                    
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node02: SelectorSpreadPriority, Score: (10)                                                                                    
generic_scheduler.go:726] cronjob-1574828880-mn7m4_project-stage -> Node03: SelectorSpreadPriority, Score: (10)                                                                                    
generic_scheduler.go:781] Host Node01 => Score 100043                                                                                                                                                                        
generic_scheduler.go:781] Host Node02 => Score 100043                                                                                                                                                                        
generic_scheduler.go:781] Host Node03 => Score 100043

それらの。ログから得られた情報から判断すると、各ノードは同じ数の最終ポイントを獲得し、計画のためにランダムなポイントが選択されました。問題のある計画の時点では、ログは次のようになっていました。

resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node02: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1587 millicores 4581125120 memory bytes, score 9
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node03: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1087 millicores 3532549120 memory bytes, score 9
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node02: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1587 millicores 4581125120 memory bytes, score 9
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node01: BalancedResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 987 millicores 3322833920 memory bytes, score 9
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node01: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 987 millicores 3322833920 memory bytes, score 9 
resource_allocation.go:78] cronjob-1574211360-bzfkr -> Node03: LeastResourceAllocation, capacity 23900 millicores 67167186944 memory bytes, total request 1087 millicores 3532549120 memory bytes, score 9
interpod_affinity.go:237] cronjob-1574211360-bzfkr -> Node03: InterPodAffinityPriority, Score: (0)                                                                                                        
interpod_affinity.go:237] cronjob-1574211360-bzfkr -> Node02: InterPodAffinityPriority, Score: (0)                                                                                                        
interpod_affinity.go:237] cronjob-1574211360-bzfkr -> Node01: InterPodAffinityPriority, Score: (0)                                                                                                        
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node03: TaintTolerationPriority, Score: (10)                                                                                   
selector_spreading.go:146] cronjob-1574211360-bzfkr -> Node03: SelectorSpreadPriority, Score: (10)                                                                                                        
selector_spreading.go:146] cronjob-1574211360-bzfkr -> Node02: SelectorSpreadPriority, Score: (10)                                                                                                        
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node02: TaintTolerationPriority, Score: (10)                                                                                   
selector_spreading.go:146] cronjob-1574211360-bzfkr -> Node01: SelectorSpreadPriority, Score: (10)                                                                                                        
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node03: NodeAffinityPriority, Score: (0)                                                                                       
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node03: SelectorSpreadPriority, Score: (10)                                                                                    
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node02: SelectorSpreadPriority, Score: (10)                                                                                    
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node01: TaintTolerationPriority, Score: (10)                                                                                   
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node02: NodeAffinityPriority, Score: (0)                                                                                       
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node01: NodeAffinityPriority, Score: (0)                                                                                       
generic_scheduler.go:726] cronjob-1574211360-bzfkr_project-stage -> Node01: SelectorSpreadPriority, Score: (10)                                                                                    
generic_scheduler.go:781] Host Node03 => Score 100041                                                                                                                                                                        
generic_scheduler.go:781] Host Node02 => Score 100041                                                                                                                                                                        
generic_scheduler.go:781] Host Node01 => Score 100038

ここから、ノードの XNUMX つが他のノードより最終的なポイントのスコアが少なかったため、最大スコアを獲得した XNUMX つのノードに対してのみ計画が実行されたことがわかります。したがって、問題はまさにポッドのスケジュールにあると私たちは確信していました。

問題を解決するためのさらなるアルゴリズムは、私たちにとって明らかでした。ログを分析し、ノードがどの優先順位によってポイントを獲得しなかったかを理解し、必要に応じて、デフォルトの kube-scheduler のポリシーを調整します。ただし、ここで XNUMX つの重大な問題に直面します。

最大ロギングレベル（10）では、一部の優先度でのみ獲得したポイントが反映されます。上記のログの抜粋では、ログに反映されているすべての優先順位について、ノードは通常のスケジューリングと問題のスケジューリングで同じポイントを獲得しますが、問題のプランニングの場合の最終結果は異なることがわかります。したがって、一部の優先順位ではスコアリングが「舞台裏」で行われ、ノードがどの優先順位でポイントを獲得できなかったのかを理解する方法がないと結論付けることができます。この問題については、次の記事で詳しく説明しました。問題 Github 上の Kubernetes リポジトリ。この記事の執筆時点では、Kubernetes v1.15,1.16、1.17、および XNUMX のアップデートでログ記録のサポートが追加される予定であるという回答が開発者から受け取られています。
kube-scheduler が現在どの特定のポリシーセットを使用しているかを理解する簡単な方法はありません。はい、でドキュメンテーションこのリストにはリストされていますが、各優先ポリシーにどのような特定の重みが割り当てられているかに関する情報は含まれていません。デフォルトの kube-scheduler の重みを確認したりポリシーを編集したりできるのは、ソースコード.

ノードが ImageLocalityPriority ポリシーに従ってポイントを受け取らなかったことを記録できたことは注目に値します。このポリシーは、アプリケーションの実行に必要なイメージをノードにすでに持っている場合にポイントを付与します。つまり、アプリケーションの新しいバージョンがロールアウトされた時点で、cron タスクは XNUMX つのノード上で実行でき、docker レジストリから新しいイメージをそれらのノードにダウンロードしたため、XNUMX つのノードは XNUMX 番目のノードに比べて高い最終スコアを受け取りました。。

上で書いたように、ログには ImageLocalityPriority ポリシーの評価に関する情報が表示されないため、仮定を確認するために、アプリケーションの新しいバージョンを含むイメージを XNUMX 番目のノードにダンプしました。その後、スケジューリングは正しく機能しました。。 ImageLocalityPriority ポリシーのおかげで、スケジュールの問題がほとんど観察されず、他の何かに関連していることがより多くありました。デフォルトの kube-scheduler の優先順位のリストにある各ポリシーを完全にはデバッグできなかったため、ポッドスケジューリングポリシーを柔軟に管理する必要がありました。

問題の定式化

私たちは、問題の解決策をできるだけ具体的にしたいと考えていました。つまり、Kubernetes の主要なエンティティ (ここでは、デフォルトの kube-scheduler を意味します) は変更しないでください。私たちは、ある場所で問題を解決し、別の場所で問題を引き起こすことを望んでいませんでした。したがって、この問題を解決するには、記事の冒頭で発表した XNUMX つのオプション、つまり追加のスケジューラを作成するか、独自のスケジューラを作成するかという選択肢にたどり着きました。 cron タスクをスケジュールするための主な要件は、XNUMX つのノード間で負荷を均等に分散することです。この要件は既存の kube-scheduler ポリシーによって満たされるため、問題を解決するために独自のスケジューラーを作成する意味はありません。

追加の kube-scheduler を作成してデプロイする手順については、「ドキュメンテーション。しかし、kube-scheduler のような重要なサービスの運用における耐障害性を確保するには、Deployment エンティティだけでは十分ではないと思われたため、新しい kube-scheduler を静的ポッドとしてデプロイし、直接監視することにしました。キュベレット著。したがって、新しい kube-scheduler には次の要件があります。

サービスはすべてのクラスターマスターに静的ポッドとしてデプロイする必要があります
kube-scheduler を備えたアクティブなポッドが使用できない場合に備えて、フォールトトレランスを提供する必要がある
計画時の主な優先事項は、ノード上で利用可能なリソースの数 (LeastRequestedPriority) である必要があります。

実装ソリューション

すべての作業を Kubernetes v1.14.7 で実行することにすぐに注目してください。これはプロジェクトで使用されたバージョンです。新しい kube-scheduler のマニフェストを書くことから始めましょう。デフォルトのマニフェスト (/etc/kubernetes/manifests/kube-scheduler.yaml) をベースとして、次の形式にします。

kind: Pod
metadata:
  labels:
    component: scheduler
    tier: control-plane
  name: kube-scheduler-cron
  namespace: kube-system
spec:
      containers:
      - command:
        - /usr/local/bin/kube-scheduler
        - --address=0.0.0.0
        - --port=10151
        - --secure-port=10159
        - --config=/etc/kubernetes/scheduler-custom.conf
        - --authentication-kubeconfig=/etc/kubernetes/scheduler.conf
        - --authorization-kubeconfig=/etc/kubernetes/scheduler.conf
        - --v=2
        image: gcr.io/google-containers/kube-scheduler:v1.14.7
        imagePullPolicy: IfNotPresent
        livenessProbe:
          failureThreshold: 8
          httpGet:
            host: 127.0.0.1
            path: /healthz
            port: 10151
            scheme: HTTP
          initialDelaySeconds: 15
          timeoutSeconds: 15
        name: kube-scheduler-cron-container
        resources:
          requests:
            cpu: '0.1'
        volumeMounts:
        - mountPath: /etc/kubernetes/scheduler.conf
          name: kube-config
          readOnly: true
        - mountPath: /etc/localtime
          name: localtime
          readOnly: true
        - mountPath: /etc/kubernetes/scheduler-custom.conf
          name: scheduler-config
          readOnly: true
        - mountPath: /etc/kubernetes/scheduler-custom-policy-config.json
          name: policy-config
          readOnly: true
      hostNetwork: true
      priorityClassName: system-cluster-critical
      volumes:
      - hostPath:
          path: /etc/kubernetes/scheduler.conf
          type: FileOrCreate
        name: kube-config
      - hostPath:
          path: /etc/localtime
        name: localtime
      - hostPath:
          path: /etc/kubernetes/scheduler-custom.conf
          type: FileOrCreate
        name: scheduler-config
      - hostPath:
          path: /etc/kubernetes/scheduler-custom-policy-config.json
          type: FileOrCreate
        name: policy-config

主な変更点について簡単に説明します。

ポッドとコンテナの名前を kube-scheduler-cron に変更しました
オプションが定義されているので、ポート 10151 および 10159 の使用を指定しました。 hostNetwork: true また、デフォルトの kube-scheduler と同じポート (10251 および 10259) を使用することはできません。
--config パラメータを使用して、サービスを開始する構成ファイルを指定しました。
ホストからの構成ファイル (scheduler-custom.conf) およびスケジューリングポリシーファイル (scheduler-custom-policy-config.json) のマウントの構成

kube-scheduler にはデフォルトと同様の権限が必要であることを忘れないでください。クラスターの役割を編集します。

kubectl edit clusterrole system:kube-scheduler

...
   resourceNames:
    - kube-scheduler
    - kube-scheduler-cron
...

次に、構成ファイルとスケジュールポリシーファイルに何を含めるべきかについて説明します。

設定ファイル（scheduler-custom.conf）
デフォルトの kube-scheduler 構成を取得するには、パラメータを使用する必要があります --write-config-to のドキュメンテーション。結果の構成をファイル /etc/kubernetes/scheduler-custom.conf に配置し、次の形式に縮小します。

apiVersion: kubescheduler.config.k8s.io/v1alpha1
kind: KubeSchedulerConfiguration
schedulerName: kube-scheduler-cron
bindTimeoutSeconds: 600
clientConnection:
  acceptContentTypes: ""
  burst: 100
  contentType: application/vnd.kubernetes.protobuf
  kubeconfig: /etc/kubernetes/scheduler.conf
  qps: 50
disablePreemption: false
enableContentionProfiling: false
enableProfiling: false
failureDomains: kubernetes.io/hostname,failure-domain.beta.kubernetes.io/zone,failure-domain.beta.kubernetes.io/region
hardPodAffinitySymmetricWeight: 1
healthzBindAddress: 0.0.0.0:10151
leaderElection:
  leaderElect: true
  leaseDuration: 15s
  lockObjectName: kube-scheduler-cron
  lockObjectNamespace: kube-system
  renewDeadline: 10s
  resourceLock: endpoints
  retryPeriod: 2s
metricsBindAddress: 0.0.0.0:10151
percentageOfNodesToScore: 0
algorithmSource:
   policy:
     file:
       path: "/etc/kubernetes/scheduler-custom-policy-config.json"

主な変更点について簡単に説明します。

ここでは、schedulerName を kube-scheduler-cron サービスの名前に設定します。
パラメータで lockObjectName また、サービスの名前を設定し、パラメータが次のとおりであることを確認する必要があります。 leaderElect true に設定します (マスターノードが XNUMX つある場合は、それを false に設定できます)。
パラメータにスケジュールポリシーの説明を含むファイルへのパスを指定しました algorithmSource.

キーのパラメータを編集する XNUMX 番目のポイントを詳しく見てみる価値があります。 leaderElection。耐障害性を確保するために、(leaderElect) 単一のエンドポイントを使用して、kube スケジューラーのポッド間のリーダー (マスター) を選択するプロセス (resourceLock) 名前付き kube-scheduler-cron (lockObjectName) kube-system 名前空間 (lockObjectNamespace）。 Kubernetes が主要コンポーネント (kube-scheduler を含む) の高可用性をどのように確保するかについては、以下を参照してください。 статье.

スケジュールポリシーファイル（scheduler-custom-policy-config.json）
前に書いたように、デフォルトの kube-scheduler がどの特定のポリシーで動作するのかは、そのコードを分析することによってのみわかります。つまり、構成ファイルと同じ方法では、デフォルトの kube-scheduler のスケジューリングポリシーを含むファイルを取得できません。 /etc/kubernetes/scheduler-custom-policy-config.json ファイルに関心のあるスケジューリングポリシーを次のように記述してみましょう。

{
  "kind": "Policy",
  "apiVersion": "v1",
  "predicates": [
    {
      "name": "GeneralPredicates"
    }
  ],
  "priorities": [
    {
      "name": "ServiceSpreadingPriority",
      "weight": 1
    },
    {
      "name": "EqualPriority",
      "weight": 1
    },
    {
      "name": "LeastRequestedPriority",
      "weight": 1
    },
    {
      "name": "NodePreferAvoidPodsPriority",
      "weight": 10000
    },
    {
      "name": "NodeAffinityPriority",
      "weight": 1
    }
  ],
  "hardPodAffinitySymmetricWeight" : 10,
  "alwaysCheckAllPredicates" : false
}

したがって、kube-scheduler はまず、GeneralPredicates ポリシー (PodFitsResources、PodFitsHostPorts、HostName、および MatchNodeSelector ポリシーのセットを含む) に従ってポッドをスケジュールできるノードのリストをコンパイルします。次に、各ノードは、優先順位配列内の一連のポリシーに従って評価されます。私たちのタスクの条件を満たすには、このような一連のポリシーが最適な解決策であると考えました。詳細な説明を含む一連のポリシーは、次の場所で入手できることを思い出してください。ドキュメンテーション。タスクを達成するには、使用するポリシーのセットを変更し、それらに適切な重みを割り当てるだけです。

この章の冒頭で作成した新しい kube-scheduler のマニフェストを kube-scheduler-custom.yaml と名付け、XNUMX つのマスターノード上のパス /etc/kubernetes/manifests に配置しましょう。すべてが正しく行われると、Kubelet は各ノードでポッドを起動し、新しい kube-scheduler のログに、ポリシーファイルが正常に適用されたという情報が表示されます。

Creating scheduler from configuration: {{ } [{GeneralPredicates <nil>}] [{ServiceSpreadingPriority 1 <nil>} {EqualPriority 1 <nil>} {LeastRequestedPriority 1 <nil>} {NodePreferAvoidPodsPriority 10000 <nil>} {NodeAffinityPriority 1 <nil>}] [] 10 false}
Registering predicate: GeneralPredicates
Predicate type GeneralPredicates already registered, reusing.
Registering priority: ServiceSpreadingPriority
Priority type ServiceSpreadingPriority already registered, reusing.
Registering priority: EqualPriority
Priority type EqualPriority already registered, reusing.
Registering priority: LeastRequestedPriority
Priority type LeastRequestedPriority already registered, reusing.
Registering priority: NodePreferAvoidPodsPriority
Priority type NodePreferAvoidPodsPriority already registered, reusing.
Registering priority: NodeAffinityPriority
Priority type NodeAffinityPriority already registered, reusing.
Creating scheduler with fit predicates 'map[GeneralPredicates:{}]' and priority functions 'map[EqualPriority:{} LeastRequestedPriority:{} NodeAffinityPriority:{} NodePreferAvoidPodsPriority:{} ServiceSpreadingPriority:{}]'

ここで残っているのは、CronJob の仕様で、ポッドをスケジュールするためのすべてのリクエストが新しい kube-scheduler によって処理される必要があることを示すことだけです。

...
 jobTemplate:
    spec:
      template:
        spec:
          schedulerName: kube-scheduler-cron
...

まとめ

最終的に、独自のスケジューリングポリシーセットを備えた追加の kube スケジューラーを取得しました。その作業は kubelet によって直接監視されます。さらに、古いリーダーが何らかの理由で利用できなくなった場合に備えて、kube スケジューラーのポッド間で新しいリーダーを選出するように設定しました。

通常のアプリケーションとサービスは引き続きデフォルトの kube-scheduler を通じてスケジュールされ、すべての cron タスクは新しいものに完全に転送されました。 cron タスクによって生成される負荷は、すべてのノードに均等に分散されるようになりました。 cron タスクのほとんどがプロジェクトのメインアプリケーションと同じノードで実行されることを考慮すると、リソース不足によるポッドの移動のリスクが大幅に軽減されます。追加の kube-scheduler を導入した後、cron タスクの不均一なスケジュールの問題は発生しなくなりました。

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

出所： habr.com

カスタム スケジューリング ルール セットを使用して追加の kube-scheduler を作成する

kube-scheduler の仕組みの簡単な紹介

問題本体の説明

問題の定式化

実装ソリューション

まとめ

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

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

カスタムスケジューリングルールセットを使用して追加の kube-scheduler を作成する

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