# Kubernetes Ingress에서 Istio로 전환 테스트
Kubernetes에서 트래픽 관리를 위해 기존 Ingress를 사용하던 설정을 Istio로 전환해보는 테스트를 진행했습니다.
아래는 Ingress와 Istio 각각의 설정과 전환 과정을 정리한 내용입니다.
---
## Ingress 설정
아래는 Ingress를 이용한 트래픽 라우팅 설정 예제입니다:
```yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: cruz-apim-cloud-ingress
namespace: cruz-apim-cloud
spec:
ingressClassName: nginx
rules:
- host: testfrontend.com
http:
paths:
- backend:
service:
name: imanager-loadbalancer
port:
number: 80
path: /
pathType: Prefix
- host: testdireaingress.com
http:
paths:
- backend:
service:
name: gateway-loadbalancer
port:
number: 80
path: /test
pathType: Prefix
```
---
## Istio 설정
아래는 동일한 트래픽 라우팅을 Istio로 전환한 설정 예제입니다:
### Gateway 설정
```yaml
apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
name: http-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
```
### VirtualService 설정
```yaml
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: go-ms-virtualservice
spec:
hosts:
- "testfrontend.com"
- "testdireaingress.com"
gateways:
- http-gateway
http:
- match:
- headers:
host:
exact: "testfrontend.com"
route:
- destination:
host: imanager-loadbalancer.cruz-apim-cloud.svc.cluster.local
port:
number: 8080
- match:
- headers:
host:
exact: "testdireaingress.com"
route:
- destination:
host: gateway-loadbalancer.cruz-apim-cloud.svc.cluster.local
port:
number: 80
```
---
## 주요 차이점
항목 |
Ingress |
Istio |
컨트롤러 |
NGINX Ingress Controller 사용 |
Istio Ingress Gateway 사용 |
라우팅 방식 |
호스트 및 경로 기반 라우팅 지원 |
HTTP 헤더 및 다양한 조건 기반 라우팅 지원 |
기능 확장성 |
기본적인 트래픽 라우팅 제공 |
트래픽 분할, A/B 테스트, 재시도 등 고급 기능 제공 |
설정 복잡도 |
상대적으로 간단 |
보다 유연하지만 설정이 복잡할 수 있음 |
---
## 테스트 결과
- **동일한 트래픽 라우팅 동작**
- Ingress와 동일하게 `testfrontend.com`과 `testdireaingress.com`으로 요청을 라우팅 성공.
- **추가 기능 확인**
- Istio의 VirtualService를 통해 HTTP 헤더 매칭, 재시도 정책 설정 등 고급 기능 구현 가능성 확인.
---
![flow](https://img1.daumcdn.net/thumb/R1280x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FmY0Tf%2FbtsLtIfRlGd%2FxK4oka8MY0gSsEetLpxaQ0%2Fimg.png)
---
### 검색하면서 알게 된 istio 사용하는 이유 (Secure, Connect, Observer)
###### 1. **Secure: 서비스 간 통신 보안**
- `mTLS(상호 TLS)`를 통해 **서비스 간 통신을 암호화**하고, 신뢰할 수 없는 서비스 간 접근을 차단합니다.
---
###### 2. **Connect: 트래픽 제어**
- **Canary 배포**: 트래픽의 90%는 기존 버전, 10%는 새로운 버전으로 분배 가능.
- **정책 기반 라우팅**: URI, Header에 따라 특정 서비스로 트래픽 라우팅.
- **장애 관리**: 타임아웃, 재시도(Retry), 회로 차단(Circuit Breaker)로 안전한 트래픽 처리.
---
###### 3. **Observer: 서비스 가시성 확보**
- **분산 트레이싱**: 서비스 간 요청 흐름을 시각화하고 병목 지점을 파악.
---
### 참고 자료
- [Kubernetes 공식 문서 - Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)
- [Istio 공식 문서 - Gateway](https://istio.io/latest/docs/tasks/traffic-management/ingress/)
- [Istio 공식 문서 - VirtualService](https://istio.io/latest/docs/reference/config/networking/virtual-service/)