WAN 연동 데이터센터 간 서비스 간 트래픽 활성화
WAN 연동 데이터센터 간 서비스 간 트래픽 활성화
메시 게이트웨이를 사용하여 서로 다른 Consul 데이터센터 간 서비스 메시 트래픽을 라우팅하는 방법을 설명해 드릴게요. 전제 조건, 구성, 예시 구성을 살펴볼게요.
출처: 문서
본문
1.6.0+: 이 기능은 Consul 1.6.0 이상 버전에서 사용할 수 있어요.
메시 게이트웨이는 서로 다른 Consul 데이터센터 간 서비스 메시 트래픽을 라우팅할 수 있게 해줘요. 데이터센터는 모든 데이터센터의 모든 서비스 간 일반적인 상호 연결이 불가능한 서로 다른 클라우드나 런타임 환경에 있을 수 있어요.
메시 게이트웨이는 서비스 메시 세션에서 서버 이름 표시(SNI) 헤더를 스니핑하고 추출하여 요청된 서버 이름을 기준으로 연결을 적절한 대상으로 라우팅하는 방식으로 작동해요. 게이트웨이는 mTLS 세션 내의 데이터를 해독하지 않아요.
다음 다이어그램은 데이터센터 간 통신에 메시 게이트웨이를 사용하기 위한 아키텍처를 설명해요:
메시 게이트웨이 튜토리얼: 데이터센터 간 서비스 연결에 메시 게이트웨이를 사용하는 것과 관련된 중요한 개념을 배우려면 메시 게이트웨이 튜토리얼을 따라 해 주세요.
전제 조건
Consul 환경이 다음 요구 사항을 충족하는지 확인해 주세요.
Consul
- Consul 버전 1.6.0 이상.
- 구성 관리에 로컬 Consul 에이전트가 필요해요.
- 두 데이터센터 모두에서 Consul 서비스 메시가 활성화되어야 해요.
- 각 데이터센터는 고유한 이름을 가져야 해요.
- 각 데이터센터는 WAN으로 합류되어야 해요.
- 기본 데이터센터(primary datacenter)가 두 데이터센터 모두에서 동일한 값으로 설정되어야 해요. 이는 어떤 데이터센터가 서비스 메시 인증서의 권위인지 지정하며, 모든 데이터센터의 서비스가 서로 mutual TLS를 확립하는 데 필요해요.
- gRPC가 활성화되어야 해요.
- 게이트웨이를 전역적으로 활성화하려면 중앙 집중식 구성을 활성화해야 해요.
네트워크
- 로컬 Consul 데이터센터 내 모든 서비스에 대한 일반 네트워크 연결.
- 원격 Consul 데이터센터 내 모든 메시 게이트웨이에 대한 일반 네트워크 연결.
프록시
Envoy는 Consul에서 메시 게이트웨이 기능을 가진 유일한 프록시예요.
메시 게이트웨이 프록시는 프록시의 등록을 기반으로 자동 생성되는 구성을 통해 Consul에서 수신해요. Consul은 메시 게이트웨이 등록 정보만 Envoy 구성으로 변환할 수 있어요.
게이트웨이를 통해 업스트림 서비스로 트래픽을 보내는 사이드카 프록시는 해당 게이트웨이의 위치를 알아야 해요. 이들은 사이드카 프록시 등록을 기반으로 게이트웨이를 발견해요. Consul은 게이트웨이 등록 정보만 Envoy 구성으로 변환할 수 있어요.
게이트웨이를 통해 업스트림 트래픽을 보내지 않는 사이드카 프록시는 게이트웨이를 배포해도 영향을 받지 않아요. Consul의 내장 프록시를 서비스 메시 사이드카로 사용한다면 데이터센터 내 트래픽에는 계속 작동하며, 트래픽이 게이트웨이를 통과했더라도 들어오는 트래픽을 계속 받아요.
구성
메시 게이트웨이를 Consul의 서비스로 등록하려면 다음 설정을 구성해 주세요.
- 게이트웨이를 Consul에 등록하려면
kind필드에mesh-gateway를 지정해 주세요. - 트래픽을 올바른 서비스, 네임스페이스, 데이터센터로 라우팅하려면
proxy.upstreams매개변수를 구성해 주세요. 자세한 내용은 upstreams 문서를 참고해 주세요.proxy.upstreams.destination_name서비스는 항상 필요해요. 데이터센터 간 트래픽을 활성화하려면proxy.upstreams.datacenter를 구성해야 해요.proxy.upstreams.destination_namespace구성은 대상 서비스가 다른 네임스페이스에 있는 경우에만 필요해요. - 프록시(즉 Envoy)와 호환되는 불투명 매개변수를 사용하여
Proxy.Config설정을 정의해 주세요. Envoy의 경우 추가 구성 정보는 게이트웨이 옵션 및 escape-hatch 재정의 문서를 참고해 주세요. - ACL이 활성화된 경우 게이트웨이의 서비스 이름에 대한
service:write권한과 데이터센터 또는 파티션의 모든 서비스에 대한service:read권한을 부여하는 토큰을 게이트웨이의 서비스 정의에 추가해야 해요. 이 권한은 토큰이 다른 Consul 서비스 메시 서비스의 통신을 라우팅할 수 있게 인가하지만, 통신을 해독하는 것은 허용하지 않아요.
모드
서비스 메시 프록시와 연결된 각 업스트림은 메시 게이트웨이를 통해 라우팅되도록 구성할 수 있어요. 네트워크에 따라 프록시의 게이트웨이 연결은 다음 모드 중 하나로 작동할 수 있어요(mesh-architecture-diagram 참조):
-
none - (기본값) 게이트웨이가 사용되지 않으며 서비스 메시 사이드카 프록시가 대상 서비스에 직접 아웃바운드 연결을 해요.
-
local - 서비스 메시 사이드카 프록시가 같은 데이터센터에서 실행되는 게이트웨이에 아웃바운드 연결을 해요. 해당 게이트웨이는 데이터가 대상 데이터센터의 게이트웨이로 전달되도록 보장해요. mesh-architecture-diagram의
local로 표시된 흐름을 참고해 주세요. -
remote - 서비스 메시 사이드카 프록시가 대상 데이터센터에서 실행되는 게이트웨이에 아웃바운드 연결을 해요. 게이트웨이는 데이터를 최종 대상 서비스로 전달해요. mesh-architecture-diagram의
remote로 표시된 흐름을 참고해 주세요.
서비스 메시 프록시 구성
선호하는 모드로 프록시를 설정하여 서비스 메시 프록시를 구성해 주세요. 모드를 전역적으로 또는 하위 구성 내에서 지정하여 더 낮은 수준에서 프록시 동작을 제어할 수 있어요. 게이트웨이 모드가 여러 위치에서 구성된 경우 우선순위 순서는 다음과 같아요:
- 업스트림 정의 (최우선)
- 서비스 인스턴스 정의
- 중앙 집중식
service-defaults구성 엔트리 - 중앙 집중식
proxy-defaults구성 엔트리
예시 구성
일반적인 시나리오 중 일부를 이해하는 데 도움이 되도록 다음 예시 구성을 사용해 주세요.
게이트웨이 전역 활성화
다음 proxy-defaults 구성은 모든 메시 서비스에 대해 local 모드에서 게이트웨이를 활성화해요.
게이트웨이 전역 활성화 예시
HCL / YAML / JSON
Kind = "proxy-defaults"
Name = "global"
MeshGateway {
Mode = "local"
}
apiVersion: consul.hashicorp.com/v1alpha1
kind: ProxyDefaults
metadata:
name: global
spec:
meshGateway:
mode: local
{
"Kind": "proxy-defaults",
"Name": "global",
"MeshGateway": {
"Mode": "local"
}
}
서비스별 게이트웨이 활성화
다음 service-defaults 구성은 web이라는 이름의 모든 메시 서비스에 대해 게이트웨이를 활성화해요.
서비스별 게이트웨이 활성화 예시
HCL / YAML / JSON
Kind = "service-defaults"
Name = "web"
MeshGateway {
Mode = "local"
}
apiVersion: consul.hashicorp.com/v1alpha1
kind: ServiceDefaults
metadata:
name: web
spec:
meshGateway:
mode: local
{
"Kind": "service-defaults",
"Name": "web",
"MeshGateway": {
"Mode": "local"
}
}
서비스 인스턴스에 대한 게이트웨이 활성화
다음 프록시 서비스 구성은 remote 모드에서 서비스 인스턴스에 대해 게이트웨이를 활성화해요.
서비스 인스턴스에 대한 게이트웨이 활성화 예시.
service {
name = "web-sidecar-proxy"
kind = "connect-proxy"
port = 8181
proxy {
destination_service_name = "web"
mesh_gateway {
mode = "remote"
}
upstreams = [
{
destination_name = "api"
datacenter = "secondary"
local_bind_port = 10000
}
]
}
}
# Or alternatively inline with the service definition:
service {
name = "web"
port = 8181
connect {
sidecar_service {
proxy {
mesh_gateway {
mode = "remote"
}
upstreams = [
{
destination_name = "api"
datacenter = "secondary"
local_bind_port = 10000
}
]
}
}
}
}
{
"service": {
"kind": "connect-proxy",
"name": "web-sidecar-proxy",
"port": 8181,
"proxy": {
"destination_service_name": "web",
"mesh_gateway": {
"mode": "remote"
},
"upstreams": [
{
"destination_name": "api",
"datacenter": "secondary",
"local_bind_port": 10000
}
]
}
}
}
프록시 업스트림에 대한 게이트웨이 활성화
다음 서비스 정의는 첫 번째 업스트림에는 local 모드, 두 번째 업스트림에는 remote 모드로 게이트웨이를 활성화하고 세 번째 업스트림에는 게이트웨이를 비활성화해요.
프록시 업스트림에 대한 게이트웨이 활성화 예시.
HCL / JSON
service {
name = "web-sidecar-proxy"
kind = "connect-proxy"
port = 8181
proxy {
destination_service_name = "web"
upstreams = [
{
destination_name = "api"
local_bind_port = 10000
mesh_gateway {
mode = "remote"
}
},
{
destination_name = "db"
local_bind_port = 10001
mesh_gateway {
mode = "local"
}
},
{
destination_name = "logging"
local_bind_port = 10002
mesh_gateway {
mode = "none"
}
},
]
}
}
{
"service": {
"kind": "connect-proxy",
"name": "web-sidecar-proxy",
"port": 8181,
"proxy": {
"destination_service_name": "web",
"upstreams": [
{
"destination_name": "api",
"local_bind_port": 10000,
"mesh_gateway": {
"mode": "remote"
}
},
{
"destination_name": "db",
"local_bind_port": 10001,
"mesh_gateway": {
"mode": "local"
}
},
{
"destination_name": "logging",
"local_bind_port": 10002,
"mesh_gateway": {
"mode": "none"
}
}
]
}
}
}