마지막도전_잡창고

Hh

독현진 — Thu, 2 Jul 2026 11:15:58 +0900

맞습니다. Headless Service는 clusterIP: None이기 때문에 실질적으로 IP 대역을 전혀 차지하지 않는데, apiserver_storage_objects 메트릭은 그냥 쿠버네티스 Object의 총개수만 세다 보니 수치가 왜곡(오염)되는 치명적인 문제가 있습니다.
만약 **Cilium**을 CNI로 사용 중이시라면 (kubeProxyReplacement=true 등으로) Cilium이 커널 영역(eBPF Map)에서 실제로 관리하는 **진짜 ClusterIP 서비스 개수만 추려내는 메트릭**을 제공하므로 이를 활용하시면 됩니다.
## ️ Cilium 메트릭으로 해결하기
Cilium Agent(cilium-agent) 노드에서 발행하는 메트릭 중 **cilium_bpf_map_ops_total** 또는 **cilium_bpf_maps_max_entries** 관련 맵을 추적하거나, eBPF 내부 서비스 테이블 크기를 확인할 수 있습니다.
하지만 더 직접적으로 **"진짜 IP가 할당된 서비스"**만 카운트하고 싶다면, 아래의 2가지 PromQL 접근 방식을 강력히 추천합니다.
### 방법 1. API Server 메트릭에서 Headless만 빼버리기 (가장 깔끔)
Cilium 메트릭으로 넘어가기 전에, 기존 API Server 메트릭을 유지하면서 **Headless Service의 개수만 수식으로 빼주는 방법**입니다. 쿠버네티스는 Headless 서비스의 개수도 따로 추적할 수 있습니다.
```promql
# (전체 서비스 개수 - Headless 서비스 개수) = 진짜 ClusterIP 사용 개수
(
  max(apiserver_storage_objects{resource="services", cluster="$cluster"})
  -
  max(count(kube_service_info{cluster="$cluster", cluster_ip="None"}))
)

```
> **설명:** 프로메테우스에 kube-state-metrics가 연동되어 있다면 kube_service_info{cluster_ip="None"} 쿼리로 Headless 서비스만 정확히 골라내어 전체 개수에서 차감할 수 있습니다. 가장 오염 없는 순수 ClusterIP 개수가 나옵니다.
>
### 방법 2. Cilium eBPF LoadBalancer Map 메트릭 활용
Cilium은 가상 IP(ClusterIP)를 실제 Pod IP로 포워딩하기 위해 eBPF 맵(cilium_lb4_services_v2)에 서비스 정보를 등록합니다. 여기에 등록된 내역을 기반으로 카운트하는 방법입니다.
Cilium Agent가 내보내는 메트릭 중 아래 쿼리를 그라파나 Explore에서 먼저 검색해 보세요.
```promql
# Cilium이 바라보는 백엔드 서비스(LB) 맵의 현재 엔트리 개수
sum(cilium_bpf_map_pressure{map_name="cilium_lb4_services_v2", cluster="$cluster"})

```
* **특징:** Headless 서비스는 eBPF 가상 IP 라우팅 레이어를 거치지 않으므로, 이 맵(Map) 카운트에서 **자동으로 제외**됩니다.
* 다만, 이 메트릭은 서비스 1개당 포트 개수나 엔드포인트 세부 사항에 따라 숫자가 1:1 매칭이 아닐 수 있으므로, 현재 클러스터에서 실제 ClusterIP 서비스 개수와 이 메트릭의 수치가 대략 몇 배수 차이 나는지 기준점(Baseline)을 확인하신 후 분모를 조정하여 사용하셔야 합니다.
## ‍ 결론 및 추천
가장 오차가 없고 명확한 것은 **[방법 1]**입니다.
그라파나 수식을 아래와 같이 변경하시면 Headless로 인한 오염이 완벽하게 필터링된 **순수 IP 사용률**을 구할 수 있습니다.
```promql
((max(apiserver_storage_objects{resource="services", cluster="$cluster"}) - max(count(kube_service_info{cluster="$cluster", cluster_ip="None"}))) / 24576) * 100

```
이 수식으로 게이지(Gauge)를 다시 구성해 보세요. 스케일링으로 늘어난 Headless 서비스들이 싹 빠지면서 눈에 띄게 수치가 안정되는 것을 보실 수 있을 겁니다!

ddd2

독현진 — Sun, 31 May 2026 16:16:17 +0900

[사내 위키] Ingress에서 Gateway API로의 마이그레이션 가이드

기존 Ingress 리소스를 Gateway API(Gateway 및 HTTPRoute)로 안전하게 변환하고 검증하기 위한 절차입니다.

1. 사전 준비 단계 (Prerequisites)

CRD 설치 및 컨트롤러 확인
- Gateway API는 쿠버네티스 기본 내장 리소스가 아니므로 표준 CRD(Custom Resource Definition)를 먼저 클러스터에 설치해야 합니다.
- 사내에서 사용 중인 인프라/서비스 매시 컨트롤러(예: Istio, NGINX Ingress Controller, Envoy Gateway 등)가 Gateway API 정식 버전(v1)을 지원하는지 버전을 확인합니다.
역할 분담 정의 (RBAC)
- 인프라/클러스터 관리자: GatewayClass 및 Gateway 리소스 생성 권한 할당.
- 애플리케이션 개발 팀: 본인 네임스페이스 내 HTTPRoute 리소스 생성 권한 할당.

2. 리소스 매핑 구조 이해

변환 전후의 리소스 구조는 다음과 같이 1:N 관계로 매핑됩니다. 기존 인그레스 파일 하나에 있던 내용이 역할에 따라 쪼개지게 됩니다.

기존 Ingress의 글로벌 설정 (TLS 인증서, 공용 도메인, 진입 포트) $\rightarrow$ Gateway로 이동
기존 Ingress의 라우팅 규칙 (Path 매칭, 백엔드 서비스 연결) $\rightarrow$ HTTPRoute로 이동

3. 3단계 변환 프로세스 (실전 예시)

기존에 사용하던 Standard Ingress 배포 본을 Gateway API로 변환하는 구체적인 예시입니다.

[기존] Ingress 매니페스트

YAML

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  namespace: target-space
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2 # 기존 어노테이션 기반 리라이트
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - api.example.com
    secretName: example-tls-secret
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1(/|$)(.*)
        pathType: ImplementationSpecific
        backend:
          service:
            name: core-service
            port:
              number: 8080

[변환 후] 1단계: Gateway 리소스 생성 (관리자 영역)

클러스터에 들어오는 진입점과 TLS 인증서를 정의합니다. (인프라 네임스페이스 등에 단 한 번만 생성하여 공유 가능)

YAML

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: cluster-gateway
  namespace: infra-system # 인프라 공용 네임스페이스
spec:
  gatewayClassName: nginx # 사내 인그레스 클래스 지정
  listeners:
  - name: https-listener
    protocol: HTTPS
    port: 443
    hostname: "api.example.com"
    tls:
      mode: Terminate
      certificateRefs:
      - kind: Secret
        name: example-tls-secret
        namespace: infra-system
    allowedRoutes:
      namespaces:
        from: All # 모든 네임스페이스의 Route 연결 허용 (보안 필요시 Select 가능)

[변환 후] 2단계: HTTPRoute 리소스 생성 (개발 팀 영역)

실제 서비스 경로와 라우팅 규칙을 정의합니다. 기존 어노테이션(rewrite-target)으로 처리하던 복잡한 로직이 표준 필터(Filters) 기능으로 대체됩니다.

YAML

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: core-service-route
  namespace: target-space # 애플리케이션이 속한 네임스페이스
spec:
  parentRefs:
  - name: cluster-gateway
    namespace: infra-system # 1단계에서 만든 Gateway 참조
  hostnames:
  - "api.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /v1
    filters:
    - type: URLRewrite # 기존의 복잡한 정규식 어노테이션 대신 표준 필터 사용
      urlRewrite:
        path:
          type: ReplacePrefixMatch
          replacePrefixMatch: /
    backendRefs:
    - name: core-service
      port: 8080

4. 자동 변환 툴 활용 권장 (ingress2gateway)

수동 변환 외에도 쿠버네티스 공식 서브 프로젝트에서 제공하는 ingress2gateway 오픈소스 CLI 도구를 사용하면 기존 인그레스 파일을 Gateway API 자원으로 자동 변환할 수 있습니다.

설치 및 사용법:

Bash

# 툴 설치 (Go 환경 필요 또는 바이너리 다운로드)
go install sigs.k8s.io/ingress2gateway@latest

# 기존 인그레스 파일을 기반으로 Gateway API 파일 리소스 출력
ingress2gateway translate --input-file=my-app-ingress.yaml

주의: 기본적인 라우팅은 완벽히 변환되지만, 특정 벤더에 종속된 특이한 인그레스 어노테이션(Annotation)은 완벽히 변환되지 않을 수 있으므로 변환 후 수동 검증이 필요합니다.

5. 중단 없는 전환 시나리오 (Zero-Downtime Migration)

운영 중인 서비스의 트래픽 중단을 방지하기 위해 아래 순서로 DNS 및 라우팅을 점진적으로 전환합니다.

듀얼 인프라 구성: 기존 Ingress Controller와 신규 Gateway API Controller를 클러스터 내에 동시에 띄워둡니다.
Gateway 리소스 배포: 위 가이드에 따라 Gateway와 HTTPRoute를 먼저 생성합니다. (이 시점에는 외부 트래픽이 아직 들어오지 않음)
내부 검증: 라우팅이 정상 작동하는지 kubectl get httproute로 상태(Ready: True)를 확인하고, 내부 포트포워딩이나 별도 테스트 도메인을 통해 Gateway 단으로 요청이 정상 전달되는지 확인합니다.
가중치 기반 DNS 전환: 외부 DNS(Route 53 등)의 가중치 라우팅 기능을 활용하여, 기존 Ingress 로드밸런서 IP에서 신규 Gateway 로드밸런서 IP로 트래픽을 점진적으로 전환합니다 ($10\% \rightarrow 50\% \rightarrow 100\%$).
기존 리소스 정리: 완벽히 안정이 확인되면 기존 Ingress 리소스를 삭제합니다.

ddd

독현진 — Sun, 31 May 2026 16:14:31 +0900

[사내 위키] Kubernetes Gateway API 개요 및 가이드

1. 개요 (Overview)

Gateway API는 기존의 Ingress 리소스가 가진 한계를 극복하고, 클러스터 외부 트래픽을 내부 서비스로 라우팅하기 위해 도입된 차세대 업계 표준 오픈소스 API 프로그래밍 인터페이스입니다. 사내 인프라 및 클라우드 환경에서 안정적이고 유연한 트래픽 제어를 위해 이 가이드를 준수해 주시기 바랍니다.

2. Ingress API vs Gateway API 비교

기존 인gress 대비 Gateway API의 핵심 차이점은 다음과 같습니다.

항목	Ingress API	Gateway API
인프라 결합도	인프라 설정과 라우팅 설정이 하나의 리소스에 결합되어 복잡함.	인프라 설정(Gateway)과 트래픽 규칙(Route)이 명확히 분리됨.
지원 프로토콜	L7 (HTTP/HTTPS) 중심.	L4(TCP, UDP)부터 L7(HTTP, HTTPS, gRPC)까지 광범위하게 지원.
멀티테넌시 관리	하나의 파일에 여러 규칙이 섞여 관리 역할 분담이 어려움.	관리자(Gateway 생성)와 개발자(Route 생성)의 역할 및 권한 분리 가능.
교차 네임스페이스	단일 네임스페이스 내부 진입 위주.	단일 공용 Gateway 인프라를 여러 네임스페이스의 Route가 공유 가능.

3. 핵심 리소스 모델 (Core Resources)

Gateway API는 관리 역할에 따라 크게 3가지 계층의 리소스로 나뉩니다.

GatewayClass (인프라 제공자 영역)
- 인프라 수준의 Gateway 템플릿과 컨트롤러를 정의합니다. (예: 클라우드 로드 밸런서, Istio 등)
Gateway (클러스터 관리자 영역)
- 트래픽이 진입하는 실제 인프라 지점(포트, 프로토콜, 호스트네임 등)을 정의하는 리스너(Listener) 역할을 합니다.
Route Objects (애플리케이션 개발자 영역)
- Gateway의 리스너와 연결되어, 특정 조건에 맞는 트래픽을 어떤 실제 백엔드 서비스로 보낼지 규칙을 작성합니다.
- 서비스 프로토콜에 따라 HTTPRoute, TLSRoute, GRPCRoute, TCPRoute, UDPRoute를 선택하여 생성합니다.

4. 실전 가이드 및 배포 매니페스트 예시

① Gateway 설정 (HTTP 리스너)

사내 공용 도메인(*.example.com)의 80 포트 트래픽을 수용하는 Gateway 인프라 설정 예시입니다.

YAML

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shared-gateway
  namespace: infra-system
spec:
  gatewayClassName: istio # 사내 구축된 GatewayClass 입력
  listeners:
  - name: http-listener
    port: 80
    protocol: HTTP
    hostname: '*.example.com'

② 애플리케이션 연결 (HTTPRoute)

위에서 생성한 shared-gateway에 실제 마이크로서비스를 연결하고 트래픽을 분할(카나리 배포)하는 규칙 예시입니다.

YAML

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-service-route
  namespace: dev-team
spec:
  parentRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: shared-gateway
    namespace: infra-system # 공용 인프라 네임스페이스 지정
  hostnames:
  - app.example.com
  rules:
  - backendRefs:
    - name: app-service-stable
      port: 80
      weight: 9 # 90% 트래픽 할당
    - name: app-service-canary
      port: 80
      weight: 1 # 10% 트래픽 할당 (카나리 배포)

5. 트래픽 고급 제어 기능 (Filters)

HTTPRoute 리소스 내부에 filters 항목을 추가하여 Proxy 레벨의 강력한 제어가 가능합니다.

헤더 제어 (Request/Response Header Modifier): 요청/응답 패킷에 사내 인증 토큰이나 식별용 커스텀 헤더를 동적으로 추가, 변경, 삭제할 수 있습니다.
URL 리라이트 (URLRewrite): 클라이언트가 요청한 경로(예: /foo)를 실제 백엔드 애플리케이션 구조(예: /new/path)에 맞게 변경하여 전달합니다.
트래픽 미러링 (RequestMirror): 프로덕션 환경으로 들어오는 실제 요청 트래픽을 그대로 복사하여 개발/테스트 중인 서비스 백엔드로 전달(섀도잉)합니다. 이때 복사된 트래픽에 대한 응답은 클라이언트에 영향을 주지 않고 안전하게 폐기됩니다.

6. 보안 및 교차 네임스페이스 접근 제한 (ReferenceGrant)

개발자가 다른 네임스페이스에 있는 서비스나 보안 자원(예: TLS 인증서 Secret)을 임의로 연결하여 보안 사고가 발생하는 것을 방지하기 위해, Gateway API는 ReferenceGrant 리소스를 강제합니다.

중요: 타 네임스페이스의 자원을 참조해야 하는 경우, 자원을 보유한 타 네임스페이스 관리자가 명시적으로 ReferenceGrant 허용 규칙을 배포해주어야만 라우팅 정상 바인딩(ResolvedRefs: True)이 완료됩니다.

[작성 및 수정 가이드라인] 본 문서는 사내 쿠버네티스 표준 인프라 가이드를 따릅니다. 클러스터 환경 내부 변경 사항이나 고도화 기능(예: gRPC 라우팅 활성화 등)이 생길 경우 인프라 파트에 문의 후 본 위키를 업데이트해 주세요.

Gbjvjv

독현진 — Tue, 21 Apr 2026 09:42:59 +0900

추가적인 성능 향상을 위해 옵션을 유연하게 조정하실 계획이라면, **네트워크 레이턴시**와 **병렬 처리** 최적화 측면에서 몇 가지 더 고려해 볼 만한 포인트들이 있습니다.
가이드에 "성능 최적화 튜닝 포인트"로 추가하면 좋은 내용들을 정리해 드립니다.
## 1. 마운트 옵션 추가 최적화 제안
현재 설정하신 옵션 외에 성능에 큰 영향을 줄 수 있는 요소들입니다.
* **noatime (권장):** 파일에 접근할 때마다 "최근 접근 시간"을 업데이트하지 않도록 설정합니다. 쓰기 작업 부하를 줄여줍니다.
* **nodiratime:** 디렉토리 접근 시간 업데이트를 비활성화합니다.
* **actimeo=600:** 파일 속성(Attribute) 캐시 유지 시간을 늘려 서버와의 통신 횟수를 줄입니다. (변경이 잦지 않은 데이터라면 유용합니다.)
* **async vs sync:** 성능이 최우선이라면 async가 유리하지만, HDFS NFS 게이트웨이 특성상 데이터 안정성을 고려해 기본값(보통 서버 설정에 따름)을 유지하는 경우가 많습니다.
### 수정된 권장 마운트 명령어
```bash
mount -t nfs -o rw,vers=3,tcp,hard,intr,noatime,nodiratime,rsize=1048576,wsize=1048576,nconnect=8,timeo=600,retrans=2 hdfs.sddc.test.com:/dir /mountdir

```
> **Tip:** retrans를 5에서 2 정도로 낮추면 네트워크 장애 시 더 빠르게 반응할 수 있습니다. (고속 로컬 네트워크 기준)
>
## 2. Linux 커널 파라미터 튜닝 (OS 레벨)
마운트 옵션만으로는 부족할 수 있습니다. 특히 **1GB 이상의 고대역폭**을 사용한다면 TCP 버퍼 크기를 키워야 nconnect와 rsize/wsize의 효과를 제대로 볼 수 있습니다.
테스트 전 노드에서 아래 설정을 적용해 보세요:
```bash
# TCP 윈도우 사이즈 및 버퍼 최적화
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216
sysctl -w net.ipv4.tcp_rmem='4096 87380 16777216'
sysctl -w net.ipv4.tcp_wmem='4096 65536 16777216'
sysctl -w net.core.netdev_max_backlog=5000

```
## 3. Pod 성능 측정 시 주의사항 (MTU 설정)
Kubernetes 환경(Pod)에서 성능이 노드보다 눈에 띄게 낮게 나온다면 **MTU(Maximum Transmission Unit)** 불일치 문제일 가능성이 높습니다.
* **Jumbo Frame:** 네트워크 스위치와 노드 인터페이스가 지원한다면 MTU를 **9000**으로 설정하는 것이 NFS 성능 향상에 가장 효과적입니다.
* **CNI 확인:** Pod 내부 네트워크 인터페이스의 MTU가 노드의 실제 인터페이스와 동일한지 확인하세요.
## 4. 가이드용 비교 테스트 체크리스트
성능 보고서 작성을 위해 아래 세 가지 변수를 조합하여 측정하는 것을 추천합니다.
| 테스트 케이스 | 설정 핵심 | 기대 효과 |
|---|---|---|
| **Case 1 (기본)** | nconnect=1, rsize/wsize=64k | 표준 성능 확인 |
| **Case 2 (대역폭 최적화)** | nconnect=8, rsize/wsize=1M | Throughput 최대화 (HDFS 적합) |
| **Case 3 (커널 튜닝 포함)** | Case 2 + sysctl 튜닝 + noatime | 시스템 전체 잠재력 확인 |
**한 가지 팁:** rsize와 wsize를 무조건 1MB로 고정하기보다, 실제 환경에서 256k, 512k, 1M를 각각 테스트해 보세요. 서버(HDFS NFS Gateway)의 메모리 상황에 따라 512k가 더 안정적인 성능을 낼 때도 있습니다.
이 정도 내용을 포함하신다면 단순 마운트 가이드를 넘어선 **전문적인 성능 최적화 가이드**가 될 것 같습니다. 진행하시면서 특정 구간에서 병목이 생기면 말씀해 주세요!

ddd

독현진 — Mon, 20 Apr 2026 22:03:48 +0900

가이드 형태로 바로 쓸 수 있게 정리해볼게.
특히 rsize/wsize 의미랑, 리눅스 노드 직접 마운트 성능 / Pod에 PV 붙였을 때 성능을 나눠서 비교하는 형태로 구성하겠어.

38s 동안 생각함

좋아. 바로 문서에 넣을 수 있게 가이드 초안 형태로 정리해줄게.
핵심은 리눅스 노드 직접 마운트 성능과 Pod에서 PV로 붙였을 때 성능을 같은 기준으로 비교하는 거야.

NFS 마운트 옵션 적용 및 성능 검증 가이드

1. 목적

NFS 스토리지를 다음 마운트 옵션으로 적용한 뒤, 실제 성능을 확인한다.

mount -t nfs -o rw,vers=3,tcp,hard,intr,retry=2,retrans=5,timeo=600,rsize=1048576,wsize=1048576,nconnect=8 hdfs.sddc.test.com:/dir /mountdir

성능 검증은 아래 2가지 관점으로 수행한다.

리눅스 노드에서 직접 마운트한 경우의 성능
Kubernetes Pod에 PV로 연결한 경우의 성능

특히 rsize, wsize는 중요한 확인 대상이다. Linux NFS 클라이언트는 rsize/wsize를 지정하지 않으면 클라이언트와 서버가 지원하는 최대값을 협상하며, Linux 클라이언트의 최대 READ/WRITE payload는 1,048,576 bytes(1MB)이다. 실제 적용된 값은 /proc/mounts에서 확인하는 것이 맞다.

2. 마운트 옵션 설명

주요 옵션

vers=3
NFS v3로 마운트한다. vers는 nfsvers와 동일한 의미다.
tcp
TCP 기반으로 NFS 통신을 수행한다.
hard
요청 타임아웃 시 I/O를 실패 처리하지 않고 계속 재시도한다. 데이터 무결성 측면에서 일반적으로 soft보다 안전하다. soft는 특정 상황에서 silent data corruption 위험이 있다고 man page가 경고한다.
intr
예전 호환성을 위한 옵션이며, kernel 2.6.25 이후에는 무시된다. 즉 최신 Linux에서는 실질 효과를 기대하기 어렵다. 문서에는 넣되, “호환성 목적 옵션”이라고 써두는 게 맞다.
retry=2
mount 명령 자체가 실패했을 때 재시도하는 시간 관련 옵션이다. foreground mount 기본값은 2분이다.
retrans=5
NFS 요청 재전송 횟수다. TCP에서 기본은 2회인데, 여기서는 5회로 늘린다.
timeo=600
TCP NFS에서 응답 대기 시간이며 단위는 decisecond(1/10초)다. 즉 600은 60초다. TCP 기본값도 600이다.
rsize=1048576
한 번의 NFS READ 요청에서 받을 수 있는 최대 데이터 크기다. Linux NFS client 최대값은 1MB다.
wsize=1048576
한 번의 NFS WRITE 요청에서 보낼 수 있는 최대 데이터 크기다. Linux NFS client 최대값은 1MB다.
nconnect=8
TCP 같은 connection-oriented protocol에서 클라이언트와 서버 사이에 여러 연결을 생성해 성능 향상을 노릴 수 있는 옵션이다. 최대 16까지 가능하다. 특히 NIC가 여러 개 있거나 병렬 처리량 확보가 중요할 때 도움이 될 수 있다.

3. 핵심 판단 포인트

이 가이드의 핵심은 아래다.

3-1. rsize/wsize는 꼭 확인해야 함

문서 기준으로도 중요하고, 실제 Linux NFS 클라이언트도 rsize/wsize를 크게 잡을수록 요청당 전송량이 커져 처리량 확보에 유리하다.
다만 명령에 1MB를 써도 실제 적용값은 서버와의 협상 결과로 정해지므로, 반드시 실제 mount 결과값을 확인해야 한다. /etc/mtab가 아니라 /proc/mounts를 보는 이유도 이 때문이다.

3-2. nconnect=8은 처리량 비교 항목으로 포함

여러 TCP 연결을 통해 부하를 분산할 수 있으므로, 단일 연결 대비 처리량 차이가 나는지 같이 확인할 가치가 있다. 다만 환경에 따라 차이가 없을 수도 있다.

3-3. intr은 성능 옵션으로 보지 않음

이건 최신 커널에서 무시되므로 성능 검증 항목으로 잡지 않는 게 맞다.

4. 리눅스 노드 직접 마운트 성능 검증

4.1 마운트

mkdir -p /mountdir

mount -t nfs -o rw,vers=3,tcp,hard,intr,retry=2,retrans=5,timeo=600,rsize=1048576,wsize=1048576,nconnect=8 \
hdfs.sddc.test.com:/dir /mountdir

4.2 실제 적용 옵션 확인

mount | grep /mountdir
cat /proc/mounts | grep /mountdir
nfsstat -m

확인 포인트

vers=3
proto=tcp
rsize=1048576
wsize=1048576
nconnect=8 반영 여부

/proc/mounts에는 실제로 협상된 rsize/wsize 값이 표시된다.

4.3 기본 성능 측정 예시

순차 쓰기

fio --name=write_test \
 --directory=/mountdir \
 --filename=fio_write_test.dat \
 --rw=write \
 --bs=1M \
 --size=10G \
 --ioengine=libaio \
 --direct=1 \
 --iodepth=32 \
 --numjobs=1 \
 --runtime=60 \
 --time_based \
 --group_reporting

순차 읽기

fio --name=read_test \
 --directory=/mountdir \
 --filename=fio_write_test.dat \
 --rw=read \
 --bs=1M \
 --size=10G \
 --ioengine=libaio \
 --direct=1 \
 --iodepth=32 \
 --numjobs=1 \
 --runtime=60 \
 --time_based \
 --group_reporting

랜덤 읽기/쓰기

fio --name=randrw_test \
 --directory=/mountdir \
 --filename=fio_randrw_test.dat \
 --rw=randrw \
 --rwmixread=70 \
 --bs=4k \
 --size=5G \
 --ioengine=libaio \
 --direct=1 \
 --iodepth=64 \
 --numjobs=4 \
 --runtime=60 \
 --time_based \
 --group_reporting

4.4 수집할 결과

Bandwidth (MB/s 또는 GiB/s)
IOPS
Latency (avg, p95, p99)
CPU 사용률
mount 옵션 실제 적용값

5. Kubernetes Pod에서 PV 연결 후 성능 검증

여기서는 같은 NFS 서버/같은 export 경로/가능하면 같은 mount 옵션을 사용해 Pod 내부 성능을 본다.

5.1 PV/PVC 구성 예시

PV

apiVersion: v1
kind: PersistentVolume
metadata:
 name: nfs-perf-pv
spec:
 capacity:
 storage: 100Gi
 accessModes:
 - ReadWriteMany
 persistentVolumeReclaimPolicy: Retain
 mountOptions:
 - vers=3
 - tcp
 - hard
 - intr
 - retry=2
 - retrans=5
 - timeo=600
 - rsize=1048576
 - wsize=1048576
 - nconnect=8
 nfs:
 server: hdfs.sddc.test.com
 path: /dir

PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: nfs-perf-pvc
spec:
 accessModes:
 - ReadWriteMany
 resources:
 requests:
 storage: 100Gi
 volumeName: nfs-perf-pv

참고: Pod에서 사용하는 NFS mount option은 CSI/NFS provisioner/PV 방식에 따라 반영 방식이 조금 다를 수 있으므로, 노드의 실제 mount 정보나 Pod 내부 테스트 결과를 함께 확인해야 한다.
특히 nconnect는 커널/클라이언트 지원 여부 영향을 받으니 실제 노드 mount 결과 확인이 필요하다. nconnect 자체는 Linux NFS man page에 정의되어 있다.

5.2 테스트 Pod 예시

apiVersion: v1
kind: Pod
metadata:
 name: nfs-perf-test
spec:
 containers:
 - name: fio
 image: alpine:3.20
 command: ["/bin/sh", "-c"]
 args:
 - apk add --no-cache fio && sleep 36000
 volumeMounts:
 - name: testvol
 mountPath: /data
 volumes:
 - name: testvol
 persistentVolumeClaim:
 claimName: nfs-perf-pvc

배포 후 접속:

kubectl exec -it nfs-perf-test -- sh

5.3 Pod 내부 성능 측정

순차 쓰기

fio --name=write_test \
 --directory=/data \
 --filename=fio_write_test.dat \
 --rw=write \
 --bs=1M \
 --size=10G \
 --ioengine=libaio \
 --direct=1 \
 --iodepth=32 \
 --numjobs=1 \
 --runtime=60 \
 --time_based \
 --group_reporting

순차 읽기

fio --name=read_test \
 --directory=/data \
 --filename=fio_write_test.dat \
 --rw=read \
 --bs=1M \
 --size=10G \
 --ioengine=libaio \
 --direct=1 \
 --iodepth=32 \
 --numjobs=1 \
 --runtime=60 \
 --time_based \
 --group_reporting

랜덤 읽기/쓰기

fio --name=randrw_test \
 --directory=/data \
 --filename=fio_randrw_test.dat \
 --rw=randrw \
 --rwmixread=70 \
 --bs=4k \
 --size=5G \
 --ioengine=libaio \
 --direct=1 \
 --iodepth=64 \
 --numjobs=4 \
 --runtime=60 \
 --time_based \
 --group_reporting

6. 비교 방법

같은 조건으로 아래를 비교한다.

구분리눅스 노드 직접 마운트Pod + PV

순차 쓰기 MB/s	측정값	측정값
순차 읽기 MB/s	측정값	측정값
랜덤 IOPS	측정값	측정값
평균 지연시간	측정값	측정값
p95/p99 지연시간	측정값	측정값
CPU 사용률	측정값	측정값

해석 기준

노드 직접 마운트가 더 높고 Pod가 낮다면
Kubernetes 경유 오버헤드, 네트워크 네임스페이스, 스토리지 플러그인/마운트 방식 차이를 의심
둘 다 비슷하게 낮다면
NFS 서버 성능, 네트워크 대역폭, export 설정, 서버측 디스크 병목 가능성 우선 확인
rsize/wsize가 1MB로 협상되지 않았다면
서버/클라이언트 조합상 실제 1MB가 적용되지 않은 것

7. 권장 검증 절차

1단계

리눅스 노드에서 직접 마운트 후 /proc/mounts, nfsstat -m로 실제 옵션 확인

2단계

노드에서 fio로 baseline 성능 측정

3단계

동일 export를 PV/PVC로 연결

4단계

Pod 내부에서 동일 fio 조건으로 측정

5단계

노드 vs Pod 결과 비교

6단계

필요 시 아래 추가 비교

nconnect=1 vs nconnect=8
rsize/wsize=262144 vs 1048576
vers=3 vs vers=4.1
단, 이번 가이드의 기본안은 vers=3 기준

8. 문서에 넣을 만한 결론 문구

아래처럼 써도 돼.

NFS 마운트 성능 검증 시 rsize와 wsize는 핵심 확인 항목이다. Linux NFS 클라이언트는 서버와의 협상을 통해 최대 1MB까지 READ/WRITE payload를 사용할 수 있으므로, 실제 처리량 확보를 위해 rsize=1048576, wsize=1048576 설정 여부와 협상 결과를 반드시 확인해야 한다. 실제 적용값은 /proc/mounts 또는 nfsstat -m 기준으로 검증한다. 또한 노드 직접 마운트 성능과 Kubernetes Pod에서 PV로 연결한 성능을 각각 측정하여, 플랫폼 경유 오버헤드 유무를 함께 판단해야 한다.

9. 주의사항

intr은 최신 Linux에서는 무시되므로, 성능 향상 목적 옵션으로 해석하면 안 된다.
hard는 안정성 관점에서 일반적으로 유리하지만, 장애 시 I/O가 오래 대기할 수 있다.
nconnect=8은 환경에 따라 효과 차이가 있으므로 반드시 실측으로 판단해야 한다. man page는 다중 연결이 성능 향상에 유리할 수 있다고 설명하지만, 항상 향상된다고 보장하진 않는다.

원하면 내가 이걸 바로 운영 가이드 문체로 더 다듬어서
목적 / 사전조건 / 절차 / 검증 / 결과해석 / 주의사항 형식의 완성본으로 써줄게.

스케

독현진 — Thu, 16 Apr 2026 20:12:32 +0900

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)**까지 모든 레이어의 튜닝 포인트와 삽입 위치를 다뤘습니다. 가이드의 목차를 잡고 내용을 배치하시기만 하면 되겠네요! 추가로 궁금하신 세부 속성이 있으신가요?

M

독현진 — Tue, 14 Apr 2026 11:12:49 +0900

upgradeCRDs: true

image:
  repository: velero/velero
  tag: v1.16.0
  pullPolicy: IfNotPresent

initContainers:
  - name: velero-plugin-for-aws
    image: velero/velero-plugin-for-aws:v1.13.1
    imagePullPolicy: IfNotPresent
    volumeMounts:
      - mountPath: /target
        name: plugins

credentials:
  useSecret: true
  existingSecret: cloud-credentials

configuration:
  backupStorageLocation:
    - name: default
      provider: aws
      bucket: velero
      default: true
      accessMode: ReadWrite
      config:
        region: minio
        s3Url: http://<MINIO-ENDPOINT>:9000
        s3ForcePathStyle: "true"
        # prefix: cluster-a   # 필요하면 추가

  volumeSnapshotLocation: []

  defaultBackupTTL: 168h
  uploaderType: kopia

snapshotsEnabled: false
deployNodeAgent: true

dd

독현진 — Sun, 12 Apr 2026 12:24:05 +0900

Kube-scheduler 튜닝포인트 정리
/etc/kubernetes/scheduler-config.yaml 파일 생성해 kubescheduler.config.k8s.io/v1 적용

/etc/kubernetes/manifest/kubec-scheduler 에 컨피그 적용 설정
이후 spec.container.command에 아래 내용 추가
- kube-scheduler
- --config=/etc/kubernetes/scheduler-config.yaml
.
.
.
(mount)

#성능 튜닝
- percentageOfNodesToScore {0 ~ 100}
    스케줄링시 만족하는 노드의 개수가 지정한 수를 충족하면 탐색을 중단한다.
    이로 모든 노드에 대해 스케줄링을 고려하는 것 보다 시간을 절약할 수 있다.
    기본적인 임계값을 지정하지 않으면
    100 노드    : 50%
    5000 노드   : 10%
    위 값을 산출하는 선형공식을 사용하게된다. (클러스터 노드가 아무리 많아져도 최소값 5%)

    해당 값을 조절하여 스케줄링의 노드 스코어링 시간을 단축할 수 있다.
    하지만 충분한 개수만큼 노드를 확인하지 않기 때문에 가장 이상적인 파드 배치와 멀어질 수 있다.

    설정 예시
##########
    apiVersion: kubescheduler.config.k8s.io/v1
    kind: KubeSchedulerConfiguration
    percentageOfNodesToScore: 50
    .
    .
    .
##########

- parallelism
    스케줄러가 노드 필터링, 스코어링 작업을 병렬로 몇개씩 진행할지 결정한다. ( 기본값 16 )
    값이 상승할 수록 해당 스케줄링시  CPU 부하가 증가한다.

    설정 예시
##########
    apiVersion: kubescheduler.config.k8s.io/v1
    kind: KubeSchedulerConfiguration
    parallelism: 32
    .
    .

    .
    .
##########

#NodeResourcesFit
    스케줄러의 스코어링 전략 변경
- LeastAllocated
    여유가 많은 노드 선호
- MostAllocated
    이미 채워져가는 노드 선호
- RequestedToCapacityRatio
    커스텀된 값으로 선호 조절 (예 GPU)

1. Kube-scheduler 설정 구조 (v1 기준)

Kubernetes v1.23 이상부터는 kubescheduler.config.k8s.io/v1 API가 안정화되어 사용됩니다. 설정 파일은 크게 전역 설정과 프로파일(Profiles) 설정으로 나뉩니다.

/etc/kubernetes/scheduler-config.yaml

YAML

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
clientConnection:
  kubeconfig: /etc/kubernetes/scheduler.conf # 1. 인증 정보 (가장 중요)
leaderElection:
  leaderElect: true  # 고가용성(HA) 구성 시 필수
parallelism: 32      # [튜닝] 병렬 처리 수 (기본 16)
percentageOfNodesToScore: 50 # [튜닝] 노드 탐색 임계치 (%)
profiles:
  - schedulerName: default-scheduler
    plugins:
      score:
        disabled:
          - name: NodeResourcesFit # 기본 전략 비활성화 (전략 변경 시)
        enabled:
          - name: NodeResourcesFit
            weight: 1
    pluginConfig:
      - name: NodeResourceFit
        args:
          scoringStrategy:
            type: LeastAllocated # [튜닝] LeastAllocated | MostAllocated | RequestedToCapacityRatio

2. 핵심 튜닝 포인트 상세 분석

① 성능 최적화: percentageOfNodesToScore

이 설정은 스케줄러가 노드를 어디까지 훑어볼지 결정하는 '조기 종료' 조건입니다.

효과: 노드가 수천 대인 환경에서 모든 노드의 점수를 매기는 오버헤드를 줄여 Scheduling Latency를 획기적으로 낮춥니다.
주의점: 값이 너무 낮으면 최적의 노드가 아닌 '그냥 적당한' 노드에 파드가 배치되어 클러스터 자원 불균형이 생길 수 있습니다.

② 병렬성 제어: parallelism

기본값: 16
튜닝: 마스터 노드(Control Plane)의 CPU 코어 수가 넉넉하다면 이 값을 키워 필터링/스코어링 속도를 높일 수 있습니다. 보통 CPU 코어 수의 2~4배 정도로 설정하며 모니터링을 통해 조정합니다.

③ 스코어링 전략: NodeResourcesFit

파드를 어느 노드에 우선 배치할지 결정하는 알고리즘입니다.

전략	특징	권장 상황
LeastAllocated	여유 자원(CPU/MEM)이 가장 많은 노드에 배치	일반적인 워크로드, 자원 분산 필요 시
MostAllocated	자원이 이미 사용 중인 노드에 최대한 밀어넣기	Bin Packing, 노드 수를 최소화하여 비용 절감 시
RequestedToCapacityRatio	특정 리소스 비율에 따라 가중치 부여	GPU 등 특수 자원 비율에 따른 정교한 배치 필요 시

3. Static Pod 매니페스트 적용 (정리)

정리하신 대로 /etc/kubernetes/manifests/kube-scheduler.yaml을 수정할 때, 설정 파일이 컨테이너 내부로 올바르게 전달되도록 Volume Mount 설정이 정확해야 합니다.

kube-scheduler.yaml (핵심 요약)

YAML

spec:
  containers:
  - command:
    - kube-scheduler
    - --config=/etc/kubernetes/scheduler-config.yaml # 설정 파일 지정
    - -v=5 # 로그 표시레벨
    - --authentication-kubeconfig=/etc/kubernetes/scheduler.conf
    - --authorization-kubeconfig=/etc/kubernetes/scheduler.conf
    volumeMounts:
    - mountPath: /etc/kubernetes/scheduler-config.yaml
      name: scheduler-config
      readOnly: true
  volumes:
  - hostPath:
      path: /etc/kubernetes/scheduler-config.yaml
      type: FileOrCreate
    name: scheduler-config

추가 팁:

변경 사항 확인: 설정을 변경한 후에는 kubectl get nodes로 상태를 보는 것이 아니라, 스케줄러 로그를 통해 successfully renewed lease 또는 설정 오류 메시지가 없는지 확인해야 합니다.
다중 프로필: 하나의 클러스터에서 어떤 파드는 MostAllocated로, 어떤 파드는 LeastAllocated로 보내고 싶다면 profiles 섹션에 여러 개의 schedulerName을 정의하여 사용할 수 있습니다.

1. 스케줄링 대기열 튜닝 (Scheduling Queue)

파드가 스케줄링에 실패했을 때 다시 시도하기까지의 시간을 조절합니다.

# 파드 배치 실패시 이니셜백오프 시간의 두배씩 늘어납니다, 이후 맥스백오프 시간에 도달하면 고정됩니다.
예) 실패> 1초후 시도 > 실패 > 2초후 시도 > 실패 > 4초후 시도 > 8초후 시도 > 실패 > 10초후 시도 > 실패 > 10초후 시도

podInitialBackoffSeconds: 스케줄링 실패 시 재시도 전 대기하는 최소 시간 (기본값 1초).
podMaxBackoffSeconds: 재시도 대기 시간의 최대치 (기본값 10초).
튜닝 포인트:
- 클러스터 자원이 항상 타이트하여 스케줄링 실패가 잦다면, 이 값을 약간 높여 스케줄러의 불필요한 재시도 부하를 줄일 수 있습니다.
- 반대로 빠른 배치가 중요하다면 낮게 유지합니다.

2. 우선순위 및 선점 (Priority & Preemption)

중요한 파드가 먼저 실행되도록 보장하는 설정입니다.

disablePreemption: 기본값은 false입니다.
튜닝 포인트:
- 매우 급박한 워크로드가 많은 환경에서, 중요도가 낮은 파드를 밀어내고 자원을 확보해야 한다면 이 기능을 활성화합니다.
- 하지만 선점(Preemption)이 너무 자주 발생하면 클러스터가 요동칠 수 있으므로, PriorityClass를 정교하게 설계해야 합니다.

3. 특정 리소스 가중치 튜닝 (Resource Weight)

기본적으로 CPU와 Memory는 동일한 중요도로 계산됩니다.

binpacking 및 가중치: NodeResourcesFit 아규먼트 내에서 CPU와 Memory의 가중치를 다르게 줄 수 있습니다.
튜닝 포인트:
- 우리 서비스가 메모리를 훨씬 많이 사용한다면 메모리 여유 비중에 가중치를 더 높여서(예: CPU: 1, MEM: 5) 배치의 질을 높일 수 있습니다.

4. 멀티 스케줄러 (Multiple Schedulers)

하나의 스케줄러 설정으로 모든 워크로드를 만족시키기 어려울 때 사용합니다.

방법: 서로 다른 scheduler-config.yaml을 가진 스케줄러 디플로이먼트를 여러 개 실행합니다.
튜닝 포인트:
- 일반 파드: LeastAllocated 전략의 기본 스케줄러 사용.
- 배치/AI 학습 파드: MostAllocated (Bin Packing) 전략의 커스텀 스케줄러 사용.
- 파드 정의서(spec.schedulerName)에서 선택하여 사용할 수 있습니다.

5. Inter-Pod Affinity 성능 영향

podAffinity나 podAntiAffinity는 스케줄러에게 매우 무거운 작업입니다.

주의사항: 노드가 수백 대가 넘는 환경에서 대규모 파드들에 AntiAffinity를 걸면 스케줄링 속도가 급격히 느려집니다.
튜닝 포인트: 성능이 최우선이라면 podAffinity 대신 nodeAffinity나 TopologySpreadConstraints를 사용하는 것이 훨씬 가볍습니다.

요약: 추가하면 좋은 설정 예시 (v1)

YAML

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
...
profiles:
  - schedulerName: default-scheduler
    pluginConfig:
      - name: NodeResourcesFit
        args:
          scoringStrategy:
            type: LeastAllocated
            resources: # 리소스별 가중치 조절
              - name: cpu
                weight: 1
              - name: memory
                weight: 2 
    # 스케줄링 대기열 튜닝
    podInitialBackoffSeconds: 1
    podMaxBackoffSeconds: 10

정리하자면, 성능을 위해서는 작성하신 percentageOfNodesToScore와 parallelism이 가장 중요하고, 운영의 정교함을 위해서는 NodeResourcesFit의 가중치 조절과 Backoff 설정을 살펴보시는 것이 좋습니다.

스케줄링 튜닝 테스트

1. 스케줄링시 노드 탐색 범위 설정

#nginx 파드 20개 생성
kubectl create deployment test-tuning --image=nginx --replicas=20

# 로그에서 'nodes'나 'scoring' 관련 키워드 확인
kubectl logs -n kube-system kube-scheduler-k8s-redhat88-m01 | grep "nodes"

@1퍼센트 설정 후 테스트
root  k8s-redhat88-m01  ⎈ H4  default  etc  kubernetes  #  k get pod -o wide
NAME                           READY   STATUS    RESTARTS   AGE   IP              NODE                NOMINATED NODE   READINESS GATES
test-tuning-55c6f5cf5c-72rjq   1/1     Running   0          6s    10.244.3.155    k8s-redhat88-w05    <none>           <none>
test-tuning-55c6f5cf5c-7v9pt   1/1     Running   0          6s    10.244.6.175    k8s-redhat88-w02    <none>           <none>
test-tuning-55c6f5cf5c-8f9xx   1/1     Running   0          6s    10.244.10.184   k8s-redhat88-w010   <none>           <none>
test-tuning-55c6f5cf5c-9svps   1/1     Running   0          6s    10.244.6.208    k8s-redhat88-w02    <none>           <none>
test-tuning-55c6f5cf5c-bhpxp   1/1     Running   0          6s    10.244.8.22     k8s-redhat88-w09    <none>           <none>
test-tuning-55c6f5cf5c-dwpgn   1/1     Running   0          6s    10.244.10.130   k8s-redhat88-w010   <none>           <none>
test-tuning-55c6f5cf5c-fzzw6   1/1     Running   0          6s    10.244.7.19     k8s-redhat88-w03    <none>           <none>
test-tuning-55c6f5cf5c-gnj2q   1/1     Running   0          6s    10.244.12.247   k8s-redhat88-w08    <none>           <none>
test-tuning-55c6f5cf5c-jkdkh   1/1     Running   0          6s    10.244.5.230    k8s-redhat88-w04    <none>           <none>
test-tuning-55c6f5cf5c-kcf96   1/1     Running   0          6s    10.244.5.121    k8s-redhat88-w04    <none>           <none>
test-tuning-55c6f5cf5c-kmwc7   1/1     Running   0          6s    10.244.4.123    k8s-redhat88-w01    <none>           <none>
test-tuning-55c6f5cf5c-lgxt8   1/1     Running   0          6s    10.244.9.88     k8s-redhat88-w07    <none>           <none>
test-tuning-55c6f5cf5c-llvvw   1/1     Running   0          6s    10.244.4.249    k8s-redhat88-w01    <none>           <none>
test-tuning-55c6f5cf5c-mf7k7   1/1     Running   0          6s    10.244.3.112    k8s-redhat88-w05    <none>           <none>
test-tuning-55c6f5cf5c-qzz9t   1/1     Running   0          6s    10.244.8.161    k8s-redhat88-w09    <none>           <none>
test-tuning-55c6f5cf5c-r5d75   1/1     Running   0          6s    10.244.11.54    k8s-redhat88-w06    <none>           <none>
test-tuning-55c6f5cf5c-rksll   1/1     Running   0          6s    10.244.12.125   k8s-redhat88-w08    <none>           <none>
test-tuning-55c6f5cf5c-scrfv   1/1     Running   0          6s    10.244.7.34     k8s-redhat88-w03    <none>           <none>
test-tuning-55c6f5cf5c-wtcwz   1/1     Running   0          6s    10.244.9.74     k8s-redhat88-w07    <none>           <none>
test-tuning-55c6f5cf5c-zthg4   1/1     Running   0          6s    10.244.11.58    k8s-redhat88-w06    <none>           <none>

위 배포 pod 확인시 노드당 2개씩 배포됨을 확인
percentageOfNodesToScore: 1 는 스케줄러 로그에 명시되어 있음에도 균등하게 분배됨

이유 ) percentageOfNodesToScore 옵션의 경우 10개의 노드에서 테스트시 설정 적용은 확인 됐으나,

k8s 특성상 100개미만 의 노드에서는 자동으로 모든 노드를 탐색하고 스코어링 함

또한, 스케줄러의 노드 탐색 방식이 노드를 탐색 방식이 첫번째 탐색 후 두번째 탐색은 마지막 탐색지점부터 시작하고 이를 반복함,

#참고
https://kubernetes.io/docs/concepts/scheduling-eviction/scheduler-perf-tuning/

2. 스케줄링 대기열 튜닝 (Scheduling Queue) 테스트

YAML

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
# --- [전역 설정 영역] ---
leaderElection:
  leaderElect: true
  resourceName: kube-scheduler
  resourceNamespace: kube-system
clientConnection:
  kubeconfig: /etc/kubernetes/scheduler.conf

# [튜닝 1번] 스케줄링 대기열 (가장 바깥쪽 레벨)
# 실패한 파드가 다시 시도될 때까지의 '초' 단위 시간입니다.
podInitialBackoffSeconds: 1  # 처음 실패 시 1초 대기
podMaxBackoffSeconds: 10     # 아무리 길어져도 최대 10초 대기

# 노드 탐색 범위 제한
percentageOfNodesToScore: 1

# --- [개별 프로파일 영역] ---
profiles:
  - schedulerName: default-scheduler
    pluginConfig:
      - name: NodeResourcesFit # 's' 붙이는 것 잊지 마세요!
        args:
          scoringStrategy:
            type: MostAllocated
            resources:
              - name: cpu
                weight: 1
              - name: memory
                weight:

설정 파일 예시 (프로파일은 이전 설정이 남아있는 부분)

기본값

podInitialBackoffSeconds: 1 # 처음 실패 시 1초 대기 (대시 시간은 이니셜 백오프 시간의 두배씩 늘어남)

podMaxBackoffSeconds: 10 # 아무리 길어져도 최대 10초 대기

3. 우선순위 및 선점 (Priority & Preemption)

YAML

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
# ... (생략) ...
profiles:
  - schedulerName: default-scheduler
    # --- [2번 튜닝 포인트] ---
    disablePreemption: true  # 선점 기능 비활성화
    # ------------------------
    pluginConfig:
      - name: NodeResourcesFit
        args:
          scoringStrategy:
            type: MostAllocated
            resources:
              - name: cpu
                weight: 1
              - name: memory
                weight:

기본값

disablePreemption: false

true 설정시 priorityClass가 높은 파드가 큐에 들어오면 낮은 중요도의 파드를 강제 종료(evicted) 시키고 높은 파드를 배치
false(기본값) 설정시 기존 파드를 종료시키지 않고 노드가 조건을 충족시킬때 까지 대기

4. 특정 리소스 가중치 튜닝 (Resource Weight)

NodeResourcesFit의 weight 튜닝엔 두가지 방식이 있는데 아래와 같다

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
clientConnection:
  kubeconfig: /etc/kubernetes/scheduler.conf #인증 정보 (가장 중요)
profiles:
  - schedulerName: default-scheduler
    disablePreemption: true # 2번에서 설정한 값
    pluginConfig:
      - name: NodeResourcesFit
        args:
          scoringStrategy:
            type: MostAllocated # 자원을 꽉꽉 채워 쓰는 전략
            resources:
              - name: cpu
                weight: 1   # CPU는 기본 비중
              - name: memory
                weight: 5   # 메모리는 CPU보다 5배 더 중요하게 취급

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
clientConnection:
  kubeconfig: /etc/kubernetes/scheduler.conf # 1. 인증 정보 (가장 중요)
leaderElection:
  leaderElect: true  # 고가용성(HA) 구성 시 필수
profiles:
  - schedulerName: default-scheduler
    plugins:
      score:
        disabled:
          - name: NodeResourcesFit # 기본 전략 비활성화 (전략 변경 시)
        enabled:
          - name: NodeResourcesFit
            weight: 1
    pluginConfig:
      - name: NodeResourceFit
        args:
          scoringStrategy:
            type: MostAllocated

위의 두 설정 파일에서 차이 ( 모든 플러그인 weight 기본값 : 1 )

- 리소스에 mem weight :5 적용

계산식: c= 최종점수

- 플러그인 자체에 weight :5 적용

계산식 예시: (cpu 점수 *1 ) + (mem 점수 *1) * 5= 최종점수

만약 노드가 A,B 두개가 존재하는 클러스터에 MostAllocated 전략 ( pod를 노드에 최대한 적재하는 방식 ) 을 사용하고

Pod 배치시 메모리 가중치를 늘리고자 할때의 예시다.

노드	CPU 여유	메모리 여유
노드 A	10% (거의 꽉 참)	90% (매우 널널)
노드 B	90% (매우 널널)	10% (거의 꽉 참)

(메모리 가중치 5):
- 노드 A 점수: (90*1) + (10 *5) = 140
- 노드 B 점수: (10 * 1) + (90 * 5) = 460
- 결과: 메모리를 꽉 채울 수 있는 노드 B 선택 (의도대로 작동)
(플러그인 가중치 5):
- 노드 A 점수: (90 + 10) *5 = 500
- 노드 B 점수: (10 + 90) *5 = 500
- 결과: 점수가 같음 (메모리 비중 강화 실패)

wight 가중치를 어떻게 설정하느냐에 따라 무의미해질 수 있기 때문에 어떻게 설정할지 고려해야한다.

@NodeResourcesFit : MostAllocated 최대한 적은 노드에 배치 설정후 테스트 (weight : 5 )

root  k8s-redhat88-m02  ⎈ H4  default  ~  #  k get pod -o wide
NAME                           READY   STATUS    RESTARTS   AGE   IP             NODE               NOMINATED NODE   READINESS GATES
test-tuning-55c6f5cf5c-4tbbs   1/1     Running   0          47s   10.244.7.185   k8s-redhat88-w03   <none>           <none>
test-tuning-55c6f5cf5c-544mr   1/1     Running   0          47s   10.244.7.59    k8s-redhat88-w03   <none>           <none>
test-tuning-55c6f5cf5c-6d8sp   1/1     Running   0          47s   10.244.7.55    k8s-redhat88-w03   <none>           <none>
test-tuning-55c6f5cf5c-f5b5h   1/1     Running   0          47s   10.244.7.207   k8s-redhat88-w03   <none>           <none>
test-tuning-55c6f5cf5c-ffsvj   1/1     Running   0          47s   10.244.7.209   k8s-redhat88-w03   <none>           <none>
test-tuning-55c6f5cf5c-g77wh   1/1     Running   0          47s   10.244.7.152   k8s-redhat88-w03   <none>           <none>
test-tuning-55c6f5cf5c-l4kcj   1/1     Running   0          47s   10.244.7.200   k8s-redhat88-w03   <none>           <none>
test-tuning-55c6f5cf5c-l7vd4   1/1     Running   0          47s   10.244.7.236   k8s-redhat88-w03   <none>           <none>
test-tuning-55c6f5cf5c-m929m   1/1     Running   0          47s   10.244.7.231   k8s-redhat88-w03   <none>           <none>
test-tuning-55c6f5cf5c-nrnj4   1/1     Running   0          47s   10.244.7.6     k8s-redhat88-w03   <none>           <none>
test-tuning-55c6f5cf5c-pmmb6   1/1     Running   0          47s   10.244.7.245   k8s-redhat88-w03   <none>           <none>
test-tuning-55c6f5cf5c-pq4nc   1/1     Running   0          47s   10.244.7.71    k8s-redhat88-w03   <none>           <none>
test-tuning-55c6f5cf5c-qfd6g   1/1     Running   0          47s   10.244.7.135   k8s-redhat88-w03   <none>           <none>
test-tuning-55c6f5cf5c-r4dkr   1/1     Running   0          47s   10.244.7.52    k8s-redhat88-w03   <none>           <none>
test-tuning-55c6f5cf5c-rczpq   1/1     Running   0          47s   10.244.7.214   k8s-redhat88-w03   <none>           <none>
test-tuning-55c6f5cf5c-s2x9p   1/1     Running   0          47s   10.244.7.40    k8s-redhat88-w03   <none>           <none>
test-tuning-55c6f5cf5c-t66pz   1/1     Running   0          47s   10.244.7.35    k8s-redhat88-w03   <none>           <none>
test-tuning-55c6f5cf5c-tjzt2   1/1     Running   0          47s   10.244.7.89    k8s-redhat88-w03   <none>           <none>
test-tuning-55c6f5cf5c-x2d7t   1/1     Running   0          47s   10.244.7.30    k8s-redhat88-w03   <none>           <none>
test-tuning-55c6f5cf5c-xbpg8   1/1     Running   0          47s   10.244.7.227   k8s-redhat88-w03   <none>           <none>

모든 pod w03 배치

# weight 1로 설정시 별 영향 없음( 각노드에 2개 pod 배치 )

root  k8s-redhat88-m02  ⎈ H4  default  ~  #  k get pod -o wide
NAME                           READY   STATUS    RESTARTS   AGE   IP              NODE                NOMINATED NODE   READINESS GATES
test-tuning-55c6f5cf5c-28qlf   1/1     Running   0          6s    10.244.3.104    k8s-redhat88-w05    <none>           <none>
test-tuning-55c6f5cf5c-45d6c   1/1     Running   0          7s    10.244.7.13     k8s-redhat88-w03    <none>           <none>
test-tuning-55c6f5cf5c-5rrw7   1/1     Running   0          6s    10.244.10.17    k8s-redhat88-w010   <none>           <none>
test-tuning-55c6f5cf5c-87qh5   1/1     Running   0          7s    10.244.11.253   k8s-redhat88-w06    <none>           <none>
test-tuning-55c6f5cf5c-b49p6   1/1     Running   0          7s    10.244.12.72    k8s-redhat88-w08    <none>           <none>
test-tuning-55c6f5cf5c-b5s2z   1/1     Running   0          6s    10.244.3.21     k8s-redhat88-w05    <none>           <none>
test-tuning-55c6f5cf5c-fn7gj   1/1     Running   0          6s    10.244.12.54    k8s-redhat88-w08    <none>           <none>
test-tuning-55c6f5cf5c-g4t9n   1/1     Running   0          6s    10.244.6.37     k8s-redhat88-w02    <none>           <none>
test-tuning-55c6f5cf5c-gvb7d   1/1     Running   0          6s    10.244.4.105    k8s-redhat88-w01    <none>           <none>
test-tuning-55c6f5cf5c-j4sgb   1/1     Running   0          6s    10.244.5.233    k8s-redhat88-w04    <none>           <none>
test-tuning-55c6f5cf5c-jfvg9   1/1     Running   0          6s    10.244.11.222   k8s-redhat88-w06    <none>           <none>
test-tuning-55c6f5cf5c-k7j4s   1/1     Running   0          7s    10.244.6.254    k8s-redhat88-w02    <none>           <none>
test-tuning-55c6f5cf5c-kwsjd   1/1     Running   0          6s    10.244.5.220    k8s-redhat88-w04    <none>           <none>
test-tuning-55c6f5cf5c-m7z4x   1/1     Running   0          7s    10.244.9.37     k8s-redhat88-w07    <none>           <none>
test-tuning-55c6f5cf5c-nq2gx   1/1     Running   0          6s    10.244.10.50    k8s-redhat88-w010   <none>           <none>
test-tuning-55c6f5cf5c-pnpzs   1/1     Running   0          7s    10.244.8.195    k8s-redhat88-w09    <none>           <none>
test-tuning-55c6f5cf5c-px2t2   1/1     Running   0          6s    10.244.9.241    k8s-redhat88-w07    <none>           <none>
test-tuning-55c6f5cf5c-qbfzh   1/1     Running   0          7s    10.244.4.176    k8s-redhat88-w01    <none>           <none>
test-tuning-55c6f5cf5c-th7dt   1/1     Running   0          6s    10.244.8.218    k8s-redhat88-w09    <none>           <none>
test-tuning-55c6f5cf5c-zvvzg   1/1     Running   0          6s    10.244.7.157    k8s-redhat88-w03    <none>           <none>

5. 병렬 처리 설정: parallelism

YAML

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
leaderElection:
  leaderElect: true
clientConnection:
  kubeconfig: /etc/kubernetes/scheduler.conf
parallelism: 16

기본값 16

설정값에 따라서 스케줄러가 노드를 분산해 필터링, 스코어링 작업을 수행한다,

예) (16으로 설정) 100개의 노드에 배치할때 10개의 그룹으로 나눠 16개씩 스케줄러가 노드 평가작업을 실시한다.

Velero 설치

독현진 — Sun, 12 Apr 2026 11:59:53 +0900

[cloud-user@ethan-dev2 velero]$ cat ansible/qks-velero/tasks/main.yaml
---

- name: QKS Velero | Create manifests directory for {{ component }}
  when:
    - inventory_hostname in groups['kube-master']
  become: true
  file:
    path: "{{ qks_manifests_location}}/{{ component }}"
    state: directory
    owner: root
    group: root
    mode: '0755'
    recurse: true

#################################################################################################

- name: QKS Velero | Create Namespaces
  when: inventory_hostname in groups['kube-master']
  become: true
  run_once: true
  shell: "kubectl create namespace {{ qks_velero_namespace }} --dry-run -o yaml | kubectl apply -f -"

- name: QKS Velero | Install External-Snapshotter Components
  when:
    - not qks_offline_enabled | bool
    - inventory_hostname in groups['kube-master']
  become: true
  vars:
    snapshotter_components:
      - client/config/crd
      - deploy/kubernetes/csi-snapshotter
      - deploy/kubernetes/snapshot-controller
  shell: |
    kubens {{ qks_velero_namespace }}
    kubectl apply -k https://github.com/kubernetes-csi/external-snapshotter/{{ item }}?ref=release-{{ qks_velero_external_snapshotter_version }}
  loop: "{{ snapshotter_components }}"
  loop_control:
    label: "{{ item }}"
  run_once: true

- name: QKS Velero | Install External-Snapshotter Components
  when:
    - qks_offline_enabled | bool
    - inventory_hostname in groups['kube-master']
  become: true
  run_once: true
  block:
    - name: QKS Velero | Copy Manifests
      copy:
        src: "{{ item }}.yaml"
        dest: "{{ qks_manifests_location }}/{{ component }}/{{ item }}.yaml"
      loop:
        - groupsnapshot.storage.k8s.io_volumegroupsnapshotclasses
        - groupsnapshot.storage.k8s.io_volumegroupsnapshotcontents
        - groupsnapshot.storage.k8s.io_volumegroupsnapshots
        - kustomization
        - rbac-csi-snapshotter
        - rbac-external-provisioner
        - rbac-snapshot-controller
        - setup-csi-snapshotter
        - setup-snapshot-controller
        - snapshot.storage.k8s.io_volumesnapshotclasses
        - snapshot.storage.k8s.io_volumesnapshotcontents
        - snapshot.storage.k8s.io_volumesnapshots
    - name: QKS Velero | Apply Manifests
      shell: |
            kubens {{ qks_velero_namespace }}
            kubectl apply -k {{ qks_manifests_location }}/{{ component }}

###############
#
###############
- name: QKS Velero | Create Secret & VSClass
  when:
    - inventory_hostname in groups['kube-master']
  become: true
  run_once: true
  block:
    - name: QKS Velero | Template VSClass
      template:
        src: volumesnapshotclass.yaml.j2
        dest: "{{ qks_manifests_location }}/{{ component }}/volumesnapshotclass.yaml"

    - name: QKS Velero | Prepare base64-encoded S3 credentials
      set_fact:
        s3_credentials_raw: |
          [default]
          aws_access_key_id={{ qks_velero_s3_access_key_id }}
          aws_secret_access_key={{ qks_velero_s3_secret_access_key }}

    - name: QKS Velero | Encode credentials to base64
      set_fact:
        s3_credentials_base64: "{{ s3_credentials_raw | b64encode }}"

    - name: QKS Velero | Template Secret
      template:
        src: secret-s3-credentials.yaml.j2
        dest: "{{ qks_manifests_location }}/{{ component }}/secret-s3-credentials.yaml"

    - name: QKS Velero | Apply Secret & VSClass
      shell: >
        kubectl apply -f {{ qks_manifests_location }}/{{ component }}/{{ item }}.yaml
      loop:
        - volumesnapshotclass
        - secret-s3-credentials

- name: QKS Velero | Add Chart Repository 'vmware-tanzu'
  when:
    - not qks_offline_enabled | bool
    - inventory_hostname in groups['kube-master']
  become: true
  helm_repository:
    name: vmware-tanzu
    url: https://vmware-tanzu.github.io/helm-charts
    state: present
  no_log: true

- name: QKS Velero | Ensure S3 bucket exists
  when:
    - inventory_hostname in groups['kube-master']
    - qks_velero_create_bucket | default(true) | bool
  become: true
  run_once: true
  shell: |
    set -euo pipefail

    CREDS="$(mktemp /tmp/velero-aws-creds.XXXXXX)"
    kubectl -n {{ qks_velero_namespace }} get secret s3-credentials \
      -o jsonpath='{.data.aws}' | base64 -d > "${CREDS}"

    export AWS_SHARED_CREDENTIALS_FILE="${CREDS}"

    aws --endpoint-url https://{{ qks_velero_s3_url }} --no-verify-ssl s3api head-bucket --bucket {{ qks_velero_bucket | default('velero') }} \
      || aws --endpoint-url https://{{ qks_velero_s3_url }} --no-verify-ssl s3 mb s3://{{ qks_velero_bucket | default('velero') }}

    rm -f "${CREDS}"
  args:
    executable: /bin/bash

- name: QKS Velero | Set chart location
  when:
    - inventory_hostname in groups['kube-master']
  set_fact:
    chartname: >-
      {% if qks_offline_enabled | bool                                                    %}
      {{ qks_offline_target }}/{{ component }}/charts/velero-{{ qks_velero_version }}.tgz
      {% else                                                                              %}
      vmware-tanzu/velero
      {% endif                                                                             %}
  run_once: true

- name: QKS Velero | Deploy {{ qks_velero_release }}
  when:
    - inventory_hostname in groups['kube-master']
  become: true
  helm_cmd:
    name: "{{ chartname }}"
    release: "{{ qks_velero_release }}"
    version: "{{ qks_velero_version }}"
    namespace: "{{ qks_velero_namespace }}"
    state: present
    update_cache: no
    force: true
    wait: true
    options:
      - '--set cleanUpCRDs=true'
      - '--set deployNodeAgent=true'
      - '--set configuration.features=EnableCSI'
      - '--set configuration.backupStorageLocation[0].name=velero'
      - '--set configuration.backupStorageLocation[0].provider=aws'
      - '--set configuration.backupStorageLocation[0].bucket=velero'
      - '--set configuration.backupStorageLocation[0].default=true'
      - '--set configuration.backupStorageLocation[0].config.region=ap-northeast-2'
      - '--set configuration.backupStorageLocation[0].config.checksumAlgorithm=""'
      - '--set configuration.backupStorageLocation[0].config.s3ForcePathStyle=true'
      - '--set configuration.backupStorageLocation[0].config.s3Url=https://{{ qks_velero_s3_url }}'
      - '--set configuration.backupStorageLocation[0].credential.name=s3-credentials'
      - '--set configuration.backupStorageLocation[0].credential.key=aws'
      - '--set configuration.volumeSnapshotLocation[0].name=velero-volume'
      - '--set configuration.volumeSnapshotLocation[0].provider=aws'
      - '--set configuration.volumeSnapshotLocation[0].config.region=ap-northeast-2'
      - '--set configuration.volumeSnapshotLocation[0].credential.name=s3-credentials'
      - '--set configuration.volumeSnapshotLocation[0].credential.key=aws'
      - '--set initContainers[0].name=velero-plugin-for-aws'
      - '--set initContainers[0].image=velero/velero-plugin-for-aws:{{ qks_velero_plugin_for_aws_version }}'
      - '--set initContainers[0].volumeMounts[0].mountPath=/target'
      - '--set initContainers[0].volumeMounts[0].name=plugins'
  run_once: yes

- name: QKS Velero-UI | Add Chart Repository 'otwld'
  when:
    - not qks_offline_enabled | bool
    - inventory_hostname in groups['kube-master']
  become: true
  helm_repository:
    name: otwld
    url: https://helm.otwld.com/
    state: present
  no_log: true

- name: QKS Velero-UI | Set chart location
  when:
    - inventory_hostname in groups['kube-master']
  become: true
  set_fact:
    chartname: >-
      {% if qks_offline_enabled | bool                                                    %}
      {{ qks_offline_target }}/{{ component }}/charts/velero-ui-{{ qks_velero_ui_version }}.tgz
      {% else                                                                              %}
      otwld/velero-ui
      {% endif                                                                             %}
  run_once: yes

- name: QKS Velero-UI | Create ConfigMap
  when:
    - inventory_hostname in groups['kube-master']
  become: true
  run_once: true
  block:
    - name: QKS Velero-UI | Template ConfigMap
      template:
        src: velero-ui-env-vars.yaml.j2
        dest: "{{ qks_manifests_location }}/{{ component }}/velero-ui-env-vars.yaml"
    - name: QKS Velero-UI | Apply ConfigMap
      shell: >
        kubectl apply -f {{ qks_manifests_location }}/{{ component }}/{{ item }}.yaml
      loop:
        - velero-ui-env-vars

- name: QKS Velero-UI | Deploy {{ qks_velero_ui_release }}
  when:
    - inventory_hostname in groups['kube-master']
  become: true
  run_once: yes
  helm_cmd:
    name: "{{ chartname }}"
    release: "{{ qks_velero_ui_release }}"
    version: "{{ qks_velero_ui_version }}"
    namespace: "{{ qks_velero_namespace }}"
    state: present
    update_cache: no
    force: yes
    wait: true
    options:
      - '--set ingress.enabled=true'
      - '--set ingress.hosts[0].host={{ qks_velero_ui_fqdn }}'
      - '--set-string ingress.hosts[0].paths[0].path=/'
      - '--set-string ingress.hosts[0].paths[0].pathType=Prefix'
      - '--set configuration.general.secretPassPhrase.useSecret=false'
      - '--set envFrom[0].configMapRef.name=velero-ui-env-vars'
        #- '--set envFrom[1].secretRef.name=velero-ui-secret'

- name: QKS Velero | Add FQDN to /etc/hosts file
  become: yes
  lineinfile:
    dest: /etc/hosts
    insertafter: EOF
    state: present
    line: "{{ qks_load_balancer_addr }} {{ item }}"
  loop:
    - '{{ qks_velero_ui_fqdn }}'

- name: QKS Velero | Patch BSL
  when:
    - inventory_hostname in groups['kube-master']
  become: yes
  run_once: true
  shell: |
        kubectl patch bsl velero --patch '{"spec": {"config": {"insecureSkipTLSVerify": "true"}}}' --type merge -n {{ qks_velero_namespace }}

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

velero-nfs

apiVersion: v1
kind: PersistentVolume
metadata:
  name: velero-nfs-pv
spec:
  capacity:
    storage: 100Gi
  accessModes:
    - ReadWriteMany
  nfs:
    server: <NFS_SERVER_IP>  # 예: 192.168.1.10
    path: /path/to/backup    # NFS 공유 경로
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: velero-nfs-pvc
  namespace: velero
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 100Gi
  volumeName: velero-nfs-pv

values

# values.yaml

# 최신 Velero 이미지 사용
image:
  repository: velero/velero
  tag: v1.18.0
  pullPolicy: IfNotPresent

# 플러그인 설정
initContainers:
  # CSI 스냅샷 연동용 (필수)
  - name: velero-plugin-for-csi
    image: velero/velero-plugin-for-csi:v0.8.0 # 2026 최신 호환 버전
    volumeMounts:
      - mountPath: /target
        name: plugins
  # NFS/파일시스템 백업용 플러그인
  - name: velero-plugin-for-file-system
    image: velero/velero-plugin-for-file-system:v0.8.0
    volumeMounts:
      - mountPath: /target
        name: plugins

configuration:
  # NFS를 저장소로 지정
  backupStorageLocation:
    - name: default
      provider: community.velero.io/file-system-plugin
      bucket: velero-backups
      default: true
      config:
        path: /var/velero-local-storage # 컨테이너 내부 마운트 경로
  
  # NFS 환경에서는 CSI Snapshot보다 Data Mover(Kopia) 방식이 안정적입니다.
  volumeSnapshotLocation: []
  uploaderType: kopia 

# 노드 에이전트 활성화 (데이터 복사 및 전송 담당)
deployNodeAgent: true

# NFS PVC를 Velero 서버와 노드 에이전트 Pod에 마운트
volumes:
  - name: backup-storage
    persistentVolumeClaim:
      claimName: velero-nfs-pvc

volumeMounts:
  - name: backup-storage
    mountPath: /var/velero-local-storage

# NFS 환경이므로 별도의 S3 Secret 등은 필요 없음
credentials:
  useSecret: false

# RBAC 활성화
rbac:
  create: true

# [옵션] 앤서블 코드에서 사용하던 UI나 추가 설정이 필요하다면 여기에 추가

헬름으로 설치

# 1. 레포지토리 추가 및 업데이트
helm repo add vmware-tanzu https://vmware-tanzu.github.io/helm-charts
helm repo update

# 2. 최신 차트 버전 확인 (선택 사항)
helm search repo vmware-tanzu/velero --versions | head -n 5

# 3. 설치
helm install velero vmware-tanzu/velero \
  --namespace velero \
  -f values.yaml \
  --version 12.0.0

확인

# BSL 상태 확인 (PHASE가 Available이어야 합니다)
kubectl get bsl -n velero

# 에이전트들이 모든 노드에 잘 떴는지 확인
kubectl get daemonset -n velero node-agent

syslog

독현진 — Tue, 19 Nov 2024 16:00:30 +0900

syslog는 로깅을 위한 표준 형식이다.

한마디로 장치에 특이사항이나 변동이 발생하면

메세지가 발생하게 된다.

예로 OSPF의 활성화 후 인접성을 형성하는 syslog를 확인해보자

00:07:33: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.100.1 on Serial0/0/0 from LOADING to FULL, Loading Done
-OSPF 인접성 형성

%LINK-5-CHANGED: Interface Serial0/0/0, changed state to administratively down
-인터페이스 수동 shutdown

두개의 라우터에 같은 area의 ospf를 설정하면 잠시뒤 위와같은 syslog가 출력된다.

( ospf 설정 후 기다리면 CLI 창에서 확인이 가능하다 )

이 것을 분석해보자

각 항목은 : (콜론) 으로 구분된다.

*00:07:33: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.100.1 on Serial0/0/0 from LOADING to FULL, Loading Done

* 시퀀스 넘버 (패킷 트레이서에는 미표기)

00:07:33 이벤트 발생 시간 (월,일까지 표기되나 패킷트레이서에는 미표기)

%OSPF %Facility 범주 (링크 상태 관련이면 %LINK로 표시됨)

5 Serverity 번호

ADJCHG Mnemonic (이벤트의 간단한 요약)

Process 1 ..... Loading Done Description ( 이벤트의 자세한 설명 )

중간의 Serverity 레벨은

레벨	심각도	내용
0	Emergency	시스템이 더 이상 사용할 수 없는 심각한 상태
1	Alert	즉각적인 조치가 필요한 상황
2	Critical	심각한 문제
3	Error	일반적인 오류 상황
4	Warning	주의가 필요한 상황
5	Notice	중요하지만 경고는 아님(정상적인 중요한 이벤트)
6	Informational	정보성 메시지 (일반적인 상태 보고)
7	Debug	디버깅용 상세 메시지

위의 표를 따른다

해당 표는 모든 업체에서 따르는 표준이고 숫자가 낮을수록 중요하다.

0~3 단계의 로그 발생시 심각한 문제로 본다.

즉, 예시의 OSPF 인접성 형성 로그는

5단계의 로그인 것을 알 수 있다.

로깅위치

로그는 다양한 장소에서 로깅된다.

Console line

네트워크 장비에 콘솔 포트로 작업을 하면

CLI 창에 syslog가 표시되는 것을 볼 수 있다.

기본적으로 활성화 되어있고 Serverity레벨은 7(Debug)이다.

(7레벨이 활성화되면 7 ~ 0레벨 까지의 모든 로그가 표시된다.)

VTY Terminal line

telnet, ssh 를 이용해 접속하는 경우 VTY 즉, 가상 터미널 라인에 로그가 표시된다.

기본적으로 비활성화 되어있다.

Logging Buffer

장치의 RAM에 이벤트가 저장된다.

show logging 명령어로 확인이 가능하다.

기본적으로 활성화 되어있고 7( Debug )레벨이다.

(7레벨이 활성화되면 7 ~ 0레벨 까지의 모든 로그가 표시된다.)

외부 syslog 서버

로그의 저장장소를 외부로 지정할 수도 있다.

syslog 설정 예

R1(config)# no logging console
로깅 비활성화

R1(config)# logging monitor 6
Telnet, SSH 접속시 로깅 Informational(6레벨) 보다 위의 레벨만 기록됨

R1(config)# loggin buffered debugging
RAM 버퍼에 7레벨(debug) 이상의 로그만 기록됨

R1(config)# logging 10.0.0.100
R1(config)# logging trap debugging
10.0.0.100의 서버에 로그 저장
7레벨 (debugging) 이상만 저장됨

로깅 위치는 원하는 곳에 원하는 개수로 설정 가능하다.

서로 다른 위치에 같은 내용의 로그가 기록되지만

다른 위치에 다른 레벨의 로그만 기록되게 할 수도 있다