Spinnaker on Kubernetes #2

4 분 소요

Spinnaker on Kubernetes

이전 포스팅 Spinnaker on Kubernetes #1에서 검토할때는 많이 개념을 이해하기 어려웠던것 같지만 어느정도 시간이 지났고 또 몇일 후에 발표도 있어서 다른 이야기를 해보고자 한다.

지난 포스팅에 대충 집고 넘어간 용어들에 대한 정리를 다시 하고 기본적인 사상들을 정리해보고자 한다. 허접한 플랫폼 엔지니어 생각이니 언제든 다른 의견을 환영하는 바이다.

What is spinnaker? (+History)

최근 트렌드인 멀티 클라우드를 지향하는 오픈소스 플랫폼이다.
2014년 Netflix의 Asgard로 시작되어 2015년에 오픈소스화 되었다.
빠른 속도와 신뢰도있는 소프트웨어 릴리즈를 위해 만들어졌으며 대부분의 메이저 클라우드 프로바이더들을 지원한다.(AWS,GCP,Azure,openstack..)
현재 Netflix, Google, MS, Veritas등이 Contribution을 하고 있다.

왜 Spinnaker를 써야하지?

여러가지 이유가 있겠지만

  • Multi-Cloud용 Continuous Delivery/Deployment Platform 으로 대체가 가능
  • 다양한 pipeline 형태로 배포가 가능하고 Rollback이 쉬움
  • 빠른 배포가 가능하고 여러번 배포가 용이함
  • 유연한 pipeline management system을 가지고 있음
  • 다양한 배포전략을 가진다(Blue-Green, Rolling Red/Black, Canary)
  • community 활동 활발 (github, slack) - 답은 잘 안해줌 ㅠㅠ
  • VM과 Container 동시에 통합관리 가능
  • CI통합 용이(Jenkins)
  • CLI를 통한 설치 및 관리(halyard)
  • VM, Helm Packaging 가능
  • RBAC 지원
  • Notification - Email, Slack, Hipchat등
  • Safe Deployment - Judgement (승인기능)
  • Chaos Monkey Built-in

이정도면 무조건 써야하지 않을까?

Jenkins vs Spinnaker

Jenkins Spinnaker
강력한 빌드서버 클라우드 자원의 1차 연동
완전한 deployment tool이 아님 vm & deployments 안에 빌드되어 있음
스크립팅이 많이 필요함 별도의 스크립팅이 많이 필요없음
기능들이 모두 플러그인 형태 CI tool이 아님(CI tools이 백엔드로)

Kubernetes vs Spinnaker

Kubernetes Spinnaker
리소스 사용 제한 정의한 퍼센트로 rollout
slow rollout 각 단계별 검증 가능
High rollback cost Fast rollbacks
Linear rollouts resource 사용량이 큼
검증단계가 없음  

Deploy Pipeline

Spinnaker를 사용할때 기본적으로 아래와 같은 파이프라인으로 구성한다.
수동으로 UI나 API로 트리거링할수 있고, 자동으로 Jenkins 등과 트리거 연동하여 빌드완료시 배포되도록 할수 있다.

spinnaker-pipeline

Deployment Strategies

Spinnaker에서의 배포전략은 다음과 같이 제공된다.

deployment-strategies

Red / Black (same as Blue / Green)

  • 동일한 양의 instance로 이루어진 새로운 Server Group을 생성한다
  • 신규 Server Group이 정상상태가 되면 LB는 신규 Server Group에 트래픽을 분산한다.

Rolling red/black

  • 이전과 동일하지만 인스턴스별 또는 그룹별로 rolling

Canary

  • 가장 작은 개수의 인스턴스를 교체시키고
  • 새로운 버전으로 트래픽을 분산시킨다 (1~5프로)
  • 새로운 버전에 이슈가 없을때까지 테스트를 진행하고
  • 특정시간까지 이슈가 없으면 배포를 늘려간다.

용어정리 2탄

이전 post에서 정리한걸 다시 복기하고 추가적인 내용을들 적어봤다.

사용하면서 혼돈이 많이 생기는 부분이다 이게 GCE나 EC2를 쓰면 용어 매칭이 쉬운데 k8s를 위한 별도의 메뉴가 아닌 기능을 통합하다보니 용어가 조금 혼동스럽게 구성이 되었다.
특히 Load Balancer 부분은 Service로 매핑되고 퍼블릭 k8s에서 제공하는 Type LoadBalancer는 미지원한다.
그리고 모든 Resource들은 Deploy, Delete, Scale, Rollout(Undo, Pause, Resume)을 지원하며 Versioning이 지원된다. Versioning은 여기에 설명된 대로 strategy.spinnaker.io/versioned annotation을 통해 manifest별로 재정의가 가능하다.

Spinnaker Kubernetes 비고
Server Group Workloads CRD의 경우 별도 Build
Clusters Logical Server Group  
Load Balancer Services LoadBalancer(k8s) 미지원
Firewall NetworkPolicies  

Application Management

Spinnaker에서 Application 이란 배포하려는 서비스를 나타내는 구조라 생각하면 된다.

  • pipeline
  • Clusters, Server Group의 집합이며, firewall과 loadbalancer를 포함한다.
  • Canary Config

Cluster

Kubernetes의 Cluster가 아니라 Spinnaker에서 Server Group의 논리적인 그룹

Server Group

기본자원인 서버그룹은 배포할수 있는 artifacts(vm image, docker image, source)와 인스턴스(pod) 수, Auto-Scaling, metadata 등 기본 구성등을 가지고 있다.
서버그룹은 LoadBalacer나 Firewall 도 선택적으로 연결되고, vm이나 pod 형태로 배포된 application의 집합체라 볼수 있다.

Cloud Provider

  • IaaS - AWS, GCP, Azure, Oracle, Openstack
  • PaaS - Google App Engine
  • Orchestrator - K8s, DC/OS
  • Docker v2 Registry

Account

Cloud Provider에 인증하기 위한 Spinnaker에서만 사용하는 Account Name

Pipeline

Pipeline은 주요 배포 관리도구로 사용된다. Stage라고하는 일련의 Action으로 구성되며 파이프라인을 따라 Stage간 매개변수 전달이 가능하다.
수동으로 시작하거나, Jenkins 작업완료, Docker Registry 신규 Docker 이미지, Cron일정 또는 다른 Stage와 같은 이벤트에 의해 자동으로 트리거링되도록 구성할수 있다.
Pipeline 실행중에(시작/완료/실패) mail, slack, hipchat(사라짐)을 통해 Alert가 가능하다.

pipeline

Stage (atomic building block)

Pipeline이 수행할 동작을 말한다.
Deploy, Resize, Disable, Manual Judgement 등을 수행할수 있다.

stage

  • Stage - Multiple steps
  • Step - 진행되기전에 교정/폴링이 필요한 tasks
  • Task - 특정 Cloud Platform으로 동시에 여러 API호출
  • Operation - 단위 API

정리

용어나 개념은 어느정도 정리된듯 하고 다음 포스팅에서는 실제 multi cluster 환경에서 deploy하고 pipeline을 사용하는 내용을 적어볼 예정이다.

댓글남기기