Linkerd 멀티 클러스터 통신
Linkerd는 Kubernetes 서비스를 클러스터 경계를 넘어 안전하고, 애플리케이션에 완전히 투명하며, 네트워크 토폴로지와 무관하게 연결할 수 있어요. 이 멀티 클러스터 기능은 다음을 제공하도록 설계되었어요:
- 통합 트러스트 도메인. 소스와 목적지 워크로드의 아이덴티티가 클러스터 안에서건 클러스터 경계를 넘어서건 모든 단계에서 검증돼요.
- 분리된 장애 도메인. 한 클러스터의 장애가 나머지 클러스터의 동작에 영향을 주지 않아요.
- 모든 유형의 네트워크 지원. Linkerd는 클러스터 간 특정 네트워크 토폴로지를 요구하지 않아요. 계층적 네트워크에서도, 클러스터들이 동일한 플랫 네트워크를 공유할 때도 동작해요.
- 클러스터 내 통신과의 통일된 모델. Linkerd가 클러스터 내 통신에 제공하는 관찰 가능성, 신뢰성, 보안 기능이 크로스 클러스터 통신에도 그대로 확장돼요.
클러스터 내 연결과 마찬가지로, Linkerd의 크로스 클러스터 연결도 애플리케이션 코드에는 투명해요. 통신이 클러스터 안에서 일어나든, 데이터센터 또는 VPC 안의 다른 클러스터로 가든, 공용 인터넷을 통해 가든, Linkerd는 양쪽 모두 mTLS로 인증되고 암호화되며 신뢰할 수 있는 클러스터 간 연결을 설정해요.
동작 방식
Linkerd의 멀티 클러스터 지원은 클러스터 간에 서비스 정보를 '미러링(mirroring)'하는 방식으로 동작해요. 대상 클러스터의 서비스 업데이트를 감시하고, 그 업데이트를 소스 클러스터에 로컬로 적용하는 컨트롤러를 사용해요.
이렇게 미러링된 서비스에는 원격 클러스터의 이름이 접미사로 붙어요. 예를 들어 west 클러스터의 Foo 서비스는 로컬 클러스터에서 Foo-west로 미러링돼요. 이 접근 방식은 보통 트래픽 분할 또는 동적 요청 라우팅과 결합해서, 로컬 서비스가 Foo 서비스를 마치 로컬 클러스터에 있는 것처럼 접근할 수 있게 해요.
Linkerd는 계층형(hierarchical), 플랫(flat), 페더레이션(federated)의 세 가지 기본적인 멀티 클러스터 통신 형태를 지원해요.
계층형 네트워크 (Hierarchical networks)
계층형 모드에서 Linkerd는 대상 클러스터에 게이트웨이(gateway) 구성요소를 배포해서 소스 클러스터의 요청을 받을 수 있게 해요. 이 접근 방식은 목적지 클러스터의 게이트웨이 IP에만 소스 클러스터의 파드가 도달할 수 있으면 되기 때문에 거의 모든 네트워크 토폴로지에서 동작해요.
플랫 네트워크 (Flat networks)
Linkerd 2.14부터 Linkerd는 플랫 네트워크를 공유하는 클러스터에 대해 파드간(pod-to-pod) 통신을 지원해요. 이 환경에서는 파드들이 클러스터 경계를 넘어 서로 직접 TCP 연결을 맺고 트래픽을 보낼 수 있어요. 이런 환경에서 Linkerd는 데이터 플레인 트래픽에 게이트웨이 중간자를 사용하지 않는데, 여기에는 몇 가지 장점이 있어요:
- 추가 네트워크 홉을 피해 지연 시간 개선
- 게이트웨이에 LoadBalancer 유형 서비스가 필요한 클라우드 환경에서 운영 비용 절감
- 워크로드 아이덴티티가 클러스터 경계를 넘어 보존되므로 더 나은 멀티 클러스터 인가 정책
페더레이션 서비스 (Federated services)
페더레이션 서비스는 여러 다른 클러스터에 있는 같은 이름과 네임스페이스의 서비스들의 합집합이에요. 페더레이션 서비스로 트래픽을 보내는 메시 클라이언트는 그 트래픽이 클러스터 전반의 페더레이션 서비스의 모든 복제본에 분산돼요. 페더레이션 서비스는 플랫 네트워킹 모델을 사용하며 게이트웨이 중간자를 사용하지 않아요.
이 모드들은 결합될 수 있으며, 각 특정 서비스가 자신에게 가장 적합한 모드를 선택해요. 자세한 내용은 파드간 멀티 클러스터 통신 가이드, 페더레이션 서비스 가이드, 멀티 클러스터 레퍼런스를 참고하세요.
헤드리스 서비스 (Headless services)
기본적으로 Linkerd는 내보낸 모든 서비스를 Kubernetes clusterIP 서비스로 미러링해요. 이는 헤드리스 서비스에도 적용돼요. 내보낸 헤드리스 서비스는 clusterIP로 미러링되고 IP 주소가 할당돼요. 일반적으로 헤드리스 서비스는 IP 주소를 가져서는 안 됩니다. 헤드리스 서비스는 워크로드가 안정적인 네트워크 식별자가 필요하거나, Kubernetes의 네이티브 구현에 얽매이지 않고 서비스 디스커버리를 원활히 할 때 사용돼요. 이를 통해 클라이언트가 자체 로드 밸런싱을 구현하거나 파드에 DNS 이름으로 직접 접근할 수 있어요. 특정 상황에서는, 특히 StatefulSet처럼 이를 요구하는 Kubernetes 객체와 작업할 때, 이런 기능 중 일부를 보존하는 것이 바람직해요.
Linkerd의 멀티 클러스터 확장은 두 클러스터를 연결할 때 헤드리스 서비스 지원으로 구성할 수 있어요. 이 기능을 켜면 컨트롤러가 헤드리스 서비스를 IP를 할당하지 않고 내보내요. 이를 통해 클라이언트가 클러스터 간 특정 파드(또는 호스트)와 통신할 수 있어요. 직접 통신을 지원하기 위해, 내부적으로 서비스 미러 구성요소는 헤드리스 서비스를 뒷받침하는 각 호스트에 대해 endpoint mirror를 만들어요. 예를 들어 대상 클러스터에 두 개의 복제본으로 배포된 StatefulSet이 있고, 그 StatefulSet이 헤드리스 서비스로 뒷받침된다면, 서비스가 내보내질 때 소스 클러스터는 StatefulSet의 호스트를 나타내는 두 개의 'endpoint mirror'와 함께 헤드리스 미러를 만들어요.
이 접근 방식 덕분에 Linkerd는 DNS 레코드 생성을 보존하고 클러스터 간 파드 직접 통신을 지원할 수 있어요. 클라이언트는 헤드리스 서비스가 만든 DNS 레코드를 기준으로 자체 로드 밸런싱을 구현할 수도 있어요. 호스트 이름도 클러스터 간에 보존되므로, DNS 이름(또는 FQDN)의 유일한 차이는 헤드리스 서비스의 미러 이름뿐이에요. 헤드리스 서비스로 내보내려면 서비스를 뒷받침하는 호스트에 이름이 있어야 해요(예: StatefulSet은 모든 파드에 호스트 이름이 있으므로 지원되지만, Deployment는 파드 스펙에 임의의 호스트 이름을 허용하지 않으므로 지원되지 않아요).
참고로, 헤드리스 서비스는 페더레이션 서비스의 일부가 될 수 없어요.
시작할 준비가 되셨나요? 멀티 클러스터 시작하기 가이드에서 워크스루를 확인해 보세요.
더 읽어보기
- 멀티 클러스터 설치 지침
- 멀티 클러스터 구성요소 업그레이드
- 파드간 멀티 클러스터 통신
- StatefulSet과 함께하는 멀티 클러스터 통신
- 페더레이션 서비스
- Architecting for multi-cluster Kubernetes - Linkerd 멀티 클러스터 구현의 설계 근거 중 일부를 설명하는 블로그 글.
- Multi-cluster Kubernetes with service mirroring - Linkerd 멀티 클러스터 구현 뒤의 아키텍처 결정 중 일부를 깊이 있게 다루는 글.
본문
Linkerd는 Kubernetes 서비스를 클러스터 경계를 넘어 안전하고, 애플리케이션에 완전히 투명하며, 네트워크 토폴로지와 무관하게 연결할 수 있어요. 이 멀티 클러스터 기능은 다음을 제공하도록 설계되었어요:
- 통합 트러스트 도메인. 소스와 목적지 워크로드의 아이덴티티가 클러스터 안에서건 클러스터 경계를 넘어서건 모든 단계에서 검증돼요.
- 분리된 장애 도메인. 한 클러스터의 장애가 나머지 클러스터의 동작에 영향을 주지 않아요.
- 모든 유형의 네트워크 지원. Linkerd는 클러스터 간 특정 네트워크 토폴로지를 요구하지 않아요. 계층적 네트워크에서도, 클러스터들이 동일한 플랫 네트워크를 공유할 때도 동작해요.
- 클러스터 내 통신과의 통일된 모델. Linkerd가 클러스터 내 통신에 제공하는 관찰 가능성, 신뢰성, 보안 기능이 크로스 클러스터 통신에도 그대로 확장돼요.
클러스터 내 연결과 마찬가지로, Linkerd의 크로스 클러스터 연결도 애플리케이션 코드에는 투명해요. 통신이 클러스터 안에서 일어나든, 데이터센터 또는 VPC 안의 다른 클러스터로 가든, 공용 인터넷을 통해 가든, Linkerd는 양쪽 모두 mTLS로 인증되고 암호화되며 신뢰할 수 있는 클러스터 간 연결을 설정해요.
동작 방식
Linkerd의 멀티 클러스터 지원은 클러스터 간에 서비스 정보를 '미러링(mirroring)'하는 방식으로 동작해요. 대상 클러스터의 서비스 업데이트를 감시하고, 그 업데이트를 소스 클러스터에 로컬로 적용하는 컨트롤러를 사용해요.
이렇게 미러링된 서비스에는 원격 클러스터의 이름이 접미사로 붙어요. 예를 들어 west 클러스터의 Foo 서비스는 로컬 클러스터에서 Foo-west로 미러링돼요. 이 접근 방식은 보통 트래픽 분할 또는 동적 요청 라우팅과 결합해서, 로컬 서비스가 Foo 서비스를 마치 로컬 클러스터에 있는 것처럼 접근할 수 있게 해요.
Linkerd는 계층형(hierarchical), 플랫(flat), 페더레이션(federated)의 세 가지 기본적인 멀티 클러스터 통신 형태를 지원해요.
계층형 네트워크 (Hierarchical networks)
계층형 모드에서 Linkerd는 대상 클러스터에 게이트웨이(gateway) 구성요소를 배포해서 소스 클러스터의 요청을 받을 수 있게 해요. 이 접근 방식은 목적지 클러스터의 게이트웨이 IP에만 소스 클러스터의 파드가 도달할 수 있으면 되기 때문에 거의 모든 네트워크 토폴로지에서 동작해요.
플랫 네트워크 (Flat networks)
Linkerd 2.14부터 Linkerd는 플랫 네트워크를 공유하는 클러스터에 대해 파드간(pod-to-pod) 통신을 지원해요. 이 환경에서는 파드들이 클러스터 경계를 넘어 서로 직접 TCP 연결을 맺고 트래픽을 보낼 수 있어요. 이런 환경에서 Linkerd는 데이터 플레인 트래픽에 게이트웨이 중간자를 사용하지 않는데, 여기에는 몇 가지 장점이 있어요:
- 추가 네트워크 홉을 피해 지연 시간 개선
- 게이트웨이에 LoadBalancer 유형 서비스가 필요한 클라우드 환경에서 운영 비용 절감
- 워크로드 아이덴티티가 클러스터 경계를 넘어 보존되므로 더 나은 멀티 클러스터 인가 정책
페더레이션 서비스 (Federated services)
페더레이션 서비스는 여러 다른 클러스터에 있는 같은 이름과 네임스페이스의 서비스들의 합집합이에요. 페더레이션 서비스로 트래픽을 보내는 메시 클라이언트는 그 트래픽이 클러스터 전반의 페더레이션 서비스의 모든 복제본에 분산돼요. 페더레이션 서비스는 플랫 네트워킹 모델을 사용하며 게이트웨이 중간자를 사용하지 않아요.
이 모드들은 결합될 수 있으며, 각 특정 서비스가 자신에게 가장 적합한 모드를 선택해요. 자세한 내용은 파드간 멀티 클러스터 통신 가이드, 페더레이션 서비스 가이드, 멀티 클러스터 레퍼런스를 참고하세요.
헤드리스 서비스 (Headless services)
기본적으로 Linkerd는 내보낸 모든 서비스를 Kubernetes clusterIP 서비스로 미러링해요. 이는 헤드리스 서비스에도 적용돼요. 내보낸 헤드리스 서비스는 clusterIP로 미러링되고 IP 주소가 할당돼요. 일반적으로 헤드리스 서비스는 IP 주소를 가져서는 안 됩니다. 헤드리스 서비스는 워크로드가 안정적인 네트워크 식별자가 필요하거나, Kubernetes의 네이티브 구현에 얽매이지 않고 서비스 디스커버리를 원활히 할 때 사용돼요. 이를 통해 클라이언트가 자체 로드 밸런싱을 구현하거나 파드에 DNS 이름으로 직접 접근할 수 있어요. 특정 상황에서는, 특히 StatefulSet처럼 이를 요구하는 Kubernetes 객체와 작업할 때, 이런 기능 중 일부를 보존하는 것이 바람직해요.
Linkerd의 멀티 클러스터 확장은 두 클러스터를 연결할 때 헤드리스 서비스 지원으로 구성할 수 있어요. 이 기능을 켜면 컨트롤러가 헤드리스 서비스를 IP를 할당하지 않고 내보내요. 이를 통해 클라이언트가 클러스터 간 특정 파드(또는 호스트)와 통신할 수 있어요. 직접 통신을 지원하기 위해, 내부적으로 서비스 미러 구성요소는 헤드리스 서비스를 뒷받침하는 각 호스트에 대해 endpoint mirror를 만들어요. 예를 들어 대상 클러스터에 두 개의 복제본으로 배포된 StatefulSet이 있고, 그 StatefulSet이 헤드리스 서비스로 뒷받침된다면, 서비스가 내보내질 때 소스 클러스터는 StatefulSet의 호스트를 나타내는 두 개의 'endpoint mirror'와 함께 헤드리스 미러를 만들어요.
이 접근 방식 덕분에 Linkerd는 DNS 레코드 생성을 보존하고 클러스터 간 파드 직접 통신을 지원할 수 있어요. 클라이언트는 헤드리스 서비스가 만든 DNS 레코드를 기준으로 자체 로드 밸런싱을 구현할 수도 있어요. 호스트 이름도 클러스터 간에 보존되므로, DNS 이름(또는 FQDN)의 유일한 차이는 헤드리스 서비스의 미러 이름뿐이에요. 헤드리스 서비스로 내보내려면 서비스를 뒷받침하는 호스트에 이름이 있어야 해요(예: StatefulSet은 모든 파드에 호스트 이름이 있으므로 지원되지만, Deployment는 파드 스펙에 임의의 호스트 이름을 허용하지 않으므로 지원되지 않아요).
참고로, 헤드리스 서비스는 페더레이션 서비스의 일부가 될 수 없어요.
시작할 준비가 되셨나요? 멀티 클러스터 시작하기 가이드에서 워크스루를 확인해 보세요.
더 읽어보기
- 멀티 클러스터 설치 지침
- 멀티 클러스터 구성요소 업그레이드
- 파드간 멀티 클러스터 통신
- StatefulSet과 함께하는 멀티 클러스터 통신
- 페더레이션 서비스
- Architecting for multi-cluster Kubernetes - Linkerd 멀티 클러스터 구현의 설계 근거 중 일부를 설명하는 블로그 글.
- Multi-cluster Kubernetes with service mirroring - Linkerd 멀티 클러스터 구현 뒤의 아키텍처 결정 중 일부를 깊이 있게 다루는 글.