Kubernetes Distributions — Build Them Yourself
Quiz: Upgrades and version skew
한국어 원문으로 표시합니다.
API 서버가 1.35 인 클러스터에서 skew 정책이 허용하는 가장 오래된 kubelet 마이너 판은?
- 1.34
- 1.33
- 1.32
- 1.31
k3s 1.34 클러스터를 stable 채널로 올리려는데 그날 stable 이 1.36 을 가리킨다. 어떻게 해야 하나?
- 1.35 로 판을 고정해 먼저 올리고, 그다음 1.36 으로 한 칸 더 올린다
- 노드가 한 대뿐이면 skew 가 생기지 않으므로 바로 1.36 으로 올린다
- 설치 스크립트가 중간 판을 알아서 거쳐 가므로 채널을 그대로 쓴다
- 에이전트 노드를 먼저 1.36 으로 올려 서버와의 차이를 줄인다
처음 설치 때 INSTALL_K3S_EXEC 로 --disable traefik 을 줬던 서버에서, 판만 바꿔 설치 스크립트를 다시 돌리면 어떻게 되나?
- 기존 서비스 파일의 인자를 읽어 그대로 이어 쓴다
- k3s 가 저장소에 기록한 옛 인자를 되살려 적용한다
- 판이 바뀌면 인자를 무시하고 모든 기본값을 끈다
- 다시 주지 않은 설치 인자는 사라져 traefik 이 되살아날 수 있다
노드가 한 대뿐인 클러스터에 레플리카 2개와 minAvailable 1 PDB 를 두고 drain 했다. 실측에서 무슨 일이 일어났나?
- PDB 가 첫 eviction 부터 막아 파드가 하나도 나가지 않는다
- 하나는 쫓겨났지만 대체 파드가 Pending 이라 두 번째 eviction 이 계속 거절됐다
- drain 이 PDB 를 무시하고 두 파드를 모두 지운 뒤 끝났다
- DaemonSet 이 아니라서 --ignore-daemonsets 없이도 바로 끝났다
apiserver_requested_deprecated_apis 지표에 removed_release="" 인 v1 endpoints 줄이 있다. 1.35 업그레이드에 대해 무엇을 뜻하나?
- 1.35 에서 제거되므로 업그레이드 전에 반드시 옮겨야 한다
- 지표가 아직 수집되지 않아 제거 판을 알 수 없다는 뜻이다
- 사용 중단은 되었지만 제거 일정이 없어 1.35 로 가는 데 걸리지 않는다
- 그 API 를 부른 요청이 모두 실패했다는 뜻이다
system-upgrade-controller 의 Plan CRD 에 version 도 channel 도 없는 Plan 을 적용했더니 성공했다. 여기서 얻을 교훈은?
- CRD 가 받아 줬으니 컨트롤러도 기본 판으로 올려 준다
- 적용 성공은 스키마를 통과했다는 뜻일 뿐, 판 고정은 사람이 확인해야 한다
- version 이 없으면 컨트롤러가 한 칸씩 올리는 판을 알아서 고른다
- channel 을 쓰면 skew 정책을 지키도록 CRD 가 막아 준다