프록시 동시성(Proxy Concurrency) 구성

원문 보기 위키 갱신 2026.10.03

Linkerd 데이터 플레인 프록시는 시작할 때 고정된 수의 워커 스레드를 할당하고, 이 스레드 수가 프록시의 최대 CPU 사용량을 직접 결정해요. 프록시가 같은 포드 안의 다른 컨테이너와 나란히, 같은 노드의 다른 포드와 함께 실행되는 Kubernetes 환경에서 이 정적 할당은 스레드를 너무 많이 고르면 CPU 초과 할당(oversubscription)으로 이어질 수 있어요. 운영자는 프록시의 고정 스레드 수와 포드의 CPU 한도·리소스 쿼터 사이에서 균형을 맞춰, 프록시와 애플리케이션 컨테이너 모두 전체 성능을 떨어뜨리지 않고 효율적으로 동작하게 해야 해요.

출처: Linkerd Configuring Proxy Concurrency

본문

Linkerd 데이터 플레인 프록시는 시작 시 고정된 수의 워커 스레드를 할당하고, 이 스레드 수가 프록시의 최대 CPU 소비량을 직접 결정해요. 프록시가 같은 포드의 다른 컨테이너와 함께, 그리고 같은 노드의 다른 포드와 공존하며 실행되는 Kubernetes 환경에서 이 정적 할당은 스레드를 너무 많이 선택하면 CPU 초과 할당으로 이어질 수 있어요. 운영자는 프록시의 고정 스레드 수와 포드의 CPU 한도 및 리소스 쿼터 사이의 균형을 맞춰, 프록시와 애플리케이션 컨테이너 모두 전체 성능을 떨어뜨리지 않고 효율적으로 동작하도록 해야 해요.

기본 동작

Linkerd의 기본 Helm 구성은 사이드카 프록시를 런타임 워커 하나로 실행해요. 프록시에 대해 요청(request)이나 한도(limit)가 구성되어 있지 않아요.

`proxy:
  resources:
    cpu:
      request:
      limit:
  runtime:
    workers:
      minimum: 1
`

이 문서는 추가 런타임 워커로 프록시를 실행하는 방법을 설명해요.

프록시 CPU 요청과 한도 구성

Kubernetes는 모든 컨테이너에 대해 CPU 요청과 한도를 설정할 수 있게 해 주고, 이 설정이 Linkerd 프록시의 CPU 사용량도 제어할 수 있어요. 다만 이 설정의 효과는 kubelet이 CPU 한도를 어떻게 강제하는지에 따라 달라져요.

kubelet은 --cpu-manager-policy 플래그에 따라 두 가지 접근 방식 중 하나로 포드 CPU 한도를 강제해요.

기본 CPU 매니저 정책

기본 none 정책을 사용할 때, kubelet은 Completely Fair Scheduler (CFS) 쿼터에 의존해요. 이 모드에서 Linux 커널은 (Linkerd 프록시를 포함한) 프로세스가 사용할 수 있는 CPU 시간의 비율을 제한해요.

정적 CPU 매니저 정책

kubelet이 정적 CPU 매니저 정책으로 구성되면 Linux cgroup cpuset을 활용해 컨테이너에 전체 CPU 코어를 할당해요. 이 메커니즘을 성공적으로 사용하려면 다음 조건이 충족되어야 해요.

kubelet이 정적 CPU 매니저 정책으로 실행되어야 해요.
포드가 Guaranteed QoS 클래스에 속해야 해요. 이를 위해 포드의 모든 컨테이너가 일치하는 CPU(및 메모리) 요청과 한도를 가져야 해요.
프록시의 CPU 요청과 CPU 한도가 정수로 지정되고 최소 1이어야 해요.

Helm으로 기본 프록시 CPU 요청과 한도 구성

제어 플레인 helm 차트에서 전역 기본 CPU 요청을 구성해 스케줄러에 영향을 줄 수 있어요.

`proxy:
  resources:
    cpu:
      request: 100m
`

요청만 지정되면 그 값으로 프록시의 런타임(다음 정수로 올림)을 구성해요.

또는 제어 플레인 helm 차트에서 전역 기본 CPU 한도를 구성할 수 있어요.

`proxy:
  resources:
    cpu:
      limit: 2000m
`

마찬가지로 이 값이 프록시의 런타임 구성(다음 정수로 올림)을 제어해요.

두 값이 모두 지정되면 요청은 스케줄러에 영향을 주는 데 사용되고 한도는 프록시 런타임을 구성하는 데 사용돼요.

`proxy:
  resources:
    cpu:
      request: 100m
      limit: 2000m
`

주석으로 프록시 CPU 요청과 한도 재정의

config.linkerd.io/proxy-cpu-request와 config.linkerd.io/proxy-cpu-limit 주석으로 특정 네임스페이스나 워크로드에 대한 Helm 구성을 재정의할 수 있어요.

`kind: Deployment
apiVersion: apps/v1
metadata:
  # ...
spec:
  template:
    metadata:
      annotations:
        config.linkerd.io/proxy-cpu-request: 100m
        config.linkerd.io/proxy-cpu-limit: 2000m
  # ...
`

참고

CPU 수량 주석 값이 정수로 표현되지 않으면, 프록시 런타임을 구성할 때 다음 정수로 올림돼요.

합리적 프록시 CPU 한도 구성

일부 환경에서는 워크로드에 고정 CPU 한도를 사용하는 것이 실용적이지 않을 수 있어요(예: 워크로드가 CPU 한도를 지정하지 않고 크기가 다양한 노드에서 실행되는 경우). 이 경우 프록시를 호스트의 총 사용 가능 CPU에 대한 최대 비율로 구성할 수 있어요.

runtime.workers.maximumCPURatio 값이 1.0이면 CPU마다 워커 하나를 할당하도록 프록시를 구성하고, 0.2면 사용 가능한 코어 5개마다 프록시 워커 1개를 할당하도록 구성해요(상황에 따라 올림 또는 내림). runtime.workers.minimum 값은 프록시당 워커 수의 하한을 설정해요.

Helm으로 합리적 프록시 CPU 한도 구성

제어 플레인 helm 차트에서 전역 기본값을 구성할 수 있어요.

`proxy:
  runtime:
    workers:
      maximumCPURatio: 0.2
      minimum: 1
`

참고

CPU 한도는 최대 CPU 비율보다 우선하므로, 전역 기본 maximumCPURatio를 설정하면서 특정 워크로드에는 한도를 설정하는 것이 적절해요.

주석으로 합리적 프록시 CPU 한도 재정의

기본 최대 CPU 비율을 재정의하려면 config.linkerd.io/proxy-cpu-ratio-limit 주석을 사용해요.

`kind: Deployment
apiVersion: apps/v1
metadata:
  # ...
spec:
  template:
    metadata:
      annotations:
        config.linkerd.io/proxy-cpu-ratio-limit: "0.3"
  # ...
`