고가용성
고가용성 (High Availability)
프로덕션 워크로드를 위해 Linkerd 제어 플레인을 고가용성(HA) 모드로 실행할 수 있어요. 이 모드는 핵심 제어 플레인 컴포넌트 3개의 레플리카를 실행하고, 제어 플레인 컴포넌트와 데이터 플레인 프록시에 프로덕션에 적합한 CPU·메모리 리소스 요청을 설정하며, 포드가 스케줄되려면 프록시 자동 주입기가 동작해야 한다는 요구 사항과 함께 가능하면 별도 노드와 별도 영역에 스케줄되도록 하는 안티-어피니티 정책을 적용해요.
본문
프로덕션 워크로드의 경우 Linkerd 제어 플레인을 고가용성(HA) 모드로 실행할 수 있어요. 이 모드는:
- 핵심 제어 플레인 컴포넌트의 레플리카 3개를 실행해요.
- 제어 플레인 컴포넌트에 프로덕션에 적합한 CPU 및 메모리 리소스 요청을 설정해요.
- 데이터 플레인 프록시에 프로덕션에 적합한 CPU 및 메모리 리소스 요청을 설정해요.
- 어떤 포드든 스케줄되려면 프록시 자동 주입기가 동작해야 한다는 요구 사항을 걸어요.
- 핵심 제어 플레인 컴포넌트에 안티-어피니티(anti-affinity) 정책을 설정해, 가능하면 별도 노드와 별도 영역에 기본으로 스케줄되도록 해요.
HA 활성화
제어 플레인 설치 시 --ha 플래그로 HA 모드를 활성화할 수 있어요.
`linkerd install --ha | kubectl apply -f -
`
Viz 확장도 비슷한 특성의 --ha 플래그를 지원한다는 점도 참고하세요.
`linkerd viz install --ha | kubectl apply -f -
`
설치 시 install 명령에 다른 플래그를 전달해 HA 동작의 특정 측면을 재정의할 수 있어요. 예를 들어 --controller-replicas 플래그로 핵심 컴포넌트의 레플리카 수를 재정의할 수 있어요.
`linkerd install --ha --controller-replicas=2 | kubectl apply -f -
`
전체 install CLI 문서를 참고해 주세요.
linkerd upgrade 명령으로 기존 제어 플레인에 HA 모드를 활성화할 수 있어요.
`linkerd upgrade --ha | kubectl apply -f -
`
프록시 주입기 실패 정책
HA 프록시 주입기는 자동 프록시 주입을 강제하기 위해 더 엄격한 실패 정책으로 배포돼요. 이 구성은 Linkerd 프록시 없이 주석이 달린 워크로드가 실수로 클러스터에 스케줄되지 않도록 보장해요. (이는 프록시 주입기가 다운되어 있을 때 발생할 수 있어요.)
주입 과정이 승인 단계에서 인식되지 않는 오류나 타임아웃 오류로 실패하면, 워크로드 승인이 Kubernetes API 서버에 의해 거부되고 배포가 실패해요.
따라서 클러스터에 항상 최소 하나의 건강한 프록시 주입기 레플리카가 실행 중인 것이 매우 중요해요.
클러스터에서 건강한 프록시 주입기 수를 보장할 수 없다면, Linkerd Helm 차트에서 볼 수 있듯이 웹훅 실패 정책 값을 Ignore로 설정해 완화할 수 있어요.
참고
어드미션 웹훅 실패 정책에 대한 자세한 내용은 Kubernetes 문서를 참고해 주세요.
포드 안티-어피니티 규칙
모든 핵심 제어 플레인 컴포넌트는 중복을 보장하기 위해 포드 안티-어피니티 규칙으로 배포돼요.
Linkerd는 requiredDuringSchedulingIgnoredDuringExecution 포드 안티-어피니티 규칙을 사용해 Kubernetes 스케줄러가 핵심 컴포넌트의 레플리카를 같은 노드에 배치하지 않도록 보장해요. preferredDuringSchedulingIgnoredDuringExecution 포드 안티-어피니티 규칙도 추가되어, 가능하면 레플리카를 서로 다른 영역에 스케줄하려고 시도해요.
이 안티-어피니티 규칙을 충족하려면 HA 모드는 Kubernetes 클러스터에 항상 최소 3개 노드가 있다고 가정해요. 이 가정이 위반되면(예: 클러스터가 2개 이하 노드로 축소되면) 시스템이 기능하지 않는 상태에 놓일 수 있어요.
이 안티-어피니티 규칙은 Prometheus와 같은 애드온 컴포넌트에는 적용되지 않는다는 점을 참고하세요.
Prometheus 확장
Linkerd Viz 확장은 사전 구성된 Prometheus 포드를 제공하지만, 프로덕션 워크로드에서는 자체 Prometheus 인스턴스를 구성할 것을 권장해요. 데이터 플레인 메트릭을 스크래핑하려면 여기의 지침을 따르세요. 그러면 리소스 요구 사항, 백업 전략, 데이터 보존에 대한 더 많은 제어권을 얻을 수 있어요.
Linkerd 시계열 데이터를 저장할 메모리 용량을 계획할 때 일반적인 지침은 메시된 포드당 5MB예요.
데이터 플레인에서 오는 데이터 양 때문에 Prometheus가 주기적으로 OOMKilled 이벤트를 겪고 있다면 조정할 수 있는 두 가지 핵심 파라미터가 있어요.
- storage.tsdb.retention.time는 저장소에서 샘플을 보존할 기간을 정의해요. 값이 높을수록 데이터를 더 오래 유지하려면 더 많은 메모리가 필요해요. 이 값을 낮추면 데이터 보존 기간이 짧아져 OOMKilled 이벤트 수가 줄어들어요.
- storage.tsdb.retention.size는 블록에 저장할 수 있는 최대 바이트 수를 정의해요. 더 낮은 값도 OOMKilled 이벤트 수를 줄이는 데 도움이 돼요.
자세한 내용과 지원되는 다른 저장 옵션은 Prometheus 문서를 참고해 주세요.
Cluster AutoScaler와 함께 사용하기
Linkerd 프록시는 mTLS 개인 키를 tmpfs emptyDir 볼륨에 저장해 이 정보가 절대 포드를 떠나지 않도록 보장해요. 이 때문에 기본 설정의 Cluster AutoScaler는 주입된 워크로드 레플리카가 있는 노드를 축소할 수 없어요.
해결 방법은 주입된 워크로드에 cluster-autoscaler.kubernetes.io/safe-to-evict: "true" 주석을 다는 거예요. Cluster AutoScaler 구성을 완전히 제어할 수 있다면 --skip-nodes-with-local-storage=false 옵션으로 Cluster AutoScaler를 시작할 수 있어요.
자세한 내용은 Cluster AutoScaler 문서를 참고해 주세요.