스케

2026. 4. 16. 20:12ㆍ카테고리 없음

API 서버와의 통신 (Client Connection) 적용 가이드

스케줄러가 API 서버로부터 클러스터 상태(노드, 파드 정보)를 가져오거나 배치 결정을 보낼 때 사용하는 통로를 넓히는 작업입니다. 대규모 워크로드가 한꺼번에 생성될 때 발생하는 Throttling(속도 제한) 문제를 해결합니다.

Step 1: 설정 파일(ConfigMap 또는 File) 확인

일반적으로 쿠버네티스 컨트롤 플레인 구성 요소들은 /etc/kubernetes/manifests/kube-scheduler.yaml 파일에 실행 옵션이 정의되어 있습니다. 먼저 이 파일에서 --config 옵션이 가리키는 경로를 확인하세요.

설정 파일 경로 예시: /etc/kubernetes/scheduler-config.yaml

Step 2: YAML 파일 수정

확인한 설정 파일의 clientConnection 섹션을 다음과 같이 수정합니다.

YAML

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
# ... 기타 설정 ...

# [튜닝 포인트] API 서버 통신 설정
clientConnection:
  kubeconfig: "/etc/kubernetes/scheduler.conf" # 스케줄러 권한 인증 파일
  qps: 100    # (기본값: 50) 초당 지속적으로 보낼 수 있는 요청 수
  burst: 200  # (기본값: 100) 짧은 순간 최대 허용 요청 수

[이미지: Kubernetes API Server Throttling Concept - Client-side QPS and Burst]

Step 3: 파라미터 상세 설명 (가이드 기입용)

qps (Queries Per Second):
- 의미: 스케줄러가 API 서버와 대화하는 '속도 차선'의 너비입니다.
- 권장값: 노드 수가 500개 이상이거나 초당 수십 개의 파드가 생성되는 환경에서는 100~200으로 상향합니다.
burst:
- 의미: 일시적인 트래픽 폭주 시 허용되는 '임시 갓길'입니다.
- 권장값: 보통 QPS의 2배 정도로 설정합니다. (예: QPS 100이면 Burst 200)

Step 5: 튜닝 결과 검증 (Metrics)

실제로 튜닝이 효과가 있는지 확인하려면 스케줄러 메트릭을 모니터링해야 합니다.

확인할 메트릭: rest_client_request_duration_seconds
로그 확인: 스케줄러 로그에 Throttling request...라는 경고 문구가 사라졌는지 확인합니다.

Bash

kubectl logs -n kube-system [스케줄러_파드_이름] | grep -i throttle

@@@@@@@@@@@@@@@@@@@@@@

가이드의 "고가용성 및 안정성 (HA & Stability) 튜닝" 섹션은 클러스터의 중단 없는 운영과 장애 복구 속도를 결정하는 중요한 파트입니다. 이 설정들은 주로 스케줄러 간의 주도권 싸움(Leader Election)과 실패한 작업의 재시도 로직을 다룹니다.

3. 고가용성 및 안정성 (HA & Stability) 적용 가이드

이 영역은 스케줄러가 여러 대 실행되는 환경에서 어떻게 리더를 유지하는지, 그리고 배치에 실패했을 때 얼마나 영리하게 다시 시도하는지를 설정합니다.

① 리더 선출 (Leader Election) 튜닝

스케줄러는 보통 3대의 마스터 노드에서 실행되지만, 실제 배치는 '리더' 1대만 수행합니다. 리더 노드에 문제가 생겼을 때 다른 노드가 빠르게 리더를 넘겨받도록 설정하는 것이 핵심입니다.

방법: KubeSchedulerConfiguration의 leaderElection 섹션을 수정합니다.
YAML 예시:

YAML

leaderElection:
  leaderElect: true               # 다중 스케줄러 운영 시 필수
  leaseDuration: 15s              # 리더가 갱신 안 될 때 대기 시간 (기본 15s)
  renewDeadline: 10s              # 리더가 갱신을 시도하는 기한 (기본 10s)
  retryPeriod: 2s                 # 리더 선출 재시도 간격 (기본 2s)
  resourceName: "kube-scheduler"
  resourceNamespace: "kube-system"

튜닝 팁:
- 네트워크가 불안정한 환경에서 leaseDuration을 너무 짧게 잡으면 리더가 계속 바뀌는 '플래핑(Flapping)' 현상이 발생합니다.
- 고성능/안정적인 네트워크라면 이 값들을 낮추어 장애 조치(Failover) 시간을 줄일 수 있습니다.

② 백오프(Backoff) 정책 튜닝

파드가 노드에 배치되지 못했을 때(예: 자원 부족), 스케줄러는 해당 파드를 큐에 넣고 다시 시도합니다. 이 재시도 간격을 조절하여 스케줄러의 불필요한 연산을 줄입니다.

방법: 전역 설정 필드에서 직접 수정합니다.
YAML 예시:

YAML

podInitialBackoffSeconds: 1     # 첫 실패 후 재시도까지 대기 시간 (기본 1s)
podMaxBackoffSeconds: 10        # 재시도 대기 시간의 최대치 (기본 10s)

튜닝 팁:
- 클러스터가 항상 꽉 차 있는 환경이라면 이 값을 높여(Initial: 5s, Max: 30s) 스케줄러가 계속해서 불가능한 계산을 반복하지 않도록 '휴식기'를 주는 것이 좋습니다.

③ 헬스 체크 및 메트릭 바인딩 (Health & Metrics)

안정적인 운영을 위해서는 스케줄러가 살아있는지 외부에서 감시할 수 있어야 합니다.

방법: healthzBindAddress와 metricsBindAddress를 설정합니다.
YAML 예시:

YAML

healthzBindAddress: 0.0.0.0:10259   # 헬스 체크 주소 (HTTPS 포트)
metricsBindAddress: 0.0.0.0:10259   # 메트릭 노출 주소

보안 팁: 외부 노출이 걱정된다면 127.0.0.1로 설정하여 로컬 통신만 허용하세요.

④ 적용 확인 (Troubleshooting)

설정을 변경한 후에는 아래 명령어를 통해 리더 선출이 정상적으로 이루어지는지 확인해야 합니다.

리더 확인:

Bash

kubectl get endpoints kube-scheduler -n kube-system -o yaml
# 'control-plane.alpha.kubernetes.io/leader' 어노테이션에서 현재 리더 확인

이벤트 모니터링:

Bash

kubectl get events -n kube-system --field-selector involvedObject.name=kube-scheduler
# 리더 선출 과정(LeaderElection) 로그 확인

지금까지 튜닝포인트 설정 예시

YAML

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
# 1. 인증 및 API 통신 설정 (clientConnection)
clientConnection:
  kubeconfig: "/etc/kubernetes/scheduler.conf"
  qps: 100       # [튜닝] 초당 요청 수 상향
  burst: 200     # [튜닝] 순간 최대 요청 수 상향

# 2. 성능 및 알고리즘 전역 설정
parallelism: 16                    # [튜닝] 병렬 처리 고루틴 수
percentageOfNodesToScore: 20       # [튜닝] 노드 탐색 비율 (대규모 클러스터용)

# 3. 고가용성(HA) 및 리더 선출 설정
leaderElection:
  leaderElect: true
  leaseDuration: 15s               # [튜닝] 장애 감지 시간 관련
  renewDeadline: 10s
  retryPeriod: 2s
  resourceName: "kube-scheduler"
  resourceNamespace: "kube-system"

# 4. 안정성 및 모니터링 접점 설정
healthzBindAddress: 0.0.0.0:10259   # [튜닝] 모든 인터페이스에서 헬스체크 허용
metricsBindAddress: 0.0.0.0:10259   # [튜닝] 모든 인터페이스에서 메트릭 수집 허용

# 5. 재시도 로직 설정
podInitialBackoffSeconds: 1        # [튜닝] 실패 시 첫 재시도 대기 시간
podMaxBackoffSeconds: 10           # [튜닝] 재시도 최대 대기 시간

# 6. 세부 스케줄링 프로파일 (전략)
profiles:
  - schedulerName: default-scheduler
    # 이 아래에 플러그인 설정(Bin-packing 등)이 들어갑니다.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

**익스텐더(Extender)**는 쿠버네티스 기본 스케줄러의 기능을 수정하지 않고, **외부 서비스(HTTP Server)**를 호출하여 스케줄링 의사결정에 참여시키는 방식입니다. 특정 하드웨어 전용 로직이나 복잡한 비즈니스 조건이 필요할 때 사용합니다.

이 설정은 매우 민감한데, 외부 호출이 지연되면 전체 클러스터의 파드 배치 속도가 느려지기 때문입니다.

1. 익스텐더(Extender) 설정 상세 가이드

익스텐더 설정 역시 KubeSchedulerConfiguration 파일 내부에 위치하지만, extenders라는 전역 배열 형태로 작성합니다.

YAML 삽입 위치 및 상세 예시

profiles 섹션과 동등한 최상위 레벨에 위치합니다.

YAML

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
# --- 전역 설정 영역 ---
# 1. 익스텐더 설정
extenders:
  - urlPrefix: "https://my-scheduler-extender.com/api" # 익스텐더 서비스 주소
    filterVerb: "filter"   # 노드 필터링 시 호출할 엔드포인트
    prioritizeVerb: "prioritize" # 점수 매길 때 호출할 엔드포인트
    weight: 1              # 이 익스텐더 점수의 가중치
    enableHTTPS: true      # HTTPS 사용 여부
    httpTimeout: 5s        # [튜닝] 매우 중요! 타임아웃 설정
    nodeCacheCapable: true # 스케줄러가 노드 정보를 캐싱하여 전달할지 여부
    managedResources:      # 이 익스텐더가 관리할 특수 리소스
      - name: "example.com/special-gpu"
        ignoredByScheduler: true

# 2. 다른 전역 설정들
parallelism: 16
# ... 생략 ...

profiles:
  - schedulerName: default-scheduler

2. 핵심 튜닝 포인트 및 파라미터 설명

가이드에 다음 내용을 포함하면 독자가 성능 저하를 방지하는 데 큰 도움이 됩니다.

① httpTimeout (응답 대기 시간)

설명: 스케줄러가 외부 익스텐더의 응답을 얼마나 기다릴지 결정합니다.
튜닝: 기본값은 없으나 보통 2s ~ 5s 사이로 설정합니다.
이유: 익스텐더 서버가 응답하지 않을 때 이 값이 너무 길면 스케줄러 전체가 먹통(Blocked)이 되어 다른 파드들도 배치가 안 됩니다.

② nodeCacheCapable (노드 정보 전달 방식)

설명: true로 설정하면 스케줄러가 알고 있는 노드 정보 전체를 익스텐더에게 보냅니다.
효과: 익스텐더가 별도로 API 서버를 호출할 필요가 없어 성능이 향상됩니다. 하지만 데이터 전송량이 커질 수 있으므로 네트워크 대역폭을 고려해야 합니다.

③ managedResources (관리 리소스 정의)

설명: 특정 커스텀 리소스(예: 특수 GPU, 네트워크 가속기)가 필요한 파드에 대해서만 익스텐더를 호출하도록 제한합니다.
효과: 모든 파드에 대해 익스텐더를 호출하는 낭비를 줄이고, 꼭 필요한 파드만 필터링하여 성능을 최적화합니다.

3. 익스텐더 적용 시 주의사항 (Troubleshooting)

네트워크 지연: 익스텐더는 HTTP 호출이므로 동일한 네트워크 내부나 마스터 노드 근처에 배치하는 것이 필수입니다.
가용성: 익스텐더가 죽으면 해당 리소스를 사용하는 파드들은 배치가 불가능해집니다. 반드시 익스텐더 자체도 고가용성(HA)으로 구성해야 합니다.
순서: 익스텐더는 기본 스케줄러의 Filter 단계가 끝난 직후에 호출됩니다.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

가이드의 가장 핵심적인 부분이자, 실제 배치 로직을 결정하는 프로파일(Profiles) 설정입니다.

전역 설정이 '스케줄러라는 엔진의 기본 사양'이라면, 프로파일 설정은 **'어떤 주행 모드(배치 전략)로 달릴 것인가'**를 정의하는 곳입니다.

4. 스케줄링 프로파일 (Profiles) 적용 가이드

프로파일 설정은 profiles라는 리스트(Array) 아래에 위치하며, 각 프로파일은 **플러그인(Plugins)**과 **플러그인 설정(PluginConfig)**으로 구성됩니다.

① 프로파일 기본 구조 및 삽입 위치

KubeSchedulerConfiguration 파일의 하단부에 위치합니다.

YAML

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
# ... 전역 설정들 (parallelism, clientConnection 등) ...

profiles:
  - schedulerName: default-scheduler  # 프로파일 이름 (기본값)
    plugins:
      # 각 단계별로 어떤 기능을 켜고 끌지 정의
      score:
        disabled:
          - name: NodeResourcesBalancedAllocation # 특정 플러그인 끄기
        enabled:
          - name: NodeResourcesFit # 특정 플러그인 켜기
            weight: 5              # 가중치 부여
    
    pluginConfig:
      # 켠 플러그인에 세부 파라미터 전달
      - name: NodeResourcesFit
        args:
          scoringStrategy:
            type: MostAllocated    # [튜닝] 빈 패킹 전략 적용

② 주요 단계별 튜닝 포인트 (Extension Points)

가이드 작성 시, 스케줄링의 각 단계에서 어떤 튜닝이 가능한지 설명해 주면 좋습니다.

Filter 단계: 파드가 들어갈 수 없는 노드를 걸러냅니다.
- NodeResourcesFit: 노드에 남은 CPU/메모리가 충분한지 체크.
Score 단계: 필터를 통과한 노드들에게 점수를 매깁니다. (가장 튜닝이 많이 일어나는 곳)
- NodeResourcesFit: MostAllocated(빈 패킹) 또는 LeastAllocated(분산 배치) 중 선택.
- InterPodAffinity: 파드 간 친밀도 점수 계산. 성능 저하의 주범이므로 필요한 경우 disabled 하거나 가중치를 낮춤.
Reserve/Prebind 단계: 실제 노드에 바인딩하기 전 자원을 선점하는 단계입니다.

③ 상세 튜닝 사례: 워크로드별 프로파일 분리

가이드에 아래와 같은 '다중 프로파일' 예시를 넣어보세요. 운영자가 상황에 맞춰 선택할 수 있게 도와줍니다.

YAML

profiles:
  # 1번 프로파일: 일반 서비스용 (분산 배치)
  - schedulerName: low-latency-profile
    pluginConfig:
      - name: NodeResourcesFit
        args:
          scoringStrategy:
            type: LeastAllocated 

  # 2번 프로파일: 배치 작업/비용 절감용 (빈 패킹)
  - schedulerName: cost-saver-profile
    pluginConfig:
      - name: NodeResourcesFit
        args:
          scoringStrategy:
            type: MostAllocated

[사용 방법] 개발자가 파드를 생성할 때 YAML에 다음과 같이 선언하면 해당 전략이 적용됩니다.

YAML

spec:
  schedulerName: cost-saver-profile # 프로파일에서 정의한 이름 사용

④ 플러그인 설정(pluginConfig) 튜닝 가이드

특정 플러그인의 동작을 미세 조정할 때 사용합니다.

NodeResourcesFit:
- resources: 점수 계산에 포함할 리소스를 정의합니다 (예: cpu, memory 외에 nvidia.com/gpu 추가).
VolumeBinding:
- bindTimeoutSeconds: 볼륨이 노드에 연결될 때까지 기다리는 시간 (기본 600s). 네트워크 스토리지가 느리다면 튜닝이 필요합니다.

💡 가이드 작성 시 팁: "가중치(Weight)의 힘"

독자들에게 weight 설정의 중요성을 강조하세요.

여러 플러그인이 점수를 매길 때, 특정 플러그인의 점수에 가중치를 높게 주면(예: weight: 100) 해당 조건이 배치의 절대적인 기준이 됩니다.
예를 들어, "비용 절감이 가용성보다 훨씬 중요하다"면 NodeResourcesFit의 MostAllocated 가중치를 극단적으로 높이면 됩니다.

이제 **전역 설정(Global)**부터 익스텐더(Extender), 그리고 **프로파일(Profiles)**까지 모든 레이어의 튜닝 포인트와 삽입 위치를 다뤘습니다. 가이드의 목차를 잡고 내용을 배치하시기만 하면 되겠네요! 추가로 궁금하신 세부 속성이 있으신가요?

마지막도전_잡창고

마지막도전_잡창고

태그

최근글

댓글

공지사항

아카이브

API 서버와의 통신 (Client Connection) 적용 가이드

Step 1: 설정 파일(ConfigMap 또는 File) 확인

Step 2: YAML 파일 수정

Step 3: 파라미터 상세 설명 (가이드 기입용)

Step 5: 튜닝 결과 검증 (Metrics)

3. 고가용성 및 안정성 (HA & Stability) 적용 가이드

① 리더 선출 (Leader Election) 튜닝

② 백오프(Backoff) 정책 튜닝

③ 헬스 체크 및 메트릭 바인딩 (Health & Metrics)

④ 적용 확인 (Troubleshooting)

1. 익스텐더(Extender) 설정 상세 가이드

YAML 삽입 위치 및 상세 예시

2. 핵심 튜닝 포인트 및 파라미터 설명

① httpTimeout (응답 대기 시간)

② nodeCacheCapable (노드 정보 전달 방식)

③ managedResources (관리 리소스 정의)

3. 익스텐더 적용 시 주의사항 (Troubleshooting)

4. 스케줄링 프로파일 (Profiles) 적용 가이드

① 프로파일 기본 구조 및 삽입 위치

② 주요 단계별 튜닝 포인트 (Extension Points)

③ 상세 튜닝 사례: 워크로드별 프로파일 분리

④ 플러그인 설정(pluginConfig) 튜닝 가이드

💡 가이드 작성 시 팁: "가중치(Weight)의 힘"

티스토리툴바