Kubbernetes Multi-Cluster Networking의 비교(2022년 2월까지)

개시하다
안녕하세요.
클럽베네츠가 멀티-클러스터에서 활용될 때 과제 중 하나로 클러스터 간 네트워크가 어떻게 구성되는지 열거할 수 있다는 점을 고려했다.
본고는 주로Kubernetes의Multi-Cluster Networking에 집중되고 특히Cluster 간의East-West 통신의 실현 방법에 대해 구상된 요건에 대해 각종 방법의 비교를 총괄한다.
※ 또한, 본고에서 기술한 견해는 개인의 견해이며, 소속 조직의 공식적인 견해는 아닙니다.
Kubbernetes Multi-Cluster의 용례
원래, Multi-Cluster가 Kubernetes를 사용하는 용례는 무엇입니까?
나의 경험에 의하면 다음과 같은 느낌이 든다.

패턴
용례 개요
단일 인프라 환경 모델
· Cluster Migration으로 Cluster 업데이트를 진행하고 싶다/Cluster를 이중화하고 장애에 대한 저항성을 높이고 싶다
구름 모드
• 구름의 분집을 이용하여 장애에 대한 저항성을 높이고자 함
혼합 클라우드 모드
· 예선 가동을 통한 데이터 관리 상태에서 공적 클라우드를 사용하고자 함·예선 가동 실패 시 보험·예선 가동을 안전하게 하려는 클러스터 업데이트 등
에지 클라우드 패턴
● 지리적 위치 서비스를 제공하고자 함/응답성을 개선하고자 함/고객 테두리를 처리할 수 없는 중형 처리를 가까운 네트워크 테두리로 마운트 해제하고 함

다중 단일 인프라 환경 모델

다음 용례는 구름이 많고 혼합운 모드

가 증가할 것이다.
라는 느낌을 받았다.
에지 클라우드는 F5사의 볼테라 등이 부분적으로 구현했다.
CDN 사업자와 통신사업자가 제공하는 MEC(Multi-access Edge Computing)에서 인터넷의 층과 네트워크 가장자리가 장비와 클라우드의 응용 통신의 중계 역할을 충당할 수 있다는 망상이다.
Multi-Cluster Networking 의 비전 요건
멀티-Cluster를 구성할 때는 네트워크 관점에서 고객에서 Cluster로의 입국통신(North-Souuth 통신)과 Cluster 간 통신(East-West 통신)을 어떻게 구성할 것인지를 주로 논의한다.

North-South 통신은 다음 글에서도 특히 MEC(Multi-access Edge Computing)의 과제가 커 Kubernetes와 다른 층에서 해법이 필요하다고 언급했다.
예를 들어 Verizon이 북미에서 제공한Verizon 5G Edge은 독특한Edge Discovery Service(EDS) API를 제공하여 터미널에서 여러 개의 테두리 사이트(예를 들어 Wavelength 구역)로 확장된 응용 프로그램에 접근할 때 적당한 테두리 노드로 돌아가는 해결 방안을 제공한다.
이와 유사한 MobiledgeX의 DME(Distributed Matching Engine)도 있습니다.(자세한 내용은 위 MEC 기사에서 언급됨)
이 문서의 주제인 East-West 커뮤니케이션에 대해 다음과 같이 요약해 보겠습니다.
구상의 필요조건
개요
설정
수동 또는 자동
보안
Cluster 사이의 안전 터널 등
서비스 할인
외부 DNS 또는 내부 DNS
세입자 분리
Cluster Level or Namespace Level
토폴로지
Full Mesh, Hub&Spoke...
NAT 밑에 있는 Multi-Cluster가
Cluster가 NAT 뒤에 있을 때 가져올 수 있는지 여부
인프라 FW 규칙 관리의 번거로움
Cluster 간 통신의 FW 규칙 설정 용이성
Cluster 간 통신 제어의 유연성
Cluster에서 Cluster로의 하중 분산 등
CNI 의존성 없음
CNI에 의존하지 않고 가져올 수 있는지 여부
확장성
Cluster 간 Namespace 연장 기능 없음
클러스터 간 IP 중복
Cluster 간에 IP 중복 가능 여부
2개 이상의 클러스터 지원
둘 이상의 클러스터 지원 여부
성숙도
기술 성숙도
공급업체 잠금
공급업체 잠금 여부
Cluster 간 통신 솔루션
내 조사에 따르면 접근 방식을 정리하면 다음과 같은 5가지 8가지 기법으로 나눌 수 있다.

8 방법의 비교는 다음과 같다.

각 기법의 차이를 대충 정리해 보면 다음과 같은 그림의 느낌을 받을 수 있을 것이다.

각 수법의 차이점을 고려해 보자
모호함을 감안하여 아래의 그림으로 총결하였다.

① Ingress 모드
① Ingress 모델의 용도, 예를 들어 "Cluster=시스템과 마찬가지로 시스템 A와 시스템 B의 개발 담당자는 각각 다르다. 시스템 A에서 시스템 B가 개발한 API를 실행하고자 하는 경우.
② ServiceMesh 모드
② ServiceMesh 모드는 Gateway를 통한 연장 서비스 Mesh
③ Tunneling, ④ L7 Message 모드는 Cluster의 Overlay Network 간의 연결입니다.
Cluster 간 통신 제어의 유연성을 볼 때 ② ServiceMesh 모델은 ③ ④보다 우수할 수 있다.
한편, 안전성을 높이려는 수요에 ⑤SaaS(F5사의VoltMesh가 강점을 느꼈다.
VoltMesh 표현

단독 부하 평형기(VoltMesh)를 사용하여 Multi-Cluster에서 서비스 Mesh

를 실현

IPsec/SSL 터널을 통해 노드를 연결하는 구조

응용간 통신은 인터넷이 아닌 볼테라를 통해 구축Volterra Global Backbone된 핵심

이러한 구성에서 저는 독립된 골간과 IPsec/SSL 터널에서의 통신을 통해 두 가지 장점을 느꼈습니다.
하지만 볼트메시는 F5사가 제공하는 SaaS여서 개발사인 록이 걱정된다.
참고 문장
따라서 Istio와 Submariner 두 가지 모델을 고려할 수도 있습니다.
Multi-Cluster로 ServiceMesh를 구성할 때Pod 사이에reachable가 필요합니다.
Submariner를 통해 Cluster 간에 L3 Interconnect를 진행하여 평탄한 Multi-Cluster 네트워크를 구성하는 기초 위에서
Istio를 사용하여 ServiceMesh를 구성하는 혼합 사용 방법을 구상할 수도 있습니다.
참고 문장
Volterra Global Backbone 및 IPsec/SSL 터널을 통한 애플리케이션 간 통신
나는 인터넷상의 IPsec 터널을 통해 다소 안전 등급의 차이가 있다고 생각한다
개방원의 조합은 어느 정도 대응할 수 있다.
③ Tunneling 모드 vs ④ L7 Messageing 모드
③ 터널링 모드의 관심사로서 클러스터 수가 늘면서 FW 규칙이 추가되는 번거로움을 고려한다.
Gateway 간의 소통에서 예를 들어 4500/UDP 등 FW의 구멍을 뚫는 것이 필요하다.
또 테두리 장비를 이용해 Kubbernetes 클러스터를 구성하고 클라우드의 Cluster와 연합하는 이런 용례를 실현하려면 IPsec에서도 테두리 장비의 자원 측면의 과제가 될 수 있다.
따라서 Cluster 수가 증가하거나 가장자리 계산의 용례를 가정할 때
④ L7 Messageing 모드가 더 강합니다.
최후
본고는 Kubernetes Multi-Cluster Networking의 기법과 각종 기법의 비교를 총괄하고 이들의 차이점을 고찰했다.
특히 서로 다른 인프라 환경에서 3Cluster 이상을 사용하기에는 아직 멀었다고 생각하지만 테두리 계산 등 새로운 용례가 될 수 있는 유력한 해결 방안이 기대되기 때문에 멀티-Cluster의 용례를 깊이 파고들고 싶습니다!
마지막으로 다양한 솔루션의 비교와 사용법 등 다양한 의견을 알고 싶고, 댓글이나 트위터에서 논의할 수 있다면 기쁠 것 같습니다.
참조 링크

https://submariner.io/

https://liqo.io/

https://skupper.io/

https://istio.io/latest/docs/setup/install/multicluster/

https://linkerd.io/2.10/features/multicluster/

https://cilium.io/blog/2019/03/12/clustermesh

https://www.volterra.io/