커스텀 스케줄링 규칙 세트로 추가 kube-scheduler 생성

Kube-scheduler는 지정된 정책에 따라 노드 전체에서 Pod를 예약하는 Kubernetes의 필수 구성 요소입니다. 종종 Kubernetes 클러스터를 운영하는 동안 기본 kube-scheduler의 정책 세트가 대부분의 일상 작업에 적합하기 때문에 포드를 예약하는 데 정확히 어떤 정책이 사용되는지 생각할 필요가 없습니다. 그러나 포드 배포를 미세 조정하는 것이 중요한 상황이 있으며 이 작업을 수행하는 두 가지 방법이 있습니다.

1. 커스텀 규칙 세트로 kube-scheduler 생성
2. 자신의 스케줄러를 작성하고 API 서버 요청과 함께 작동하도록 가르칩니다.

이 기사에서는 우리 프로젝트 중 하나에서 고르지 않은 포드 스케줄링 문제를 해결하기 위한 첫 번째 포인트 구현에 대해 설명합니다.

kube-scheduler'a 작업에 대한 간략한 소개

주목할 만한 점은 kube-scheduler가 포드를 직접 예약하는 일을 담당하지 않는다는 사실입니다. 포드를 배치할 노드를 결정하는 일만 담당합니다. 즉, kube-scheduler의 작업 결과는 스케줄링 요청을 위해 API 서버에 반환하는 노드의 이름이며 여기에서 작업이 종료됩니다.

먼저 kube-scheduler는 조건자 정책에 따라 포드를 예약할 수 있는 노드를 나열합니다. 또한 이 목록의 각 노드는 우선 순위 정책에 따라 특정 점수를 받습니다. 결과적으로 점수가 가장 높은 노드가 선택됩니다. 최대 점수가 같은 노드가 있으면 임의의 노드가 선택됩니다. 조건자(필터링) 및 우선 순위(점수 지정) 정책의 목록 및 설명은 다음에서 찾을 수 있습니다. 선적 서류 비치.

문제 본문에 대한 설명

Nixys에서 유지 관리되는 다양한 Kubernetes 클러스터에도 불구하고 우리는 프로젝트 중 하나에서 많은 수의 주기적 작업(~ 100 CronJob 엔터티)을 실행해야 하는 최근에야 포드 예약 문제에 처음으로 직면했습니다. 가능한 한 문제에 대한 설명을 단순화하기 위해 예를 들어 크론 작업이 24분에 한 번 시작되어 CPU에 약간의 부하를 생성하는 하나의 마이크로 서비스를 살펴보겠습니다. 크론 작업을 위해 XNUMX개의 완전히 동일한 노드(각 노드에 XNUMX개의 vCPU)가 할당되었습니다.

동시에 입력 데이터의 양이 지속적으로 변하기 때문에 CronJob이 얼마나 오래 실행될지 정확히 말할 수 없습니다. 평균적으로 일반적인 kube-scheduler 작업 중에 각 노드는 3~4개의 작업 인스턴스를 실행하며 각 노드의 CPU 부하의 ~20~30%를 생성합니다.

문제 자체는 때때로 cron 작업 포드가 세 노드 중 하나에 대한 예약을 중지한다는 것입니다. 즉, 어떤 시점에서 노드 중 하나에 대해 단일 포드가 계획되지 않은 반면 6-8개의 작업 인스턴스가 다른 두 노드에서 실행되어 CPU 부하의 ~40-60%를 생성했습니다.

문제는 절대적으로 임의의 빈도로 반복되었으며 때때로 새 버전의 코드를 롤아웃하는 순간과 관련이 있습니다.

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

이를 통해 하나의 노드가 다른 노드보다 총 점수가 낮음을 알 수 있으므로 최대 점수를 얻은 두 개의 노드에 대해서만 계획을 세웠습니다. 따라서 우리는 문제가 정확히 포드 계획에 있다고 확신했습니다.

문제를 해결하기 위한 추가 알고리즘은 우리에게 분명했습니다. 로그를 분석하고 노드가 포인트를 얻지 못한 우선 순위를 이해하고 필요한 경우 기본 kube-scheduler의 정책을 조정합니다. 그러나 여기서 우리는 두 가지 중요한 어려움에 직면하게 됩니다.

1. 최대 로깅 수준(10)은 일부 우선 순위에 대해서만 포인트 집합을 반영합니다. 위의 로그 발췌에서 로그에 반영된 모든 우선 순위에 대해 노드가 정상 및 문제 일정에서 동일한 점수를 얻었지만 문제 일정의 경우 최종 결과가 다른 것을 볼 수 있습니다. 따라서 우리는 일부 우선 순위에 대해 점수 매기기가 "뒤에서" 발생하며 노드가 점수를 얻지 못한 우선 순위를 이해할 방법이 없다고 결론을 내릴 수 있습니다. 이 문제에 대해 자세히 설명했습니다. 발행물 Github의 Kubernetes 리포지토리. 작성 시점에 Kubernetes v1.15,1.16, 1.17 및 XNUMX 업데이트에 로깅 지원이 추가될 것이라는 개발자의 응답을 받았습니다.
2. kube-scheduler가 현재 작업 중인 특정 정책 세트를 쉽게 이해할 수 있는 방법은 없습니다. 예, 안으로 선적 서류 비치 이 목록이 나열되지만 각 우선 순위 정책에 대해 설정된 특정 가중치에 대한 정보는 포함되어 있지 않습니다. 기본 kube-scheduler의 가중치를 보거나 정책을 편집하는 것만 가능합니다. 출처.

애플리케이션을 실행하는 데 필요한 이미지가 이미 있는 경우 노드에 포인트를 부여하는 ImageLocalityPriority 정책에 따라 노드가 포인트를 얻지 못하는 문제를 해결한 후에는 주목할 가치가 있습니다. 즉, 응용 프로그램의 새 버전을 롤아웃할 때 cron 작업이 두 개의 노드에서 실행되고 도커 레지스트리에서 새 이미지를 다운로드하여 두 노드가 상대적으로 더 높은 최종 점수를 받았습니다. 세번째 것.

위에서 쓴 것처럼 로그에는 ImageLocalityPriority 정책 평가에 대한 정보가 표시되지 않으므로 가정을 확인하기 위해 새 버전의 애플리케이션으로 이미지를 세 번째 노드로 스풀링한 후 계획 올바르게 작동했습니다. ImageLocalityPriority 정책 때문에 일정 문제가 거의 관찰되지 않고 더 자주 다른 문제와 연관되었습니다. 기본 kube-scheduler의 우선 순위 목록에 있는 각 정책을 완전히 디버깅할 수 없기 때문에 포드 스케줄링 정책을 유연하게 관리할 필요가 있었습니다.

문제 성명

우리는 문제에 대한 솔루션이 가능한 한 대상화되기를 원했습니다. 즉, Kubernetes의 주요 엔티티(여기서는 기본 kube-scheduler를 의미함)가 변경되지 않은 상태로 유지되어야 합니다. 우리는 한 곳에서 문제를 해결하고 다른 곳에서 만들고 싶지 않았습니다. 따라서 기사 소개에서 발표된 문제를 해결하기 위한 두 가지 옵션, 즉 추가 스케줄러를 생성하거나 직접 작성하는 두 가지 옵션에 도달했습니다. 크론 작업을 예약하기 위한 주요 요구 사항은 로드를 세 노드에 고르게 분산시키는 것입니다. 이 요구 사항은 기존 kube-scheduler 정책으로 충족할 수 있으므로 작업에 대한 자체 스케줄러를 작성하는 것은 의미가 없습니다.

추가 kube-scheduler 생성 및 배포 지침은 다음 항목에 설명되어 있습니다. 선적 서류 비치. 그러나 배포 엔터티는 kube-scheduler와 같은 중요한 서비스의 작동에서 내결함성을 보장하기에 충분하지 않은 것으로 보였기 때문에 새로운 kube-scheduler를 정적 포드로 배포하기로 결정했습니다. 이 포드는 Kubelet이 직접 모니터링합니다. . 따라서 새로운 kube-scheduler에 대한 요구 사항은 다음과 같습니다.

1. 서비스는 모든 클러스터 마스터에서 정적 포드로 배포되어야 합니다.
2. kube-scheduler가 포함된 활성 포드를 사용할 수 없는 경우 장애 조치를 제공해야 합니다.
3. 계획 시 주요 우선 순위는 노드에서 사용 가능한 리소스의 양(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

주요 변경 사항에 대해 간략히 설명합니다.

1. 포드 및 컨테이너 이름이 kube-scheduler-cron으로 변경됨
2. 옵션 정의에 따라 포트 10151 및 10159를 사용하도록 지정됨 hostNetwork: true 기본 kube-scheduler(10251 및 10259)와 동일한 포트를 사용할 수 없습니다.
3. --config 매개변수를 사용하여 서비스를 시작할 구성 파일을 지정합니다.
4. 호스트에서 구성 파일(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"

주요 변경 사항에 대해 간략히 설명합니다.

1. schedulerName을 서비스 kube-scheduler-cron의 이름으로 설정합니다.
2. 매개변수에서 lockObjectName 또한 서비스 이름을 설정하고 매개변수가 leaderElect true로 설정합니다(마스터 노드가 하나인 경우 값을 false로 설정할 수 있음).
3. 파라미터에 스케줄링 정책의 설명으로 파일 경로 지정 algorithmSource.

키에 대한 매개 변수를 편집하는 두 번째 단락에 대해 자세히 살펴볼 가치가 있습니다. leaderElection. 내결함성을 위해 우리는 (leaderElect) 단일 엔드포인트를 사용하여 kube-scheduler의 포드 간에 리더(마스터)를 선택하는 프로세스(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 정책 세트 포함)에 따라 Pod를 예약할 수 있는 노드를 나열합니다. 그런 다음 각 노드는 우선 순위 배열의 정책 집합에 따라 평가됩니다. 우리 임무의 조건을 충족시키기 위해 우리는 그러한 일련의 정책이 최선의 해결책이 될 것이라고 생각했습니다. 자세한 설명과 함께 일련의 정책이 제공됨을 알려드립니다. 선적 서류 비치. 작업을 수행하려면 사용된 정책 집합을 변경하고 적절한 가중치를 할당하기만 하면 됩니다.

이 장의 시작 부분에서 생성한 새로운 kube-scheduler 매니페스트는 kube-scheduler-custom.yaml이라고 하며 세 개의 마스터 노드에서 /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:{}]'

이제 파드 스케줄링에 대한 모든 요청이 새로운 kube-scheduler에 의해 처리되어야 한다는 것을 CronJob의 사양에 지정하는 일만 남았습니다.

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

결론

결국 우리는 kubelet에 의해 직접 모니터링되는 고유한 스케줄링 정책 세트가 있는 추가 kube-scheduler를 얻었습니다. 또한 어떤 이유로 이전 리더를 사용할 수 없게 되는 경우를 대비하여 kube-scheduler의 포드 간에 새 리더 선출을 설정합니다.

일반 응용 프로그램 및 서비스는 기본 kube-scheduler를 통해 계속 예약되며 모든 cron 작업은 새 작업으로 완전히 이전되었습니다. 크론 작업으로 생성된 부하는 이제 모든 노드에 고르게 분산됩니다. 대부분의 크론 작업이 프로젝트의 주요 애플리케이션과 동일한 노드에서 실행된다는 점을 고려하면 리소스 부족으로 인한 Pod 이동 위험이 크게 줄었습니다. 추가 kube-scheduler를 도입한 후 cron 작업의 일정하지 않은 일정 문제가 더 이상 발생하지 않았습니다.

블로그에서 다른 기사도 읽어보세요.

• Calico를 사용한 Kubernetes 클러스터의 트래픽 관리
• Calico를 사용한 네트워크 정책 시행 옵션 이해
• Linux conntrack이 더 이상 친구가 아닌 경우
• iota 열거형의 4가지 예
• 다운타임 없이 Kubernetes 클러스터 업그레이드
• 가동 중지 시간이 없는 배포 및 데이터베이스
• Kubernetes: 시스템 리소스 관리를 설정하는 것이 왜 그렇게 중요한가요?

출처 : habr.com