Updating 버전 업그레이드 - EKS Cluster

PreviousObservability NextUpgrade EKS control Plane

Last updated 5 months ago

Was this helpful?

Updating 버전 업그레이드 - EKS Cluster

EKS가 업스티림 Kubernetes를 추적하므로 인하여 EKS 사용자는 주기적으로 EKS Cluster를 업그레이드해야 합니다. 지원되는 버전은 현재 버전에서 이전 버전 2개(N-2)였으나, 되었습니다.

분기마다 새로운 주요 버전의 Kubernetes가 출시가 되고 있으며, 이는 쿠버네티스의 지원 기간이 1년중 3/4로 단축되었음을 의미합니다.

Amazon EKS에서 지원되는 Kubernetes 버전은 아래 링크에서 확인 하십시요.

Kubernetes의 업그레이드 외에도 클러스터에서 고려해야 할 다른 관련 업그레이드도 있습니다.

노드의 Amazon Machine Image(AMI) - Kubernetes 뿐만 아니라 Kubelet, 다른 모든 부분(OS, containerD 등)을 포함하고 있으며, Control Plan은 항상 자체 버전의 N-1의 Kubelet를 지원하고 있습니다.
기본 Daemonset - 모든 EKS 클러스터(Kube-proxy, CoreDNS, AWS CNI)에 배포되는 기본 데몬셋으로, Kubernetes를 업그레이드 할 때 업그레이드해야 할 수 있습니다. 에서 이 작업이 필요한지 여부와 업그레이드할 버전이 나와 있습니다.
사용자가 추가한 Add-ons/Controllers/Drivers를 Kubernetes를 업그레이드할 때 같이 업그레이드해야 할 수 있습니다.

이 실습에서는 관리 노드 그룹을 포함하여 클러스터를 1.20에서 1.21로 업그레이드하는 프로세스를 수행하여 EKS 및 관리 노드 그룹을 업그레이드 합니다.

Upgrade 절차

업그레이드 하려는 새 버전에서 기존 API 사용이 중단되어 YAML Spec 파일을 변경해야 하는지 확인합니다. (1.15 to 1.16 과 같은 일부 버전 업그레이드의 경우에만 해당됩니다.) 이를 위해서 과 같은 다양한 도구가 있습니다. 실습에서 사용하는 1.20에서 1.21까지는 이러한 내용이 없기 때문에 실습에서는 이 단계를 생략합니다.
kubectl get node 명령어를 실행하여 모든 노드가 현재 버전을 실행 중으로 확인합니다. 모든 노드가 현재 Kubernetes 버전과 일치해야 하므로 EKS control plane을 업그레이드할 때 한 버전 뒤에 있는 노드만 지원합니다. Fargate의 경우 PoD를 다시 시작하고 ReplicaSet이 이를 대체하도록 하면 현재 Kubernetes 버전과 일치합니다.
EKS control Plane을 새로운 버전으로 업그레이드합니다.
EKS와 함께 제공되는 Core Add-ons(Kubeproxy, CoreDNS 및 CNI)를 Major upgrade와 결합하기 위해 업그레이드가 필요한지 확인합니다. 이 내용은 에 나와 있습니다. 1.20~1.21 업그레이드 설명서에는 CoreDNS와 Kubeproxy를 모두 업그레이드해야 한다고 나와 있습니다.
모든 Worker 노드를 업그레이드 하여 Worker node내의 Kubelet이 EKS control plane과 일치하도록 합니다. 이 작업은 반드시 수행할 필요는 없지만, 가급적 노드들을 Control Plane과 동일한 버전에 있도록 하는 것이 좋습니다. Managed Node Group을 사용하는 경우 EKS는 AWS 및 Kubernetes 측 모두 rolling Node replacement/upgrade 를 조정하는 안전한 자동 프로세스를 통해 이러한 작업을 용이하게 할 수 있습니다. Fargate를 사용하는 경우 다음 PoD 가 교체 될때 이 작업이 자동으로 수행됩니다.

PreviousObservability NextUpgrade EKS control Plane

Last updated 5 months ago

Was this helpful?

분기마다 새로운 주요 버전의 Kubernetes가 출시가 되고 있으며, 이는 쿠버네티스의 지원 기간이 1년중 3/4로 단축되었음을 의미합니다.

Amazon EKS에서 지원되는 Kubernetes 버전은 아래 링크에서 확인 하십시요.

Kubernetes의 업그레이드 외에도 클러스터에서 고려해야 할 다른 관련 업그레이드도 있습니다.

노드의 Amazon Machine Image(AMI) - Kubernetes 뿐만 아니라 Kubelet, 다른 모든 부분(OS, containerD 등)을 포함하고 있으며, Control Plan은 항상 자체 버전의 N-1의 Kubelet를 지원하고 있습니다.
기본 Daemonset - 모든 EKS 클러스터(Kube-proxy, CoreDNS, AWS CNI)에 배포되는 기본 데몬셋으로, Kubernetes를 업그레이드 할 때 업그레이드해야 할 수 있습니다. 에서 이 작업이 필요한지 여부와 업그레이드할 버전이 나와 있습니다.
사용자가 추가한 Add-ons/Controllers/Drivers를 Kubernetes를 업그레이드할 때 같이 업그레이드해야 할 수 있습니다.

Upgrade 절차

업그레이드 하려는 새 버전에서 기존 API 사용이 중단되어 YAML Spec 파일을 변경해야 하는지 확인합니다. (1.15 to 1.16 과 같은 일부 버전 업그레이드의 경우에만 해당됩니다.) 이를 위해서 과 같은 다양한 도구가 있습니다. 실습에서 사용하는 1.20에서 1.21까지는 이러한 내용이 없기 때문에 실습에서는 이 단계를 생략합니다.
kubectl get node 명령어를 실행하여 모든 노드가 현재 버전을 실행 중으로 확인합니다. 모든 노드가 현재 Kubernetes 버전과 일치해야 하므로 EKS control plane을 업그레이드할 때 한 버전 뒤에 있는 노드만 지원합니다. Fargate의 경우 PoD를 다시 시작하고 ReplicaSet이 이를 대체하도록 하면 현재 Kubernetes 버전과 일치합니다.
EKS control Plane을 새로운 버전으로 업그레이드합니다.
EKS와 함께 제공되는 Core Add-ons(Kubeproxy, CoreDNS 및 CNI)를 Major upgrade와 결합하기 위해 업그레이드가 필요한지 확인합니다. 이 내용은 에 나와 있습니다. 1.20~1.21 업그레이드 설명서에는 CoreDNS와 Kubeproxy를 모두 업그레이드해야 한다고 나와 있습니다.
모든 Worker 노드를 업그레이드 하여 Worker node내의 Kubelet이 EKS control plane과 일치하도록 합니다. 이 작업은 반드시 수행할 필요는 없지만, 가급적 노드들을 Control Plane과 동일한 버전에 있도록 하는 것이 좋습니다. Managed Node Group을 사용하는 경우 EKS는 AWS 및 Kubernetes 측 모두 rolling Node replacement/upgrade 를 조정하는 안전한 자동 프로세스를 통해 이러한 작업을 용이하게 할 수 있습니다. Fargate를 사용하는 경우 다음 PoD 가 교체 될때 이 작업이 자동으로 수행됩니다.