[Kubernetes Best Practice] 6. 버전, 릴리스, 롤아웃

이 글은 Kubernetes Best Practice를 읽고 개인적으로 중요하다고 생각하는 부분과 잘 모르는 부분에 대해 공부한 내용을 작성한 글입니다. 모든 내용은 책에 포함되어 있는 내용을 기반으로 작성하였으며 자세한 내용이 궁금하신 분들은 책을 구매해서 읽는 것을 권장드립니다. 

최근 서비스 메시에 대해 알아보거나 쿠버네티스를 사용하고 공부하면서 가장 많이 들었던 생각은 이 방법이 최선인가? 라는 생각이었습니다. 이에 대한 궁금증을 해결하는데 도움이 될만한 책을 발견해서 읽어보고자 합니다.

---

 

시스템의 규모가 커질수록 업그레이드, 버전 관리, 변경에 대해 자동화 프로세스를 구축하는데 많은 어려움이 따릅니다. 이를 위해 쿠버네티스, 하시코프 노마드와 같은 오케스트레이터는 런타임에 자동화 관련 컴포넌트를 제공함으로써 어플리케이션의 버전 관리, 릴리스, 배포에 대한 복잡도를 낮추는 역할을 수행합니다. 이번 글에서는 버전, 릴리스, 배포에 대한 모범 사례에 대하여 다루게 됩니다.

---

버전

일반적으로 버전 표기에는 시멘틱 버전을 사용합니다. 시멘틱 버전은 (Major).(Minor).(Patch) 형식으로 표기합니다. 패치 버전은 사소한 변경사항 마다 증가하게 되고, 마이너 버전은 버전의 변경이 발생했지만 이전 버전과 하위 호환이 가능한 변경을 의미합니다. 메이저 버전은 대규모의 코드 변경으로 메이저 버전 사이의 API는 호환되지 않는 경우가 많습니다.

---

릴리스

 쿠버네티스는 릴리스를 관리하기 위한 컨트롤러가 따로 존재하지 않습니다. 일반적으로 릴리스 정보를 Deployment metadata.labels, pod.spec.template.metadata.label 필드에 넣음으로써 관리를 수행합니다. 릴리스 정보를 넣는 시점은 CD를 통해 변경 사항을 업데이트하는 방법에 따라 다양한 영항을 끼칠 수 있다는 점을 명심해야 합니다. 이를 좀 더 편리하게 수행하기 위해 Helm을 사용합니다. Helm은 릴리스 내역을 추적해주며 대부분의 CD 툴은 Helm과 통합하여 릴리스 서비스를 제공해줍니다.

릴리스 이름은 서비스 메시같은 세밀한 라우팅을 설정할 때 운영 및 관리의 용이성을 위해 약속된 이름을 사용해야 합니다. ex) stable, canary

---

롤아웃

Deployment가 등장하기 이전의 쿠버네티스에서는 ReplicaSet을 업데이트 하기위한 방법은 CLI를 통한 방법밖에 없었고, 이는 쿠버네티스가 지향하는 선언전 패러다임에 부합하지 않았습니다. 이후 등장한 Deployment Controller는 spec.template의 변경 사항을 기반으로 선언된 상태를 읽어 변경이 발생하며 업데이트를 수행하게 됩니다. 

Deployment가 업데이트를 수행하는 방법은 RollingUpdate와 recreate 방법이 존재합니다. RollingUpdate는 서비스의 중단없이 업데이트를 수행하고자 할 때 사용되며, recreate는 모든 Pod을 중단하더라도 서비스에 영향을 받지 않는 특정 워크로드에 사용합니다.

---

버전, 릴리스, 롤아웃 모범 사례

• 컨테이너 이미지와 배포 버전은 독립적인 라이프사이클을 가진다는 점을 유의하자. 아래 예시와 같이 컨테이너 이미지의 버전은 1.1.6이지만 Pod의 명세는 1.1.8을 따르고 있습니다. 이는 ConfigMap, Secret과 같은 변경으로 인해 pod 명세가 변경되었음을 의미합니다. 또한 전체 배포버전은 1.3.5로 전체 어플리케이션에 대한 변경 사항이 존재함을 의미합니다.

apiVersion: apps/v1
kind: Deployment
metadata: 
    name: server-deploy
    appVersion: 1.3.5
    env: prod
    release: stable
    release number: 1234567
spec:
    selector:
    	matchLabels:
            app: server
            appVersion: 1.1.8
            env: prod
    template:
    	metadata:
            labels:
            	app: server
                appVersion: 1.1.8
                env: prod
        spec:
            containers:
            - name: web-server
              image: sphong0417/web-server:v1.1.6
...

 

• 릴리스 이름 및 번호를 통해 CI/CD 릴리스를 추적해야 합니다. 위의 예시와 같이 metadata 필드에 CI/CD의 실제 릴리스 정보와 연관되는 레이블을 추가하여 CI/CD 과정 추적 및 롤백을 식별하기 용이해집니다.

• Helm을 사용한다면 Helm 차트에 포함되지 않은 서비스들도 함께 업데이트 및 롤백이 될 수 있도록 고려해야합니다. 예를 들면 Helm Chart에 웹 어플리케이션을 위한 메니페스트가 존재하고 이를 업데이트 및 롤백 할 때 Helm 외부의 DB 백업이 필요하다면 이 처리를 함께 수행될 수 있도록 설정해줘야 합니다. Helm은 lifecycle Hook이라는 기능을 통해 이런 작업을 수행할 수 있도록 해줍니다.