Spinnaker canary usage
위의 참고 URL 을 쭈욱 따라하면서 카나리 디플로이에 대하여 기본적으로 이해하고,
현재 버전에서 정상적으로 동작하는지를 테스트 하였다.
설치 버전 halyard 1.12.5 kubernetes 1.11
prometheus 는 istio 를 설치하면 같이 설치되는 프로그램이다.
S3 는 minio 를 셋팅하였다.
> hal config canary enable
> hal config canary prometheus enable
> hal config canary prometheus account add my-prometheus --base-url http://a83f0e6aa3ee611e9a56802910c21b39-1872812420.ap-> northeast-2.elb.amazonaws.com:9090
> hal config canary aws enable
> MINIO_ACCESS_KEY=AKIAJxxx
> MINIO_SECRET_KEY=QfvochKlxxxxx
> echo $MINIO_SECRET_KEY | \
hal config canary aws account add my-s3 --bucket spin-bucket --endpoint \
http://minio:9000 --access-key-id $MINIO_ACCESS_KEY \
--secret-access-key
> hal config canary aws edit --s3-enabled=true
> hal config canary edit --default-metrics-store prometheus
> hal config canary edit --default-metrics-account my-prometheus
> hal config canary edit --default-storage-account my-s3
# 최종 변경사항 반영
> hal deploy apply
위와같이 셋팅 후 배포시 정상적으로 spin-kayenta pod 가 생기는 것을 확인 할 수있었다.
또한 Config 항목에 Canary 가 생성되었다.
현재 default namespace 에 istio 가 auto injection 이 되어있어서,
위 화면에서 설명한 injector 에서 curl 명령어는 정상적으로 작동을 안 한다.
istio 로 pod 가 배포되면 컨테이너가 두개이상이 되기때문에,
컨테이너 명을 지정해서 curl 을 날려야 하는 것 같다.
kubectl -n default run injector --image=alpine -- \
/bin/sh -c "apk add --no-cache --yes curl; \
while true; do curl -sS --max-time 3 \
http://sampleapp:8080/; done"
그리하여 다른 네임스페이스에 설치하였음.
kubectl -n spinnaker run injector --image=alpine -- \
/bin/sh -c "apk add --no-cache --yes curl; \
while true; do curl -sS --max-time 3 \
http://sampleapp.default.svc.cluster.local:8080/; done"
injector 를 돌리지 않으면 호출되는 값이 없기때문에 successRate 값을 75 아래로 줘도 Pass 로 값이 나와버린다.
위의 prometheus 화면을 보면 알수있듯이
카나리 진행중에 canary, baseline 의 pod 를 생성하여서
해당 서비스를 호출하였을때 이 두개의 pod 로 연결을 하여 score 를 측정하고,
카나리로 지정해 놓은 시간이 지났을때 결과 값을 내어놓고, 해당 pod 는 삭제 된다.
우선 카나리 파이프 라인을 실행하기 전에 base deploy 를 먼저 실행하여야 한다.
카나리 파이프 라인을 분석해보면
Deploy Baseline 은 기존에 돌아가고있는 (version=prod) 의 successRate 값을
env 에서 가져와서 하나의 pod 를 생성한다.
Deploy Canary 는 카나리 파이프 라인 시작시 입력받은 successRate 값을 받아서 pod 를 생성한다.
기존에 4개의 sampleapp pod 에 데이터가 전송되었다면, 카나리 파이프라인이 실행되면서 총 6개의 pod 에
실 데이터가 나누어져서 호출된다.
프로메테우스 화면에서 보여지는 y 축은 에러율인데..(responce_500 / (responce_500+responce_200) * 100)
카나리 분석의 통과기준은
Spinnaker에서 자동화된 카나리아 분석은 여러 측정항목에서 통계 테스트를 실행하고 점수를 출력합니다. 이 점수 범위는 0~100 사이이며, 기준과 카나리아 사이의 비교를 통과 또는 실패한 측정항목 수를 나타냅니다. 각 그룹에 대해 서로 다른 가중치를 사용해서 여러 그룹에 측정항목을 배치하면 점수가 달라질 수 있습니다. 분석 점수에 따라 배포를 진행할지 여부를 결정할 수 있습니다. 이 가이드에서와 같이 단일 측정항목을 사용할 경우 점수는 0(실패) 또는 100(통과)만 가능합니다.
출처 : https://cloud.google.com/solutions/automated-canary-analysis-kubernetes-engine-spinnaker
위의 이미지 처럼 카나리가 분석 완료된 후에, 더 높은 successRate (90) 값을 받아서 새롭게 pod 들이 배포가 되었다.
최초 sampleapp 을 successRate : 70 으로 주고 배포하였고,
두번째로 successRate : 60 으로 카나리 파이프라인을 실행하니 분석실패하면서 파이프라인이 죽어버렸다.
세번째로 successRate : 90 으로 카나리 파이프라인을 실행하니 분석성공과 동시에 successRate : 90으로
prod pod 들이 배포가 되었다.
이 상태에서 successRate : 80 을 주어서 카나리 파이프라인을 실행시키면 어떻게 될지 테스트를 해보았다.
이런생각을 하게 된 이유는 Marginal(한계): 75 , Pass(통과): 95 를 주었는데
이 값이 영향을 미치는지 확인 하려는 이유이다.
결과적으로는 실패하였다.
그리고 파이프 라인이 중간에 죽어버리면서 새로 생긴 pod 들을 delete 못하는 문제가 발생하였다.
이를 해결하기 위해서는 스테이지가 실패해도 다음으로 넘어가는 설정을 해줘야 한다.
이번 실험은 최초 sampleapp 을 successRate : 40 으로 주고 배포한 후에
카나리 파이프라인을 successRate : 60 으로 실행을 해 보는 것이다.
역시나 Marginal(한계): 75 , Pass(통과): 95 값이 영향을 미치는지 테스트를 하기 위함이다.
결과를 보면 성공 하였다.
통과기준은 측정치가 1개일때는 기존값보다 높으면 성공으로 치는 것을 확인 할 수 있었다.
카나리 분석의 통과 기준은 canary config 에서 작성하였던 값을 따른다.
이미지에서 보듯이 rate_requests 로 나오는 값이 increase 하였을때 실패로 친다는 의미이다.
프로메테우스에서 rate_requests{app="sampleapp"} 값으로 조회를 하였듯이
y 축이 에러율이기 때문에 에러율이 증가하면 분석이 실패로 떨어진다.
스피니커 site 에서 Marginal과 Pass 에 대한 설명이 있는데 그것은 아래와 같다.
Marginal(한계) : If a canary run has a score below than this threshold, then the whole canary fails.
Pass(통과): The last canary run of the analysis must score higher than this threshold for the whole analysis to be considered successful. Otherwise it fails.
결과적으로 1개의 측정항목은 0점 or 100점이 나오기 때문에 두개의 설정값이 크게 의미가 없어진다.
참고 : https://www.spinnaker.io/guides/user/canary/best-practices/