Kubernetes - Deployment

이번에는 kubernetes에서 운영중인 서비스를 업데이트하여 재배포 할 시 사용되는 기능들에 대해 알아보겠다.

Deployment Controller는 크게 4가지로 구성할 수 있다.

• ReCreate
• Rolling Update
• Blue / Green
• Canary

---

ReCreate

ReCreate는 일시적인 서비스 정지가 가능한 곳에서 사용된다.

ReCreate로 업데이트를 수행할 경우 기존 사용되던 Pod를 삭제하고 새로운 Pod를 만들어 Service에 연결하게 되는데,

이 때 기존의 Pod를 삭제하면서 잠깐의 Downtime이 발생하게 된다.

따라서 이러한 서비스 중단을 감안할 수 있는 곳에서 쓰일 수 있다.

참고로 revisionHistoryLimit를 이용하여 limit 수 만큼의 업데이트 이전 ReplicaSet을 보존하고 롤백할 수 있다.

---

Rolling Update

Rolling Update의 경우 기본적으로 설정되는 deployment 옵션이다.

Deployment는 업데이트를 위해 기존의 Pod를 삭제하지 않고 새로운 Pod 하나를 먼저 만들어주게 된다.

두 버전의 Pod가 모두 서비스되고 있기 때문에 누군가는 기존 서비스에, 누군가는 새로운 서비스에 접근하게 된다.

단계적으로 Pod를 하나씩 늘려나가며 새로운 Pod를 만든 후 기존의 Pod를 삭제하는 방식으로 사용한다.

다만 배포 중간중간에 Pod가 생성되면서 추가적인 리소스를 요구하지만 downtime이 없다는 이점이 있다.

---

Blue / Green

Blue/Green은 Replicas를 관리하는 Controller를 통해서 관리하는 방식이다.

Controller를 통해 Pod를 생성하면 Label을 이용해서 Service에 연결되는데, 이 Label을 바꿔줌으로써 업데이트를 수행하게 된다.

서비스가 운영되는 동안 새로운 Controller를 만들어주며 서비스의 Label을 새로 만든 Controller의 Pod와 연결해주면 된다.

Label만 바꿔주면 되기 때문에 업데이트와 롤백이 편하다는 장점이 있다.

다만 한 번에 전체 Pod를 생성하기 때문에 리소스 요구량이 두 배가 된다는 단점이 있다.

---

Canary

canary의 경우 기존의 Pod와 새로운 Pod를 별개의 서비스로 나누어놓고 Ingress Controller를 통해 유입되는 트래픽을 UrlPath를 나누어 분산시킨다.

분산된 path를 통해 트래픽을 전송하며 이상이 없으면 기존의 Pod를 삭제하고 새로운 Pod의 UrlPath를 기존의 Pod로 변경한다.

Canary 또한 downtime은 존재하지 않지만 리소스 요구량은 테스트할 Pod의 수 혹은 테스트용 Pod를 얼마나 생성해두고 기존의 Pod를 얼마나 삭제하느냐에 따라 유동적이게 된다.