쿠버네티스 인 액션 책 내용 요약 + 제 생각을 녹여냈습니다.

버전 업데이트

우리는 파드를 통해 어플리케이션을 배포한다. 배포 후에 새로운 버전으로 업그레이드하고 싶으면 현재 파드를 죽이고 새로운 이미지로 교체 후에 새로운 파드를 띄우거나, 새로운 버전의 파드를 먼저 같이 띄운 후 기존 파드를 죽이는 방법으로 해야한다.

2가지 방법은 각각 장단점이 있다.

1. 기존 파드를 죽이고 새로운 파드 배포

   짧은 시간 동안의 다운타임이 발생. 짧은 다운타임을 허용할 수 있다면 가장 단순한 방법

2. 새로운 파드 먼저 배포 후 기존 파드 삭제

   다운타임 없이 새로운 버전으로 업그레이드 할 수 있음. 하지만 디비 스키마가 변동됐을 때 기존 데이터를 오염시킬 우려가 있음. 그리고 짧은 시간에 파드가 2배가 되므로 리소스도 더 필요함.

디플로이먼트를 이용한 버전 업데이트

쿠버네티스에서 디플로이먼트 리소스를 활용하여 위의 2가지 버전 업그레이드 방법을 쉽게 이용할 수 있다.

Recreate

기존 파드를 전부 삭제한 후 새로운 파드를 생성한다. 앞서 말했듯이 짧은 다운타임이 발생한다.

RollingUpdate (default)

새로운 파드가 하나 생성되면 기존 파드 하나만 죽이고, 또 새로운 파드를 띄우면 기존 파드 하나 더 죽이는 방식으로 점진적으로 업데이트하는 한다. 다른 버전이 동시에 실행될 수 있는 어플리케이션의 경우에만 사용해야 한다.

디플로이먼트는 파드 이미지만 변경하면 자동으로 업데이트 전략에 따라 업데이트를 수행해준다. 이는 예전에 레플리카컨트롤러나 레플리카셋을 직접 다룰 때보다 훨씬 간결하고 안전한 방법이다.

Revision History

디플리오먼트로 업데이트하면 이전에 업데이트 했던 기록이 자동으로 남아있다. 즉 예전 레플리카 셋 리소스들도 계속 남아있어서, 이전 버전으로 롤백할 수 있게 된다.

MaxSurge와 MaxUnavailable

rollingUpdate의 속성으로, 업데이트 중 동시에 실행될 수 있는 파드 개수, 사용할 수 없는 파드의 개수 등을 지정하는 속성이다.

maxSurge

동시에 실행될 수 있는 파드 수를 정한다. 25%를 기본값으로 가진다. 동시에 실행될 수 있는 파드가 최대로 desired 개수에서 25% 추가한 만큼까지 가능하다. 만약 레플리카 수가 3일 경우 25%의 반올림해서 4개까지 업데이트 과정에서 허용된다.

maxUnavailable

사용할 수 없는 파드의 최대 개수를 정한다. 똑같이 25%를 기본값으로 가지며, 최소 75%의 파드 개수가 사용가능한 상태로 유지되어 있어야 한다. 레플리카 수가 3이면 내림하여 0이 되므로, 사용할 수 없는 파드 개수가 최대 0개이기 때문에 하나도 허용하지 않게 된다.

MinReadySeconds

새로운 버전이 버그가 있을 경우에 유용한 속성이다. 새로운 파드는 minReadySeconds 동안 정상상태를 유지해야 롤아웃 프로세스가 다음 동작을 이어나간다. 만약 그렇지 않다면 롤아웃 프로세스는 그 상태에서 멈추고 새로운 파드가 정상 동작할 때까지 업데이트를 멈춘다.

하지만 단순히 minReadySeconds 속성만 설정한다고 되는 것이 아니다. 파드가 정상상태임을 판단해야 하기 때문에 파드에 readiness probe가 적절하게 설정되어 있어야 한다. 만약 실패한다면 해당 파드는 서비스에서도 제외되고, 업데이트도 중단되고, 만약 maxUnavailable 값도 0이라면 기존 파드도 삭제하지 않게 된다.