# Linkerd

## 1. 개요
Linkerd는 쿠버네티스(Kubernetes) 환경을 위해 설계된 초경량, 고성능의 오픈 소스 서비스 메시(Service Mesh)입니다. 서비스 메시란 마이크로서비스 아키텍처에서 서비스 간의 통신(East-West traffic)을 관리, 제어, 관찰하기 위해 인프라 계층에 구축하는 전용 네트워크 계층을 의미합니다. Linkerd는 복잡한 설정보다는 '가볍고 단순함(Lightweight and Simple)'을 핵심 철학으로 삼아, 운영자의 학습 곡선을 낮추고 시스템 리소스 소모를 최소화하는 데 집중합니다.

## 2. 주요 특징 및 아키텍처
Linkerd는 컨트롤 플레인(Control Plane)과 데이터 플레인(Data Plane)으로 분리된 구조를 가집니다. 특히 데이터 플레인에 사용되는 프록시는 성능과 보안을 위해 Rust 언어로 작성된 `linkerd2-proxy`를 사용합니다.

### 2.1 아키텍처 구성 요소
| 구성 요소 | 역할 | 설명 |
| :--- | :--- | :--- |
| **linkerd2-proxy** | 데이터 플레인 | 각 서비스 팟(Pod)에 사이드카 형태로 배치되어 실제 트래픽을 가로채고 전달하는 초경량 프록시 |
| **Destination Service** | 컨트롤 플레인 | 서비스 디스커버리를 수행하며, 프록시가 트래픽을 보낼 대상의 엔드포인트 정보를 제공 |
| **Identity Service** | 컨트롤 플레인 | mTLS 통신을 위한 인증서 발급 및 신원 확인을 담당하는 CA(Certificate Authority) 역할 |
| **Proxy Injector** | 컨트롤 플레인 | 팟 생성 시 자동으로 `linkerd2-proxy` 컨테이너를 주입하는 뮤테이팅 웹훅(Mutating Webhook) |

### 2.2 멀티 클러스터(Multi-cluster)
Linkerd는 단일 클러스터를 넘어 여러 클러스터 간의 통신을 지원합니다. **서비스 미러링(Service Mirroring)** 개념을 통해 원격 클러스터의 서비스를 로컬 클러스터의 서비스처럼 보이게 하여, 클러스터 간 트래픽을 투명하게 연결하고 관리합니다.

## 3. 핵심 기능
### 3.1 자동 mTLS (Mutual TLS)
Linkerd는 서비스 간 통신 시 상호 TLS(mTLS)를 자동으로 적용합니다. 별도의 인증서 설정 없이도 데이터 플레인 간의 통신을 암호화하여 중간자 공격(MITM)을 방지하고 제로 트러스트(Zero Trust) 보안 모델을 구현합니다.

### 3.2 트래픽 분할 (Traffic Splitting)
과거에는 SMI(Service Mesh Interface) 표준을 지원했으나, 현재 Linkerd는 쿠버네티스 표준인 **Gateway API(HTTPRoute 등)**를 통한 트래픽 제어를 강력히 권장합니다. 이를 통해 새로운 버전의 서비스를 일부 사용자에게만 노출하는 카나리 배포(Canary Deployment)를 표준화된 방식으로 구현할 수 있습니다.

### 3.3 관찰 가능성 (Observability) 및 골든 메트릭스
Linkerd는 별도의 애플리케이션 코드 수정 없이 다음과 같은 '골든 메트릭스(Golden Metrics)'를 실시간으로 제공합니다.
- **Success Rate**: 요청 성공률
- **Latency**: 응답 지연 시간 (P50, P95, P99)
- **RPS (Requests Per Second)**: 초당 요청 수

## 4. 지원 요구사항
### 4.1 환경 요구사항
- **Kubernetes 버전**: v1.21 이상 권장
- **CLI 도구**: `linkerd` CLI (설치 및 관리용)
- **네트워크**: 팟 간 통신을 위한 네트워크 정책(Network Policy)이 mTLS 포트(4143, 4191 등)를 허용해야 함

### 4.2 리소스 소모량 (프록시 기준)
Linkerd 프록시는 매우 낮은 리소스 점유율을 자랑합니다.
| 구분 | 평균 사용량 (Typical) | 제한 설정 (Limit) | 비고 |
| :--- | :--- | :--- | :--- |
| **CPU** | 수 mCPU | 1/2 vCPU | 트래픽 양에 따라 가변적 |
| **Memory** | 10MB ~ 30MB | 128MB | 매우 낮은 메모리 풋프린트 |

## 5. 설치 및 기본 설정
Linkerd는 전용 CLI를 통해 설치 프로세스를 단순화하였습니다.

### 5.1 설치 단계
```bash
# 1. Linkerd CLI 설치 (클라이언트 설정)
curl --proto '=https' --tlsv1.2 -sSfL https://install.linkerd.io/install.sh | sh

# 2. 클러스터 설치 준비 상태 검증 (클러스터 서버 설정 확인)
linkerd check --pre

# 3. CRD(Custom Resource Definitions) 설치 (클러스터 서버 설정)
linkerd install --crds | kubectl apply -f -

# 4. 컨트롤 플레인 설치 (클러스터 서버 설정)
linkerd install | kubectl apply -f -

# 5. 설치 완료 후 최종 검증 (클러스터 서버 설정 확인)
linkerd check
```

### 5.2 서비스 메시 주입 (Injection)
특정 네임스페이스의 팟에 프록시를 자동으로 주입하려면 다음과 같이 어노테이션을 추가합니다.
```bash
kubectl annotate ns <namespace-name> linkerd.io/inject=enabled
```

## 6. 운영 환경 설정 (Production Setup)
기본 설치 시 생성되는 인증서는 임시 인증서이므로, 실제 운영 환경에서는 보안과 안정성을 위해 **사용자 정의 CA 인증서(Trust Anchor)**를 반드시 적용해야 합니다.

### 6.1 인증서 적용 설치
운영 환경에서는 다음과 같이 신뢰 루트 인증서 파일을 지정하여 설치합니다.
```bash
linkerd install \
  --identity-trust-anchors-file trust-anchor.crt \
  --identity-issuer-certificate-file issuer.crt \
  | kubectl apply -f -
```

### 6.2 mTLS 인증서 갱신 방법
인증서 만료 전 다음과 같은 절차로 갱신을 수행합니다.
1. 새로운 인증서 파일(`trust-anchor.crt`, `issuer.crt`)을 준비합니다.
2. `linkerd install` 명령에 새로운 인증서 파일을 지정하여 다시 실행합니다.
3. 컨트롤 플레인이 업데이트되면, 데이터 플레인의 프록시들은 롤링 업데이트(`kubectl rollout restart deployment`)를 통해 새로운 인증서를 적용받아야 합니다.

## 7. 활용 사례 및 설정 예시
### 7.1 카나리 배포를 위한 트래픽 제어 (Gateway API)
쿠버네티스 표준 Gateway API의 `HTTPRoute`를 사용하여 트래픽의 10%만 신규 버전(`v2`)으로 보내는 설정 예시입니다.

```yaml
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: my-service-route
spec:
  parentRefs:
  - name: my-gateway
  rules:
  - backendRefs:
    - name: my-service-v1
      port: 80
      weight: 90
    - name: my-service-v2
      port: 80
      weight: 10
```

### 7.2 모니터링 대시보드 활용
`linkerd viz` 확장 기능을 설치하면 웹 기반의 대시보드를 통해 서비스 간의 의존성 그래프와 실시간 트래픽 상태를 시각적으로 확인할 수 있습니다.

```bash
# Linkerd Viz 확장 기능 설치
linkerd viz install | kubectl apply -f -

# 대시보드 접속을 위한 포트 포워딩
linkerd viz dashboard
```

## 8. 타 서비스 메시와의 비교
Linkerd는 Istio와 같은 대형 서비스 메시와 비교했을 때 '단순함'과 '효율성'에서 강점을 가집니다.

| 비교 항목 | Linkerd | Istio |
| :--- | :--- | :--- |
| **프록시 구현** | Rust (자체 개발 `linkerd2-proxy`) | C++ (Envoy Proxy) |
| **리소스 사용량** | 매우 낮음 (초경량) | 상대적으로 높음 |
| **설치 및 설정** | 매우 단순 (CLI 중심) | 복잡함 (다양한 설정 옵션) |
| **기능 범위** | 핵심 기능 집중 (보안, 관찰, 트래픽) | 광범위함 (정책 제어, 게이트웨이 등) |
| **학습 곡선** | 낮음 | 높음 |
| **표준 준수** | Gateway API 중심 | 자체 API 및 Gateway API 지원 |

## 9. 트러블슈팅 가이드
- **`linkerd check` 실패**: 대부분의 경우 네트워크 방화벽 설정이나 RBAC 권한 부족으로 발생합니다. 출력된 에러 메시지의 포트 번호를 확인하여 네트워크 정책을 수정하십시오.
- **프록시 주입 누락**: 팟 생성 후 `kubectl describe pod`를 통해 `linkerd-proxy` 컨테이너가 포함되었는지 확인하십시오. 어노테이션 설정 후 기존 팟을 재시작(`kubectl rollout restart`)해야 적용됩니다.
- **mTLS 통신 오류**: 인증서 만료 여부를 확인하십시오. 운영 환경에서는 `linkerd install` 시 사용한 Trust Root 인증서의 유효 기간을 체크하고, 만료 전 갱신 절차를 수행해야 합니다.

## 10. 최신 버전 변경 사항
- **Rust 프록시 최적화**: 메모리 사용량을 더욱 줄이고 처리량을 높인 최신 Rust 런타임 적용.
- **멀티 클러스터 확장성 개선**: 서로 다른 클러스터 간의 서비스 미러링(Service Mirroring) 성능 향상 및 설정 간소화.
- **Gateway API 지원**: 쿠버네티스 표준 Gateway API와의 통합을 통해 보다 표준화된 트래픽 관리 방식 제공.