업그레이드 할 때 고려해야할 점
쿠버네티스 버전 관리
- 쿠버네티스는 최대 한번에 3개씩 동시 지원함
- 업그레이드를 진행할 때는 Minor 버전을 한 단계 식만 진행이 가능하며 Patch 버전은 여러 단계를 업그레이드를 가능
업그레이드 시 고려해야할 점
- 쿠버네티스 버전을 업그레이드 하는 방법에는 기존 쿠버네티스를 최신 버전까지 업그레이드 하는 방법과 최신 버전으로 새 클러스터를 설치 후에 LB의 트래픽을 전환하는 방법이 있음
- 전자는 업그레이드 동안 리소스 제어가 불가능하기 때문에 master 노드를 여러 개 놔두어야하고 drain과 같은 기술을 사용하여 업그레이드 대상 노드의 pod를 옮긴 후 진행해야함 (개발 서버는 필수는 아니지만 운영 서버는 필수임)
- 후자는 트래픽만 옮기면 되지만 기존에 사용하던 DB나 storage는 이관 절차가 필요함
업그레이드 시 필요한 기술들 (기존 node가 있는 상태에서 그것을 업그레이드 할 때)
- 업그레이드 동안의 문제를 해결하기 위해서는 위와 같은 기술들이 필요함
- 새로 생성하는 것은 그냥 트래픽만 옮겨 주면 되기 때문에 위와 같은 과정이 필요 없음
워커 노드 추가
- worker 노드 구축 후 각 node에서 host를 연결해주고
- master node에서 토큰을 생성 후 worker 노드에 해당 토큰을 넣어서 연결해주면 됨
노드 스케줄링
업그레이드 시 노드 스케줄링에 대한 이해가 필요한 이유
- 해당 노드를 업그레이드 하기 위해서는 무중단을 이루기 위해 worker node를 비워줘야하는 데 그때 drain을 사용가능
- drain은 cordon과 no schedule로 작동이 됨 (후술할 예정)
- 아무 것도 모르고 그냥 drain 시 pod 이동이 안될 수도 있기에 traint, cordon 등 기반 기술에 대한 이해가 필요함
노드 스케줄링에 관한 간단한 명령어 정리
- pod를 원하는 node에 배치하기 위해서는 nodeSelector, nodeAffinity, nodeName의 속성을 이용하여 할 수 있음
- pod간 집중, 분산 배치를 위해서는 각각 podAffinity, podAntiAffinity가 필요함
- pod가 node에 생성되지 않도록 제한하기 위해서는 trains가 필요함
- 그에 파생으로 일시적으로 사용하기 위해 drain, cordon, uncordon이 존재함
- traints로 생성이 제한된 노드에 pod를 생성하기 위해서는 tolerations가 필요함
- 참고로 trains와 tolerations가 연결 되었다고 바로 해당 노드로 설치하는 게 아니라 그냥 허용만 해주는 것이기 때문에 nodeSelector 설정과 같은 것이 필요함
사용자 관점에서 Pod를 배치하는 방법
- 원하는 곳에 pod를 배치하기 위해서는 nodeSelector, nodeAffinity, podAffinity 등이 필요함
- 각 설정마다 required가 붙여져 있으면 무조건 해당 조건을 따라야하고 preferred는 선호(만약 불가능하다면 규칙을 깨고 만듦) 정도임
- 우선 순위는 규칙 매칭, 각 노드 별로 자원이 얼마나 남아있는 가임
- 얼마나 자원이 남아있는 가는 실시간 자원 점유율이 아니라 yaml 상에 기록된 점유율을 뜻함 (limit 등)
- nodeSelector와 podAntiAffinity(pod 분산 배치)는 많이 사용하나 nodeAffinity와 podAffinity는 사용 케이스가 적음
- 복잡도가 증가하기 때문에 필수적이지 않다면 사용하지 않는 것이 좋음
- 개인적으로 사용할 때는 nodeSelector면 충분함
운영자 관점에서 Node를 관리하는 방법
- traint를 설정하면 해당 node에 pod가 만들어지지 않게 해줌
- drain은 cordon + pod 이동이기에 끝나고 설정을 해주려면 uncordon을 해주어야 함
- Tolerations는 해당 traint에 허용하는 것
- Equal은 하나의 traint와 일치 하더라도 다른 traint와 일치하지 않다면 거부됨
- 허용을 하는 거지 우선 순위를 거기로 설정하는 것은 아니기 때문에 우선 순위를 생각한다면 nodeSelector와 같은 설정을 해주어야 함
- tolerationSeconds를 설정해주면 해당 일이 발생했을 때 설정한 시간 만큼 기다리는 설정
- pod를 생성할 때마다 비정상 작동 때 준비되지 않을 때 300초로 설정이 됨
- 만약 비정상 작동 시 빨리 pod를 옮기고 싶거나 원하지 않는 다면 미리 설정을 해주어야 함
쿠버네티스 업그레이드 때 고려해야할 점
개요
- 맨 처음에 말한 대로 위와 같은 지식들이 필요함
개발 환경에 업그레이드 테스트를 해보면서 확인해봐야할 것들
- 밑에 파란 색 업그레이드와 새로 설치에서 파란색으로 되어있는 것만 살펴 보면 됨
- 예를 들어 ETCD 데이터 확인 때는 새로 설치 한다면 그냥 옮겨주어야하기 때문에 업그레이드 때만 살펴보면 됨
- ETCD 데이터 확인 같은 경우 원래 ETCD는 자동으로 하위 호환성 유지를 해주기 때문에 문제는 없지만 그래도 확인 해주는 것이 좋음
- 무중단 서비스 확인의 경우 master node를 업그레이드 할 때 component가 잠시 멈추기 때문에 생각해보는 것이 좋음
- 순서는 위와 같음
- 추가로 쿠버네티스 업그레이드 할 때는 Addon, Component, Containerd 등이 모두 호환 되는 것이 다르기에 모두 들어가서 확인해봐야함
- minor 버전은 하나씩만 업그레이드가 가능하고 master와 worker 노드의 minor 버전이 2 이상 차이 나면 안됨
- 만약 모든 노드를 1.27에서 1.30으로 바꾸려면 master node를 1.27 -> 1.28 -> 1.29로 하고 worker node를 1.29로 바꾼 다음 master node를 1.30으로 바꾸고 worker node를 1.30으로 바꿔야함
- 참고로 기존 master node와 worker node가 있는 상태에서 업그레이드 하는 방식일때만 위와 같은 과정이 필요함 (새로 환경을 구축할 때는 그냥 새로 구축하고 트래픽만 옮기면 되기 때문에 위와 같은 과정이 필요가 없음)
출처: https://inf.run/wLXM7