Istio on ApexCaptain의 기술 블로그

Multi-Cluster 모니터링 스택 구축하기

Sun, 23 Nov 2025 00:00:00 +0900

연관 포스트

“Istio를 활용해 다중 클러스터에 Service Mesh 구성하기”

들어가기 앞서

며칠 전에 건강검진을 받고 왔다.

피도 뽑고, 혈압도 재고, 환청이 들리진 않는지, 눈이 멀진 않았는지 등등 이런저런 점검을 수행한다.
행여나 무슨 큰 병이 나기 전에 미리 체크하고 대응할 여지를 만들어 주기 위함이다.

서버도 마찬가지로 주기적인 건강검진이 필요하다.

클러스터 안에서는 동시에 수많은 로직이 동작하고,
각 워크로드는 클러스터 내 다른 서비스들과 협력하며 크고 복잡한 작업을 수행한다.

앱이 1~2개 정도라면 직접 kubectl logs나 kubectl top 커맨드로 안에서 무슨 일이 일어나고 있는지,
리소스는 얼마나 소모 중인지 파악할 수 있지만, 그 수가 많아지면 인간이 감당하는 것이 불가능해진다.

안색만 살피면 무슨 병을 앓고 있는지 알 수 있을 정도로 실력이 뛰어난 의사가 아니라면,
X-Ray, CT와 같은 전문적인 장비와 거기서 산출된 일련의 차트 정보를 바탕으로 판단하는 것이 합리적일 것이다.

이번 포스트에서는 Prometheus, Loki, Kiali, Grafana를 통해 멀티 클러스터 환경에서
기본적인 모니터링 스택을 구축하는 방법에 대해 공유한다.

시스템 개요

전체 시스템의 개요는 위와 같다.

설치되는 컴포넌트 수가 많은 만큼 최종 결과물이 굉장히 다양할 수밖에 없다.
예를 들어 총 5개의 옵션이 있는 3개의 선택지가 있다면, 발생할 수 있는 경우의 수는 125가지나 된다.
당연히 그 모든 경우에 대해 빠짐없이 기술하는 것은 한계가 있다.

Multi Cluster 모니터링 스택에 대해 최대한 간략하게 정의한 요구사항은 다음과 같다.

2개 이상의 클러스터에서
메트릭 / 서비스 메시 / 애플리케이션 로그 데이터를 수집하여
통합된 대시보드_{(Grafana, Kiali)}로 확인 가능할 것

ELK 대신 Loki를 택한 이유

이번 작업에서는 ELK_{(Elasticsearch, Logstash, Kibana)} 대신 Loki를 사용했다.
이유는 단순하다.

ELK의 리소스 소모량이 감당이 안 된다.

Oracle에서 무료로 사용 중인 클러스터에 ELK를 설치했다면 배보다 배꼽이 더 커지는 상황이 연출될 것이다.
여러 대체재를 알아봤는데, Loki가 k8s에 경량으로 쓰기 좋다는 소식을 들었다.

Elasticsearch의 검색 기능이 매우 훌륭하긴 하나, 샤드 관리하기도 복잡하고 저장 공간도 엄청나게 잡아먹는다.
Logstash 역시 CPU/메모리 사용량이 굉장히 높다.

Loki는 Elasticsearch와 달리 데이터를 인덱싱하지 않고 레이블을 기반으로 저장한다.
인덱스 저장 공간이 별도로 필요한 것이 아니므로 저장 공간을 크게 절약할 수 있다.
당연히 샤드 관리 같은 것도 필요 없다.

공통 네임스페이스 구성

각 섹션의 앞에는 “Istio를 활용해 다중 클러스터에 Service Mesh 구성하기” 포스트에서와 마찬가지로
어떤 Kubernetes Context에서 작업하는 것인지 명시했다.

사용하는 k8s가 1개라면 Context : Remote 레이블이 붙은 섹션은 무시하도록 하자.

우선 공통적으로 컴포넌트가 배포될 Namespace는 monitoring이다.
각 클러스터에 네임스페이스를 만들어준다.

ㅤ⚠️ Context : Primaryㅤ

1

kubectl create namespace monitoring

ㅤ⚠️ Context : Remoteㅤ

1

kubectl create namespace monitoring

Loki & Promtail

Primary에 Loki & Promtail 설치

ㅤ⚠️ Context : Primaryㅤ

Primary Cluster에 Loki와 Promtail을 설치한다.
배포는 “loki-stack” Helm 차트를 사용한다.

Helm Chart 가져오기

1

helm repo add grafana https://grafana.github.io/helm-charts

Helm Values 정의

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50


# Primary-Loki-Stack.values.yml

# Grafana 설정
grafana:
 # 다른 Helm 차트를 통해 설치할 것이므로 비활성화
 enabled: false

# Loki 설정
# 로그 데이터가 저장되는 일종의 데이터베이스다
# ELK의 Elasticsearch와 유사
loki:
 config:
 limits_config:
 ingestion_burst_size_mb: 200
 ingestion_rate_mb: 100
 max_streams_per_user: 10000
 enabled: true
 persistence:
 accessModes:
 - ReadWriteOnce
 enabled: true
 size: 20Gi
 storageClassName: <사용할 StorageClass 명>
 resources:
 limits:
 cpu: 500m
 memory: 1024Mi
 requests:
 cpu: 300m
 memory: 512Mi

# Promtail 설정
# 로그 수집기다
# ELK의 Logstash와 유사
promtail:
 enabled: true
 config:
 clients:
 - external_labels:
 # Primary Cluster의 이름을 적어주자
 # 단일 k8s일 경우 clients 설정 전체를 생략해도 된다
 cluster: oke
 url: http://loki-stack.monitoring.svc.cluster.local:3100/loki/api/v1/push
 resources:
 limits:
 cpu: 200m
 memory: 256Mi
 requests:
 cpu: 100m
 memory: 128Mi

Helm 차트 배포

1
2
3


helm install loki-stack grafana/loki-stack \
 -n monitoring \
 -f Primary-Loki-Stack.values.yml

배포 상태 확인

1
2
3


kubectl get all \
 -l app.kubernetes.io/instance=loki-stack \
 -n monitoring

다음과 같이 출력되면 정상이다.

1
2
3
4
5
6


NAME READY STATUS RESTARTS AGE
pod/loki-stack-promtail-gckgr 1/1 Running 0 4d4h
pod/loki-stack-promtail-tnnrz 1/1 Running 0 4d4h

NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
daemonset.apps/loki-stack-promtail 2 2 2 2 2 <none> 4d4h

Primary Loki 외부 진입점 설정

ㅤ⚠️ Context : Primaryㅤ

Ingress 혹은 VirtualService 등을 사용해 Loki 외부 진입점을 만들어야 한다.
이는 Remote Cluster에 추후 설치할 Promtail이 Primary의 Loki에 데이터를 밀어넣을 수 있도록 하기 위함이다.

단일 클러스터를 운영 중이라면 이 부분은 생략하도록 하자.

이 예시에서는 VirtualService를 통해 외부로 노출했다.

VirtualService 정의

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


# Primary-Loki-VS.yml
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
 name: monitoring-loki-virtual-service
 namespace: monitoring
spec:
 gateways:
 - <사용할 Istio Gateway. 가령, istio-system/my-istio-gateway>
 hosts:
 - <사용할 Domain Host. 가령, my-primary-loki.example.com>
 http:
 - match:
 - port: 3100
 route:
 - destination:
 host: loki-stack
 port:
 number: 3100

VirtualService 배포

1

kubectl apply -f Primary-Loki-VS.yml

Remote에 Promtail 설치

ㅤ⚠️ Context : Remoteㅤ

“Loki"는 이미 Primary에 설치되어 있으므로, Remote Cluster에는 Promtail만 설치하면 된다.
Promtail 단일 컴포넌트만 배포해도 상관 없지만, 편의를 위해 동일한 Helm Chart를 사용했다.

Helm Values 정의

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


# Remote-Loki-Stack.values.yml

# Grafana 설정
grafana:
 # Primary와 마찬가지 이유로 Grafana 비활성화
 enabled: false

# Loki 설정
loki:
 # Primary의 Loki를 쓸 예정이므로 이것도 비활성화
 enabled: false

# Promtail 설정
promtail:
 config:
 clients:
 - external_labels:
 # Remote Cluster의 이름을 적어주자
 cluster: workstation
 url: https://<앞서 설정한 Primary Loki의 도메인, 가령 my-primary-loki.example.com>/loki/api/v1/push
 enabled: true
 resources:
 limits:
 cpu: 400m
 memory: 1Gi
 requests:
 cpu: 200m
 memory: 512Mi

Helm 차트 배포

1
2
3


helm install loki-stack grafana/loki-stack \
 -n monitoring \
 -f Remote-Loki-Stack.values.yml

배포 상태 확인

1
2
3


kubectl get all \
 -l app.kubernetes.io/instance=loki-stack \
 -n monitoring

다음과 같이 출력되면 정상이다.

1
2
3
4
5


NAME READY STATUS RESTARTS AGE
pod/loki-stack-promtail-22vvg 1/1 Running 15 4d4h

NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
daemonset.apps/loki-stack-promtail 1 1 1 1 1 <none> 4d5h

Primary와 다르게 Promtail만 설치된 모습이다.

Prometheus & Grafana

Primary에 Prometheus & Grafana 설치

ㅤ⚠️ Context : Primaryㅤ

Primary Cluster에 Prometheus와 Grafana를 설치한다.
배포는 kube-prometheus-stack Helm 차트를 사용한다.

Helm Chart 가져오기

1

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

Helm Values 정의

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115


# Primary-Kube-Prometheus-Stack.values.yml

# AlertManager 설정
alertmanager:
 # 비활성화
 # 이 부분은 추후 다른 포스트를 통해 다루도록 하겠다.
 enabled: false

# Grafana 설정
grafana:
 enabled: true

 # Primary Cluster에 배포한 Loki를 데이터 소스에 추가해주자
 additionalDataSources:
 - access: proxy
 isDefault: false
 jsonData:
 maxLines: 1000
 name: Loki
 type: loki
 url: http://loki-stack.monitoring.svc.cluster.local:3100

 adminPassword: <관리자 비밀번호>
 adminUser: <관리자 ID>
 defaultDashboardsTimezone: Asia/Seoul

 persistence:
 accessModes:
 - ReadWriteOnce
 enabled: true
 finalizers:
 - kubernetes.io/pvc-protection
 size: 20Gi
 storageClassName: <사용할 StorageClass 명>
 type: sts

 # Grafana Dashboard 설정
 # 미리 각종 Dashboard를 추가해두었다.
 # dashboardProviders, dashboards 모두 비워두고 추후 웹에서 추가해도 된다.
 dashboardProviders:
 dashboardproviders.yaml:
 apiVersion: 1
 providers:
 - folder: Custom Node Exporter
 name: custom-node-exporter
 options:
 path: /var/lib/grafana/dashboards/custom-node-exporter
 type: file
 - folder: Istio
 name: istio
 options:
 path: /var/lib/grafana/dashboards/istio
 type: file
 - folder: Loki
 name: loki
 options:
 path: /var/lib/grafana/dashboards/loki
 type: file

 dashboards:
 custom-node-exporter:
 node-exporter-full:
 datasource: Prometheus
 gnetId: 1860
 revision: 42
 istio:
 istio-control-plane-dashboard:
 datasource: Prometheus
 gnetId: 7645
 revision: 278
 istio-mesh-dashboard:
 datasource: Prometheus
 gnetId: 7639
 revision: 278
 istio-performance-dashboard:
 datasource: Prometheus
 gnetId: 11829
 revision: 278
 istio-service-dashboard:
 datasource: Prometheus
 gnetId: 7636
 revision: 278
 istio-workload-dashboard:
 datasource: Prometheus
 gnetId: 7630
 revision: 278
 loki:
 logs-app:
 datasource: Loki
 gnetId: 13639
 revision: 2

# Prometheus 설정
prometheus:
 enabled: true
 prometheusSpec:
 enableRemoteWriteReceiver: true
 externalLabels:
 cluster: oke
 resources:
 limits:
 cpu: "1"
 memory: 2Gi
 requests:
 cpu: 300m
 memory: 512Mi
 storageSpec:
 volumeClaimTemplate:
 spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 50Gi
 storageClassName: <사용할 StorageClass 명>

Helm 차트 배포

1
2
3


helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack \
 -n monitoring \
 -f Primary-Kube-Prometheus-Stack.values.yml

배포 상태 확인

1
2
3


kubectl get all \
 -l app.kubernetes.io/instance=kube-prometheus-stack \
 -n monitoring

다음과 같이 출력되면 정상이다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


NAME READY STATUS RESTARTS AGE
pod/kube-prometheus-stack-grafana-0 3/3 Running 0 5d3h
pod/kube-prometheus-stack-kube-state-metrics-787d55fc86-9j42s 1/1 Running 0 6d4h
pod/kube-prometheus-stack-operator-79df675c88-s6rnj 1/1 Running 0 6d4h
pod/kube-prometheus-stack-prometheus-node-exporter-24rdg 1/1 Running 0 6d4h
pod/kube-prometheus-stack-prometheus-node-exporter-q8tcb 1/1 Running 0 6d4h

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kube-prometheus-stack-grafana ClusterIP 10.96.147.47 <none> 80/TCP 6d4h
service/kube-prometheus-stack-grafana-headless ClusterIP None <none> 9094/TCP 5d21h
service/kube-prometheus-stack-kube-state-metrics ClusterIP 10.96.216.187 <none> 8080/TCP 6d4h
service/kube-prometheus-stack-operator ClusterIP 10.96.244.110 <none> 443/TCP 6d4h
service/kube-prometheus-stack-prometheus ClusterIP 10.96.134.158 <none> 9090/TCP,8080/TCP 6d4h
service/kube-prometheus-stack-prometheus-node-exporter ClusterIP 10.96.255.80 <none> 9100/TCP 6d4h

NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
daemonset.apps/kube-prometheus-stack-prometheus-node-exporter 2 2 2 2 2 kubernetes.io/os=linux 6d4h

NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/kube-prometheus-stack-kube-state-metrics 1/1 1 1 6d4h
deployment.apps/kube-prometheus-stack-operator 1/1 1 1 6d4h

NAME DESIRED CURRENT READY AGE
replicaset.apps/kube-prometheus-stack-kube-state-metrics-787d55fc86 1 1 1 6d4h
replicaset.apps/kube-prometheus-stack-operator-79df675c88 1 1 1 6d4h

NAME READY AGE
statefulset.apps/kube-prometheus-stack-grafana 1/1 5d21h

Primary Prometheus 외부 진입점 설정

Loki와 마찬가지로 Prometheus도 Ingress 혹은 VirtualService로 외부 진입점을 만들어야 한다.
이 예시에서는 VirtualService로 작성했다.

VirtualService 정의

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


# Primary-Prometheus-VS.yml
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
 name: monitoring-prometheus-virtual-service
 namespace: monitoring
spec:
 gateways:
 - <사용할 Istio Gateway. 가령, istio-system/my-istio-gateway>
 hosts:
 - <사용할 Domain Host. 가령, my-primary-prometheus.example.com>
 http:
 - match:
 - port: 9090
 route:
 - destination:
 host: kube-prometheus-stack-prometheus
 port:
 number: 9090

VirtualService 배포

1

kubectl apply -f Primary-Prometheus-VS.yml

Primary에 Istiod Service Monitor 설치

ㅤ⚠️ Context : Primaryㅤ

Prometheus가 Istio 제어 평면의 메트릭을 수집할 수 있도록 Service Monitor 배포

ServiceMonitor 정의

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


# Primary-Istiod-ServiceMonitor.yml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
 labels:
 monitoring: istio-control-plane
 release: kube-prometheus-stack
 name: monitoring-istiod-service-monitor
 namespace: monitoring
spec:
 endpoints:
 - interval: 15s
 port: http-monitoring
 jobLabel: istiod
 namespaceSelector:
 matchNames:
 - istio-system
 selector:
 matchExpressions:
 - key: istio
 operator: In
 values:
 - pilot
 targetLabels:
 - app

ServiceMonitor 배포

1

kubectl apply -f Primary-Istiod-ServiceMonitor.yml

Primary에 Istio Envoy Pod Monitor 설치

ㅤ⚠️ Context : Primaryㅤ

Prometheus가 Istio Envoy Sidecar의 메트릭 정보를 수집할 수 있도록 Pod Monitor 배포

PodMonitor 정의

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


# Primary-Istio-Envoy-PodMonitor.yml
apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
 labels:
 monitoring: istio-envoy-proxies
 release: kube-prometheus-stack
 name: monitoring-istio-envoy-stats-pod-monitor
 namespace: monitoring
spec:
 jobLabel: envoy-stats
 namespaceSelector:
 any: true
 podMetricsEndpoints:
 - interval: 15s
 path: /stats/prometheus
 port: http-envoy-prom
 selector:
 matchExpressions:
 - key: service.istio.io/canonical-revision
 operator: Exists

PodMonitor 배포

1

kubectl apply -f Primary-Istio-Envoy-PodMonitor.yml

Remote에 Prometheus 설치

ㅤ⚠️ Context : Remoteㅤ

“Grafana"는 이미 Primary에 설치되어 있으므로, Remote Cluster에는 Prometheus만 설치하면 된다.

Helm Values 정의

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


# Remote-Kube-Prometheus-Stack.values.yml

# AlertManager 설정
alertmanager:
 # 비활성화
 enabled: false

# Grafana 설정
grafana:
 # 비활성화
 enabled: false

# Prometheus 설정
prometheus:
 enabled: true
 prometheusSpec:
 externalLabels:
 # Remote Cluster의 이름을 적어주자
 cluster: workstation
 remoteWrite:
 - url: https://<앞서 설정한 Primary Prometheus의 도메인, 가령 my-primary-prometheus.example.com>/api/v1/write
 resources:
 limits:
 cpu: '1'
 memory: 2Gi
 requests:
 cpu: 500m
 memory: 1024Mi

Helm 차트 배포

1
2
3


helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack \
 -n monitoring \
 -f Remote-Kube-Prometheus-Stack.values.yml

배포 상태 확인

1
2
3


kubectl get all \
 -l app.kubernetes.io/instance=kube-prometheus-stack \
 -n monitoring

다음과 같이 출력되면 정상이다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


NAME READY STATUS RESTARTS AGE
pod/kube-prometheus-stack-kube-state-metrics-787d55fc86-dnlzf 1/1 Running 15 4d5h
pod/kube-prometheus-stack-operator-79df675c88-xpdxw 1/1 Running 15 4d5h
pod/kube-prometheus-stack-prometheus-node-exporter-sjwml 1/1 Running 15 4d5h

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kube-prometheus-stack-kube-state-metrics ClusterIP 10.152.183.231 <none> 8080/TCP 4d5h
service/kube-prometheus-stack-operator ClusterIP 10.152.183.227 <none> 443/TCP 4d5h
service/kube-prometheus-stack-prometheus ClusterIP 10.152.183.185 <none> 9090/TCP,8080/TCP 4d5h
service/kube-prometheus-stack-prometheus-node-exporter ClusterIP 10.152.183.205 <none> 9100/TCP 4d5h

NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
daemonset.apps/kube-prometheus-stack-prometheus-node-exporter 1 1 1 1 1 kubernetes.io/os=linux 4d5h

NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/kube-prometheus-stack-kube-state-metrics 1/1 1 1 4d5h
deployment.apps/kube-prometheus-stack-operator 1/1 1 1 4d5h

NAME DESIRED CURRENT READY AGE
replicaset.apps/kube-prometheus-stack-kube-state-metrics-787d55fc86 1 1 1 4d5h
replicaset.apps/kube-prometheus-stack-operator-79df675c88 1 1 1 4d5h

Remote에 Istio Envoy Pod Monitor 설치

ㅤ⚠️ Context : Remoteㅤ

Prometheus가 Istio Envoy Sidecar의 메트릭 정보를 수집할 수 있도록 Pod Monitor 배포

PodMonitor 정의

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


# Remote-Istio-Envoy-PodMonitor.yml
apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
 labels:
 monitoring: istio-envoy-proxies
 release: kube-prometheus-stack
 name: monitoring-istio-envoy-stats-pod-monitor
 namespace: monitoring
spec:
 jobLabel: envoy-stats
 namespaceSelector:
 any: true
 podMetricsEndpoints:
 - interval: 15s
 path: /stats/prometheus
 port: http-envoy-prom
 selector:
 matchExpressions:
 - key: service.istio.io/canonical-revision
 operator: Exists

PodMonitor 배포

1

kubectl apply -f Remote-Istio-Envoy-PodMonitor.yml

Primary Grafana 외부 진입점 설정

ㅤ⚠️ Context : Primaryㅤ

이제 Grafana의 외부 진입점을 설정해 웹 페이지를 통해 확인해볼 차례이다.

VirtualService 정의

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# Primary-Grafana-VS.yml
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
 name: monitoring-grafana-virtual-service
 namespace: monitoring
spec:
 gateways:
 - <사용할 Istio Gateway. 가령, istio-system/my-istio-gateway>
 hosts:
 - <사용할 Domain Host. 가령, my-primary-grafana.example.com>
 http:
 - route:
 - destination:
 host: kube-prometheus-stack-grafana
 port:
 number: 80

VirtualService 배포

1

kubectl apply -f Primary-Grafana-VS.yml

Grafana 페이지 접속

Ingress 혹은 VirtualService로 설정한 호스트에 접속해보자.

Primary Cluster에 kube-prometheus-stack 배포 시,
Grafana의 대시보드 값을 넣어줬다면, 설정한 대시보드가 미리 프로비저닝되어 있을 것이다.

Dashboard -> Custom Node Exporter -> Node Exporter Full로 접속해보자

두 클러스터의 정보를 모두 확인 가능하다면 기본적인 Grafana 설정은 완료되었다.

Kiali

Primary에 Kiali Operator 설치

ㅤ⚠️ Context : Primaryㅤ

Kiali는 Operator Pattern을 사용하는 것이 일반적이다.

별도 네임스페이스에 kiali-operator를 helm으로 설치하고,
배포된 CRD와 Operator를 통해 monitoring 네임스페이스에 실제 Kiali CR을 배포한다.

네임스페이스 생성

1

kubectl create namespace kiali-operator

Helm Chart 가져오기

1

helm repo add kiali https://kiali.org/helm-charts

Helm Values 정의

1
2
3


# Primary-Kiali-Operator.values.yml
cr:
 create: false

Helm 차트 배포

1
2
3


helm install kiali-operator kiali/kiali-operator \
 -n kiali-operator \
 -f Primary-Kiali-Operator.values.yml

배포 상태 확인

1
2
3


kubectl get all \
 -l app.kubernetes.io/instance=kiali-operator \
 -n kiali-operator

다음과 같이 출력되면 정상이다.

1
2
3
4
5
6
7
8


NAME READY STATUS RESTARTS AGE
pod/kiali-operator-8647f4d94c-x75fp 1/1 Running 0 5d18h

NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/kiali-operator 1/1 1 1 5d18h

NAME DESIRED CURRENT READY AGE
replicaset.apps/kiali-operator-8647f4d94c 1 1 1 5d18h

Remote에 Kiali용 Service Account 생성

ㅤ⚠️ Context : Remoteㅤ

Primary에 설치되는 Kiali가 Remote Cluster에 접근할 수 있도록
Remote에 Service Account와 Cluster Role, Cluster Role Binding을 만들어줘야 한다.

이 부분은 하나의 yml 파일로 정리하도록 하겠다.

Manifest 정의

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49


# Remote-Kiali-Account-Info.yml
---
apiVersion: v1
kind: ServiceAccount
metadata:
 name: kiali-remote-access-service-account
 namespace: istio-system
secrets:
 - name: kiali-remote-access-service-account-token
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
 name: kiali-remote-access-cluster-role
rules:
 - apiGroups:
 - '*'
 resources:
 - '*'
 verbs:
 - get
 - list
 - watch
 - nonResourceURLs:
 - '*'
 verbs:
 - get
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: kiali-remote-access-cluster-role-binding
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: kiali-remote-access-cluster-role
subjects:
 - kind: ServiceAccount
 name: kiali-remote-access-service-account
 namespace: istio-system
---
apiVersion: v1
kind: Secret
metadata:
 name: kiali-remote-access-service-account-token
 namespace: istio-system
 annotations:
 kubernetes.io/service-account.name: kiali-remote-access-service-account
type: kubernetes.io/service-account-token

Manifest 배포

1

kubectl apply -f Remote-Kiali-Account-Info.yml

Remote ServiceAccount를 기반으로 kubeconfig 작성

ㅤ⚠️ Context : Remoteㅤ

ca.crt 값 확인

1
2
3


kubectl get secret kiali-remote-access-service-account-token \
 -n istio-system \
 -o jsonpath='{.data.ca\.crt}'

token 값 확인

1
2
3


kubectl get secret kiali-remote-access-service-account-token \
 -n istio-system \
 -o jsonpath='{.data.token}' | base64 -d

KubeConfig 파일 작성

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# Kiali-Remote-Kubeconfig.yml
apiVersion: v1
kind: Config
clusters:
 - name: workstation
 cluster:
 server: <Remote Cluster URL>
 certificate-authority-data: <위에서 추출한 ca.crt 값>
users:
 - name: kiali-remote-access-service-account
 user:
 token: <위에서 추출한 token 값>
contexts:
 - name: workstation-context
 context:
 cluster: workstation
 user: kiali-remote-access-service-account
current-context: workstation-context

Primary Kiali -> Remote Cluster에 접속 가능하도록 Secret 생성

ㅤ⚠️ Context : Primaryㅤ

Secret 정의

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# Primary-Kiali-Multi-Cluster-Secret.yml
apiVersion: v1
data:
 workstation: <위에서 생성한 Kiali-Remote-Kubeconfig.yml을 base64로 인코딩한 값>
kind: Secret
metadata:
 annotations:
 kiali.io/cluster: workstation
 labels:
 kiali.io/multiCluster: 'true'
 name: monitoring-kiali-workstation-cluster-secret
 namespace: monitoring
type: Opaque

workstation은 사용 중인 Remote Cluster의 이름이다.

Secret 배포

1

kubectl apply -f Primary-Kiali-Multi-Cluster-Secret.yml

Primary에 Kiali 설치

ㅤ⚠️ Context : Primaryㅤ

Kiali 정의

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# Primary-Kiali.yml
apiVersion: kiali.io/v1alpha1
kind: Kiali
metadata:
 name: monitoring-kiali
 namespace: monitoring
spec:
 auth:
 # ⚠️ 테스트를 위한 것으로 Production에서 사용할 때는 반드시 인증 절차를 구축하도록 하자
 strategy: anonymous
 deployment:
 namespace: monitoring
 accessible_namespaces:
 - '*'
 external_services:
 prometheus:
 url: http://kube-prometheus-stack-prometheus.monitoring.svc.cluster.local:9090

Kiali 배포

1

kubectl apply -f Primary-Kiali.yml

Primary Kiali 외부 진입점 설정

ㅤ⚠️ Context : Primaryㅤ

이제 Kiali의 외부 진입점을 설정해 웹 페이지를 통해 확인해볼 차례이다.

VirtualService 정의

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# Primary-Kiali-VS.yml
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
 name: monitoring-kiali-virtual-service
 namespace: monitoring
spec:
 gateways:
 - <사용할 Istio Gateway. 가령, istio-system/my-istio-gateway>
 hosts:
 - <사용할 Domain Host. 가령, my-primary-kiali.example.com>
 http:
 - route:
 - destination:
 host: kiali
 port:
 number: 20001

VirtualService 배포

1

kubectl apply -f Primary-Kiali-VS.yml

Kiali 페이지 접속

Ingress 혹은 VirtualService로 설정한 호스트에 접속해보자.

두 클러스터의 워크로드들이 모두 표시된다면 성공이다.

Istio Primary-Remote Multi Cluster Mesh 시나리오에 따라
OKE(Primary)에 단일 제어 평면(Control Plane),
그리고 각 클러스터에 1개씩의 데이터 평면(Data Plane)이 구성된 모습이다.

마치며

이번 포스트에서는 Multi-Cluster 환경에서 모니터링 스택을 구축하는 방법을 다뤘다.

Primary Cluster에는 데이터를 수집하고 시각화하는 컴포넌트들_{(Grafana, Loki, Prometheus, Kiali)}을 배포했고,
Remote Cluster에는 데이터를 수집하여 Primary로 전송하는 컴포넌트들_{(Promtail, Prometheus)}만 배포하여 리소스 사용을 최적화했다.

이를 통해 여러 클러스터에 분산된 워크로드의 메트릭, 로그, 서비스 메시 정보를 하나의 대시보드에서 통합하여 확인할 수 있게 되었다.

클러스터의 건강 상태를 지속적으로 모니터링하고 이상 징후를 조기에 발견하는 것은 안정적인 서비스 운영을 위한 필수 요소다.
이번에 구축한 모니터링 스택이 기반이 되어 당신이 운영하는 클러스터의 건강검진을 수행하는 데 부디 도움이 되길 바란다.

이번 포스트에서는 멀티 클러스터 모니터링 스택의 기본 구축에 집중했다.
추가로 고려하면 좋을 주제들은 다음과 같다:

AlertManager를 통한 알림 설정: 이상 징후 발생 시 즉시 알림을 받을 수 있도록 구성
리소스 튜닝: 클러스터 규모와 워크로드에 맞는 리소스 최적화
보안 설정: 인증/인가를 통한 접근 제어 및 데이터 보호
트러블슈팅 가이드: 자주 발생하는 문제와 해결 방법
네트워크 정책: 모니터링 컴포넌트 간 통신 보안 강화
백업 전략: 모니터링 데이터의 장기 보관 및 복구 계획

이러한 주제들은 추후 별도의 포스트를 통해 다루도록 하겠다.

참고자료

Helm Charts

loki-stack - Grafana Loki Stack Helm Chart
kube-prometheus-stack - Prometheus Community Helm Charts
kiali-operator - Kiali Operator Helm Chart

공식 문서

Istio를 활용해 다중 Cluster에 Service Mesh 구성하기

Sat, 15 Nov 2025 00:00:00 +0900

들어가기 앞서

지난 달 말에 “k8s에 Ollama AI 서버 올려보기”라는 포스트를 통해
“GPU가 포함된 인프라 구축에 대해 고민 중“이라는 내용을 언급했다.

GPU 서버 스펙

이리저리 정보를 취합해 비교/토의한 결과,
결국 독립된 GPU 서버를 IDC 센터에 설치하는 형태로 마무리 되었다.

그냥 GPU 서버를 클라우드에 올려 준다면야 나는 매우 편하고 좋겠지만,
클라우드의 엄청난 비용 부담을 고려하면 이 방식이 가장 합리적인 판단이라고 생각한다.

RTX A6000 GPU의 성능이 지금 당장은 충분해 보이나,
향후 확장성을 고려하면 GPU 서버 역시 k8s 클러스터로 구성해야 한다.

하지만 실제 서비스를 사용자에게 제공할 때는 클라우드에 있는 k8s를 사용한다.
GPU 클러스터는 GPU 중심의 워크로드만 담당하고 각종 인증, 데이터 처리, 웹 서비스 등은 클라우드에서 제공한다는 의미이다.

요컨대 클러스터 간의 통신을 구축할 필요성이 생겼다.

사실 이런 시나리오를 전혀 예측하지 못한 것은 아니다.

현대적인 인프라 아키텍처에서는 점차 여러 개의 k8s 클러스터를 운영하는 것이 일반적인 관습이 되어가고 있다. 처음에 k8s를 사용할 때는 하나의 클러스터로도 필요한 모든 서비스를 처리하는 게 가능해 보이지만, 확장성이나 장애 시 복원 탄력성 등 머지 않아 그 한계에 부딪히게 된다.

이번 GPU 케이스의 경우 “클라우드에 올리기에 너무 비싸 자체적으로 운영한다"라는 물리적인 확장성 이슈이다.

Istio는 이런 상황에 대응할 수 있도록 다수의 클러스터를 하나의 서비스 메시로 통합해 여러 클러스터에 걸친 워크로드 간 통신을 안전하고_{(mTLS, Authorization Policy)}, 일관된 방식_{(트래픽 제어)}으로 구성할 수 있는 기능을 제공한다.

Service Mesh 확장 방식

Istio Deployment Models 공식 문서에 따르면 서비스 메시 확장은 크게 2가지 모델이 존재한다.

Multiple Clusters

동일한 Service Mesh가 여러 k8s 클러스터에 걸쳐 뻗어있는 방식이다. _{(클러스터 클러스터)}
여러 클러스터의 서비스들이 하나의 통합된 메시로 관리되며, 클러스터 간 자동 서비스 발견 및 로드 밸런싱이 가능하다.

Multiple Clusters 모델의 주요 특징:
- 서비스 발견 (Service Discovery): 여러 클러스터의 서비스 엔드포인트를 자동으로 통합
- 크로스 클러스터 로드 밸런싱: 요청을 여러 클러스터의 엔드포인트에 자동 분산
- 네트워크 구성: 단일 네트워크 또는 다중 네트워크(지리적 분산, 보안 격리) 구성 가능
- 제어 평면 (Control Plane): 단일 제어 평면으로 여러 클러스터 관리 혹은 각 클러스터에 독립적으로 배치
클러스터 간 엔드포인트 발견을 위해서는 각 제어 평면에 remote secret을 배포하여 다른 클러스터의 API 서버에 접근할 수 있도록 구성해야 한다.

하나의 국가 내에 존재하는 여러 도시들을 생각해보자, 예를 들면 대한민국의 서울/부산/대구.

지리적 위치는 물론 수도, 가스, 전기, 하다못해 지하철 노선 등등 분명 독립된 인프라가 존재한다.
하지만 모든 도시는 “대한민국"이라는 국가 내에서 동일한 법률, 정부, 화폐, 신분증 체계를 공유한다.
도시 간 이동은 상당히 자유로우며, 다른 도시에 있는 사람을 같은 국가의 시민으로 인식한다.
Multiple Meshes

여러 개의 독립적인 서비스 메시를 연합(Mesh Federation)하는 방식이다. _{(클러스터 클러스터 클러스터)}
각 메시는 고유한 mesh ID를 가지며, 서비스 이름이나 네임스페이스 이름을 재사용할 수 있다.

Multiple Meshes 모델은 다음과 같은 상황에서 유용하다:
- 조직 경계: 서로 다른 조직이나 사업부가 독립적인 메시를 운영
- 강한 격리: 테스트 워크로드와 프로덕션 워크로드 간 완전한 격리
메시 간 통신을 위해서는 Mesh Federation을 구성해야 하며, 서로 다른 trust domain을 가진 메시 간 통신을 위해서는 trust bundle 교환이 필요하다.

세상에는 여러 개의 나라가 있다. 예를 들면 대한민국, 일본, 미국 등등.

각각의 국가는 기본적인 인프라는 물론 저마다 다른 법률, 정부, 통화, 언어 및 신분증 체계를 가지고 있다.
국가 간 이동은 여권과 비자가 필요하며, 행동에 상당한 제약이 따른다.
가령, 미국에 여행 간 사람이 총기를 구매한다거나 투표를 한다거나 하는 것은 불가능하다.

멀티 클러스터 서비스 메시 시나리오

위 언급한 2가지 모델 중 이번에 사용할 것은 멀티 클러스터이다.
멀티 클러스터 메시를 구성할 때는 네트워크 분리 여부와 제어 평면 배포 방식에 따라 4개의 시나리오가 있다.

시나리오	네트워크	제어 평면(Control Plane)
1. Multi-Primary	동일 네트워크	개별 배포
2. Primary-Remote	동일 네트워크	단일 배포
3. Multi-Primary on different network	개별 네트워크	개별 배포
4. Primary-Remote on different network	개별 네트워크	단일 배포

내 경우 연결할 두 클러스터의 네트워크가 물리적으로 완전히 분리된 상황이므로 3번 혹은 4번만 보면 된다.

Multi-Primary와 Primary-Remote의 차이는 제어 평면을 각 클러스터마다 배포 할 것인지(Multi-Primary),
아니면 하나의 제어 평면만 두고(Primary), 다른 클러스터를(Remote) 관리만 할 것인지(Primary-Remote)이다.

앞서 비유를 이어가면 다음과 같다.

Multi-Primary (개별 제어 평면): 연방제 국가의 각 주(州)가 독립적인 정부를_{(주 정부)} 가지는 방식.

예를 들어, 미국의 캘리포니아, 텍사스, 뉴욕은 각각 독립적인 주 정부를 가지고 있다.
한 주의 정부가 마비되어도 다른 주는 정상적으로 운영되지만, 각 주마다 정부 조직을 유지해야 하므로 비용과 운영 부담이 크다.

Primary-Remote (단일 제어 평면): 단일 국가의 중앙 정부가 여러 지역을 관리하는 방식.

예를 들어, 우리나라는 중앙정부(서울)가 서울, 부산, 대구 등 모든 도시를 관리한다.
하나의 정부로 통합 관리하므로 운영이 간단하지만, 중앙정부가 마비되면 전국이 위험해진다.
_{(물론 우리나라도 지방 자치가 있긴 한데, 미국이나 독일 등의 주 정부에 비하면 권한이 매우 약하다.)}

	개별 제어 평면(Multi-Primary)	단일 제어 평면(Primary-Remote)
장점	고 가용성, 장애 격리	구성과 운영 난이도가 낮음
단점	리소스 소모가 많아지고 운영 난이도가 높음	Primary의 Istiod 다운 시 전체 메시가 위험해짐

2가지 시나리오를 모두 경험해보고 싶어서, 내가 개인적으로 운영하는 k8s는 단일 제어 평면,
회사의 k8s는 개별 제어 평면으로 구성하려고 한다.

이번 포스트에선 개인 k8s에 멀티 클러스터 서비스 메시를 Primary-Remote on different network 시나리오에 맞춰 구성한 내용을 담는다.

멀티 클러스터 서비스 메시 구현

실습한 시나리오는 Primary-Remote이다.

Primary Cluster는 Oracle Cloud Infrastructure에 OKE Cluster,
Remote Cluster는 집에 있는 On-Premise Cluster이다.

Primary 클러스터에 단일 제어 평면(Istio Control Plane)을 설치하고,
Remote 클러스터는 Primary가 만든 서비스 메시에 클라이언트로서 참여한다.

전체 클러스터를 아우르는 Mesh ID 값을 정해야 한다.
내 경우 apex-captain-mesh로 지정했다.

각 클러스터에 Istio 리소스가 배포되는 Namespace는 istio-system이다. (기본값)

각 클러스터의 이름과 네트워크명을 할당했다.
Primary Cluster는 oke, Remote Cluster는 workstation이다.

⚠️ 두 클러스터를 왔다갔다 하면서 작업해야 해서 헷갈릴 수 있다.

각 섹션 앞에는 어느 Context에서 진행하는 내용인지 명시 해두었으니 참고하자.

Primary 기본 네트워크 설정

ㅤ⚠️ Context : Primaryㅤ

Primary 클러스터의 istio-system Namespace에 Network 값을 Label로 달아준다.

1

kubectl label namespace istio-system topology.istio.io/network=oke

OKE 클러스터를 Primary로 구성

ㅤ⚠️ Context : Primaryㅤ

우선 istio-base를 설치한다.

1

helm install istio-base istio/base -n istio-system

istiod는 다음과 같은 values를 사용해 설치한다.

1
2
3
4
5
6
7
8


# Primary-Istiod.yml
global:
 meshID: apex-captain-mesh
 externalIstiod: true
 network: oke
 multiCluster:
 clusterName: oke
# 기타 설정...

1
2


helm install istiod istio/istiod -n istio-system \
 -f Primary-Istiod.yml

global.externalIstiod를 true로 설정하는 것이 중요하다.
이는 OKE 클러스터에 설치되는 Istiod가 외부 제어 평면으로 기능 할 수 있도록 하는 플래그이다.

Primary에 `east-west gateway` 설치

ㅤ⚠️ Context : Primaryㅤ

Istio에는 north-south, east-west 게이트웨이라는 개념이 있다.
남북이니, 동서니 하는데 이게 Istio에서만 쓰는 이상한 용어는 아니고, 트래픽의 방향에 대한 얘기이다.

위 그림의 Data Center를 각각 하나의 k8s라고 생각해 보자.

External Network, 즉 “인터넷"을 북쪽, “k8s"를 남쪽에 두면
north-south 트래픽이란 것은 인터넷과 서비스 간, 즉 외부 사용자와의 통신을 의미한다.
일반적으로 많이 쓰는 “Nginx Ingress Controller"가 담당하는 것이 north-south 트래픽인 것이다.

반면, 두 k8s를 나란히 옆으로 두면 두 k8s 간의 통신은
동-서 간, 즉 east-west 간의 통신이 된다.
east-west 게이트웨이는 k8s 간의 istio mesh 구성을 위해 통신하는 출입문이다.
멀티 클러스터 서비스 메시를 구성하는 모든 k8s에 하나씩 필요하다.

우선 Primary 클러스터에 east-west gateway를 설치해보자.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# Primary-Istio-East-West-Gateway.yml
name: istio-eastwestgateway
networkGateway: oke
service:
 type: LoadBalancer

 # Reserved IP를 생성해서 고정된 값을 넣는 것을 추천한다
 loadBalancerIP: <할당할 LB의 IP> 

 # 기타 추가할 Annotations
 # 아래는 OCI Free Tier에 부합하는 로드밸런서 설정이다.
 # 사용하는 클라우드 혹은 LB 공급자에 맞춰 설정하자.
 # annotations: 
 # 'service.beta.kubernetes.io/oci-load-balancer-security-list-management-mode':'None',
 # 'service.beta.kubernetes.io/oci-load-balancer-shape':'flexible',
 # 'service.beta.kubernetes.io/oci-load-balancer-shape-flex-max':'10',
 # 'service.beta.kubernetes.io/oci-load-balancer-shape-flex-min':'10',

helm 차트 배포:

1
2
3


helm install istio-eastwestgateway istio/gateway \
 -n istio-system \
 -f Primary-Istio-East-West-Gateway.yml

배포 상태 확인:

1

kubectl get svc -n istio-system -l app=istio-eastwestgateway

다음과 같이 나오면 정상이다.

1
2


NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
istio-eastwestgateway LoadBalancer <클러스터 내부 IP> <LB의 IP> 15021:30358/TCP,15443:30461/TCP,15012:30494/TCP,15017:32510/TCP 2d4h

Primary Cluster의 제어 평면 노출

ㅤ⚠️ Context : Primaryㅤ

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54


# Primary-Expose-Istiod.yml
apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
 name: istiod-gateway
spec:
 selector:
 istio: eastwestgateway
 servers:
 - port:
 name: tls-istiod
 number: 15012
 protocol: tls
 tls:
 mode: PASSTHROUGH 
 hosts:
 - "*"
 - port:
 name: tls-istiodwebhook
 number: 15017
 protocol: tls
 tls:
 mode: PASSTHROUGH 
 hosts:
 - "*"
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
 name: istiod-vs
spec:
 hosts:
 - "*"
 gateways:
 - istiod-gateway
 tls:
 - match:
 - port: 15012
 sniHosts:
 - "*"
 route:
 - destination:
 host: istiod.istio-system.svc.cluster.local
 port:
 number: 15012
 - match:
 - port: 15017
 sniHosts:
 - "*"
 route:
 - destination:
 host: istiod.istio-system.svc.cluster.local
 port:
 number: 443

k8s manifest 배포:

1

kubectl apply -f Primary-Expose-Istiod.yml -n istio-system

배포 상태 확인:

1

kubectl get gateway,vs -n istio-system

다음과 같이 나오면 정상이다.

1
2
3
4
5


NAME AGE
gateway.networking.istio.io/istiod-gateway 2d4h

NAME GATEWAYS HOSTS AGE
virtualservice.networking.istio.io/istiod-vs ["istiod-gateway"] ["*"] 2d4h

Remote Cluster 제어 평면 설정

ㅤ⚠️ Context : Remoteㅤ

Remote 클러스터의 istio-system 네임스페이스에 Primary의 제어 평면을 사용할 것임을 지정해주자.

1
2


kubectl annotate namespace istio-system \
 topology.istio.io/controlPlaneClusters=oke

Remote 기본 네트워크 설정

ㅤ⚠️ Context : Remoteㅤ

Remote 클러스터의 istio-system Namespace에도 Network 값을 Label로 달아준다.

1

kubectl label namespace istio-system topology.istio.io/network=workstation

Workstation 클러스터를 Remote로 구성

ㅤ⚠️ Context : Remoteㅤ

Remote에도 istio-base를 설치한다.

1
2


helm install istio-base istio/base -n istio-system \
 --set profile=remote

profile 값을 “remote“로 해준다.

istiod는 다음과 같은 values를 사용해 설치한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# Remote-Istiod.yml
profile: remote
global:
 configCluster: true
 remotePilotAddress: <Primary 클러스터의 East-West Gateway LB IP>
 multiCluster:
 clusterName: workstation
 network: workstation
 istiodRemote:
 injectionPath: /inject/cluster/workstation/net/workstation

# 기타 설정...

1
2


helm install istiod istio/istiod -n istio-system \
 -f Remote-Istiod.yml

Remote 클러스터의 연결 정보 생성

ㅤ⚠️ Context : Remoteㅤ

istioctl 명령어로 Remote Cluster에 Service Account와 Role/RoleBinding을 만들고
이 정보를 Primary에 Secret으로 넣어줘야 한다.

1
2


istioctl create-remote-secret \
 --name=workstation > remote-workstation.yml

remote-workstation.yml 파일이 생성되었다면 성공이다.

Primary에 Remote 클러스터의 연결 정보 주입

ㅤ⚠️ Context : Primaryㅤ

위에서 생성한 remote-workstation.yml 파일을 그대로 Primary 클러스터에 배포해준다.

1

kubectl apply -f remote-workstation.yml

Remote에 `east-west gateway` 설치

ㅤ⚠️ Context : Remoteㅤ

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# Remote-Istio-East-West-Gateway.yml
name: istio-eastwestgateway
networkGateway: workstation
service:
 type: LoadBalancer
 loadBalancerIP: <할당할 LB의 IP> 
 # 이 부분이 좀 특이한데,
 # 내가 운영 중인 Workstation Cluster의 경우 Iptime Router 뒤에서 동작한다.
 # 단순 LB IP만 가지고는 Primary가 접근할 수 없으므로
 # 실제 Router의 IP를 넣어줘야 한다.
 externalIPs:
 - <Router의 외부 IP>

helm 차트 배포:

1
2
3


helm install istio-eastwestgateway istio/gateway \
 -n istio-system \
 -f Remote-Istio-East-West-Gateway.yml

배포 상태 확인:

1

kubectl get svc -n istio-system -l app=istio-eastwestgateway

다음과 같이 나오면 정상이다.

1
2


NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
istio-eastwestgateway LoadBalancer <클러스터 내부 IP> <LB의 IP>,<Router의 IP> 15021:30358/TCP,15443:30461/TCP,15012:30494/TCP,15017:32510/TCP 35h

Primary / Remote 양쪽 모두에 Cross Network Gateway 배포

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# Cross-Network-Gateway.yml
apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
 name: cross-network-gateway
spec:
 selector:
 istio: eastwestgateway
 servers:
 - port:
 number: 15443
 name: tls
 protocol: TLS
 tls:
 mode: AUTO_PASSTHROUGH
 hosts:
 - "*.local"

Cross-Network-Gateway.yml을 양쪽 클러스터 모두에 배포해준다.

ㅤ⚠️ Context : Primaryㅤ

1

kubectl apply -f Cross-Network-Gateway.yml -n istio-system

ㅤ⚠️ Context : Remoteㅤ

1

kubectl apply -f Cross-Network-Gateway.yml -n istio-system

기본 연결 상태 확인

istioctl로 멀티 클러스터 상태 확인

ㅤ⚠️ Context : Primaryㅤ

1

istioctl remote-clusters

다음과 같이 나오면 정상이다.

1
2
3


NAME SECRET STATUS ISTIOD
oke synced istiod-59fc7749cd-2bvtx
workstation istio-system/istio-remote-secret-workstation synced istiod-59fc7749cd-2bvtx

Primary(oke)에 Secret이 안 보이는 건 당연하다.
OKE 자체가 istio 입장에선 Home이라 그렇다. 모든 클러스터가 synced이면 정상이다.

istioctl로 프록시 상태 확인

ㅤ⚠️ Context : Primaryㅤ

1

istioctl proxy-status

다음과 같이 나오면 정상이다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


NAME CLUSTER ISTIOD VERSION SUBSCRIBED TYPES
ak-outpost-oke-authentik-proxy-outpost-57bd89b88c-9968m.authentik oke istiod-59fc7749cd-2bvtx 1.28.0 5 (CDS,LDS,EDS,RDS,NDS)
ak-outpost-workstation-authentik-proxy-outpost-fcfb6fd5b-5hs99.authentik workstation istiod-59fc7749cd-2bvtx 1.28.0 5 (CDS,LDS,EDS,RDS,NDS)
authentik-postgresql-0.authentik oke istiod-59fc7749cd-2bvtx 1.28.0 5 (CDS,LDS,EDS,RDS,NDS)
authentik-redis-master-0.authentik oke istiod-59fc7749cd-2bvtx 1.28.0 5 (CDS,LDS,EDS,RDS,NDS)
authentik-server-7bc95fb9b9-qgnsp.authentik oke istiod-59fc7749cd-2bvtx 1.28.0 5 (CDS,LDS,EDS,RDS,NDS)
authentik-worker-586897c75d-vspq7.authentik oke istiod-59fc7749cd-2bvtx 1.28.0 5 (CDS,LDS,EDS,RDS,NDS)
cloudbeaver-deployment-5dcf4cd996-nwmjs.cloudbeaver oke istiod-59fc7749cd-2bvtx 1.28.0 5 (CDS,LDS,EDS,RDS,NDS)
game-sdtd-deployment-f9dd8578b-llhks.game workstation istiod-59fc7749cd-2bvtx 1.28.0 4 (CDS,LDS,EDS,RDS)
game-sftp-deployment-75ddb69cb4-pmbx7.game workstation istiod-59fc7749cd-2bvtx 1.28.0 4 (CDS,LDS,EDS,RDS)
home-l2tp-vpn-proxy-stateful-set-1.home-l2tp-vpn-proxy oke istiod-59fc7749cd-2bvtx 1.28.0 4 (CDS,LDS,EDS,RDS)
ingress-controller-ingress-nginx-controller-85cf749c6f-xzh4d.ingress-controller workstation istiod-59fc7749cd-2bvtx 1.28.0 5 (CDS,LDS,EDS,RDS,NDS)
istio-eastwestgateway-6cfbb6f579-j8rgd.istio-system oke istiod-59fc7749cd-2bvtx 1.28.0 5 (CDS,LDS,EDS,RDS,SDS)
istio-eastwestgateway-787568f5ff-w5jr5.istio-system workstation istiod-59fc7749cd-2bvtx 1.28.0 5 (CDS,LDS,EDS,RDS,SDS)
jellyfin-859d64757b-qrh4m.nas workstation istiod-59fc7749cd-2bvtx 1.28.0 5 (CDS,LDS,EDS,RDS,NDS)
nas-sftp-deployment-6544d44588-5kvng.nas workstation istiod-59fc7749cd-2bvtx 1.28.0 4 (CDS,LDS,EDS,RDS)
ollama-75d4d849bc-xzlfz.ollama workstation istiod-59fc7749cd-2bvtx 1.28.0 5 (CDS,LDS,EDS,RDS,NDS)
open-webui-0.open-webui workstation istiod-59fc7749cd-2bvtx 1.28.0 5 (CDS,LDS,EDS,RDS,NDS)
open-webui-pipelines-996f759d7-gzxwg.open-webui workstation istiod-59fc7749cd-2bvtx 1.28.0 5 (CDS,LDS,EDS,RDS,NDS)
open-webui-tika-fb987c668-8zswp.open-webui workstation istiod-59fc7749cd-2bvtx 1.28.0 4 (CDS,LDS,EDS,RDS)
redis-ui-deployment-65b968c54f-mbxpc.redis-ui oke istiod-59fc7749cd-2bvtx 1.28.0 4 (CDS,LDS,EDS,RDS)

크로스 클러스터 트래픽 테스트

Istio 공식 가이드에 따라 두 클러스터에 샘플 서비스를 배포해 정상적으로 동작하는지 테스트해보자.

Primary에 샘플 앱 배포

ㅤ⚠️ Context : Primaryㅤ

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105


# Primary-Sample.yml
apiVersion: v1
kind: Namespace
metadata:
 name: sample
 labels:
 istio-injection: enabled
---
apiVersion: v1
kind: Service
metadata:
 namespace: sample
 name: helloworld
 labels:
 app: helloworld
 service: helloworld
spec:
 ports:
 - port: 5000
 name: http
 selector:
 app: helloworld
---
apiVersion: apps/v1
kind: Deployment
metadata:
 namespace: sample
 name: helloworld-v1
 labels:
 app: helloworld
 version: v1
spec:
 replicas: 1
 selector:
 matchLabels:
 app: helloworld
 version: v1
 template:
 metadata:
 labels:
 app: helloworld
 version: v1
 spec:
 containers:
 - name: helloworld
 image: docker.io/istio/examples-helloworld-v1:1.0
 resources:
 requests:
 cpu: "100m"
 imagePullPolicy: IfNotPresent #Always
 ports:
 - containerPort: 5000
---
apiVersion: v1
kind: ServiceAccount
metadata:
 namespace: sample
 name: curl
---
apiVersion: v1
kind: Service
metadata:
 namespace: sample
 name: curl
 labels:
 app: curl
 service: curl
spec:
 ports:
 - port: 80
 name: http
 selector:
 app: curl
---
apiVersion: apps/v1
kind: Deployment
metadata:
 namespace: sample
 name: curl
spec:
 replicas: 1
 selector:
 matchLabels:
 app: curl
 template:
 metadata:
 labels:
 app: curl
 spec:
 terminationGracePeriodSeconds: 0
 serviceAccountName: curl
 containers:
 - name: curl
 image: docker.io/curlimages/curl:8.16.0
 command: ["/bin/sleep", "infinity"]
 imagePullPolicy: IfNotPresent
 volumeMounts:
 - mountPath: /etc/curl/tls
 name: secret-volume
 volumes:
 - name: secret-volume
 secret:
 secretName: curl-secret
 optional: true
---

k8s manifest 배포:

1

kubectl apply -f Primary-Sample.yml

Remote에 샘플 앱 배포

ㅤ⚠️ Context : Remoteㅤ

Primary와 거의 유사하다. Deployment만 조금 다르다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105


# Remote-Sample.yml
apiVersion: v1
kind: Namespace
metadata:
 name: sample
 labels:
 istio-injection: enabled
---
apiVersion: v1
kind: Service
metadata:
 namespace: sample
 name: helloworld
 labels:
 app: helloworld
 service: helloworld
spec:
 ports:
 - port: 5000
 name: http
 selector:
 app: helloworld
---
apiVersion: apps/v1
kind: Deployment
metadata:
 namespace: sample
 name: helloworld-v2
 labels:
 app: helloworld
 version: v2
spec:
 replicas: 1
 selector:
 matchLabels:
 app: helloworld
 version: v2
 template:
 metadata:
 labels:
 app: helloworld
 version: v2
 spec:
 containers:
 - name: helloworld
 image: docker.io/istio/examples-helloworld-v2:1.0
 resources:
 requests:
 cpu: "100m"
 imagePullPolicy: IfNotPresent #Always
 ports:
 - containerPort: 5000
---
apiVersion: v1
kind: ServiceAccount
metadata:
 namespace: sample
 name: curl
---
apiVersion: v1
kind: Service
metadata:
 namespace: sample
 name: curl
 labels:
 app: curl
 service: curl
spec:
 ports:
 - port: 80
 name: http
 selector:
 app: curl
---
apiVersion: apps/v1
kind: Deployment
metadata:
 namespace: sample
 name: curl
spec:
 replicas: 1
 selector:
 matchLabels:
 app: curl
 template:
 metadata:
 labels:
 app: curl
 spec:
 terminationGracePeriodSeconds: 0
 serviceAccountName: curl
 containers:
 - name: curl
 image: docker.io/curlimages/curl:8.16.0
 command: ["/bin/sleep", "infinity"]
 imagePullPolicy: IfNotPresent
 volumeMounts:
 - mountPath: /etc/curl/tls
 name: secret-volume
 volumes:
 - name: secret-volume
 secret:
 secretName: curl-secret
 optional: true
---

k8s manifest 배포:

1

kubectl apply -f Remote-Sample.yml

Primary에서 연결 테스트

ㅤ⚠️ Context : Primaryㅤ

1
2
3
4


kubectl exec -n sample -c curl \
 "$(kubectl get pod -n sample -l \
 app=curl -o jsonpath='{.items[0].metadata.name}')" \
 -- curl -sS helloworld.sample:5000/hello

위 명령어를 여러 번 반복해보자.
다음과 같이 v1과 v2가 출력되면 정상이다.

1
2
3
4


Hello version: v2, instance: helloworld-v2-6746879bdd-8csng
Hello version: v1, instance: helloworld-v1-5787f49bd8-kmgdm
Hello version: v1, instance: helloworld-v1-5787f49bd8-kmgdm
...

Remote에서 연결 테스트

ㅤ⚠️ Context : Remoteㅤ

1
2
3
4


kubectl exec -n sample -c curl \
 "$(kubectl get pod -n sample -l \
 app=curl -o jsonpath='{.items[0].metadata.name}')" \
 -- curl -sS helloworld.sample:5000/hello

위 명령어를 여러 번 반복해보자.
다음과 같이 v1과 v2가 출력되면 정상이다.

1
2
3
4


Hello version: v1, instance: helloworld-v1-5787f49bd8-kmgdm
Hello version: v1, instance: helloworld-v1-5787f49bd8-kmgdm
Hello version: v2, instance: helloworld-v2-6746879bdd-8csng
...

여기까지 결과를 봤다면 멀티 클러스터 서비스 메시 구성은 끝이다. 🎉

두 클러스터를 왔다갔다 하며 설정해야 하기에 헷갈릴 수 있는데,
공식 문서의 시나리오를 천천히 따라가다 보면 어렵지 않게 설정할 수 있을 것이다.

확인이 끝났다면 각 클러스터에서 sample 네임스페이스는 지워 주도록 하자.
1
kubectl delete ns sample

당면했던 문제들

멀티 클러스터 메시 구성 자체는 그렇게 어렵지는 않았다.

다만 메시를 구성하면서 온갖 종류의 문제에 직면 했었는데,
어떤 일이 있었고 어떤식으로 대응했는지 간단하게 서술하겠다.

Ingress

로드밸런서는 공짜가 아니다

클라우드에서 제공하는 LoadBalancer는 당연히 비용이 발생한다.

OCI의 Flexible LB는 1개까지는 무료이고, 초과분부터는 1달에 개당 $8.41이 부과된다.
환율 1,450원으로 계산하면 12,000원 정도이다.

그렇게 비싸진 않지만
어쨌든 LB가 늘어나면 비용이 발생한다.
Nginx Ingress Controller와 같은 LB를 공유할 수 없다

Nginx Ingress Controller로 Ingress 처리를 하고 있었는데,
Istio East-West Gateway를 배포하려면 별도의 LB를 따로 구해야 한다.

메시 구성을 위해 달 12,000원이 부과된다는 것이다.

해결책:

Istio East-West Gateway가 Istio Ingress Gateway의 기능을 겸하도록 하고,
Nginx Ingress Controller를 통째로 제거했다.

Ingress 처리 방식 자체를 Istio VirtualService 방식으로 마이그레이션 한 것이다.
여기에 대해선 할 얘기가 많지만 본 주제에서 벗어나므로 추후 포스팅 하도록 하겠다.

다만 Helm으로 East-West Gateway 배포 시 별도 포트 설정이 안 돼서 엄청 애를 먹었었는데,
이를 해결하기 위해 CDK for Terraform으로 별도 Execution 스크립트를 작성해서 강제 할당하였다.

Github 저장소에 올려 두었다. 누군가에게는 도움이 되지 않을까 싶다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100


 istioEastWestGatewayServicePortPatch = this.provide(
 Resource,
 'istioEastWestGatewayServicePortPatch',
 () => {
 const kubeConfigPath =
 this.k8sOkeEndpointStack.okeEndpointSource.shared.kubeConfigFilePath;
 const proxyUrl =
 this.k8sOkeEndpointStack.okeEndpointSource.shared.proxyUrl.socks5;
 const serviceName = this.istioEastWestGatewayRelease.shared.name;
 const namespace = this.namespace.element.metadata.name;

 const additionalPorts: {
 port: number;
 name: string;
 targetPort: number;
 protocol: string;
 present: boolean;
 }[] = [
 {
 port: 80,
 name: 'http',
 targetPort: 80,
 protocol: 'TCP',
 present: true,
 },
 {
 port: 443,
 name: 'https',
 targetPort: 443,
 protocol: 'TCP',
 present: true,
 },
 ];

 const provisioners = additionalPorts.map<LocalExecProvisioner>(
 ({ port, name, targetPort, protocol, present }) => {
 if (present) {
 // 포트 추가
 return {
 type: 'local-exec',
 command: dedent`
 port_exists=$(kubectl get svc ${serviceName} -n ${namespace} \
 -o jsonpath='{.spec.ports[?(@.port==${port})].port}' 2>/dev/null || echo '')
 if [ -z "$port_exists" ]; then
 kubectl patch svc ${serviceName} -n ${namespace} \
 --type='json' \
 -p='[{"op": "add", "path": "/spec/ports/-", "value": {"name": "${name}", "port": ${port}, "protocol": "${protocol}", "targetPort": ${targetPort}}}]' || true
 fi
 `,
 environment: {
 KUBECONFIG: kubeConfigPath,
 HTTPS_PROXY: proxyUrl,
 },
 };
 } else {
 return {
 type: 'local-exec',
 command: dedent`
 port_exists=$(kubectl get svc ${serviceName} -n ${namespace} \
 -o jsonpath="{.spec.ports[?(@.port==${port})].port}" 2>/dev/null || echo '')

 if [ -z "$port_exists" ]; then
 exit 0
 fi

 ports_list=$(kubectl get svc ${serviceName} -n ${namespace} \
 -o jsonpath='{.spec.ports[*].port}' 2>/dev/null || echo '')

 idx=0
 for port_item in $ports_list; do
 if [ "$port_item" = "${port}" ]; then
 kubectl patch svc ${serviceName} -n ${namespace} \
 --type='json' \
 -p="[{\"op\": \"remove\", \"path\": \"/spec/ports/$idx\"}]" || exit 1
 exit 0
 fi
 idx=$((idx + 1))
 done

 exit 1
 `,
 environment: {
 KUBECONFIG: kubeConfigPath,
 HTTPS_PROXY: proxyUrl,
 },
 };
 }
 },
 );

 return {
 triggers: {
 releaseId: this.istioEastWestGatewayRelease.element.id,
 ports: JSON.stringify(additionalPorts),
 },
 dependsOn: [this.istioEastWestGatewayRelease.element],
 provisioners,
 };
 },
 );

OAuth2 Proxy

위에서 이어지는 문제이다.

기존 Nginx Ingress를 썼을 때는 GitHub OAuth2 앱을 기반으로 OAuth2 Proxy를
Nginx Auth 레이어에 추가해 보호 했었는데, Istio Gateway + VirtualService에서는
GitHub OAuth를 사용하는 것이 불가능했다.

엄밀히 말하면 가능은 한데, 여러 도메인을 동시에 보호하는 게 너무 힘들었다.

어차피 언젠가 옮길 생각도 있었어서, 이참에 별도의 인증 앱을 배포하기로 했다.

본래 Keycloak을 쓸 생각이었으나,
Keycloak Helm Chart에도 적혀 있길, Bitnami가 2025년 8월 28일부로
기존 무료 컨테이너 이미지 대부분을 레거시 저장소로 옮기고 업데이트를 중단했다. (…)

이미지가 모두 내려가 있다

여기에 대해선 이리저리 말이 많은데,
Bitnami가 Broadcom에 인수된 이후 Keycloak을 유료로 바꾸려는 게 아닌가 하는 의견이 지배적이다.

해결책:

다행히 Keycloak을 사용 중이던 것은 아니어서 그냥 대체 앱을 설치해서 쓰고 있다.
선택한 앱은 Authentik. 이거에 대해서도 추후 포스팅 하도록 하겠다.

다음은 실제 시연 영상이다.

Authentik으로 인증 거쳐서 Torrent 서비스에 접속

마치며

이번 작업을 통해 클라우드와 온프레미스 환경에 있는
두 개의 Kubernetes 클러스터를 하나의 통합된 서비스 메시로 연결할 수 있게 되었다.

멀티 클러스터 서비스 메시 구성 자체는 공식 문서를 따라하면 그렇게 어렵지 않았지만,
실제 운영 환경에서 마주한 문제들 — 특히 Ingress와 인증 레이어의 재구성 — 은 예상보다 많은 시간을 소모했다.

다만 이러한 과정을 통해 Istio의 Gateway/VirtualService 아키텍처에 대해 더 깊이 이해할 수 있었고, 결국 Nginx Ingress Controller에서 Istio로의 마이그레이션까지 완료할 수 있었다.

앞서 언급했듯이, 다음 단계로는 회사에서 운영 중인 Kubernetes 클러스터에 Multi-Primary 모델을 적용해볼 계획이다. 이렇게 하면 더 높은 가용성과 장애 격리를 확보할 수 있을 것이다.

또한 이번에 도입한 Authentik과 Istio Gateway 기반의 인증/라우팅 구조에 대해서도 별도의 포스팅으로 정리할 예정이다. 이 부분은 멀티 클러스터 구성보다는 일반적인 Istio 사용 사례에 가깝지만, 실제 운영 환경에서 겪은 경험들을 공유하면 누군가에게는 도움이 되지 않을까 싶다.

현대적인 마이크로서비스 아키텍처에서는 단일 클러스터의 한계를 넘어 여러 클러스터를 운영하는 것이 점차 표준이 되어가고 있다. Istio는 이러한 트렌드에 부합하는 강력한 도구이며, 잘 활용한다면 복잡한 인프라를 일관된 방식으로 관리할 수 있다.

혹시 이 글을 읽는 누군가가 비슷한 작업을 계획하고 있다면,
이 글이 조금이나마 도움이 되기를 바란다.

참고 자료

Istio Deployment Models

Istio Multiple Clusters

Istio Multiple Meshes

Istio Multi-Primary 설치 가이드

Istio Primary-Remote 설치 가이드

Istio Multi-Primary on different network

Istio Primary-Remote on different network

Istio 멀티클러스터 검증 가이드