istio 기능 시도【고장 주입, 재시도, 거울】

이 글은 2019 졸업생 엔지니어 Advent Calendar 2019 14일째 되는 글이다.
전날 쓰려고 했는데 회선이 좋지 않아 개발하지 못해 이날이 됐다.
이번에는 istio 기능을 시도했다는 보도입니다.
환경 구축편은 여기에 있다.
https://qiita.com/erb_owl/items/dfb322ceaecdb02952e8

kiali 정보

install istio 때 kiali 이 dashboard도 들어오는데 이것은 istio와 관련된 manifest를 편집하고 확인할 때 편리하기 때문에 사용합니다.
예를 들어 kiali를 열고 istio-config 라벨을 클릭하여 Virtual 서비스로 밀어넣고 bookinfo(istio의 프레젠테이션 앱 이름)의 Virtual 서비스의 YAML을 열면 이런 화면이 된다.

직접 여기에 쓰면 반응이 가장 수월하기 때문에 이렇게 한다.하는 일 자체가 마니페스트kubectl apply를 쓰는 것과 별 차이가 없기 때문에 여기는 내가 좋아하는 곳이다.

장애 주입/FaultInjection

고장 주입은 요청을 지연시키거나 오류를 되돌려주는 기능입니다.서비스가 외부 API를 호출할 때 지연 또는 오류 일치 시 동작을 확인할 수 있습니다.혼돈 프로젝트에도 쓰일 수 있다.
이런 형태로Abort 설정이 추가됐다.

원래의 응답이 아닌 50% 확률로 400의 오류를 되돌려줍니다.Postman을 사용하여 실제 반영된 요청을 보냅니다.
200번의 요청을 보낸 결과는 여기에 있다.
status code 400으로 작성된 테스트인지 예쁘게 약 50%가 400이 된다.
우리도 딜레이를 해보자.다음과 같이 설정합니다.

20%로 설정된 요청은 3초 지연됩니다.이쪽도 포스트맨으로 확인해 보세요.

너무 잘 맞아서 20퍼센트의 요구가 지연되었다고 의심스럽다.

Retry

재시도는 문자와 같이 요청이 실패했을 때 다시 요청을 보내는 기능입니다.
이 기능을 테스트하기 위해 랜덤으로 응답을 바꾸는 서버가 있으면 편리하기 때문에 제작했습니다.
이번에는 status code가 Ruby로 200500 서버를 제작해 deploy를 진행했습니다.
server.rb

require 'webrick'

server = WEBrick::HTTPServer.new({ 
    :Port => 3000
})

server.mount_proc '/' do |req, res|
    res.status = rand(2) == 0 ? 200 : 500
end

server.start

status code는 다음과 같다.

중간에 다섯 번 끼워서 다시 처리하세요.
행동을 확인하기 위해 Postman으로 요청을 보내보세요.

200회 중 5회, 200회 반납.5회 재시도 시 1/2*6=1/64 확률로 실패합니다.
요청을 200번 보냈다면 기대치가 3번 정도인 만큼 설정대로 했을 것이다.
실제로는 1/2로 반납했지만 운이 좋아서 비슷한 움직임이 있을 수 있으니 서버 로그를 확인해 보겠습니다.요청마다 매개 변수VirtualService가 분배되었다.

각자의 요청이 200으로 되돌아오기 전에 재시도한 것으로 확인할 수 있다.그나저나 맨 왼쪽 열은 Pod의 이름입니다.동일한 Pod을 다시 시도하는 것이 아니라 다양한 Pod을 다시 시도합니다.Pod 고유 질문이 발생할 경우 잘못된 질문에 대한 답변을 방지할 수 있습니다.
(이렇게 말하면fault는 삭제를 잊어버렸지만 Retry와faultInjection은 동시에 설정할 수 없습니다.)

Mirroring

HTTP traffic에 대한 미러링 설정입니다.원본 요청과 같은 요청은 지정한 다른 서비스로 연결됩니다.새 버전을 발표하기 전에 이전 버전과 같은 요청을 재생하여 문제가 있는지 확인하거나 이상한 요청을 탐지 도구로 전송할 수 있다.나중에 설명하자면 리트리의 동시 진행판이 아니다.
따라서 id에서 설정해 보세요.

거울이지만, 오리지널과 같은 방향으로 먼저 재생 요구를 시도해 보세요.선택한 미러의 비율을 변경할 수 있지만, 이번에는 기본적으로 100%로 진행됩니다.
이번 팟캐스트 장소는 방금 사용한 1:1로 200500의 서버를 되돌릴 수 있습니다.Postman의 결과는 다음과 같습니다.

99대 101이어서 결과는 일반 팟캐스트 때와 같다.
일지 확인해 볼게요.

같은 요구가 두 번 발생했는데 다른 Pod에 갔음을 알 수 있다.

총결산

istio는 http의 리셋 기능과 리셋 등 다양한 기능이 있지만 예뻐 보이는 것을 선택했습니다.
다음 기사는 OutlierDetection(전로의 상징적 기능)Rate Limit 등을 쓰고 싶습니다.