쿠버네티스 Release note 확인 및 업그레이드 버전 결정

쿠버네티스는 최대 하나의 마이너 버전의 업그레이드만 허용한다. (ex. 1.25→ 1.26)

공식 문서의 change log를 확인하고 변경 사항으로 인한 오류는 없을지 확인해야 한다.

쿠버네티스 공식 문서에는 각 마이너 버전마다 업그레이드 문서가 존재하므로 확인한다.

업그레이드 버전에서 제거된 API를 확인하고 지원하지 않는 API를 migration한다.

서비스 버전 호환성 확인

쿠버네티스 컴포넌트와 통신하는 서비스들의 버전 호환성을 확인한다.

현재 서비스 버전 목록: DevOps 서비스 버전

1. Istio 버전 호환성 확인

   문서를 통해 버전 호환성을 확인하고 현재 쿠버네티스 버전과 호환되는 만큼 먼저 업그레이드를 진행해야 한다.

2. OpenEBS 버전 호환성 확인

   문서를 통해 OpenEBS의 버전 호환성을 확인한다.

3. Containerd 버전 호환성 확인

   문서를 통해 쿠버네티스와 외부 종속성을 가진 Containerd의 버전 호환성을 확인한다.

4. Calico 버전 호환성 확인

   문서를 통해 호환성을 확인하고 만약 Calico의 버전이 업그레이드 버전과 호환성이 맞지 않으면 공식 문서를 따라 쿠버네티스 업그레이드 중간에 업그레이드해야 한다.

업그레이드 순서 결정

업그레이드할 서비스들을 확인하였으면 업그레이드 순서를 결정한다.

서비스의 업그레이드는 high level에서 low level로 진행한다.

• 순서 결정 예시
  1. application level
     1. Istio
  2. platform level
     1. OpenEBS
     2. Kubernetes control plane node
     3. Calico
     4. kubernetes worker node
  3. OS level
     1. Containerd

업그레이드 계획 수립

각 서비스의 업그레이드 계획을 수립한다.

• 업그레이드 규칙
  • 업그레이드는 항상 공식 문서를 따른다.
  • Human error를 줄이기 위해 모든 업그레이드 명령어는 미리 작성하여 준비하고 명령어의 복사 붙여 넣기를 통해 진행한다.
  • kubelet이나 containerd 서비스를 중지할 때는 반드시 node를 drain하고 진행하여야 한다.
  • 업그레이드는 클러스터의 down time을 최소화하여 진행한다.
  • 클러스터는 Stage → Production 순서로 진행한다.
  • apt를 이용해 설치한 경우 자동 업그레이드 방지를 위해 apt-mark로 버전을 홀드시킨다.
  • 업그레이드가 잘못됐을 시를 고려하여 Rollback 계획을 세운다.
  • 업그레이드 과정은 모두 백로그로 남기고 이슈사항은 따로 기록한다.
  • 업그레이드 후의 오류 확인을 위해 항상 테스트를 거친다.
  • 업그레이드 후 manifest는 gitlab에 최신화한다.
• 테스트 규칙
  • 모니터링은 Kiali와 k8s dashboard를 통해 진행한다.
  • 공통 체크리스트
    • 서비스들의 접속 가능 여부를 확인한다.
    • 새로운 워크로드를 생성해 정상 작동 여부를 확인한다.