LabHub
배우기 러닝패스 코스

쿠버네티스 배포판 — 직접 세운다 · 업그레이드와 판 차이 · 실습

stable 채널을 따랐다면 마이너 두 칸을 건너뛰었다

LabHub 에서 이어서 보기

이 실습은 진짜 k3s 에서 돕니다

VM 안에 k3s v1.34.11+k3s1 한 대가 떠 있습니다. 이 클러스터를 1.35 로 한 칸 올리고, 올리기 전의 준비와 올린 뒤의 대조를 실제로 해 봅니다. 처음 뜨는 데 2분 안팎이 걸립니다. 작업 디렉터리는 /root/upgrade 입니다.

목표

k3s 를 마이너 판 한 칸 업그레이드하면서 출발 판 기록, 사용 중단 API 점검, 백업, drain 판단을 차례로 하고, 업그레이드 뒤 같은 노드와 같은 워크로드가 살아 있는지 UID 로 증명합니다. 마지막으로 다음 한 칸을 system-upgrade-controller Plan 으로 적습니다.

왜 중요한가

설치 스크립트를 다시 돌리면 업그레이드가 끝나기 때문에, 판을 고르는 일이 가볍게 여겨집니다. 그런데 채널(stable)은 지금 클러스터가 몇 판인지 모르고 최신 권장판으로 갑니다. 1.34 에서 stable 로 올리면 stable 이 1.36 인 날에는 마이너 두 칸을 건너뛰고, 쿠버네티스 skew 정책은 인스턴스가 하나뿐인 클러스터에서도 이것을 허용하지 않습니다. 건너뛰기를 막아 주는 도구는 없으니 사람이 판을 고정하고 한 칸씩 올려야 합니다.

그리고 "올라갔다" 는 증거가 되지 않습니다. 올리기 전에 판과 UID 를 적어 두지 않으면, 올린 뒤에 같은 클러스터가 같은 워크로드를 들고 올라왔는지 확인할 방법이 없습니다.

단계

1. API 서버 판·kubelet 판·노드 이름·노드 UID 를 /root/upgrade/before.json 에 저장하세요.
2. upg 네임스페이스에 Deployment web(nginx 1.27-alpine, 레플리카 2)과 PDB web(minAvailable 1)을 만들고 /root/upgrade/workload.json 에 UID 를 적으세요.
3. apiserver_requested_deprecated_apis 지표를 /root/upgrade/deprecated.txt 에 옮기고 removed_by_target= 을 적으세요.
4. SQLite DB 와 토큰을 /root/upgrade/backup/ 에 백업하고 /root/upgrade/backup.json 을 쓰세요.
5. drain 을 시도해 출력을 /root/upgrade/drain.txt 에 남기고, uncordon 한 뒤 decision= 줄을 붙이세요.
6. v1.35.8+k3s1 로 업그레이드하고 /root/upgrade/upgrade.json 을 쓰세요.
7. 업그레이드 뒤 상태와 skew 허용 범위를 /root/upgrade/after.json 에 적으세요.
8. Plan CRD 를 넣고 다음 한 칸을 고정한 Plan k3s-server-next/root/upgrade/plan.yaml 로 적용하세요.
9. /root/upgrade/report.md 에 다섯 줄과 설명을 쓰세요.

참고

단계 9개

  1. 출발 판을 먼저 적는다
  2. PDB 가 걸린 워크로드를 올린다
  3. 누가 아직 옛 API 를 부르나
  4. DB 와 토큰을 함께 백업한다
  5. drain 이 끝나지 않는다
  6. 마이너 한 칸만 올린다
  7. 같은 것이 올라갔는지 대조한다
  8. 다음 한 칸을 Plan 으로 쓴다
  9. stable 을 따랐다면 몇 칸이었나