롤아웃
레플리카셋을 새로 만들어 레플리카 수를 지정된 숫자만큼 늘린 후 기존 레플리카의 레프릴카 수를 0으로 낮추는 방식
주의점
디플로이먼트 정의가 변경된다고 무조건 롤아웃이 일어나지는 않음. 파드의 정의가 변경될 때만 발생한다.
리비전
디플로이먼트의 버전 기록을 의미. 디플로이먼트가 새 버전으로 롤아웃될 때마다 리비전 번호가 증가하며, 이를 통해 특정 리비전으로 롤백할 수 있음
롤백 명령
kubectl rollout undo deploy/web --to-revision=2
컨피그맵과 시크릿 관련 주의점
1. 설정을 가변적인 요소로 보고 릴리스에 컨피그맵 수정을 포함하는 방법
컨피그맵 YAML 파일의 수정이 일어나도 이름은 바뀌지 않으므로 디플로이먼트 YAML이 수정되지는 않음.
=> 이 방법은 롤아웃 기록이 남지 않아 롤백이 불가능
2. 컨피그맵/시크릿을 불변적 요소로 간주하는 방법
즉 YAML 파일을 새로 만들고 이름도 다르게 해서 디플로이먼트의 참조하는 부분 이름도 같이 수정함. 즉 아예 그냥 다른 파일.
=> 이 방법은 롤백이 가능
롤링 업데이트의 속도조절
- maxUnavailable : 업데이트 중에 동시에 사용할 수 없는 파드의 최대 수(숫자나 백분율로 지정)
- maxSurge: 데이트 중에 동시에 추가로 생성할 수 있는 파드의 최대 수(숫자나 백분율로 지정)
예시) 현재 파드 수 4개, maxUnavailable=25%
업데이트가 시작되면, Kubernetes는 기존 파드 1개를 종료하고, 새 버전의 파드를 배포합니다. 이때 1개의 파드가 비활성화되기 때문에, 클러스터는 최대 3개의 파드만 동작합니다. 새 파드가 정상적으로 실행되면 다음 파드가 교체됩니다. 이렇게 한 번에 최대 1개의 파드만 다운되도록 롤링 업데이트가 진행됩니다.
예시) 현재 파드 수 4개, maxSurge: 2개
업데이트가 시작되면, Kubernetes는 기존 4개의 파드 외에 추가로 2개의 파드를 더 생성하여, 새로운 버전의 파드가 총 6개가 됩니다. 새 파드들이 정상적으로 실행되면, 이후 기존 파드 2개를 종료하여 다시 총 파드 수를 4개로 맞춥니다. 이 설정을 통해 서비스의 가용성을 극대화하면서도 빠르게 업데이트를 진행할 수 있습니다.
예시) 현재 파드 수 10개, maxUnavailable=2개, maxSurge: 3개
업데이트가 시작되면, Kubernetes는 먼저 최대 3개의 추가 파드를 생성해 새로운 버전으로 배포합니다. 이로 인해 잠시 동안 파드 수는 13개로 늘어납니다. 새로운 파드들이 준비되면, Kubernetes는 기존 파드 2개를 종료하여 다시 11개로 줄입니다. 이후 프로세스가 반복되어 결국 10개의 새로운 파드만 남게 됩니다. 이 조합은 서비스의 중단 없이 신속한 업데이트를 가능하게 합니다.
기존 파드 종료를 먼저할지, 새 파드 생성을 먼저할지는 설정에 따라 유연하게 조절된다고 한다.
- 가용성을 최우선으로 하는 경우: maxSurge를 사용하여 새로운 파드를 먼저 생성합니다. 이 방법은 서비스의 중단을 피하고 새로운 버전의 파드가 안정적으로 실행되는 것을 확인한 후, 기존 파드를 종료하는 방식을 취합니다.
- 리소스 절약 또는 빠른 업데이트를 원하는 경우: maxUnavailable를 사용하여 기존 파드를 먼저 종료하고, 그 자리에 새 파드를 배치합니다. 이 방법은 업데이트 속도는 빠르지만, 서비스 가용성에 약간의 영향을 줄 수 있습니다.
댓글