Amazon EKS 클러스터 Kubernetes 버전 업데이트

Amazon EKS에서 새 Kubernetes 버전을 사용할 수 있는 경우 Amazon EKS 클러스터를 최신 버전으로 업데이트할 수 있습니다.

중요

새 Kubernetes 버전으로 업데이트하기 전에 Amazon EKS Kubernetes 버전의 정보 및 이 주제의 업데이트 단계를 검토하는 것이 좋습니다. 버전 1.22로 업데이트하려는 경우 업데이트 전에 Kubernetes 버전 1.22 전제 조건에 나열된 변경 사항을 클러스터에 적용해야 합니다.

새로운 Kubernetes 버전에는 때로는 큰 변화가 도입되기도 합니다. 따라서 프로덕션 클러스터를 업데이트하기 전에 새 Kubernetes 버전에 대해 애플리케이션의 동작을 테스트하는 것이 좋습니다. 새 Kubernetes 버전으로 이동하기 전에 애플리케이션 동작을 테스트하기 위한 지속적인 통합 워크플로를 구축하여 이 작업을 수행할 수 있습니다.

업데이트 프로세스는 Amazon EKS에서 업데이트된 Kubernetes 버전으로 새 API 서버 노드를 시작해 기존 노드를 대체합니다. Amazon EKS는 이러한 새 노드에서 네트워크 트래픽의 표준 인프라 및 준비 상태 검사를 수행하여 예상대로 작동하고 있는지 확인합니다. 이러한 검사 중 하나라도 실패하면 Amazon EKS는 인프라 배포를 되돌리고, 클러스터는 이전 Kubernetes 버전으로 남아 있게 됩니다. 실행 중인 애플리케이션은 영향을 받지 않으며, 클러스터가 불확정적 또는 복구 불가능 상태로 남아 있는 일은 없습니다. Amazon EKS는 모든 관리형 클러스터를 정기적으로 백업하고, 필요할 경우 클러스터를 복구하는 메커니즘이 있습니다. Kubernetes 인프라 관리 프로세스를 지속적으로 평가 및 개선하고 있습니다.

클러스터를 업데이트하려면 Amazon EKS에서 클러스터를 생성할 때 지정된 서브넷의 무료 IP 주소 최대 5개가 필요합니다. Amazon EKS에서는 지정한 서브넷에 새 클러스터 탄력적 네트워크 인터페이스(네트워크 인터페이스)를 생성합니다. 네트워크 인터페이스는 기존 네트워크 인터페이스가 있는 다른 서브넷에 생성될 수 있으므로 보안 그룹 규칙에서 클러스터를 생성할 때 지정한 모든 서브넷에 대해 필수 클러스터 통신을 허용해야 합니다. 클러스터를 생성할 때 지정한 서브넷이 없거나, 해당 서브넷에 무료 IP 주소가 충분하지 않거나 필요한 클러스터 통신을 허용하는 보안 그룹 규칙이 없는 경우 업데이트가 실패할 수 있습니다.

참고

Amazon EKS는 가용성 높은 제어 영역을 실행하지만, 업데이트 중에 심각하지 않은 서비스 중단이 발생할 수도 있습니다. 예를 들어 API 서버를 종료하고 새 Kubernetes 버전을 실행하는 새 API 서버로 교체할 때 API 서버에 연결하려고 한다고 가정합니다. API 호출 오류 또는 연결 문제가 발생할 수 있습니다. 이 문제가 발생하는 경우 성공할 때까지 API 작업을 재시도하십시오.

Amazon EKS 클러스터의 Kubernetes 버전 업데이트

클러스터의 Kubernetes 버전을 업데이트하려면 다음을 수행합니다.

1. 클러스터 컨트롤 플레인의 Kubernetes 버전과 사용자 노드의 Kubernetes 버전을 비교합니다.

   • kubectl version --short 명령으로 클러스터 컨트롤 플레인의 Kubernetes 버전을 가져옵니다.

     kubectl version --short

   • kubectl get nodes 명령으로 노드의 Kubernetes 버전을 가져옵니다. 이 명령은 자체 관리형 및 관리형 Amazon EC2 및 Fargate 노드를 모두 반환합니다. 각 Fargate pod는 자체 노드로 나열됩니다.

     kubectl get nodes

   컨트롤 플레인을 새 Kubernetes 버전으로 업데이트하기 전에 클러스터에 있는 관리형 노드 및 Fargate 노드 모두의 Kubernetes 마이너 버전이 컨트롤 플레인의 현재 버전과 동일한지 확인합니다. 예를 들어 컨트롤 플레인이 버전 1.21을 실행 중이고 노드 중 하나가 버전 1.20을 실행 중인 경우 노드를 버전 1.21으로 업데이트해야 합니다. 또한 제어 플레인을 업데이트하기 전에 자체 관리형 노드를 제어 평면과 동일한 버전으로 업데이트하는 것이 좋습니다. 자세한 내용은 관리형 노드 그룹 업데이트 및 자체 관리형 노드 업데이트 단원을 참조하십시오. Fargate 노드의 버전을 업데이트하려면 먼저 노드가 나타내는 pod를 삭제합니다. 그런 다음 컨트롤 플레인을 업데이트합니다. 나머지 pods는 모두 다시 배포한 후 새 버전으로 업데이트됩니다.

2. 기본적으로 pod 보안 정책 승인 컨트롤러는 Amazon EKS 클러스터에 사용 설정되어 있습니다. 클러스터를 업데이트하기 전에 적절한 pod 보안 정책이 있는지 확인하세요. 이는 잠재적인 보안 문제를 방지하기 위함입니다. kubectl get psp eks.privileged 명령을 사용하여 기본 정책을 확인할 수 있습니다.

   kubectl get psp eks.privileged

   다음 오류가 표시되는 경우 계속하기 전에 기본 pod 보안 정책을 참조하세요.

   Error from server (NotFound): podsecuritypolicies.extensions "eks.privileged" not found

3. 원래 클러스터를 배포한 Kubernetes 버전이 Kubernetes 1.18 이상인 경우 이 단계를 건너뜁니다.

   중단된 용어를 CoreDNS 매니페스트에서 제거해야 할 수 있습니다.

   1. CoreDNS 매니페스트에 upstream이라는 단어만 있는 줄이 있는지 확인합니다.

      kubectl get configmap coredns -n kube-system -o jsonpath='{$.data.Corefile}' | grep upstream

      결과가 반환되지 않으면 매니페스트에 해당 줄이 없는 것입니다. 이 경우 다음 단계로 건너뜁니다. upstream이라는 단어가 반환되면 줄을 제거합니다.

   2. configmap 파일에서 upstream이라는 단어만 있는 파일의 맨 위 근처의 줄을 제거합니다. 파일에서 다른 것을 변경하지 마세요. 줄을 제거한 후 변경 사항을 저장하세요.

      kubectl edit configmap coredns -n kube-system -o yaml

   더보기간략히 보기

4. eksctl, AWS Management Console 또는 AWS CLI를 사용하여 클러스터를 업데이트합니다.

   중요

   • 버전 1.22로 업데이트하려는 경우 업데이트 전에 Kubernetes 버전 1.22 전제 조건에 나열된 변경 사항을 클러스터에 적용해야 합니다.

   • Amazon EKS는 가용성 높은 제어 영역을 실행하므로 한 번에 하나의 마이너 버전만 업데이트할 수 있습니다. 이 요구 사항에 대한 자세한 내용을 알아보려면 Kubernetes 버전 및 버전 차이 지원 정책을 참조하세요. 현재 버전이 1.20인데 1.22로 업데이트하려고 한다고 가정합니다. 그러면 먼저 클러스터를 1.21로 업데이트한 다음 나중에 1.21에서 1.22로 업데이트합니다.

   • 업데이트하기 전에 관리형 및 Fargate 노드의 kubelet이 컨트롤 플레인과 동일한 Kubernetes 버전인지 확인합니다. 자체 관리형 노드를 컨트롤 플레인과 동일한 버전으로 유지하는 것이 좋습니다. 현재 버전의 컨트롤 플레인 뒤에는 최대 하나의 버전만 있을 수 있습니다.

   • 클러스터가 1.8.0 이전 버전의 Amazon VPC CNI 플러그 인으로 구성된 경우 클러스터를 버전 1.21 이상으로 업데이트하기 전에 플러그 인을 버전 1.11.2로 업데이트하는 것이 좋습니다. 자세한 내용은 Amazon VPC CNI plugin for Kubernetes 추가 기능 업데이트 또는 Amazon VPC CNI plugin for Kubernetes 자체 관리형 추가 기능 업데이트 단원을 참조하세요.

   eksctl

   이 절차에는 eksctl 버전 0.105.0 이상이 필요합니다. 버전은 다음 명령을 통해 확인할 수 있습니다.

   eksctl version

   eksctl 설치 또는 업데이트하는 방법에 대한 지침은 섹션을 참조하세요.

   다음 명령을 사용하여 Amazon EKS 컨트롤 플레인의 Kubernetes 버전을 현재 버전보다 한 개 마이너 버전 이후로 업데이트합니다. my-cluster을 클러스터 이름으로 교체합니다.

   eksctl upgrade cluster --name my-cluster --approve

   업데이트를 완료하는 데 몇 분 정도 걸립니다.

   AWS Management Console

   1. https://console.aws.amazon.com/eks/home#/clusters에서 Amazon EKS 콘솔을 엽니다.

   2. 업데이트할 Amazon EKS 클러스터의 이름을 선택한 다음 클러스터 버전 업데이트(Update cluster version)를 선택합니다.

   3. Kubernetes 버전에서 클러스터를 업데이트할 버전을 선택하고 업데이트(Update)를 선택합니다.

   4. 클러스터 이름(Cluster name)에 클러스터 이름을 입력하고 확인(Confirm)을 선택합니다.

      업데이트를 완료하는 데 몇 분 정도 걸립니다.

   AWS CLI

   1. 다음 AWS CLI 명령을 사용하여 Amazon EKS 클러스터를 업데이트합니다. example-values을 사용자의 값으로 교체합니다.

      aws eks update-cluster-version \
       --region region-code \
       --name my-cluster \
       --kubernetes-version 1.22

      출력 예는 다음과 같습니다.

      {
          "update": {
              "id": "b5f0ba18-9a87-4450-b5a0-825e6e84496f",
              "status": "InProgress",
              "type": "VersionUpdate",
              "params": [
                  {
                      "type": "Version",
                      "value": "1.22"
                  },
                  {
                      "type": "PlatformVersion",
                      "value": "eks.1"
                  }
              ],
      ...
              "errors": []
          }
      }

   2. 다음 명령을 사용하여 클러스터의 업데이트 상태를 모니터링할 수 있습니다. 이전 명령에서 반환된 클러스터 이름과 업데이트 ID를 사용합니다. Successful 상태가 표시되면 업데이트가 완료됩니다. 업데이트를 완료하는 데 몇 분 정도 걸립니다.

      aws eks describe-update \
        --region region-code \
        --name my-cluster \
        --update-id b5f0ba18-9a87-4450-b5a0-825e6e84496f

      출력 예는 다음과 같습니다.

      {
          "update": {
              "id": "b5f0ba18-9a87-4450-b5a0-825e6e84496f",
              "status": "Successful",
              "type": "VersionUpdate",
              "params": [
                  {
                      "type": "Version",
                      "value": "1.22"
                  },
                  {
                      "type": "PlatformVersion",
                      "value": "eks.1"
                  }
              ],
      ...
              "errors": []
          }
      }

5. 클러스터 업데이트가 완료된 후 업데이트한 클러스터와 동일한 Kubernetes 마이너 버전으로 노드를 업데이트합니다. 자세한 내용은 자체 관리형 노드 업데이트 및 관리형 노드 그룹 업데이트 단원을 참조하십시오. Fargate에서 시작된 새 pods에는 클러스터 버전과 일치하는 kubelet 버전이 있습니다. 기존 Fargate pods는 변경되지 않습니다.

6. (선택 사항) 클러스터를 업데이트하기 전에 Kubernetes Cluster Autoscaler를 클러스터에 배포한 경우 업그레이드한 Kubernetes 메이저 및 마이너 버전과 일치하는 최신 버전으로 Cluster Autoscaler를 업데이트합니다.

   1. 웹 브라우저에서 Cluster Autoscaler 릴리스 페이지를 열고 클러스터의 Kubernetes 메이저 및 마이너 버전과 일치하는 최신 Cluster Autoscaler 버전을 검색합니다. 예를 들어 클러스터의 Kubernetes 버전이 1.22이라면 1.22으로 시작하는 Cluster Autoscaler 릴리스를 검색합니다. 다음 단계에서 사용할 수 있도록 이 릴리스의 의미 체계 버전(<1.22.n>)을 적어 둡니다.

   2. 다음 명령을 사용하여 Cluster Autoscaler 이미지 태그를 이전 단계에서 적어 둔 버전으로 설정합니다. 필요한 경우 1.22.n을 고유 값으로 바꿉니다.

      kubectl -n kube-system set image deployment.apps/cluster-autoscaler cluster-autoscaler=k8s.gcr.io/autoscaling/cluster-autoscaler:v1.22.n

7. (GPU 노드가 있는 클러스터만 해당) 클러스터에 GPU 지원이 포함된 노드 그룹이 있는 경우(예: p3.2xlarge), 다음 명령으로 클러스터에서 Kubernetes용 NVIDIA 디바이스 플러그인 DaemonSet를 업데이트해야 합니다.

   kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.9.0/nvidia-device-plugin.yml

8. Amazon VPC CNI plugin for Kubernetes, CoreDNS 및 kube-proxy 추가 기능을 업데이트합니다. 클러스터를 버전 1.21 이상으로 업데이트한 경우 추가 기능을 서비스 계정 토큰에 나열된 최소 버전으로 업데이트하는 것이 좋습니다.

   • 클러스터를 버전 1.18로 업데이트한 경우 Amazon EKS 추가 기능을 추가할 수 있습니다. 지침은 Amazon VPC CNI Amazon EKS 추가 기능 추가, CoreDNS Amazon EKS 추가 기능 추가 및 kube-proxy Amazon EKS 추가 기능 추가 섹션을 참조하세요. Amazon EKS 추가 기능에 대한 자세한 내용은 Amazon EKS 추가 기능 섹션을 참조하세요.

   • 버전 1.19 이상으로 업데이트하고 Amazon EKS 추가 기능을 사용하는 경우 Amazon EKS 콘솔에서 클러스터(Clusters)를 선택한 다음 왼쪽 검색 창에서 업데이트한 클러스터 이름을 선택합니다. 콘솔에 알림이 표시됩니다. 사용 가능한 업데이트가 있는 각 추가 기능에 대해 새 버전을 사용할 수 있음을 사용자에게 알립니다. 추가 기능을 업데이트하려면 추가 기능(Add-ons) 탭을 선택합니다. 사용 가능한 업데이트가 있는 추가 기능의 상자 중 하나에서 [지금 업데이트(Update now)]를 선택하고 사용 가능한 버전을 선택한 다음 [업데이트(Update)]를 선택합니다.

   • 또는 AWS CLI나 eksctl을 사용하여 Amazon VPC CNI plugin for Kubernetes, CoreDNS 및 kube-proxy Amazon EKS 추가 기능을 업데이트할 수 있습니다.

Kubernetes 버전 1.22 전제 조건

더 이상 사용되지 않는 여러 베타 API(v1beta1)가 동일한 API의 GA(v1) 버전 대신에 버전 1.22에서 제거되었습니다. Kubernetes 버전 1.22 API 및 기능 제거 블로그와 더 이상 사용되지 않는 API 마이그레이션 가이드에서 확인한 것처럼 클러스터를 버전 1.22로 업데이트하기 전에 다음과 같이 배포된 리소스에 대해 API를 변경해야 합니다.

클러스터를 Kubernetes 버전 1.22로 업데이트하기 전에 다음을 수행해야 합니다.

• 새 API를 참조하도록 YAML 매니페스트 파일 및 클라이언트를 변경합니다.

• 새 API를 호출하도록 사용자 지정 통합 및 컨트롤러를 업데이트합니다.

• 타사 도구의 업데이트된 버전을 사용해야 합니다. 이러한 도구에는 수신 컨트롤러, 서비스 메시 컨트롤러, 지속적 전달 시스템 및 새 API를 호출하는 다른 도구가 포함됩니다. 사용 중단된 API가 클러스터에서 사용 중인지 확인하려면 컨트롤 플레인 로깅을 사용 설정하고 v1beta를 이벤트 필터로 지정합니다. 대체 API는 여러 버전용 Kubernetes에서 사용할 수 있습니다.

• 현재 클러스터에 AWS Load Balancer 컨트롤러가 배포된 경우 클러스터를 Kubernetes 버전 1.22로 업데이트하기 전에 버전 2.4.1로 업데이트해야 합니다.

중요

클러스터를 버전 1.22로 업데이트하는 경우, 새 API를 사용하여 기존 지속된 객체에 액세스할 수 있습니다. 그러나 이러한 새 API를 사용하려면 매니페스트를 마이그레이션하고 클라이언트를 업데이트해야 합니다. 클러스터를 업데이트하면 잠재적인 워크로드 장애를 방지합니다.

Kubernetes 버전 1.22는 다음 베타 API에서 지원을 제거합니다. 다음 정보를 기반으로 매니페스트 및 API 클라이언트를 마이그레이션합니다.

Resource	베타 버전	GA 버전	참고
ValidatingWebhookConfiguration MutatingWebhookConfiguration	admissionregistration.k8s.io/v1beta1	admissionregistration.k8s.io/v1	webhooks[*].failurePolicy 기본값이 v1의 Ignore에서 Fail로 변경되었습니다. webhooks[*].matchPolicy 기본값이 v1의 Exact에서 Equivalent로 변경되었습니다. webhooks[*].timeoutSeconds 기본값이 v1의 30s에서 10s로 변경되었습니다. webhooks[*].sideEffects 기본값이 제거되고 필드가 필수로 설정되고 None 및 NoneOnDryRun만 v1에 대해 허용됩니다. webhooks[*].admissionReviewVersions 기본값이 제거되고 필드는 v1에 대해 필수로 설정됩니다(AdmissionReview에 대해 지원되는 버전은 v1과 v1beta1입니다). webhooks[*].name은 admissionregistration.k8s.io/v1을 통해 생성된 객체의 목록에서 고유해야 합니다.
CustomResourceDefinition	apiextensions.k8s.io/v1beta1	apiextensions.k8s.io/v1	spec.scope의 기본값이 더 이상 Namespaced로 설정되지 않아 명시적으로 지정해야 합니다. spec.version은 v1에서 제거되고 대신에 spec.versions가 사용됩니다. spec.validation은 v1에서 제거되고 대신에 spec.versions[*].schema가 사용됩니다. spec.subresources는 v1에서 제거되고 대신에 spec.versions[*].subresources가 사용됩니다. spec.additionalPrinterColumns는 v1에서 제거되고 대신 spec.versions[*].additionalPrinterColumns가 사용됩니다. spec.conversion.webhookClientConfig가 v1에서 spec.conversion.webhook.clientConfig로 이동하였습니다. spec.conversion.conversionReviewVersions가 spec.conversion.webhook.conversionReviewVersions에서 v1로 이동하였습니다. v1 CustomResourceDefinition 객체를 생성하는 경우 이제 spec.versions[*].schema.openAPIV3Schema가 필요하고 구조적 스키마이어야 합니다.. v1 CustomResourceDefinition 객체를 생성하는 경우 spec.preserveUnknownFields: true는 허용되지 않으며 스키마 정의 내에서 x-kubernetes-preserve-unknown-fields: true로 지정되어야 합니다. additionalPrinterColumns 항목에서 JSONPath 필드의 이름이 v1의 jsonPath로 바뀌었습니다(#66531로 수정).
APIService	apiregistration.k8s.io/v1beta1	apiregistration.k8s.io/v1	없음
TokenReview	authentication.k8s.io/v1beta1	authentication.k8s.io/v1	없음
SubjectAccessReview LocalSubjectAccessReview SelfSubjectAccessReview	authorization.k8s.io/v1beta1	authorization.k8s.io/v1	spec.group의 이름이 spec.groups로 바뀌었습니다.
CertificateSigningRequest	certificates.k8s.io/v1beta1	certificates.k8s.io/v1	인증서를 요청하는 API 클라이언트의 경우: 이제 spec.signerName이 필요하며(알려진 Kubernetes 서명자 참조) kubernetes.io/legacy-unknown에 대한 요청은 certificates.k8s.io/v1 API를 통해 생성될 수 없습니다. spec.usages가 필요하며, 중복 값을 포함할 수 없으며, 알려진 사용량만 포함해야 합니다. 인증서를 승인하거나 서명하는 API 클라이언트의 경우: status.conditions는 중복 유형을 포함할 수 없음 이제 status.conditions[*].status가 필요함 status.certificate은 PEM 인코딩되어야 하며 CERTIFICATE 블록만 포함해야 함
Lease	coordination.k8s.io/v1beta1	coordination.k8s.io/v1	없음
Ingress	extensions/v1beta1 networking.k8s.io/v1beta1	networking.k8s.io/v1	spec.backend의 이름이 spec.defaultBackend로 바뀜 백엔드 serviceName 필드의 이름이 service.name으로 바뀜 숫자형 백엔드 servicePort 필드 이름이 service.port.number로 바뀜 문자열 백엔드 servicePort 필드 이름이 service.port.name으로 바뀜 이제 지정된 각 경로에 대해 pathType가 필요합니다. 옵션은 Prefix, Exact 및 ImplementationSpecific입니다. 정의되지 않은 v1beta1 동작과 일치시키려면 ImplementationSpecific 사용
IngressClass	networking.k8s.io/v1beta1	networking.k8s.io/v1	없음
RBAC	rbac.authorization.k8s.io/v1beta1	rbac.authorization.k8s.io/v1	없음
PriorityClass	scheduling.k8s.io/v1beta1	scheduling.k8s.io/v1	없음
CSIDriver CSINode StorageClass VolumeAttachment	storage.k8s.io/v1beta1	storage.k8s.io/v1	없음

API 제거에 대한 자세한 내용을 알아보려면 더 이상 사용되지 않는 API 마이그레이션 가이드를 참조하세요.