본문 바로가기
WIKI 기술 지식 베이스

클러스터 구성

원문 보기 위키 갱신

클러스터 구성 (Cluster Configuration)

Linkerd를 특정 클라우드/CNI 환경에서 구축할 때 필요한 구성 항목을 다루는 문서예요. GKE 프라이빗 클러스터 방화벽 규칙, Cilium과의 연동, 컨트롤 플레인의 라이프사이클 훅 타임아웃 등을 알려드립니다.

출처: Linkerd Cluster Configuration

본문

GKE

프라이빗 클러스터 (Private Clusters)

프라이빗 GKE 클러스터를 사용한다면, GKE가 운영하는 api-server가 Linkerd 컨트롤 플레인과 통신할 수 있게 해주는 방화벽 규칙을 만들어야 합니다. 이렇게 하면 자동 프록시 주입 같은 기능이 api-server로부터 직접 요청을 받을 수 있게 됩니다.

이 예시에서는 gcloud를 사용해 방화벽 규칙 생성을 단순화할 거예요.

준비:

`CLUSTER_NAME=your-cluster-name
gcloud config set compute/zone your-zone-or-region
`

클러스터의 MASTER_IPV4_CIDR을 얻습니다:

`MASTER_IPV4_CIDR=$(gcloud container clusters describe $CLUSTER_NAME \
  | grep "masterIpv4CidrBlock: " \
  | awk '{print $2}')
`

클러스터의 NETWORK를 얻습니다:

`NETWORK=$(gcloud container clusters describe $CLUSTER_NAME \
  | grep "^network: " \
  | awk '{print $2}')
`

클러스터가 자동 생성한 NETWORK_TARGET_TAG를 얻습니다:

`NETWORK_TARGET_TAG=$(gcloud compute firewall-rules list \
  --filter network=$NETWORK --format json \
  | jq ".[] | select(.name | contains(\"$CLUSTER_NAME\"))" \
  | jq -r '.targetTags[0]' | head -1)
`

네트워크 태그의 형식은 gke-cluster-name-xxxx-node 같은 형태여야 합니다.

값을 확인하세요:

`echo $MASTER_IPV4_CIDR $NETWORK $NETWORK_TARGET_TAG

# example output
10.0.0.0/28 foo-network gke-foo-cluster-c1ecba83-node
`

proxy-injector, policy-validator, tap을 위한 방화벽 규칙을 만드세요:

`gcloud compute firewall-rules create gke-to-linkerd-control-plane \
  --network "$NETWORK" \
  --allow "tcp:8443,tcp:8089,tcp:9443" \
  --source-ranges "$MASTER_IPV4_CIDR" \
  --target-tags "$NETWORK_TARGET_TAG" \
  --priority 1000 \
  --description "Allow traffic on ports 8443, 8089, 9443 for linkerd control-plane components"
`

마지막으로 방화벽이 생성되었는지 확인합니다:

`gcloud compute firewall-rules describe gke-to-linkerd-control-plane
`

Cilium

소켓 레벨 로드밸런싱 끄기

Cilium은 eBPF를 통해 kube-proxy 기능을 대체하도록 구성할 수 있습니다. kube-proxy 대체 모드로 실행하면 ClusterIP 서비스에 대한 연결이 소켓 레벨(즉 TCP 연결 설정 중)에서 서비스의 백엔드로 직접 수립됩니다. Linkerd는 서비스 디스커버리를 하기 위해 패킷에 ClusterIP가 존재하는 것에 의존합니다.

패킷에 ClusterIP 주소가 없으면 Linkerd는 대신 Cilium이 선택한 pod 엔드포인트로 곧바로 전달합니다. 결과적으로 mTLS와 텔레메트리는 여전히 올바르게 동작하지만, peak EWMA 로드밸런싱, 동적 요청 라우팅 같은 기능은 예상대로 동작하지 않을 수 있어요.

이 동작은 Cilium에서 CLI 옵션 --config bpf-lb-sock-hostns-only=true 또는 Helm 값 socketLB.hostNamespaceOnly=true로 pod에 대한 소켓 레벨 로드밸런싱을 끄면 비활성화할 수 있습니다.

Exclusive 모드 끄기

CNI로 Cilium을 사용하고 그 위에 linkerd-cni를 설치하고 싶다면, Cilium을 cni.exclusive=false 옵션으로 설치해야 합니다. 이렇게 하면 Cilium이 CNI 구성 디렉터리에 대한 소유권을 갖지 않게 됩니다. linkerd-cni 같은 다른 CNI 플러그인은 이 디렉터리에 구성을 배포해 스스로 설치하고 다른 배포된 플러그인과 체인 모드로 동작합니다.

라이프사이클 훅 타임아웃 (Lifecycle Hook Timeout)

Linkerd는 기본적으로 모든 컨트롤 플레인 컴포넌트와 주입된 모든 워크로드에 postStart 라이프사이클 훅을 사용합니다. 이 훅은 linkerd-await로 프록시 준비 상태를 폴링하고, 프록시가 트래픽을 처리할 준비가 될 때까지 메인 컨테이너의 시작을 막습니다. 기본적으로 훅은 2분 후 타임아웃됩니다.

NetworkPolicy 리소스를 설정·시행하는 CNI 플러그인은 라이프사이클 훅의 실행을 방해할 수 있습니다. 라이프사이클 훅이 실행되는 동안 컨테이너는 Running 상태에 도달하지 않습니다. 일부 CNI 플러그인 구현은 모든 컨테이너가 실행 상태에 도달하고 kubelet이 API Server를 통해 Pod 상태를 갱신한 뒤에만 Pod의 IP 주소를 획득합니다. Pod의 IP에 접근할 수 없으면 CNI 플러그인은 올바르게 동작하지 않습니다. 이것은 필요한 네트워크 연결이 없기 때문에 프록시 설정을 막게 됩니다.

해결책으로 사용자는 컨트롤 플레인 컴포넌트에서 postStart 라이프사이클 훅을 수동으로 제거할 수 있습니다. 주입된 워크로드의 경우, 루트 레벨 await: false 옵션으로 라이프사이클 훅을 선택 해제하거나, config.linkerd.io/proxy-await: disabled 주석으로 워크로드·네임스페이스 레벨에서 동작을 덮어쓸 수 있습니다. 훅을 제거하면 컨테이너가 비동기적으로 시작할 수 있게 되어, CNI 플러그인이 pod의 IP를 받으면 네트워크 연결이 풀립니다.

더 알아보기 (Learn more)

  • linkerd-await 문서
  • Cilium socketLB 구성 문서
  • GKE 프라이빗 클러스터 자동 주입