Istio Example; Bookinfo Application📘

Bookinfo Application 은 istio 문서에서 공식적으로 제공하는 예제이다. 문서의 Tasks 수행을 위한 환경이기도 하다. 이 예시 앱을 EKS 위에 구성하여, Tasks를 진행할 준비를 한다.

Bookinfo Application

Deploys a sample application composed of four separate microservices used to demonstrate various Istio features.

https://istio.io/latest/docs/examples/bookinfo/

EKS Blueprint

Bookinfo Application📘

Gateway, VirtualService

Destination Rules

정리

습득 교훈

EKS Blueprint

지난 글에서 설명한거처럼 EKS Blueprints for Terraform엔 istio pattern이 있다.

지난번에 기본적인 실습을 하기 위해 버전업 한거 외에 추가로 수정해서 Bookinfo Application을 구성한 것이 다음 PR에 전부 있다:

pull

blueprint에서도 구성하는 테라폼 리소스 이후의 kubernetes 리소스는 전부 manifests를 apply하는 local-exec provisioner로 구현했다.

아주 좋은 방법이란 생각은 들지 않지만:

•

kubernetes_manifest 리소스를 사용하기엔 manifest가 외부 종속성(url)이 있어 적합하지 않았고

•

다른 실습을 하더라고 bookinfo는 기본 환경, 거의 인프라에 해당한다고 생각해서, 테라폼 코드 안으로 넣었다.

istio 관련한 실습은 코드화(IaC)와 워크플로 보단 평문 문서화와 핸즈온 위주가 될 것 같다.

이번에도 문서 명령어대로 따라해도 한번에 안되는 지점이 있었다. 그 부분 디버깅과 해결 그리고 bookinfo application과 istio 컴포넌트의 구성에 대해 알아보자.

Bookinfo Application

manifests

워크로드의 아키텍처는 위와 같다. 이따 올려서 확인해보면 책에 대한 정보와 리뷰를 버전별로 보여주는 앱이다. MSA 구성인데:

•

productpage : details 와 reviews 를 호출하여 화면 구성.

•

details : 책 정보에 대한 서비스.

•

reviews : 책 리뷰에 대한 서비스, 세가지 버전이 있고 일부 버전은 ratings 를 호출.

◦

v1: ratings 를 호출하지 않음.

◦

v2: ratings 를 호출하여 검은색 별을 그림 .

◦

v3: ratings 를 호출하여 빨간색 별을 그림 .

•

ratings : 책 순위에 대한 서비스.

문서에선 MSA가 각각의 언어로(polyglot) 구성되어 있다고 자랑(?)하지만, 애초에 istio를 쿠버네티스 위에 올려서 구성하다보니 당연한거 같기도 하다. istio가 쿠버네티스 외의 플랫폼에 올려도 language/framework agnostic, injection 가능한 메시라는 점을 강조하고 싶은거 같다.

위 서비스를 각 마이크로서비스에 envoy proxy sidecar가 injection 가능한 곳에(istio-injection=enabled) 설치하여 istio로 트래픽 흐름을 확인해본다.

Gateway, VirtualService

bookinfo 서비스만 배포한 후에 kiali에서 그래프를 살펴보면 아무것도 나오지 않는다. 출력 메세지의 포트 포워드 명령(k port-forward -n istio-system kiali 20001:20001)으로도 kiali 웹 콘솔에 접속할 수 있지만, istioctl 을 사용하여 조금 더 편리하게 접속할 수 있다.

Getting Started

Try Istio’s features quickly and easily.

https://istio.io/latest/docs/setup/getting-started/#download

다운 받고 PATH에 바이너리를 추가하여 사용할 수 있다(얘나 apcahe kafka나 왜 brew 같은 패키지에 담아 주지 않을까?). istioctl dashboard kiali 로 포트 포워드와 브라우저 리다이렉트(아주 조금 편한 부분ㅎ)를 동시에 해준다. Graph에 들어가면 뷰를 이리저리 바꿔도 현재는 아무것도 보이지 않는다.

istio를 통한 트래픽 관리, 가시성 확보를 위해 다음 gateway, virtualservice를 서비스와 같은 네임스페이스, default 에 설치한다.

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  # The selector matches the ingress gateway pod labels.
  # If you installed Istio using Helm following the standard documentation, this would be "istio=ingress"
  selector:
    istio: ingressgateway # use istio default controller
  servers:
  - port:
      number: 80 # NOTE: 8080에서 바꿈
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookinfo
spec:
  hosts:
  - "*"
  gateways:
  - bookinfo-gateway
  http:
  - match:
    - uri:
        exact: /productpage
    - uri:
        prefix: /static
    - uri:
        exact: /login
    - uri:
        exact: /logout
    - uri:
        prefix: /api/v1/products
    route:
    - destination:
        host: productpage
        port:
          number: 9080
YAML
복사

문서 링크의 manifest를 그대로 사용할 경우 gateway의 .spec.servers[0].port.number 가 8080이다. 이 부분이 문제였는데, 결국 해결한 것은 istioctl anaylze 덕분이었다.

Warning [IST0162] (Gateway default/bookinfo-gateway) The gateway is listening on a target port (port 8080) that is not defined in the Service associated with its workload instances (Pod selector istio=ingressgateway). If you need to access the gateway port through the gateway Service, it will not be available.

gateway가 8080 포트에 대해 열어 두었지만, selector의 파드에선 해당 포트를 노출하지 않고 있다. istio=ingressgateway 를 힌트로 이것은 istio-ingress/istio-ingress deploy 이자 svc인 것을 알 수 있다.

istio-ingress는 blueprint에서 helm release로 설치했다:

•

istio/gateway:1.20

•

values(변경하지 않음)

주석의 경고(If you installed Istio using Helm following the standard documentation, this would be "istio=ingress")와 달리 레이블은 istio=ingressgateway 로 달려 있었다.

svc 템플릿은 values에서 보이는 것처럼 service.ports 를 그대로 평가한다. deploy 템플릿엔 15090 제외하고 딱히 containerPort 를 노출하거나 values로 제어할 수 없었다. 그럼 이건 앱에서 이렇게(80, 443으로) 노출하고 있다는 것이라 gateway의 포트를 바꿨다.

여기서 헤맸던 이유는:

•

blueprint values 주석에도 있고, 바로 옆 디렉토리에 있는 gateways/istio-ingress는

◦

containerPort를 values의 포트로 구성이 가능하고

◦

기본 값은 8080, 8443으로 되어 있다.

◦

하지만 이 차트에 원격으로 접근 가능한 방법은 못찾았다. 결국 실습에 사용된 것은 istio/gateway 가  맞다.

•

파드 image가 auto이다(???)

◦

굉장히 읭?스러웠으나 주석의 힌트로, mutating webhook을 사용해서(), 최적화된(?) 이미지를 런타임에 동적으로 주입한다고 이해했다.

◦

참조 링크에 따르면 프록시 사이드카 역시 이런 방법을 쓰는 것 같다. 나중에 더 살펴 볼 것.

•

구성되는 AWS LB - target group이 unhealthy이다(TODO).

◦

위의 나머지는 다 이해했지만 이 부분은 아직 의문이다. 어떻게 요청이 가지?(그런데 성공한다…)

결과적으론 .spec.servers[0].port.number 만 80으로 바꾸어주면 istioctl analyze 는 경고를 띄우지 않는다:

❯ istioctl analyze -n default

✔ No validation issues found when analyzing namespace: default.
Bash
복사

GATEWAY_URL을 구성하여 요청하면 bookinfo 서비스를 확인할 수 있다. 이것도 문서의 설명과 환경이 조금 달라(아마 EKS가 아니라서), 다음처럼 만들 수 있다:

❯ export INGRESS_HOST=$(k -n istio-ingress get svc istio-ingress -oyaml | yq .status.loadBalancer.ingress[0].hostname)
❯ export INGRESS_PORT=$(k -n istio-ingress get svc istio-ingress -oyaml | yq '.spec.ports[] | select(.name=="http2").port')
❯ export GATEWAY_URL=$INGRESS_HOST:$INGRESS_PORT
❯ echo $GATEWAY_URL
k8s-istioing-istioing-e9152dbca9-1ae09444cbc035b3.elb.ap-northeast-2.amazonaws.com:80
Bash
복사

브라우저에서 /productpage 로 요청해본다(http 주의):

리뷰에 검은별()이 있는걸로 보아 reviews:v2로 요청이 갔다고 유추할 수 있다. bookinfo는 reviews의 각 버전에 대해 라운드로빈 요청을 한다. 아직 destination rules를 설치하지 않아 istio로 이를 관리할 수 없고 kiali에서 모니터할 수 없다.

Destination Rules

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
---
YAML
복사

별다른 트래픽 제어 없이 각 워크로드(파드) version 레이블에 같은 이름으로 매핑한다. bookinfo의 파드는 모두 version 이란 레이블이 달려 있다:

❯ k -n default get po -oyaml | yq -r '.items | map({.metadata.name: .metadata.labels.version})'
- details-v1-5f4d584748-dlwnd: v1
- productpage-v1-564d4686f-nwqb9: v1
- ratings-v1-686ccfb5d8-75rkn: v1
- reviews-v1-86896b7648-lqlfq: v1
- reviews-v2-b7dcd98fb-b9f4l: v2
- reviews-v3-5c5cc7b6d-88vdp: v3
Bash
복사

ratings에 있는 v2-mysql , v2-mysql-vm 은 기본 환경 구성이 아닌거 같다. destination rules까지 설치하면 kiali에서 그래프로 요청 흐름을 볼 수 있다:

Versioned app graph로 보면 각 destination rules의 서브셋(버전)별로 흐름을 보여준다. 세모는 서비스이다. 그래프 타입의 메뉴를 위에서 아래 순서로(App > Service > Versioned service > Workload) drill down 하는 느낌이 있다. 우측 상단에 Replay에 timespan(Last)가 있기 때문에 요청을 한 후 시간이 지나면 그래프가 사라진다.

요청을 몇 번 더 하여 모든 버전에 대한 요청이 이루어지면 전체 MSA 구성을 볼 수 있다.

정리

실습을 마치면 생성한 리소스를 정리한다. blueprint 이후에 provisioner로 구성한 것은 어차피 EKS 클러스터를 종료하여 삭제가 된다. 따라서 blueprint의 지시대로 삭제한다:

tf destroy -target="module.eks_blueprints_addons" -auto-approve
tf destroy -target="module.eks" -auto-approve
tf destroy -auto-approve
Bash
복사

그런데 나의 경우 istio-ingressgateway에 해당하는 로드밸런서 삭제가 잘 안된다. EKS를 지울 때 삭제되어야 할 거 같은데 alb controller가 먼저 죽는거 같다(…). 그러면 마지막 단계(tf destroy -auto-approve)에서 VPC 삭제가 안된다. 로드밸런서를 수동으로 삭제하고 destroy를 실행한다(가끔 VPC 삭제도 안되어 수동으로 했다).

tf state list | xargs -I{} terraform state rm {}
Bash
복사

그러곤 위처럼 state에서만 지우거나 tf destroy 를 다시 실행해도 된다.

LB의 target groups은 삭제되지 않는다. 웹 콘솔에서 삭제해준다.

추가로 istio 컨텍스트와 클러스터, 사용자도 삭제하자(어차피 다시 apply하면 생성된다):

k ctx -d istio
k config delete-cluster istio
k config delete-user istio
Bash
복사

습득 교훈

•

라우팅, 장애 주입 등 트래픽을 직접 제어하진 않았지만, istio가 envoy proxy를 통해 어떻게 트래픽을 관리할지 kiali로 확인했다.

•

제공하는 문서/가이드에서 안되는 점을 최신 버전에서 수정하여 해결했다.

◦

아직 기여할 정도는 아니다. 다시 헬름이 어렵네…

•

mutating webhook을 통한 컨테이너 이미지 동적 적용이란 개념이 신기하다. 추후에 deep dive 해볼 것.

•

비록 provisioner를 썼지만, 쿠버네티스 자체가 manifest를 통한 선언적 구성이 가능하여, 예제 앱 환경을 구성할 때 큰 문제는 없었다.

•

테라폼 destroy가 한번에(하시코프 철학), 연결 안된 리소스도(e.g. 생성되는 target groups, 보안그룹, …) 삭제하도록 구성해 볼 것.

•

이제 Task를 진행하자!