Linkerd 해설: 방해하지 않는 서비스 메시

대부분의 팀은 Kubernetes 배포판을 고르듯이 서비스 메시를 선택합니다. RFP에 가장 먼저 올라온 것을 고르는 식이죠. 그래서 서비스 세 개를 위해 Istio가 배포되고, Linkerd라면 오후 한나절이면 해결했을 문제들에 대해 Linkerd가 간과되는 결과가 반복됩니다.

Linkerd는 Envoy 위에 구축되지 않은 유일한 CNCF 졸업 서비스 메시입니다. 그 설계의 모든 것은 그 하나의 결정에서 비롯됩니다.

Linkerd가 실제로 무엇인지

Linkerd는 linkerd2-proxy라고 불리는, 목적에 맞게 설계된 Rust 기반 마이크로 프록시를 중심으로 구축된 Kubernetes용 서비스 메시입니다. 거의 무엇이든 할 수 있는 범용 L7 프록시인 Envoy와 달리, linkerd2-proxy는 사이드카가 실제로 필요로 하는 것만을 구현합니다. 메인테이너들은 기능의 폭보다 더 작고 예측 가능한 프록시를 우선시하며 이 경계를 의도적으로 지켜 왔습니다.

그 좁은 범위가 곧 제품의 본질입니다. 프록시는 메모리 풋프린트가 작고 테일 레이턴시가 예측 가능하며, 머릿속에 담아둘 수 있을 만큼 작은 구성 표면을 가집니다.

대부분의 팀에게는 이것이 올바른 트레이드오프입니다. WASM 필터, 다중 프로토콜 게이트웨이, 또는 Istio 전용 확장에 의존하는 워크로드를 운영하는 팀에게는 그렇지 않습니다.

동작 방식

Linkerd는 다른 모든 메시와 동일한 2-플레인 아키텍처를 따릅니다:

데이터 플레인 — 메시화된 모든 Pod에 사이드카로 주입되는 linkerd2-proxy. iptables 규칙을 다시 쓰는 init 컨테이너를 통해 모든 TCP 트래픽을 투명하게 가로챕니다.
컨트롤 플레인 — 프록시에 서비스 디스커버리와 정책을 스트리밍하고, mTLS용 단기 워크로드 인증서를 발급하며, 어드미션 시점에 Pod 스펙을 변경해 사이드카를 주입하는 소수의 컨트롤러(destination, identity, proxy-injector).

서비스 A가 서비스 B를 호출할 때:

A에서 b.default.svc.cluster.local로 향하는 요청은, linkerd-init init 컨테이너 혹은 CNI 모드 설치에서는 linkerd-cni DaemonSet이 설치한 iptables 규칙에 의해 A의 사이드카로 리다이렉트됩니다.
A의 사이드카는 이미 destination 컨트롤러로부터 스트리밍하고 있는 엔드포인트에 대해 B를 해석한 다음, 워크로드 인증서를 사용해 B의 Pod 중 하나로 mTLS 연결을 엽니다. 해당 인증서는 프록시 시작 시 identity가 발급하고 24시간마다 identity에 대해 갱신됩니다.
B의 사이드카는 mTLS를 종료하고, policy 컨트롤러로부터 스트리밍하고 있는 인바운드 정책에 대해 클라이언트의 워크로드 ID를 확인하며, 허용되면 루프백을 통해 요청을 B로 전달합니다.

애플리케이션 코드는 바뀌지 않습니다. 서비스 간의 모든 바이트는 인증되고, 암호화되며, 관찰 가능합니다.

Linkerd 데이터 플레인 아키텍처

컨트롤 플레인

Linkerd 컨트롤 플레인 아키텍처

컨트롤 플레인은 메시의 서로 다른 측면을 담당하는 3개의 Deployment로 구성됩니다. 각 Deployment는 mTLS를 위해 자체 linkerd-proxy 사이드카 뒤에서 실행됩니다. 컨트롤 플레인도 여러분의 워크로드와 동일한 방식으로 메시화되어 있습니다.

identity: 메시화된 Pod가 시작되면, 해당 프록시는 Pod의 Kubernetes ServiceAccount 토큰으로 서명된 인증서 서명 요청(CSR)을 제출합니다. identity는 API 서버로 TokenReview 호출(identity.l5d.io audience 사용)을 보내 토큰을 검증한 뒤, 단기(24시간) 워크로드 인증서를 발급합니다.
destination: "이 서비스를 구성하는 엔드포인트는 무엇이며, 나는 무엇을 알아야 하는가?"에 답합니다. 프록시가 b.default.svc.cluster.local:80 같은 authority를 처음 해석해야 할 때, destination으로 장기 gRPC Get 스트림을 열고 푸시 업데이트를 받습니다: 준비된 엔드포인트 주소 목록과 각각에 붙은 TLS ID, 프로토콜 힌트(HTTP/2 업그레이드, opaque 포트, opaque-transport 인바운드 포트), 메트릭 라벨, 가중치. 병렬로 동작하는 GetProfile 스트림은 ServiceProfile로부터 서비스별 라우팅 구성을 반환합니다.
policy: 프록시에 두 개의 gRPC API를 제공합니다. 각 사이드카가 리스닝 포트당 한 번씩 watch하는 InboundPolicies API는 어떤 클라이언트 ID가 어떤 라우트에서 허용되는지를 학습하기 위한 것이고, 각 사이드카가 호출하는 authority당 한 번씩 watch하는 OutboundPolicies API는 라우팅 규칙, 재시도, 타임아웃, 서킷 브레이커, 속도 제한을 가져오기 위한 것입니다. 인가 판단은 그 후 프록시가 캐시된 정책에 대해 로컬에서 내립니다.
sp-validator: ServiceProfile CRD의 validating admission webhook입니다.
proxy-injector: mutating admission webhook입니다. 해당 MutatingWebhookConfiguration은 설정된 namespaceSelector와 일치하는 네임스페이스 안의 모든 Pod와 Service의 CREATE를 구독합니다. API 서버가 webhook을 호출하면, 핸들러는 객체에서 linkerd.io/inject: enabled(Pod 또는 해당 네임스페이스에 있는지)를 검사하고, 존재하면 Pod 스펙에 linkerd-proxy 컨테이너를 추가하도록 패치합니다.

운영 현실

트러스트 앵커 로테이션. 루트 CA의 만료 시점은 생성 시 설정한 값이며, Step, AWS Private CA, 또는 상위에서 발급받는 cert-manager 중 무엇을 쓰든 마찬가지입니다. Linkerd는 앵커가 만료될 때까지 워크로드 인증서를 기꺼이 발급하다가 그 시점에 모든 것이 멈춥니다. 만료 날짜를 기록하고, 알림을 설정하고, 인시던트 상황에서 필요해지기 전에 로테이션 절차를 연습해 두세요.
멀티 클러스터. linkerd-multicluster 확장은 견고하지만, 여러 토폴로지(게이트웨이 기반 연결, 플랫 Pod 네트워크, 페더레이티드 서비스)를 지원하며 각각 고유한 트레이드오프가 있습니다. 게이트웨이 기반은 추가 홉과 운영해야 할 게이트웨이 Pod를 비용으로, 어떤 네트워크 경계(별도 VPC, 동일 CIDR)에서도 동작합니다. 플랫과 페더레이티드는 더 낮은 레이턴시를 위해 게이트웨이를 건너뛰지만, 둘 다 클러스터 간 Pod 수준 연결을 필요로 하며 이를 준비하는 일은 공짜가 아닙니다. 프로덕션 토폴로지가 이 확장에 의존하기 전에 어떤 모델이 여러분의 환경에 맞는지 이해해 두는 것이 좋습니다.
프록시 리소스 제한. 보편적인 사이징 레시피는 없습니다. 초당 수천 개의 연결을 종단하는 메시화된 ingress 컨트롤러는 조금씩 내부 트래픽을 받는 상류 서비스보다 훨씬 많은 프록시 메모리를 사용합니다. 50개 서비스 클러스터를 watch하는 destination 컨트롤러는 5,000개 엔드포인트를 watch하는 것과 전혀 다릅니다. 제한을 설정하기 전에 먼저 관찰하세요: 제한 없이 돌려 보고, 프로덕션 트래픽이 워크로드를 결정하게 두고, 사이드카별·컨트롤 플레인 컴포넌트별 실제 CPU 및 메모리 소비를 살펴보세요. 피크가 포함된 일주일치 데이터가 쌓이면, 관측된 최대치 위로 여유를 두고 제한을 설정합니다.

실용적인 권고

Kubernetes 플랫폼을 위한 서비스 메시를 평가 중이고 Istio를 선택해야 할 강한 이유가 아직 없다면, 먼저 Linkerd를 파일럿으로 시도해 보세요. 설치는 오후 한나절이면 끝납니다. 필요한 것을 해낸다면 한 분기 분량의 운영 업무를 아낀 셈입니다. 그렇지 않다면, 다른 선택지로 이동하기 위한 명확하고 문서화된 근거가 생깁니다.