5장: Linkerd - 경량 서비스 메시의 철학과 실전

Linkerd는 "서비스 메시"라는 용어를 처음 만든 프로젝트입니다. 2016년 Buoyant가 발표한 이후 단순함, 경량성, 운영 용이성을 핵심 가치로 발전해 왔습니다. Istio가 풍부한 기능 세트를 추구한다면, Linkerd는 "필요한 것만 제공하되 완벽하게"라는 철학을 따릅니다.

Linkerd의 설계 철학

Linkerd 팀은 서비스 메시가 "boring infrastructure"가 되어야 한다고 주장합니다. 인프라는 존재감 없이 묵묵히 작동해야 하며, 운영자에게 부담을 주어서는 안 된다는 것입니다.

이 철학은 구체적인 설계 원칙으로 이어집니다.

최소 복잡성: 80%의 사용 사례를 커버하는 기능만 제공합니다. Istio의 VirtualService 같은 복잡한 CRD 대신, 직관적인 서비스 프로파일(ServiceProfile)과 HTTP 라우팅을 제공합니다.

자체 프록시: Envoy 대신 Rust로 작성한 linkerd2-proxy를 사용합니다. Envoy의 범용성 대신 서비스 메시에 필요한 기능만 구현하여 메모리 사용량과 공격 표면을 줄였습니다.

자동화 우선: mTLS는 설치 즉시 자동 활성화됩니다. 인증서 발급, 갱신, 폐기가 모두 자동입니다. 별도의 PeerAuthentication 설정이 필요 없습니다.

아키텍처

컨트롤 플레인

Linkerd의 컨트롤 플레인은 linkerd-control-plane 네임스페이스에 배포되는 몇 가지 컴포넌트로 구성됩니다.

Linkerd 컨트롤 플레인

┌──────────────────────────────────────────────┐
│ linkerd-control-plane 네임스페이스             │
│                                               │
│  ┌──────────────┐  ┌──────────────────────┐  │
│  │ destination   │  │ identity             │  │
│  │ (서비스       │  │ (인증서 관리,         │  │
│  │  디스커버리)  │  │  SPIFFE 아이덴티티)   │  │
│  └──────────────┘  └──────────────────────┘  │
│                                               │
│  ┌──────────────┐  ┌──────────────────────┐  │
│  │ proxy-injector│  │ heartbeat            │  │
│  │ (사이드카     │  │ (텔레메트리)          │  │
│  │  자동 주입)   │  │                      │  │
│  └──────────────┘  └──────────────────────┘  │
└──────────────────────────────────────────────┘

destination: Kubernetes API를 감시하여 서비스 엔드포인트 정보를 프록시에 전달합니다. Istio의 Pilot에 해당하지만, 훨씬 단순한 구현입니다.

identity: 각 프록시에 mTLS 인증서를 발급합니다. 기본적으로 24시간마다 자동 갱신됩니다.

proxy-injector: linkerd.io/inject: enabled 어노테이션이 있는 Pod에 linkerd2-proxy 사이드카를 자동 주입하는 Admission Webhook입니다.

데이터 플레인: linkerd2-proxy

linkerd2-proxy는 Linkerd의 핵심 차별점입니다.

설치와 기본 사용

CLI를 통한 설치

# Linkerd CLI 설치
curl --proto '=https' --tlsv1.2 -sSfL https://run.linkerd.io/install | sh
 
# 사전 조건 확인
linkerd check --pre
 
# CRD 설치
linkerd install --crds | kubectl apply -f -
 
# 컨트롤 플레인 설치
linkerd install | kubectl apply -f -
 
# 설치 확인
linkerd check

메시에 서비스 등록

네임스페이스에 어노테이션을 추가하면 해당 네임스페이스의 모든 Pod에 자동으로 프록시가 주입됩니다.

# 네임스페이스 단위 자동 주입 활성화
kubectl annotate namespace my-app linkerd.io/inject=enabled
 
# 기존 Deployment 재시작하여 프록시 주입
kubectl rollout restart deployment -n my-app

대시보드

Linkerd는 내장 대시보드(Viz 확장)를 제공합니다.

# Viz 확장 설치
linkerd viz install | kubectl apply -f -
 
# 대시보드 열기
linkerd viz dashboard

대시보드에서 서비스 간 트래픽 흐름, 성공률, 지연 시간, 요청량을 실시간으로 확인할 수 있습니다.

트래픽 관리

Linkerd의 트래픽 관리는 Istio보다 기능이 적지만, 핵심 기능은 갖추고 있습니다.

트래픽 분할

Linkerd는 Kubernetes 표준인 TrafficSplit SMI(Service Mesh Interface) 리소스를 사용합니다.

apiVersion: split.smi-spec.io/v1alpha2
kind: TrafficSplit
metadata:
  name: reviews-split
  namespace: my-app
spec:
  service: reviews
  backends:
    - service: reviews-v1
      weight: 900   # 90%
    - service: reviews-v2
      weight: 100   # 10%

서비스 프로파일

서비스별 재시도, 타임아웃, 라우트 메트릭을 정의합니다.

apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
  name: reviews.my-app.svc.cluster.local
  namespace: my-app
spec:
  routes:
    - name: GET /reviews/{id}
      condition:
        method: GET
        pathRegex: /reviews/[^/]+
      isRetryable: true
      timeout: 3s
    - name: POST /reviews
      condition:
        method: POST
        pathRegex: /reviews
      isRetryable: false
      timeout: 10s

2.20의 레이트 리밋 인지 로드 밸런싱

Linkerd 2.20에서 도입된 주목할 만한 기능입니다. HTTP 429 응답의 Retry-After 헤더를 인식하여, 스로틀링 중인 인스턴스를 자동으로 우회합니다.

기존 로드 밸런서:
요청 → [인스턴스 A: 429] → 실패 → 클라이언트가 재시도

레이트 리밋 인지 로드 밸런서:
요청 → [인스턴스 A: 429, Retry-After: 30] → 인스턴스 A를 30초간 우회
     → [인스턴스 B: 200] → 성공

이 기능은 외부 API를 호출할 때 특히 유용합니다. API 레이트 리밋에 걸린 인스턴스를 자동으로 피해서 요청을 분배합니다.

mTLS와 보안

Linkerd의 mTLS는 "제로 설정"입니다. 설치만 하면 모든 메시 내 트래픽이 자동으로 mTLS로 암호화됩니다.

인증서 계층

Trust Anchor (루트 CA)
  └── Issuer Certificate (중간 CA)
       └── Workload Certificate (서비스별, 자동 발급)

• Trust Anchor: 메시 전체의 신뢰 루트. 설치 시 생성되며 기본 10년 유효
• Issuer Certificate: 워크로드 인증서를 발급하는 중간 CA. 기본 1년 유효
• Workload Certificate: 각 프록시에 발급되는 인증서. 기본 24시간, 자동 갱신

인가 정책

Linkerd 2.12부터 세밀한 인가 정책을 지원합니다.

apiVersion: policy.linkerd.io/v1beta3
kind: Server
metadata:
  name: reviews-server
  namespace: my-app
spec:
  podSelector:
    matchLabels:
      app: reviews
  port: 8080
  proxyProtocol: HTTP/2
---
apiVersion: policy.linkerd.io/v1alpha1
kind: AuthorizationPolicy
metadata:
  name: reviews-auth
  namespace: my-app
spec:
  targetRef:
    group: policy.linkerd.io
    kind: Server
    name: reviews-server
  requiredAuthenticationRefs:
    - name: reviews-clients
      kind: MeshTLSAuthentication
      group: policy.linkerd.io
---
apiVersion: policy.linkerd.io/v1alpha1
kind: MeshTLSAuthentication
metadata:
  name: reviews-clients
  namespace: my-app
spec:
  identities:
    - "*.my-app.serviceaccount.identity.linkerd.cluster.local"

Istio vs Linkerd 비교

Linkerd를 선택해야 하는 경우

• mTLS와 기본적인 트래픽 관리만 필요하고, 운영 복잡성을 최소화하고 싶은 경우
• 리소스가 제한적인 환경에서 서비스 메시의 메모리 오버헤드를 최소화해야 하는 경우
• 팀의 Kubernetes 경험이 제한적이어서 빠른 도입과 학습이 필요한 경우
• Envoy의 보안 취약점이 우려되어 공격 표면이 작은 프록시를 원하는 경우

반면, 복잡한 L7 트래픽 관리(트래픽 미러링, 폴트 인젝션, 세밀한 라우팅 규칙)가 필요하거나 사이드카 없는 아키텍처를 원한다면 Istio가 더 적합합니다.

핵심 요약

• Linkerd는 단순함과 경량성을 핵심 가치로 하는 서비스 메시입니다
• Rust 기반 linkerd2-proxy는 Pod당 ~20MB의 메모리만 사용합니다
• mTLS가 설치 즉시 자동 활성화되어 별도 설정이 필요 없습니다
• 2.20 버전에서 레이트 리밋 인지 로드 밸런싱이 추가되었습니다
• 안정 릴리즈의 상용 라이선스 변경은 선택 시 고려해야 할 요소입니다

다음 장에서는 eBPF 기술을 활용하여 커널 수준에서 서비스 메시를 구현하는 Cilium을 살펴보겠습니다.