Oracle Cloud Infrastructure (OCI) 에서 이스티오(ISTIO)를 활용한 서비스 메쉬(Service Mesh)에 대한 기술 정리 및 이를 데모로 구현한 내용을 정리합니다.
글 순서
5. 이스티오 데모 - 이스티오 설치, 엔보이 프록시 주입
6. 이스티오 데모 - 샘플 어플리케이션 (Bookinfo) 배포
8. 이스티오 데모 - 결함 주입(Fault Injection)
REFERENCES
아래 도서 및 사이트를 참조하여 작성한 문서입니다.
- 도메인 주도 설계로 시작하는 마이크로 서비스 개발 (위키북스)
- 쿠버네티스 완벽 가이드 (길벗)
- Istio로 시작하는 서비스 메시 (에이콘)
- Isitio Documentation
카나리(Carnary) 배포 샘플
카나리 배포는 트래픽 중 작은 일부만 새 버전의 마이크로서비스에 라우팅하고 전체 사용자 기반으로 출시를 점진적으로 진행하면서 이전 버전을 단계별로 줄이고 폐기하는 방법입니다. 전체 사용자에 새로운 버전의 서비스를 롤아웃하기 전에 일부 사용자에게 유효성을 검증하는 방식으로, 새로운 버전에서 문제가 발견되면, 트래픽을 이전 버전으로 롤백할 수 있습니다.
카나리 배포를 살펴보기 전에 먼저, 특정 버전에 대해서만 서비스하도록 DestinationRule과 VirtaulService를 구성해 보겠습니다.
먼저 적용할 DestinationRule 매니페스트 파일 내용입니다. 각 마이크로 서비스의 모든 서브셋들을 정의하고 있습니다.
[opc@demo ~]$ cat ~/istio-1.14.1/samples/bookinfo/networking/destination-rule-all.yaml
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: productpage
spec:
host: productpage
subsets:
- name: v1
labels:
version: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: reviews
spec:
host: reviews
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
- name: v3
labels:
version: v3
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: ratings
spec:
host: ratings
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
- name: v2-mysql
labels:
version: v2-mysql
- name: v2-mysql-vm
labels:
version: v2-mysql-vm
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: details
spec:
host: details
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
---
위 DestinationRule을 적용합니다.
[opc@demo ~]$ kubectl apply -f ~/istio-1.14.1/samples/bookinfo/networking/destination-rule-all.yaml
destinationrule.networking.istio.io/productpage created
destinationrule.networking.istio.io/reviews created
destinationrule.networking.istio.io/ratings created
destinationrule.networking.istio.io/details created
VitualService에서는 모든 마이크로서비스의 버전1으로 트래픽이 라우팅되도록 아래와 같이 설정하고 있습니다.
[opc@demo ~]$ cat ~/istio-1.14.1/samples/bookinfo/networking/virtual-service-all-v1.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: productpage
spec:
hosts:
- productpage
http:
- route:
- destination:
host: productpage
subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings
spec:
hosts:
- ratings
http:
- route:
- destination:
host: ratings
subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: details
spec:
hosts:
- details
http:
- route:
- destination:
host: details
subset: v1
---
위 VirtualService를 적용합니다.
[opc@demo ~]$ kubectl apply -f ~/istio-1.14.1/samples/bookinfo/networking/virtual-service-all-v1.yaml
virtualservice.networking.istio.io/productpage created
virtualservice.networking.istio.io/reviews created
virtualservice.networking.istio.io/ratings created
virtualservice.networking.istio.io/details created
istioctl 명령을 통해 각 파드가 어떻게 라우팅되고 있는 지 확인할 수 있습니다. 아래와 같이 Virtaul Service가 버전1 파드로 라우팅되고 있는 것을 알 수 있습니다.
[opc@demo ~]$ kubectl get pods | grep reviews
reviews-v1-7598cc9867-pzq9r 2/2 Running 0 4h29m
reviews-v2-6bdd859457-qplsq 2/2 Running 0 4h29m
reviews-v3-6c98f9d7d7-fp48z 2/2 Running 0 4h29m
[opc@demo ~]$ istioctl x describe pod reviews-v1-7598cc9867-pzq9r
Pod: reviews-v1-7598cc9867-pzq9r
Pod Revision: default
Pod Ports: 9080 (reviews), 15090 (istio-proxy)
--------------------
Service: reviews
Port: http 9080/HTTP targets pod port 9080
DestinationRule: reviews for "reviews"
Matching subsets: v1
(Non-matching subsets v2,v3)
No Traffic Policy
VirtualService: reviews
1 HTTP route(s)
--------------------
Effective PeerAuthentication:
Workload mTLS mode: PERMISSIVE
버전2 파드의 경우, Virtual Service의 모든 트래픽이 버전1 서브셋으로 향하고 있기 때문에 버전2 파드로는 트래픽이 도달하지 못하고 있음을 나타내고 있습니다.
[opc@demo ~]$ istioctl x describe pod reviews-v2-6bdd859457-qplsq
Pod: reviews-v2-6bdd859457-qplsq
Pod Revision: default
Pod Ports: 9080 (reviews), 15090 (istio-proxy)
--------------------
Service: reviews
Port: http 9080/HTTP targets pod port 9080
DestinationRule: reviews for "reviews"
Matching subsets: v2
(Non-matching subsets v1,v3)
No Traffic Policy
VirtualService: reviews
WARNING: No destinations match pod subsets (checked 1 HTTP routes)
Route to non-matching subset v1 for (everything)
--------------------
Effective PeerAuthentication:
Workload mTLS mode: PERMISSIVE
실제 웹브라우저에서 확인해 보면 여러번 화면을 갱신해도 Review를 보여주는 화면에서 버전1의 서비스만 나타내고 있습니다.
이번에는 Reviews 마이크로서비스의 버전1으로는 80%를, 버전2에는 20%의 트래픽을 보내도록 설정해 보겠습니다. 해당 매니페스트 파일의 내용은 다음과 같습니다. 아래와 같이 VirtualService에 weight 속성으로 설정합니다. 이렇게하면 5개의 요청마다 4개를 이전 버전으로, 1개를 새로운 버전으로 트래픽을 분배합니다.
[opc@demo ~]$ cat ~/istio-1.14.1/samples/bookinfo/networking/virtual-service-reviews-80-20.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
weight: 80
- destination:
host: reviews
subset: v2
weight: 20
위 VirtualService를 적용합니다.
[opc@demo ~]$ kubectl apply -f ~/istio-1.14.1/samples/bookinfo/networking/virtual-service-reviews-80-20.yaml
virtualservice.networking.istio.io/reviews configured
웹 브라우저에서 확인해 보면 5번에 1번 꼴로 버전2의 서비스가 호출되고 있는 것을 확인할 수 있습니다. 이러한 방식으로 카나리 배포를 구현할 수 있습니다.
지금까지의 카나리 배포와는 달리 아래와 매니페스트 파일 내용과 같이 버전3에 100% 비율로 트래픽이 할당되도록 할 수 있습니다.
[opc@demo ~]$ cat ~/istio-1.14.1/samples/bookinfo/networking/virtual-service-reviews-v3.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v3
위 VirtualService를 적용합니다.
[opc@demo ~]$ kubectl apply -f ~/istio-1.14.1/samples/bookinfo/networking/virtual-service-reviews-v3.yaml
virtualservice.networking.istio.io/reviews configured
이제 버전3의 서비스만 호출되는 것을 알 수 있습니다.
<END>
