1주차 : Istio 첫걸음 (6) - Resiliency

CloudNet@ 가시다님이 진행하는 Istio Hands-on Study [1기]

---

✅ Istio Resiliency

네트워크는 언제든지 오류가 발생할 수 있기 때문에, 애플리케이션은 이를 대비해야 합니다.
과거에는 이런 처리를 애플리케이션 코드 안에 직접 작성해야 했습니다.

예: 재시도, 타임아웃, 회로 차단(circuit breaker) 등

👉 그런데 Istio가 이런 복잡한 네트워크 처리 코드를 대신해줍니다!

🛡️ Istio가 해주는 것

• 네트워크 오류 발생 시 자동 재시도
• 응답 지연 시 타임아웃 처리
• 오류가 계속되면 회로 차단(circuit breaker) 적용
• 애플리케이션 코드 수정 없이 적용 가능

Istio는 네트워크 오류에 강한 안정적인 애플리케이션을 만들 수 있게 도와주는 도구로, 복잡한 네트워크 회복 처리 코드를 애플리케이션 대신 처리해줍니다.

• bin/chaos.sh {에러코드} {빈도} - chaos.sh 500 50 (500에러를 50% 빈도로 재현)
  • 첫 번째 인자가 "500"이면: catalog 파드 목록을 찾아서 각 파드에 대해 작업을 수행합니다.
    두 번째 인자가 "delete"면 500 오류 설정을 비활성화 합니다.
  • 아니면 500 오류를 활성화 하고, 두 번째 인자로 지정한 확률(기본값 100%)로 오류를 발생시킵니다.
  • 요청은 파드의 catalog 컨테이너 안에서 localhost:3000/blowup 엔드포인트로 보내집니다.

#!/usr/bin/env bash

if [ $1 == "500" ]; then #입력한 첫 번째 인자($1)가 "500"인지 확인

    POD=$(kubectl get pod | grep catalog | awk '{ print $1 }') #실행 중인 파드(pod) 목록을 가져와서, 이름에 catalog가 포함된 파드의 이름을 $POD 변수에 저장합니다.
    echo $POD

    for p in $POD; do #$POD에 저장된 파드 이름들을 하나씩 순회하면서, 각 파드에 대해 아래 코드를 실행
        if [ ${2:-"false"} == "delete" ]; then #스크립트의 두 번째 인자($2)가 "delete"인지 확인
            echo "Deleting 500 rule from $p"
            kubectl exec -c catalog -it $p -- curl  -X POST -H "Content-Type: application/json" -d '{"active":
        false,  "type": "500"}' localhost:3000/blowup #파드 $p의 catalog 컨테이너에서 localhost:3000/blowup으로 POST 요청을 보내 500 오류 설정을 비활성화
        else
            PERCENTAGE=${2:-100} #$PERCENTAGE 변수에 두 번째 인자($2) 값을 저장합니다. $2가 없으면 기본값으로 100을 사용 
            kubectl exec -c catalog -it $p -- curl  -X POST -H "Content-Type: application/json" -d '{"active":
            true,  "type": "500",  "percentage": '"${PERCENTAGE}"'}' localhost:3000/blowup
            # 파드 $p의 catalog 컨테이너에서 localhost:3000/blowup으로 POST 요청을 보내 500 오류를 활성화하고 지정한 확률($PERCENTAGE)로 설정
            echo ""
        fi
    done


fi

• istioinaction 로 네임스페이스 변경

(⎈|kind-myk8s:N/A) ssoon@DESKTOP-UQRJB87:~/istio-in-action/book-source-code-master$ docker exec -it myk8s-control-plane bash
root@myk8s-control-plane:/#

root@myk8s-control-plane:/# kubectl config set-context $(kubectl config current-context) --namespace=istioinaction
Context "kubernetes-admin@myk8s" modified.

• catalog-6cf4b97d-5p442 파드에서 100% 확률로 500 오류를 설정

root@myk8s-control-plane:/istiobook/bin# ./chaos.sh 500 100
catalog-6cf4b97d-5p442
blowups=[object Object]

• Kiali 대시보드 - red (Error) / blue (total req.)

• Grafana 대시보드 

• Jaeger 대시보드 

💠 에러 발생 시 reslience 하게 retry 하도록 애플리케이션 코드 수정 없이 해보기!

• Resiliency 하게 해보자 ⇒ proxy(envoy)에 endpoint(catalog) 5xx 에러 시 retry 적용
  • Istio의 VirtualService를 사용해 catalog 서비스의 HTTP 트래픽을 관리하는 설정을 추가

root@myk8s-control-plane:/istiobook/bin# cat <<EOF | kubectl -n istioinaction apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: catalog
spec:
  hosts: #VirtualService가 적용될 서비스(호스트)를 지정
  - catalog #catalog라는 서비스에 이 VirtualService를 적용하겠다고 지정
  http: #[HTTP 트래픽에 적용할 규칙을 정의하는 섹션]
  - route: #HTTP 요청을 어디로 보낼지(라우팅) 정의
    - destination: #요청을 보낼 최종 목적지(destination)를 지정
        host: catalog #요청을 catalog 서비스로 보내라고 지정합니다. 즉, 들어오는 HTTP 요청을 catalog 서비스로 라우팅
    retries: #요청이 실패했을 때 재시도(retry) 정책을 정의
      attempts: 3 #최대 3번까지 재시도
      retryOn: 5xx #서버가 5xx 오류를 반환하면 재시도
      perTryTimeout: 2s #각 시도마다 최대 2초 동안 기다리라고 설정합니다. 한 번 시도할 때 2초 안에 응답이 없으면 실패로 간주
EOF
virtualservice.networking.istio.io/catalog created

• istioinaction 네임스페이스에 catalog와 webapp-virtualservice 두 VirtualService가 있으며, 각각 catalog 호스트와 모든 호스트(*)를 대상으로 설정

root@myk8s-control-plane:/istiobook/bin# kubectl get vs -n istioinaction
NAME                    GATEWAYS                 HOSTS         AGE
catalog                                          ["catalog"]   5s
webapp-virtualservice   ["outfitters-gateway"]   ["*"]         107m

• client 에 응답 성공율이 높아졌다!

• 그라파나 (Istio Mesh Dashboard) : retry 적용 후 Success Rate은 증가하고 5xx 에러는 감소하는 것을 확인