개요

이스티오를 운영 환경에서 활용할 때 어떻게 배포할지에 대해 다양한 전략을 수립할 수 있다.
서비스 메시를 어떻게 구성할 것인가?
하나의 클러스터(여기서 클러스터는 엔보이의 클러스터가 아니다..) 메시 환경을 구성할 것인가?
혹은 하나의 클러스터 안에 여러 메시를 넣을 것인가?
여러 네트워크에 걸쳐 메시를 구성할 것인가?
컨트롤 플레인은?

복수 모델의 장점

사실 이스티오를 배치하는 가장 쉬운 방식은 그냥 전부 하나로 두는 것이다.
하나의 클러스터, 하나의 네트워크, 하나의 컨플이 하나의 메시 속에 들어있는 것이 기본적으로 이스티오를 활용하는 방식이다.
이미 이스티오 자체가 MSA 환경에서 다양한 서비스를 분리하고 관리할 수 있도록 도와주는 도구이기에 이런 식으로 운용하는 것도 문제되는 방식이 아니다.
HA를 한다고 해도 한 클러스터 내에서 전부 해결할 수 있는 문제니까 말이다.

그럼에도 여러 클러스터, 여러 메시를 두는 것은 다양한 이점을 제공할 수 있다.

• 분절되는 서비스, 팀 간 격리성 강화
• 클러스터 전반에 영향을 끼치는 설정과 운영이 장애 경계 설정
• 조직 보안, 감사 차원의 컴플라이언스
• 지역 별 배치를 통한 가용성 및 성능 향상
• 다중 및 하이브리드 클라우드

컴플라이언스야 그냥 규정 자체이니 제외하고, 사실 다른 것들은 서비스 목표를 어떻게 세웠는가에 따라서 하나의 이스티오를 운영한다고 해도 달성할 수 있는 사항이다.
그럼에도 운영조직에 따라서는 한 메시 환경에서 제공할 수 있는 그 이상의 분절과 격리성을 위하여 이러한 선택지를 충분히 고려할 수 있으며, 이스티오 역시 그러한 다양한 전략이 가능하도록 기능을 제공하고 있다.

차원

이스티오에서는 구체적으로 다음의 개념들을 단일화시킬지, 복수로 세팅할지를 차원으로 삼아 배포 모델을 분기한다.

• 클러스터
• 네트워크
• 컨트롤 플레인
• 메시

이들이 각각의 고유한 모델을 가지고 있다는 것이 아니라 각 기준을 체크리스트로서 네트워크 모델을 분류할 수 있다는 것으로 이해하면 되겠다.
구체적으로 어떤 식으로 배포 모델을 분류할 수 있는지 알아보자.

전반적인 요약해서 가능한 조합을 따지자면 이 정도가 되는 것 같다.

클러스터 모델

여기에서 클러스터는 쿠버네티스 클러스터를 의미한다.

단일 클러스터 모델

단일 클러스터라면 위에서 말한 것과 같은 기본 형태의 모델을 말한다.

복수 클러스터 모델

(위 그림은 네트워크도 분절시켰지만, 전부 같은 네트워크라고 해도 상관은 없다.)
복수의 클러스터라고 하면 위와 같이 구조를 그릴 수 있다.
기본적으로 각 쿠버네티스 클러스터가 내부 통신에 주력하여 지역성을 통한 성능 향상과 고가용성을 챙기는 케이스이다.

이때 모든 클러스터는 네임스페이스 동일성(namespace sameness) 을 가진다.
즉, 클러스터 a에 default 네임스페이스에 위치한 서비스 b는 메시 환경 내에서 다른 클러스터 default 네임스페이스의 서비스 b와 네트워크 상에서 동일하며 트래픽 역시 다른 클러스터로 전달될 수 있어야 한다.
그래서 중요한 것이 바로 DNS인데, 각 쿠버네티스는 멀티 클러스터를 인지하고 DNS 리졸빙을 수행할 수 없다.
이스티오에선 호스트 이름과 ip를 매핑하기 위해 쿠버 서비스나 이스티오 서비스엔트리를 활용하기에 클러스터 간 통신을 가능하게 하기 위해서는 다음과 같은 방식을 활용할 수 있다.

• 서비스
  • 각 클러스터가 스텁 서비스(stub service)를 만들어 해당 호스트 이름을 Core DNS에 등록해야 함.
  • 호스트 이름만 대리해주는 서비스로, 호스트 이름 등록에만 사용되고 실제 ip는 이스티오에서 제공
• 서비스엔트리
  • 이것은 Core DNS에 호스트 이름을 등록하지 않는다.
  • 그러므로 각 워크로드에는 이스티오의 dns 프록싱 기능이 활성화돼야 한다.
    • ISTIO_META_DNS_CAPTURE: "true" 어노테이션^[1]을 달아 프록시 세팅 시 dns 질의도 프록시가 전담하게 만들어야 함

네트워크 모델

여기에서 네트워크라고 하면 라우팅이 필요없는 단위를 말한다.
하나의 클러스터는 하나의 네트워크에 존재하나, 한 네트워크는 여러 클러스터(서브네팅)를 포함할 수 있다.

단일 네트워크 모델

단일 네트워크 모델에서는 IP 주소의 충돌이나 별도의 라우팅 설정이 필요하지 않다.

복수 네트워크 모델

그러나 멀티 네트워크 환경은 조금 다르다.
서로 다른 네트워크 환경을 가지고 있기에 이를 연결하기 위해 에지에 별도의 게이트웨이를 두고 통신을 하도록 구축해야 한다.
이렇게 다른 네트워크의 서비스를 잇기 위해 설정하는 게이트웨이를 흔히 East-West Gateway라고 부른다.
해당 게이트웨이는 자신이 속한 네트워크의 모든 서비스로 트래픽을 라우팅되도록 하는 역할을 수행해야 한다.
만약 같은 네트워크 대역을 써서 IP 충돌이 발생하는 두 메시를 연결해야 하는 상황이라면 반드시 이렇게 구성해야만 한다.

컨트롤 플레인 모델

컨트롤 플레인을 어떻게 배치할 것인가도 메시를 구성하는 중요한 기준이 된다.
하나의 클러스터에서 하나의 컨트롤 플레인을 가지는 모델은 위에서도 봤으니 그냥 생략하겠다.
그렇다면 여러 클러스터에서 컨트롤 플레인은 어떻게 두어야 하는가?
이를 기반으로 세 가지의 모델을 생각해볼 수 있다.

컨트롤 플레인 공유(shared) 모델

첫번째는 컨트롤 플레인 공유 모델이다.
보통 컨트롤 플레인이 위치한 클러스터를 기본 클러스터(Primary Cluster), 없는 쪽은 원격 클러스터(Remote Cluster)라고 부른다.
이때 컨트롤 플레인은 원격에서 접근할 수 있도록 고정된 IP를 제공할 필요가 있으며, 이는 대체로 게이트웨이를 통해 충족된다.

이렇게 구성한다면 기본 클러스터의 장애가 전체로 확산되기 때문에 리소스를 줄여야하는 상황이 아니라면 그다지 추천되진 않는다.
다만 하나의 독립된 출처를 기반으로 메시 구성이 진행되기에 정합성 등의 이슈를 고려하지 않을 수 있다.

외부 컨트롤 플레인 모델

다음은 외부 컨트롤 플레인 모델로, 완전히 컨트롤 플레인을 외부에 두고 메시를 구성하는 방식이다.
이스티오를 서비스로 제공하는 벤더 사의 상품을 사용하는 조직은 메시 환경을 이러한 방식으로 구성하게 될 것이다.

컨트롤 플레인 복제(replicated) 모델

마지막은 클러스터마다 컨트롤 플레인을 복제하여 두는 모델이다.
모든 클러스터가 컨트롤 플레인을 가지고 있으니 Primary - Primary Cluster라고도 부른다.
추가적인 리소스를 사용하겠지만 이렇게 하면 클러스터 장애로부터 메시 전체 환경이 안정적으로 운영될 수 있기에 HA에 유리하다.

이놈이 이야기할 게 좀 있어서 가장 아래로 뺐는데, 이걸 어떻게 세팅하냐에 따라 또 여러 구축 케이스가 있을 수 있다.

컨트롤 플레인을 복제하여 운용하는 모델로서 소개를 했지만, 사실 복수 개의 별도의 컨트롤 플레인을 두는 것도 당연히 가능하다.
기본적으로는 역시 같은 설정이 적용된, 동기화되는 모델을 생각해볼 수 있다.
이때는 한 컨트롤 플레인 설정 변경이 다른 쪽에도 동일하게 세팅되도록 제어하는 작업이 필요할 것이다.
그러나 각 컨트롤 플레인 간 설정을 다르게 하도록 세팅하는 것도 가능하다!
이 경우에 설정이 격리되는 한편, 서로의 환경에게 노출할 서비스에 대한 가시성(visibility) 레벨 세팅을 정교하게 가져갈 수 있을 것이다.

문서에서는 각 클러스터를 리전 별로 운영하는 것을 상황을 기본으로 설명하는데, 이때 고가용성은 아래로 갈수록 높아진다.

• 리전 별 하나
• 리전 별 여러 개
• 지역(zone) 별 하나
• 지역 별 여러 개
• 모든 클러스터 각각..

여러 리전을 운용하는 상황이라면 최소 리전 별로 배치는 해야 하지 않을까?
쿠버 클러스터를 지역 라우팅을 이유로 지역 별 클러스터를 두는 운영 케이스가 있다고 알고 있는데, 이럴 경우에는 지역 별 컨트롤 플레인도 고려해봄직하다고 본다.

엔드포인트 디스커버리

여러 컨트롤 플레인을 둘 때, 클러스터 간 엔드포인트를 찾을 수 있도록 컨트롤 플레인이 서로의 kube-apiserver에 접근할 수 있어야 한다.
(문서에서는 여러 컨트롤 플레인이 있는 상황에 대해 한정해서 말하지만, 내가 봤을 땐 그냥 여러 클러스터면 무조건 고려할 사항이다.)
기본적으로 메시 내 워크로드와 서비스의 상황을 이스티오 컨트롤 플레인은 api 서버와 통신하여 알아내기 때문에 그렇다.
달리 말하자면 각 클러스터의 컨트롤 플레인은 상대의 시큐리티#API 서버 보안을 뚫을 수 있어야 한다는 것이다!
그래서 관련한 설정을 할 필요가 있는데 이스티오에서는 관련하여 remote secret을 쉽게 만드는 기능을 제공하고 있다.

설정을 하게 되면 각 클러스터는 서로의 클러스터의 서비스들을 탐색할 수 있게 된다.
서로 탐색이 되는 상황에서 격리가 필요하다면 이스티오 버츄얼서비스나 이스티오 데스티네이션룰, 이스티오 사이드카 등의 리소스를 활용해 이들의 가시성을 조절할 수 있을 것이다.

메시 모델

여태 이야기한 모델들은 일단 하나의 메시 차원에서 이야기한 것이긴 한데, 이스티오를 세팅할 때는 사실 메시 자체를 복수로 두는 것도 가능하다.
그런데 하나의 메시는 구체적으로 어떤 범위를 가지는가?
위에서 보면 컨트롤 플레인이 다른 설정을 가지고 있는 경우도 멀티 클러스터이지만 하나의 메시로 보고 있는 것을 볼 수 있다.

기본적으로는 SPIFFE의 신뢰 도메인(trust domain)이 메시의 기준이 된다.
이스티오 시큐리티에서는 워크로드에 고유한 식별자를 부여하기 위해 스피페를 이용하는데, 이때 설정된 신뢰 도메인이 바로 메시의 기준이다.

멀티 클러스터 메시 모델

위에서 다양하게 살펴본 구조들은 멀티 클러스터 메시이다.
하나의 메시이지만 여러 개의 클러스터를 가지는 구조를 말하여, 멀티 메시라고 한다면 보통 이걸 말한다.

이스티오에서는 멀티 클러스터 메시를 편하게 세팅할 수 있도록 각종 설정 필드와 옵션을 제공한다.
이를 통해 아래에서 볼 메시 연합에 비해서는 상대적으로 자동화되고 간편하게 세팅할 수 있는 부분들이 있다.

각 클러스터는 모두 같은 신뢰 도메인을 가지고 있어야 한다.
이렇게 구조를 세팅하기 위해서는 각 클러스터가 하나의 root CA(구체적으로는 공통 신뢰 조상)를 가져야만 한다.
해당 CA를 기반으로 클러스터 별로 체인 인증서를 두고, 이를 토대로 신뢰 도메인을 구성해야 비로소 클러스터는 서로를 신뢰하고 식별자를 활용할 수 있게 된다.

메시 연합(mesh federationi)

메시 연합은 서로 다른 신뢰 도메인을 가지고 있는 메시끼리 결합하는 케이스이다.
이때 서로 같은 root CA를 공유해도 되고, 아니어도 상관 없다.
다만 어떻든 간 서로를 검증할 수 있도록 신뢰 기반을 공유할 필요가 있으며, 이때 SPIRE 같은 것을 활용할 수 있다.

메시 연합은 그냥 정말 다른 메시 간 통신을 하는 세팅이다.
그래서 멀티 클러스터 메시처럼 자동화된 디스커버리 같은 방식이나, 메시 차원의 설정 필드를 제공하지 않는다.
다른 메시 간에는 네임스페이스나 서비스 이름이 겹치거나

멀티 클러스터 메시의 조건

다양한 모델들이 가능한데 어떻게 보면 다양한 방식의 멀티 클러스터 메시 모델이 있다고 이야기할 수도 있을 것 같다.
상술했듯 이스티오에서는 멀티 클러스터 설정을 지원하고 있는데,

위에서 간단하게 언급됐던 내용들을 종합하면 멀티 클러스터 메시 모델이 가져야 하는 조건을 3가지 정도로 정리할 수 있다.

클러스터 간 워크로드 디스커버리

워크로드가 컨트롤 플레인에 연결될 수 있어야 하고, 컨트롤 플레인은 모든 클러스터의 워크로드를 찾아 레지스트리를 제공할 수 있어야 한다.
즉 컨트롤 플레인은 모든 클러스터의 api 서버에 접근할 수 있어야 한다.
이때 api 서버로 접근하기 위한 권한은 서비스 어카운트 토큰을 이용해 신원을 세팅하는데, istioctl을 통해 쉽게 설정할 수 있다.

클러스터 간 워크로드 연결성(connectivity)

각 클러스터는 엔드포인트로 실제로 연결될 수 있어야 한다.
이때 멀티 네트워크 환경이라면 각 에지를 서로 이어주는 리버스 프록시 역할을 하는 이스트웨스트 게이트웨이가 필요하다.
사실 이건 특수한 기능을 넣은 이스티오 인그레스 게이트웨이이다.
또한 멀티 클러스터이기에 서로의 도메인을 위한 스텁 서비스, DNS 프록싱을 활용한 서비스 엔트리와 같은 세팅이 필요하다.

클러스터 간 공통 신뢰

이스티오의 보안 기능을 활용하기 위해서는 클러스터 간 워크로드가 서로 인증할 수 있어야 한다.
이를 위해서는 공통된 같은 Root CA를 가지고 있어야 한다.

구체적으로는 크게 두 가지 방법을 사용할 수 있다.

• 각 클러스터에서 사용할 신뢰 조상이 같은, 중간 인증서를 만들어 이스티오 세팅할 때 넣어준다.
• Cert Manager와 같은 CSR에 서명할 수 있는 외부 기관을 활용한다.^[2]
  • 이 경우 컨트롤 플레인은 직접 서명하지 않고 외부 기관에 서명 요청을 하는 역할만 수행한다.
  • SPIRE를 활용하는 것도 가능한 듯.

하위 문서

관련 문서

EXPLAIN - 파생 문서

기타 문서

참고