Udemy CKA 강의 정리 125: Cluster Upgrade Process

해당 내용은 Udemy의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의를 공부한 내용입니다. 내용을 그대로 번역하기보다는, 제가 이해하기 쉬운 대로 수정한 부분들이 있습니다.

⚠️ 영어 독해가 많이 부족합니다. 틀린 내용이 있으면 알려주시면 감사하겠습니다.

---

이번 강의에서는 쿠버네티스의 클러스터 업그레이드 과정에 대해 알아보도록 하겠습니다. 이전 강의에서 우리는 Kubernetes가 소프트웨어 릴리스를 관리하는 방법을 살펴보았고, 다양한 컴포넌트에 버전이 어떻게 존재하는지도 보았습니다. 지금은 ETCD 및 CoreDNS와 같은 외부 컴포넌트에 대한 종속성을 유지하면서 핵심 컨트롤 플레인 컴포넌트에 집중할 것입니다. 
이들 모두가 동일한 버전을 갖는 것이 필수일까요? 아닙니다. 컨포넌트는 다른 릴리스 버전을 가질 수 있습니다. kube API server는 컨트롤 플레안의 primary 컴포넌트이고, 다른 모든 컴포넌트와 통신하는 컴포넌트이기 때문에 다른 컴포넌트는 kube API 서버보다 높은 버전이면 안됩니다. 컨트롤러 매니저와 스케줄러는 한 버전 낮을 수도 있습니다. 따라서 kube API 서버가 x에 있으면 컨트롤러 매니저와 kube 스케줄러는 x-1에 있을 수 있습니다. 그리고 kubelet 및 kube 프록시 컴포넌트는 x에서 2를 뺀 두 가지 낮은 버전일 수 있습니다. 따라서 kube API 서버가 1.10인 경우, 컨트롤러 매니저와 스케줄러는 1.10 또는 1.9 일 수 있습니다. kubelet 및 kube 프록시는 1.8일 수 있습니다.  1.11처럼 kube API 서버보다 높은 버전만 아니면 됩니다. 

그러나 kubectl은 다릅니다. kubectl 유틸리티는 API 서버보다 높은 1.11버전일 수 있습니다. 또는 API 서버와 동일한 1.10 버전일 수도 있습니다. 혹은 API 서버보다 낮은 1.9버전일 수도 있습니다. 이제 이 허용 가능한 버전 skew를 통해 라이브 업그레이드를 수행할 수 있습니다. 필요한 경우 컴포넌트별로 업그레이드를 진행할 수 있습니다. 

그렇다면 언제 업그레이드를 해야 할까요? 지금 1.10 버전에 있고, Kubernetes 릴리스 버전은 1.11과 1.12 이라고 합시다. Kubernetes는 최근 3개의 minor 버전까지만 지원합니다. 따라서 1. 12는 최신 릴리스이므로 Kubernetes는 버전 1.11과 1.10까지 지원합니다. 1.13이 릴리스되면, 버전 1.13, 1.12, 1.11만 지원합니다. 따라서 1.13이 릴리즈되기 전이 클러스터를 다음 릴리스로 업그레이드하기에 좋은 시기입니다. 
어떻게 업그레이드할까요? 1.0에서 바로 1.3으로업그레이드 할까요? 아닙니다. 권장되는 접근 방식은 한 번에 하나의 minor 버전을 업그레이드하는 것입니다. 1.10에서 1.11로, 1.11에서 1.12로, 그리고 1.12에서 1.13으로 말이죠. 
업그레이드 프로세스는 클러스터 설정 방법에 따라 다릅니다. 예를 들어 클러스터가 Google과 같은 클라우드 서비스 공급자에 배포된 관리형 Kubernetes 클러스터인 경우라면, Google Kubernetes Engine을 사용하면 몇 번의 클릭만으로 클러스터를 쉽게 업그레이드할 수 있습니다. 
kubeadm과 같은 도구를 사용하여 클러스터를 배포한 경우, 이 도구를 사용하면 클러스터를 계획하고 업그레이드할 수 있습니다. 
클러스터를 처음부터 배포한 경우 클러스터의 여러 컴포넌트를 직접 수동으로 업그레이드 해야 합니다. 

Options to upgrade k8s cluster

이번 강의에서는 kubeadm에 의한 옵션들을 살펴보도록 하겠습니다. 여기 마스터 및 워커 노드가 있는 클러스터가 있습니다. 프로덕션 호스팅 파드에서 실행되어 사용자에게 서비스를 제공합니다. 노드와 컴포넌트들은 버전 1.10입니다. 
클러스터 업그레이드에는 두 가지 주요 단계가 포함됩니다. 먼저 마스터 노드를 업그레이드한 다음 워커 노드를 업그레이드합니다. 
마스터가 업그레이드되는 동안 API 서버, 스케줄러 및 컨트롤러 매니저와 같은 컨트롤 플레인 컴포넌트가 잠시 중단됩니다. 마스터가 다운된다고 해서 클러스터의 워커 노드와 애플리케이션이 영향을 받는 것은 아닙니다. 워커 노드에서 호스팅되는 모든 워크로드는 마스터가 중단되고 모든 관리 기능이 중단되지만, 워커 노드에서 계속해서 정상적으로 사용자에게 서비스를 제공합니다. kube control 또는 기타 Kubernetes API를 사용하여 클러스터에 액세스할 수 없습니다. 새 애플리케이션을 배포하거나 기존 애플리케이션을 삭제 또는 수정할 수 없습니다. 컨트롤러 매니저도 작동하지 않습니다. 파드가 실패하면 새 파드가 자동으로 생성되지 않습니다. 그러나 노드와 파드(Pod)가 가동되는 한 애플리케이션도 가동되고 사용자는 영향을 받지 않습니다. 
업그레이드가 완료되고 클러스터가 백업되면 정상적으로 작동해야 합니다. 이제 버전 1.11 마스터 및 마스터 컴포넌트와 버전 1.10의 워커노드가 있습니다. 

 

Cluster Upgrade Introduction

앞에서 본 것처럼 이것은 지원되는 configuration이므로 이제 워커 노드를 업그레이드할 차례입니다. 워커 노드를 업그레이드하는 데 사용할 수 있는 다양한 전략이 있습니다. 

첫 번째 전략은 한 번에 모두 업그레이드하는 것인데, 파드가 다운되고 사용자가 더 이상 애플리케이션에 액세스할 수 없게 됩니다. 업그레이드가 완료되면 노드가 백업되고 새 파드가 스케쥴링되며 사용자는 액세스를 재개할 수 있습니다. downtime이 필요한 전략 중 하나입니다. 

두 번째 전략은 한 번에 노드 하나씩 업그레이드하는 것입니다. 마스터가 업그레이드되고 노드가 업그레이드 대기 중인 상태로 돌아가서 생각해봅시다. 먼저 첫 번째 노드를 업그레이드합니다. 이 때 워크로드가 두 번째 및 세 번째 노드로 사용자는 두 번째 세 번째 노드에서 서비스를 제공 받습니다. 첫 번째 노드가 업그레이드되고 백업되면 워크로드가 첫 번째와 세 번째 노드로 이동하고 두 번째 노드를 업데이트합니다. 마지막으로 워크로드가 처음 두 노드로 이동하고 세 번째 노드를 업그레이드 합니다. 모든 노드를 새 버전으로 업그레이드한 다음 동일한 절차에 따라 노드를 1.11에서 1.12로, 1.12에서 1.13으로 업그레이드합니다. 

세 번째 전략은 새로운 소프트웨어 버전이 있는 노드를 클러스터에 추가하는 것입니다. 이는 새 노드를 쉽게 프로비저닝하고 이전 노드를 쉽게 폐기할 수 있는 클라우드 환경에 있는 경우 특히 편리합니다. 새 소프트웨어 버전이 있는 노드를 클러스터에 추가하고 워크로드를 새 노드로 옮기고 이전 노드를 제거하면 최종적으로 새 소프트웨어 버전이 있는 모든 새 노드가 생성됩니다. 

kubeadm - Upgrade master node

이제 어떻게 수행되는지 살펴보겠습니다. 이 클러스터를 1.11에서 1.13으로 업그레이드한다고 가정해 보겠습니다. kubeadm에는 클러스터 업그레이드에 도움이 되는 upgrade 커맨드가 있습니다. kubeadm으로 kubeadm upgrade plan 커맨드를 실행하면 현재 클러스터 버전, kubeadm tool 버전, Kubernetes의 최신 stable 버전 등 유용한 정보를 많이 얻을 수 있습니다. 그런 다음 모든 컨트롤 플레인 컴포넌트의 해당 버전과 업그레이드할 수 있는 버전을 보여줍니다. 또한 컨트롤 플레인 컴포넌트를 업그레이드한 후 각 노드에서 kubelet 버전을 수동으로 업그레이드해야 함을 알려줍니다. kubeadm은 kubelet을 설치하거나 업그레이드하지 않는다는 점을 기억하세요. 마지막으로 클러스터를 업그레이드하라는 커맨드를 제공합니다. 또한 클러스터를 업그레이드하기 전에 kubeadm tool 자체를 업그레이드해야 합니다. kubeadm tool도 Kubernetes와 동일한 소프트웨어 버전을 따릅니다. 따라서 지금은 1.11인데 1.3으로 가고 싶습니다. 그러나 한 번에 하나의 minor 버전만 사용할 수 있다는 점을 기억하세요. 그래서 먼저 1.12로 갑니다. 먼저 kubeadm tool 자체를 버전 1.12로 업그레이드합니다. 그런 다음 kubeadm upgrade plan output과 kubeadm upgrade apply 커맨드를 사용하여 클러스터를 업그레이드합니다. 필요한 이미지를 가져오고 클러스터 컴포넌트를 업그레이드합니다. 완료되면 이제 컨트롤 플레인 컴포넌트들이 1.12가 됩니다. 

kube control get nodes 커맨드를 실행하면 여전히 마스터 노드가 1.11로 표시됩니다. 이는 이 커맨드의 출력에서 API 서버 자체의 버전이 아니라 API 서버에 등록된 각 노드의 kubelet 버전을 표시하기 때문입니다.
다음 단계는 kubelets를 업그레이드하는 것입니다. 설정에 따라 마스터 노드에서 실행 중인 kubelet이 있을 수도 있고 없을 수도 있습니다. 이 경우 kubeadm으로 배포된 클러스터에는 마스터 노드에 kubelet이 있으며, 이는 마스터 노드에서 컨트롤 플레인 컴포넌트를 실행하는 데 사용됩니다. 이 코스 과정 후반에 Kubernetes 클러스터를 처음부터 설정할 것인데, 이때 마스터 노드에 kubelet을 설치하지 않습니다. 
따라서 다음 단계는 kubelet이 있는 경우 마스터 노드에서 kubelet을 업그레이드하는 것입니다. 이를 위해 apt-get kubelet 커맨드를 실행합니다. 패키지가 업그레이드되면 kubelet 서비스를 다시 시작합니다. 

이제 kube control get nodes 커맨드를 실행하면 마스터가 1.12로 업그레이드되었음을 볼 수 있습니다. 워커 노드는 여전히 1.11입니다.

kubeadm - Upgrade worker nodes

다음은 워커 노드입니다. 한 번에 하나씩 시작해 봅시다. 먼저 첫 번째 워커 노드에서 다른 노드로 워크로드를 이동해야 합니다.

$ kubectl drain node-1

kube control drain 커맨드를 사용하면 노드에서 모든 파드를 안전하게 종료하고 다른 노드에서 다시 예약할 수 있습니다. 또한 노드를 cordons하고 untradeable로 표시하여 새 파드가 예약되지 않도록 합니다.

$ apt-get upgrade -y kubeadm=1.12.0-00
$ apt-get upgrade -y kubelet=1.12.0-00

그런 다음 마스터 노드에서 수행한 것처럼 워커 노드에서 kubeadm 및 kubelet 패키지를 업그레이드합니다.

$ kubeadm upgrade node config --kubelet-version v1.12.0

$ systemctl restart kubelet

그런 다음 kubeadm tool 업그레이드 커맨드를 사용하여 새 kubelet 버전에 대한 구성요소를 업데이트한 다음 kubelet 서비스를 다시 시작합니다. 이제 노드가 새 소프트웨어 버전으로 작동해야 합니다.

$ kubectl uncordon node-1

그러나 노드를 드레이닝할 때 실제로 예약 불가능으로 표시했으므로 kubectl uncordon node-1 커맨드를 실행하여 표시를 해제해야 합니다. 이제 노드를 예약할 수 있지만 파드가 이 노드로 바로 돌아올 필요는 없습니다. scheculable로만 표시됩니다. 파드가 다른 노드에서 삭제되거나 새 파드가 예약된 경우에만 이 첫 번째 노드로 다시 돌아옵니다. 두 번째 노드를 중단하고 동일한 단계를 수행하여 업그레이드할 때 곧 올 것입니다. 그리고 마지막으로 세 번째 노드입니다. 이제 모든 노드가 업그레이드되었습니다.