티스토리 뷰

0. Deployment란

  • 현재 한 서비스가 운영중인데 ,이 서비스를 업데이트 해야되서 재배포를 해야될 때 도움을 주는 오브젝트
  • ReCreate: 디플로이먼트를 만들면 v1의 pod들이 만드러짐. pod하나당 하나씩 자원이 사용된다고 가정을 하면, 업그레이드를 할 때 디플로이먼트는 먼저 pod를 삭제한다. 그렇게 되면 서비스에 대한 다운타임이 발생하고 자원사용량도 없어진다. 다음으로 v2에 대한 pod 2개를 만든다.
    • 일시적인 정지가 가능할 때만 사용되는 방법
  • Rolling Upate: 디플로이먼트는 먼저 v2에 pod를 하나 만듬. 자원사용량이 그만큼 늘어남. 이 상태에서는 누군가는 v1에 접속이되고, 누군가는 v2에 접속이 됨. 그리고나서 v1을 삭제하면 사용자들은 v2에만 접속을 하게 됨
    • 중간에 추가적인 자원을 요구하지만, 다운타임이 없다는 장점이 있음
  • Blue/Green: 디플로이먼트 자체의 기능은 아니고, 디플로이먼트를 이용해서 할 수도 있지만 replicaSet과 같은 controller를 이용해서 할 수 있음. controller의 pod :v1이 Service에 있는 ver:v1과 연결되어 운영이 되고 있는 상태에서, 컨트롤러를 하나 더 만들어서(pod:v2 - 이 때 자원 사용량은 2배) 서비스에 있는 라벨만 v2로 변경하고 기존 pod:v1과의 관계를 끊어버리기
    • v2에 문제가 발생하면 서비스의 라벨만 v1으로 바꾸면 되기 때문에 문제시 롤백이 쉽다는 장점
    • 문제가 없으면 v1삭제
  • Canary: 컨트롤러의 pod:v1을 서비스의 tp:app 라벨과 연결함. 테스트용으로 컨트롤러(v2, ty:app)를 만들 때, replicas를 1로해서 서비스와 연결시킴. 그러면 서비스에서 일부는 v2버전으로 접근이 가능해짐. (불특정 다수에 대한 테스트를 할 때 사용하는 방식)
    • 문제가 발생하면 v2의 replicas만 0으로 하면 됨
    • 만약 서비스를 하나 더 생성해서 v1은 기존 서비스(v1)에 연결하고 새로 만든 컨트롤러(v2)는 서비스(v2)에 연결함. 그리고 Ingress Controller를 만들어서 서비스의 url에 따라 연결해주면 (/app, /v2/app) url 에 따라서 테스트 하는 대상을 정할 수 있음

1.ReCreate

  • RecreaterevisionHistoryLimit

2.Rolling Update (default)

  • RollingUpdateminReadySeconds
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2025/01   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
글 보관함