Amazon EKS Kubernetes 버전 - Amazon EKS

Amazon EKS Kubernetes 버전

Kubernetes 프로젝트는 새로운 기능, 디자인 업데이트, 버그 수정을 계속 통합하고 있습니다. 커뮤니티가 새로운 Kubernetes 마이너 버전(예:1.23)을 릴리스했습니다. 새 버전 업데이트는 평균 3개월마다 제공됩니다. 각 마이너 버전은 처음 릴리스된 후 약 12개월 동안 지원됩니다.

사용 가능한 Amazon EKS Kubernetes 버전

현재 다음 Kubernetes 버전은 새 Amazon EKS 클러스터에 사용할 수 있습니다.

  • 1.23.7

  • 1.22.10

  • 1.21.13

  • 1.20.15

  • 1.19.16

애플리케이션에서 특정 Kubernetes 버전이 필요하지 않은 경우 Amazon EKS에서 클러스터에 대해 지원하는 최신 버전의 Kubernetes를 사용하는 것이 좋습니다. Amazon EKS에서 새로운 Kubernetes 버전을 사용할 수 있게 되면 미리 클러스터를 업데이트하여 최신 버전을 사용하는 것이 좋습니다. 클러스터를 업데이트하는 방법에 대한 지침은 Amazon EKS 클러스터 Kubernetes 버전 업데이트 섹션을 참조하세요. Kubernetes 릴리스에 대한 자세한 내용을 알아보려면 Amazon EKS Kubernetes 릴리스 일정Amazon EKS 버전 지원 및 FAQ 섹션을 참조하세요.

참고

Kubernetes 버전 1.24 출시부터 공식적으로 발표된 Amazon EKS AMI에는 유일한 런타임으로 containerd가 포함됩니다. Kubernetes 버전 1.181.23은 Docker를 기본 런타임으로 사용합니다. 그러나 이러한 버전에는 containerd로 지원되는 클러스터에서 워크로드를 테스트하기 위해 사용할 수 있는 부트스트랩 플래그 옵션이 있습니다. 자세한 내용은 Amazon EKS는 Dockershim에 대한 지원을 종료합니다. 섹션을 참조하세요.

Kubernetes 1.23

이제 Kubernetes 1.23는 Amazon EKS에서 사용 가능합니다. Kubernetes 1.23에 대한 자세한 내용을 알아보려면 공식 릴리스 발표를 참조하세요.

  • 중요

    Kubernetes in-tree에서 컨테이너 스토리지 인터페이스(CSI)로의 볼륨 마이그레이션 기능이 활성화되었습니다. 이 기능을 사용하면 Amazon EBS의 기존 Kubernetes in-tree 스토리지 플러그인을 해당 Amazon EBS CSI 드라이버로 대체할 수 있습니다. 자세한 내용은 Kubernetes 블로그의 Kubernetes 1.17 Feature: Kubernetes In-Tree to CSI Volume Migration Moves to Beta(Kubernetes 1.17 기능: Kubernetes In-Tree에서 CSI로의 볼륨 마이그레이션이 베타 버전으로 전환)를 참조하세요.

    이 기능은 in-tree API를 동등한 CSI API로 변환하고 작업을 대체 CSI 드라이버에 위임합니다. 이 기능을 사용하면 이러한 워크로드에 속하는 기존 StorageClass, PersistentVolume, PersistentVolumeClaim 객체를 사용하는 경우 눈에 띄는 변화가 없을 것입니다. 이 기능을 사용하면 Kubernetes에서 모든 스토리지 관리 작업을 in-tree 플러그인에서 CSI 드라이버로 위임합니다. 기존 클러스터에서 Amazon EBS 볼륨을 사용하는 경우 클러스터를 버전 1.23으로 업데이트하기 전에 클러스터에 Amazon EBS CSI 드라이버를 설치합니다. 기존 클러스터를 업데이트하기 전에 드라이버를 설치하지 않은 경우 워크로드가 중단될 수 있습니다. 새 1.23 클러스터에서 Amazon EBS 볼륨을 사용하는 워크로드를 배포하려는 경우 클러스터에 워크로드를 배포하기 전에 클러스터에 Amazon EBS CSI 드라이버를 설치합니다. 클러스터에 Amazon EBS CSI 드라이버를 설치하는 방법에 대한 지침은 Amazon EBS CSI 드라이버 섹션을 참조하세요. 마이그레이션 기능에 대한 자주 묻는 질문은 Amazon EBS CSI 마이그레이션 관련 자주 묻는 질문 섹션을 참조하세요.

  • Kubernetes는 버전 1.20에서의 dockershim 지원을 중단하고 버전 1.24에서 dockershim을 제거했습니다. 자세한 내용은 Kubernetes 블로그의 Kubernetes is Moving on From Dockershim: Commitments and Next Steps(Kubernetes는 Dockershim에서 이동 중: 약속 및 다음 단계)를 참조하세요. Amazon EKS는 Amazon EKS 버전 1.24부터 dockershim에 대한 지원을 종료합니다. Amazon EKS 버전 1.24부터 Amazon EKS 공식 AMI에는 containerd가 유일한 런타임으로 포함됩니다.

    Amazon EKS 버전 1.23에서 dockershim을 계속 지원하더라도 지금 애플리케이션 테스트를 시작하여 Docker 종속성을 식별하고 제거하는 것이 좋습니다. 이렇게 하면 클러스터를 버전 1.24로 업데이트할 준비가 됩니다. dockershim 제거에 대한 자세한 내용은 Amazon EKS는 Dockershim에 대한 지원을 종료합니다. 섹션을 참조하세요.

  • Kubernetes에서 pods, 서비스, 노드에 대한 IPv4/IPv6 듀얼 스택 네트워킹이 정식 출시 단계로 전환되었습니다. 그러나 Amazon EKS와 Amazon VPC CNI plugin for Kubernetes는 듀얼 스택 네트워킹을 지원하지 않습니다. 클러스터가 pods 및 서비스에 IPv4 또는 IPv6 주소를 할당할 수 있지만 두 주소 유형을 모두 할당할 수는 없습니다.

  • Kubernetes에서 포드 보안 승인 기능이 베타 상태로 전환되었습니다. 이 기능은 기본적으로 활성화되어 있습니다. 자세한 내용은 Kubernetes 설명서의 포드 보안 승인을 참조하세요. 포드 보안 승인은 포드 보안 정책(PSP) 승인 컨트롤러를 대체합니다. PSP 승인 컨트롤러는 지원되지 않으며 Kubernetes 버전 1.25에서 제거될 예정입니다.

    PSP 승인 컨트롤러는 적용 수준을 설정하는 특정 네임스페이스 레이블을 기반으로 하는 네임스페이스에 pods에 대한 pod 보안 표준을 적용합니다. 자세한 내용은 Amazon EKS 모범 사례 안내서의 포드 보안 표준(PSS) 및 포드 보안 승인(PSA)을 참조하세요.

  • 클러스터와 함께 배포된 kube-proxy 이미지는 이제 Amazon EKS Distro(EKS-D)에서 관리하는 최소 기본 이미지입니다. 이미지에는 최소 패키지가 포함되어 있으며 셸 또는 패키지 관리자가 없습니다.

  • Kubernetes에서 임시 컨테이너가 베타 상태로 전환되었습니다. 임시 컨테이너는 기존 pod와 동일한 네임스페이스에서 실행되는 임시 컨테이너입니다. 임시 컨테이너를 사용하여 문제 해결 및 디버깅을 위해 pods 및 컨테이너 상태를 관찰할 수 있습니다. 이 방법은 컨테이너가 충돌했거나 컨테이너 이미지에 디버깅 유틸리티가 포함되어 있지 않아 kubectl exec가 충분하지 않은 경우에 대화형 문제 해결에 특히 유용합니다. 디버깅 유틸리티를 포함하는 컨테이너의 예는 Distroless 이미지입니다. 자세한 내용은 Kubernetes 설명서에서 임시 디버그 컨테이너를 사용한 디버깅을 참조하세요.

  • Kubernetes에서 HorizontalPodAutoscaler autoscaling/v2 안정적 API가 정식 출시 단계로 전환되었습니다. HorizontalPodAutoscaler autoscaling/v2beta2 API는 더 이상 지원되지 않습니다.

전체 Kubernetes 1.23 변경 로그를 확인하려면 https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.23.md#changelog-since-v1220을 참조하세요.

Kubernetes 1.22

이제 Kubernetes 1.22는 Amazon EKS에서 사용 가능합니다. Kubernetes 1.22에 대한 자세한 내용을 알아보려면 공식 릴리스 발표를 참조하세요.

  • Kubernetes 1.22는 더 이상 사용할 수 없는 많은 API를 제거합니다. Amazon EKS 버전 1.22로 업그레이드하기 전에 애플리케이션을 변경해야 할 수 있습니다. 신중하게 Kubernetes 버전 1.22 전제 조건을 따라 클러스터를 업데이트합니다.

  • 중요

    BoundServiceAccountTokenVolume은 안정 상태로 종료되고 기본적으로 Kubernetes 버전 1.22에서 사용 설정됩니다. 이 기능은 서비스 계정 토큰의 보안을 향상시킵니다. 따라서 Kubernetes에서 실행 중인 워크로드가 대상, 시간 및 키 바인딩인 JSON 웹 토큰을 요청할 수 있습니다. 이제 서비스 계정 토큰에는 1시간 만료 기간이 있습니다. 이전 Kubernetes 버전에서는 만료 기간이 없었습니다. 즉, 이러한 토큰에 의존하는 클라이언트는 1시간 이내에 토큰을 새로 고쳐야 합니다. 다음 Kubernetes 클라이언트 SDK는 필요한 시간 내에 토큰을 자동으로 새로 고칩니다.

    • Go 버전 0.15.7 이상

    • Python 버전 12.0.0 이상

    • Java 버전 9.0.0 이상

    • JavaScript 버전 0.10.3 이상

    • Ruby master 브랜치

    • Haskell 버전 0.3.0.0

    • C# 버전 7.0.5 이상

    워크로드가 이전 클라이언트 버전을 사용하는 경우 업데이트해야 합니다. 클라이언트를 최신 시간 바운드 서비스 계정 토큰으로 원활하게 마이그레이션하도록 사용 설정하려면 Kubernetes 버전 1.22는 기본 1시간 서비스 계정 토큰의 만료 기간을 추가로 연장합니다. Amazon EKS 클러스터의 경우 연장 만료 기간은 90일입니다. Amazon EKS 클러스터 Kubernetes API 서버는 90일이 지난 토큰을 사용한 요청을 거부합니다. 애플리케이션 및 해당 종속성을 확인하여 Kubernetes 클라이언트 SDK가 이전에 나열된 버전과 동일하거나 이후 버전인지 확인하는 것이 좋습니다. 오래된 토큰을 사용하는 pods를 식별하는 방법에 관한 지침은 Kubernetes 서비스 계정을 참조하세요.

  • Ingress API 버전 extensions/v1beta1networking.k8s.io/v1beta1는 Kubernetes 1.22에서 제거되었습니다. AWS Load Balancer Controller를 사용하는 경우 Amazon EKS 클러스터를 버전 1.22로 업그레이드하기 전에 최소 버전 2.4.1로 업그레이드해야 합니다. 또한 Ingress 매니페스트를 수정하여 apiVersion networking.k8s.io/v1을 사용해야 합니다. 이 기능은 Kubernetes 버전 1.19 이후에서 사용할 수 있습니다. Ingress v1beta1v1 간의 변경 사항에 대한 자세한 내용을 알아보려면 Kubernetes 설명서를 참조하세요. AWS Load Balancer Controller 컨트롤러 샘플 매니페스트v1 사양을 사용합니다.

  • Amazon EKS 레거시 Windows 지원 컨트롤러admissionregistration.k8s.io/v1beta1 Kubernetes에서 제거된 1.22 API를 사용합니다. Windows 워크로드를 실행하는 경우 레거시 Windows 지원을 제거하고, Windows 지원을 사용 설정한 후 Amazon EKS 버전 1.22로 업그레이드합니다.

  • CertificateSigningRequest(CSR) API 버전 certificates.k8s.io/v1beta1은 Kubernetes 버전 1.22에서 제거되었습니다. certificates.k8s.io/v1 CSR API를 사용하려면 매니페스트 및 API 클라이언트를 마이그레이션해야 합니다. 이 API는 1.19 이후의 버전에서 사용할 수 있습니다. Amazon EKS에서 CSR을 사용하는 방법에 대한 지침은 인증서 서명 섹션을 참조하세요.

  • CustomResourceDefinition API 버전 apiextensions.k8s.io/v1beta1은 Kubernetes 1.22에서 제거되었습니다. 클러스터의 모든 사용자 지정 리소스 정의가 v1로 업데이트되었는지 확인합니다. Open API v3 스키마 유효성 검사를 정의하려면 API 버전 v1 사용자 지정 리소스 정의가 필요합니다. 자세한 내용은 Kubernetes 설명서를 참조하세요.

  • App Mesh를 사용하는 경우 최소한 App Mesh 컨트롤러 v1.4.3 이상으로 업그레이드한 후 Amazon EKS 버전 1.22로 업그레이드해야 합니다. 이전 버전의 App Mesh 컨트롤러는 v1beta1 CustomResourceDefinition API 버전을 사용하며 Kubernetes 버전 1.22 이상과는 호환되지 않습니다.

  • Amazon EKS 버전 1.22를 사용하면 기본적으로 EndpointSlices 내에서 종료 상태의 pods가 포함되는 EndpointSliceTerminatingCondition 기능을 사용 설정할 수 있습니다. AWS Load Balancer Controller에서 enableEndpointSlicesTrue(기본값은 사용 중지되어 있음)로 설정한 경우 최소한 AWS Load Balancer Controller 버전 2.4.1+로 업그레이드한 후 Amazon EKS 버전 1.22로 업그레이드해야 합니다.

  • Amazon EKS 버전 1.22부터 kube-proxy는 기본적으로 Prometheus 지표를 pod 외부에 노출하도록 구성됩니다. 이 동작 변경은 컨테이너 로드맵 문제 #657에 대한 요청을 해결합니다.

  • Amazon EKS 버전 1.22의 초기 출시에서는 etcd 버전 3.4를 백엔드로 사용하며, etcd 버전 3.5에 있는 데이터 손상 가능성에 의해 영향을 받지 않습니다.

  • Amazon EKS 1.22부터 Amazon EKS는 out-of-tree AWS Kubernetes Cloud Controller Manager에 대한 코어 컨트롤 플레인 코드에서 AWS 클라우드별 컨트롤 논리를 분리합니다. 이는 업스트림 Kubernetes 권장 사항을 준수합니다. Kubernetes 및 기본 클라우드 인프라 간에 상호 운용성 논리를 분리하여 cloud-controller-manager 구성 요소를 사용하면 클라우드 공급자는 기본 Kubernetes 프로젝트와 다른 속도로 기능을 릴리스할 수 있습니다. 이 변경은 투명하며 아무런 조치도 필요하지 않습니다. 그러나 cloud-controller-manager라는 새 로그 스트림이 이제 사용 설정되면 ControllerManager 로그 유형 아래 나타납니다. 자세한 내용을 알아보려면 Amazon EKS 컨트롤 플레인 로깅을 참조하세요.

  • Amazon EKS 1.22부터 Amazon EKS는 서비스 계정(IRSA)에 대한 IAM 역할에서 사용하는 기본 AWS Security Token Service 엔드포인트를 글로벌 엔드포인트가 아닌 리전 엔드포인트가 되도록 변경하여 지연 시간을 줄이고 안정성을 향상시킵니다. 선택적으로 IRSA를 구성하여 서비스 계정의 AWS Security Token Service 엔드포인트 구성에서 글로벌 엔드포인트를 사용할 수 있습니다.

다음 Kubernetes 기능은 이제 Kubernetes 1.22 Amazon EKS 클러스터에서 지원됩니다.

  • GA에 대한 서버 측 적용 - 서버 측 적용은 선언적 구성을 통해 사용자와 컨트롤러가 리소스를 관리할 수 있도록 도와줍니다. 전체 지정된 인텐트를 전송하여 선언적으로 객체를 만들거나 수정할 수 있습니다. 몇 가지 릴리스에 대해 베타 버전으로 사용하고 나면 서버 측 적용을 일반적으로 사용할 수 있습니다.

  • 지원되지 않는 API 사용에 대한 경고 메커니즘 - 지원되지 않는 API를 사용하면 API 소비자에게는 경고가 표시되고 클러스터 관리자에게는 지표가 표시됩니다.

전체 Kubernetes 1.22 변경 로그를 확인하려면 https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.22.md#changelog-since-v1210을 참조하세요.

Kubernetes 1.21

이제 Kubernetes 1.21는 Amazon EKS에서 사용 가능합니다. Kubernetes 1.21에 대한 자세한 내용을 알아보려면 공식 릴리스 발표를 참조하세요.

  • 중요

    BoundServiceAccountTokenVolume은 베타 버전으로 종료되고 기본적으로 Kubernetes 버전 1.21에서 사용 설정됩니다. 이 기능은 Kubernetes에서 실행되는 워크로드가 대상, 시간 및 키 바인딩인 JSON 웹 토큰을 요청하도록 허용하여 서비스 계정 토큰의 보안을 향상시킵니다. 이제 서비스 계정 토큰에는 1시간 만료 기간이 있습니다. 이전 Kubernetes 버전에서는 만료 기간이 없었습니다. 즉, 이러한 토큰에 의존하는 클라이언트는 1시간 이내에 토큰을 새로 고쳐야 합니다. 다음 Kubernetes 클라이언트 SDK는 필요한 시간 내에 토큰을 자동으로 새로 고칩니다.

    • Go 버전 0.15.7 이상

    • Python 버전 12.0.0 이상

    • Java 버전 9.0.0 이상

    • JavaScript 버전 0.10.3 이상

    • Ruby master 브랜치

    • Haskell 버전 0.3.0.0

    • C# 버전 7.0.5 이상

    워크로드가 이전 클라이언트 버전을 사용하는 경우 업데이트해야 합니다. 클라이언트를 최신 시간 바운드 서비스 계정 토큰으로 원활하게 마이그레이션하도록 사용 설정하려면 Kubernetes 버전 1.21는 기본 1시간 서비스 계정 토큰의 만료 기간을 추가로 연장합니다. Amazon EKS 클러스터의 경우 연장 만료 기간은 90일입니다. Amazon EKS 클러스터 Kubernetes API 서버는 90일이 지난 토큰을 사용한 요청을 거부합니다. 애플리케이션 및 해당 종속성을 확인하여 Kubernetes 클라이언트 SDK가 이전에 나열된 버전과 동일하거나 이후 버전인지 확인하는 것이 좋습니다. 오래된 토큰을 사용하는 pods를 식별하는 방법에 관한 지침은 Kubernetes 서비스 계정을 참조하세요.

  • pods, 서비스, 노드의 듀얼 스택 네트워킹 지원(IPv4IPv6 주소)이 베타 상태에 도달했습니다. 그러나 Amazon EKS와 Amazon VPC CNI plugin for Kubernetes는 현재 듀얼 스택 네트워킹을 지원하지 않습니다.

  • Amazon EKS 최적화 Amazon Linux 2 AMI에 이제 부트스트랩 플래그가 포함되어 containerd 런타임을 Docker 대신 사용할 수 있습니다. 이 플래그는 다음 Kubernetes 릴리스에서 지원되는 런타임으로서의 Docker 제거를 준비를 할 수 있도록 합니다. 자세한 정보는 containerd 런타임 부트스트랩 플래그 사용을 참조하십시오. 이는 Github의 컨테이너 로드맵을 통해 추적 할 수 있습니다.

  • 관리되는 노드 그룹은 Cluster Autoscaler 우선 순위 확장기를 지원합니다.

    Amazon EKS 버전 1.21 클러스터에서 새로 생성된 관리형 노드 그룹은 기본 Auto Scaling 그룹 이름에 다음 형식을 사용합니다.

    eks-managed-node-group-name-uuid

    이는 Cluster Autoscaler의 우선순위 확장기 기능을 사용하여 사용자 지정 우선순위에 따라 노드 그룹의 크기를 조정할 수 있도록 합니다. 일반적인 사용 사례는 요청 시 스팟 노드 그룹 확장을 선호하는 것입니다. 이 동작 변경 사항은 컨테이너 로드맵 문제 #1304를 해결합니다.

다음 Kubernetes 기능은 이제 Amazon EKS 1.21 클러스터에서 지원됩니다.

  • CronJobs(이전 ScheduledJobs)가 이제 안정적인 상태로 전환되었습니다. 이 변화를 통해 사용자는 백업 및 보고서 생성과 같은 정기적으로 예약된 작업을 수행할 수 있습니다.

  • 변경 불가능한 보안 암호 및 ConfigMaps가 이제 안정된 상태로 전환되었습니다. 변경 사항을 거부하기 위해 변경 불가능한 새 필드가 이러한 객체에 추가되었습니다. 이 거부는 의도치 않게 애플리케이션을 중단시킬 수 있는 업데이트로부터 클러스터를 보호합니다. 이러한 리소스는 불변이기 때문에 kubelet은 변경 사항을 감시하거나 폴링하지 않습니다. 이렇게 하면 kube-apiserver 로드 및 확장성 및 성능 향상이 감소됩니다.

  • 정상 노드 종료가 이제 베타 상태로 전환되었습니다. 이 업데이트를 통해 kubelet이 노드 종료를 인식하며 해당 노드의 pods를 정상적으로 종료할 수 있습니다. 이 업데이트 전에는 노드가 종료될 때 해당 pods가 예상되는 종료 수명 주기를 준수하지 않았습니다. 이로 인해 워크로드 문제가 발생했습니다. 이제 kubeletsystemd를 통해 임박한 시스템 종료를 감지하고 실행 중인 pods에 알릴 수 있으므로 정상적으로 종료됩니다.

  • 여러 컨테이너가 있는 포드는 이제 kubectl.kubernetes.io/default-container 주석을 사용하여 kubectl 명령에 대해 컨테이너가 미리 선택되도록 할 수 있습니다.

  • PodSecurityPolicy가 단계적으로 종료되고 있습니다. PodSecurityPolicy는 Kubernetes 사용 중단 지침에 따라 여러 릴리스에서 작동합니다. 자세한 내용은 PodSecurityPolicy 사용 중지: 과거, 현재 및 미래AWS 블로그를 참조하세요.

전체 Kubernetes 1.21 변경 로그를 확인하려면 https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.21.md을 참조하세요.

Kubernetes 1.20

Kubernetes 1.20에 대한 자세한 내용을 알아보려면 공식 릴리스 발표를 참조하세요.

다음 Kubernetes 기능은 이제 Kubernetes 1.20 Amazon EKS 클러스터에서 지원됩니다.

  • API 우선 순위 및 공정성의 경우 베타 상태에 도달했으며 기본적으로 활성화되어 있습니다. 이를 통해 kube-apiserver가 들어오는 요청을 우선 순위 수준별로 분류할 수 있습니다.

  • RuntimeClass가 안정적인 상태에 도달했습니다. RuntimeClass 리소스는 클러스터에서 여러 런타임을 지원하는 메커니즘을 제공하며 해당 컨테이너 런타임에 대한 정보를 컨트롤 플레인에 표시합니다.

  • 프로세스 ID 한도가 이제 정식 출시 단계로 전환되었습니다.

  • kubectl 디버그가 베타 상태에 도달했습니다. kubectl debugkubectl에서 직접 일반적인 디버깅 워크플로를 지원합니다.

  • Docker 컨테이너 런타임이 단계적으로 종료되었습니다. Kubernetes 커뮤니티에서는 전용 FAQ 페이지와 함께 이를 자세히 설명하는 블로그 게시물을 작성했습니다. Docker에서 생성한 이미지는 계속 사용할 수 있으며 항상 사용할 수 있습니다. kubelet 시작 로그에 인쇄된 dockershim 사용 중단 경고 메시지를 안전하게 무시할 수 있습니다. Amazon EKS는 Amazon EKS 최적화 Amazon Linux 2 AMI의 런타임으로서 containerd로 이동될 예정입니다. 컨테이너 로드맵 문제에서 자세한 내용은 확인할 수 있습니다.

  • FQDN Pod 호스트 이름이 베타 상태로 전환되었습니다. 이 기능을 사용하면 pod의 호스트 이름을 FQDN(정규화된 도메인 이름)으로 설정하여 커널의 호스트 이름 필드를 pod의 FQDN으로 설정할 수 있습니다.

  • 이제 client-go 자격 증명 플러그 인이 KUBERNETES_EXEC_INFO 환경 변수를 통해 현재 클러스터 정보를 전달할 수 있습니다. 이러한 향상된 기능을 통해 Go 클라이언트는 키 관리 시스템(KMS)과 같은 외부 자격 증명 공급자를 사용하여 인증할 수 있습니다.

전체 Kubernetes 1.20 변경 로그를 확인하려면 https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md을 참조하세요.

Kubernetes 1.19

Kubernetes 1.19에 대한 자세한 내용을 알아보려면 공식 릴리스 발표를 참조하세요.

  • 1.19부터 Amazon EKS는 더 이상 kubernetes.io/cluster/my-cluster 태그를 클러스터 생성 중에 전달된 서브넷에 추가하지 않습니다. 이 서브넷 태그는 Kubernetes 서비스 컨트롤러 또는 AWS Load Balancer Controller가 탄력적 로드 밸런서를 배치하는 위치에 영향을 미치려는 경우에만 필요합니다. 클러스터 생성 중 Amazon EKS에 전달된 서브넷의 요구 사항에 대한 자세한 내용은 Amazon EKS VPC 및 서브넷 요구 사항과 고려 사항에 대한 업데이트를 참조하세요.

  • 더 이상 서비스 계정의 IAM 역할과 함께 사용하기 위해 웹 보안 인증 토큰 파일에 액세스해야 하는 루트가 아닌 컨테이너에 보안 컨텍스트를 제공할 필요가 없습니다. 자세한 내용은 서비스 계정에 대한 IAM 역할 및 GitHub의 예상 서비스 계정 볼륨에서 파일 권한 처리 제안을 참조하세요.

  • 누락된 시작 프로브 GitHub 문제를 해결하기 위해 pod ID 웹후크가 업데이트되었습니다. webhook는 이제 토큰 만료를 제어하는 주석을 지원합니다. 자세한 내용은 GitHub 풀 요청을 참조하세요.

  • CoreDNS 버전 1.8.0은 Amazon EKS 1.19 클러스터에 권장되는 버전입니다. 이 버전은 기본적으로 새로운 Amazon EKS 1.19 클러스터에 설치됩니다. 자세한 정보는 CoreDNS 추가 기능 관리을 참조하십시오.

  • Amazon EKS 최적화 Amazon Linux 2 AMI에는 Linux 버전 5.4용 Kubernetes 커널 버전 1.19가 포함되어 있습니다. 자세한 내용은 GitHub의 Changelog를 참조하세요.

  • CertificateSigningRequest API가 다음 변경 사항을 통해 안정적인 certificates.k8s.io/v1로 승격되었습니다.

    • 이제 spec.signerName이 필요합니다. certificates.k8s.io/v1 API를 사용하여 kubernetes.io/legacy-unknown에 대한 요청을 생성할 수 없습니다.

    • certificates.k8s.io/v1beta1 API를 사용하여 kubernetes.io/legacy-unknown 서명자 이름으로 CSR을 계속 생성할 수 있습니다.

    • CSR이 노드가 아닌 서버 인증서, webhook에 대해 서명되도록 계속 요청할 수 있습니다(예: certificates.k8s.io/v1beta1 API 사용). 이러한 CSR은 자동 승인되지 않습니다.

    • 인증서를 승인하려면 권한이 있는 사용자에게 kubectl 1.18.8 이후 버전이 필요합니다.

    인증서 v1 API에 대한 자세한 내용을 알아보려면 Kubernetes 설명서의 인증서 서명 요청을 참조하세요.

다음 Amazon EKS Kubernetes 리소스는 Kubernetes 컨트롤 플레인의 작동에 매우 중요합니다. 삭제하거나 편집하지 않는 것이 좋습니다.

권한 Kind 네임스페이스 이유
eks:certificate-controller Rolebinding kube-system 컨트롤 플레인의 서명자 및 승인자 기능에 영향을 줍니다.
eks:certificate-controller Role kube-system 컨트롤 플레인의 서명자 및 승인자 기능에 영향을 줍니다.
eks:certificate-controller ClusterRolebinding 모두 kubectl exec, kubectl logs 등의 특정 클러스터 기능에 영향을 미치는 서버 인증서를 요청하는 kubelet의 기능에 영향을 미칩니다.

다음 Kubernetes 기능은 이제 Kubernetes 1.19 Amazon EKS 클러스터에서 지원됩니다.

  • ExtendedResourceToleration 승인 컨트롤러가 활성화되었습니다. 이 승인 컨트롤러는 GPU와 같은 확장 리소스를 요청하는 pods에 테인트 허용 오차를 자동으로 추가합니다. 이렇게 하면 수동으로 허용 오차를 추가할 필요가 없습니다. 자세한 내용을 알아보려면 Kubernetes 설명서의 ExtendedResourceToleration을 참조하세요.

  • in-tree Kubernetes 서비스 컨트롤러에서 프로비저닝한 탄력적 로드 밸런서(CLB 및 NLB)는 인스턴스 대상으로 포함된 노드 필터링을 지원합니다. 이렇게 하면 대규모 클러스터에서 대상 그룹 제한에 도달하지 못하게 할 수 있습니다. 자세한 내용은 관련 GitHub 문제 및 Kubernetes 설명서의 기타 ELB 주석에서 service.beta.kubernetes.io/aws-load-balancer-target-node-labels 주석을 참조하세요.

  • 포드 토폴로지 스프레드가 안정적인 상태에 도달했습니다. 토폴로지 분산 제약 조건을 사용하여 리전, 영역, 노드 및 기타 사용자 정의 토폴로지 도메인과 같은 장애 도메인 간에 pods가 클러스터 전체에 분산되는 방식을 제어할 수 있습니다. 이를 통해 고가용성과 효율적인 리소스 활용도를 달성할 수 있습니다. 자세한 내용을 알아보려면 Kubernetes 문서의 포드 토폴로지 확산 제한 사항을 참조하세요.

  • Ingress API가 정식 출시 단계에 도달했습니다. 자세한 내용을 알아보려면 Kubernetes 문서의 Ingress를 참조하세요.

  • EndpointSlices는 기본적으로 활성화되어 있습니다. EndPointSlice는 서비스를 지원하는 포드에 대한 IP 주소, 포트, 준비 상태 및 토폴로지 정보를 추적하기 위한 엔드포인트 API에 대한 크기 조정 가능하고 확장 가능한 대안을 제공하는 새로운 API입니다. 자세한 내용을 알아보려면 Kubernetes 블로그에서 EndpointSlices로 Kubernetes 네트워킹 확장을 참조하세요.

  • 이제 비밀 및 ConfigMap 볼륨을 불변으로 표시할 수 있습니다. 이렇게 하면 클러스터에 많은 비밀 및 ConfigMap 볼륨이 있는 경우 API 서버의 로드가 크게 줄어듭니다. 자세한 내용을 알아보려면 Kubernetes 문서의 ConfigMap비밀을 참조하세요.

전체 Kubernetes 1.19 변경 로그를 확인하려면 https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.19.md을 참조하세요.

Kubernetes 1.18

Kubernetes 1.18에 대한 자세한 내용을 알아보려면 공식 릴리스 발표를 참조하세요.

다음 Kubernetes 기능은 이제 Kubernetes 1.18 Amazon EKS 클러스터에서 지원됩니다.

  • Topology Manager가 베타 상태에 도달했습니다. 이 기능을 통해 CPU 및 Device Manager는 리소스 할당 결정을 조정하고 기계 학습 및 분석 워크로드의 대기 시간을 최적화할 수 있습니다. 자세한 내용을 알아보려면 Kubernetes 설명서에서 노드에 대한 제어 토폴로지 관리 정책을 참조하세요.

  • 서버 측 적용이 새로운 베타 버전으로 업데이트되었습니다. 이 기능은 모든 새 Kubernetes 객체의 필드에 대한 변경 사항을 추적하고 관리합니다. 이렇게 하면 리소스가 변경된 내용과 시기를 알 수 있습니다. 자세한 내용을 알아보려면 Kubernetes 문서의 서버 측 적용이란?을 참조하세요.

  • 새로운 pathType 필드와 IngressClass 리소스가 Ingress 사양에 추가되었습니다. 이러한 기능을 사용하면 수신 구성을 보다 간단하게 사용자 지정할 수 있으며 AWS Load Balancer Controller(이전 ALB Ingress Controller)에서 지원됩니다. 자세한 내용을 알아보려면 Kubernetes 설명서에서 Kubernetes1.18의 Ingress API 개선 사항을 참조하세요.

  • 구성 가능한 수평적 pod 자동 크기 조정 동작. 자세한 내용을 알아보려면 Kubernetes 설명서에서 구성 가능한 확장 크기 조정 동작 지원을 참조하세요.

  • 새 클러스터에는 externalTrafficPolicy의 업데이트된 기본값이 포함되어 있습니다. HealthyThresholdCountUnhealthyThresholdCount 각각은 2개이며 HealthCheckIntervalSeconds가 10초로 줄어들었습니다. 이전 버전에서 생성되고 업그레이드된 클러스터는 이전 값을 유지합니다.

전체 Kubernetes 1.18 변경 로그를 확인하려면 https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.18.md을 참조하세요.

Amazon EKS Kubernetes 릴리스 일정

참고

월과 연도만 있는 날짜는 대략적인 날짜이며 알 수 있는 정확한 날짜로 업데이트됩니다.

Kubernetes 버전 업스트림 릴리스 Amazon EKS 릴리스 Amazon EKS 지원 종료
1.24 2022년 5월 3일 2022년 11월 2024년 1월
1.23 2021년 12월 7일 2022년 8월 11일 2023년 10월
1.22 2021년 8월 4일 2022년 4월 4일 2023년 5월
1.21 2021년 4월 8일 2021년 7월 19일 2023년 2월
1.20 2020년 12월 8일 2021년 5월 18일 2022년 11월 1일
1.19 2020년 8월 26일 2021년 2월 16일 2022년 8월 1일
1.18 2020년 3월 23일 2020년 10월 13일 2022년 3월 31일

Amazon EKS 버전 지원 및 FAQ

Kubernetes 커뮤니티가 지원하는 Kubernetes 버전에 따라 Amazon EKS는 해당하는 시간에 최소 4개의 프로덕션 지원 Kubernetes 버전을 전격 지원합니다. 지정된 Kubernetes 마이너 버전의 지원 종료일은 최소한 종료일 60일 전에 공지합니다. 새로운 Kubernetes 버전에 대한 Amazon EKS 인증 및 릴리스 프로세스로 인해, Amazon EKS의 Kubernetes 버전 지원 종료일은 Kubernetes 프로젝트가 버전 업스트림 지원을 중지하는 날짜 또는 이후가 됩니다.

FAQ

Q: Kubernetes 버전은 Amazon EKS에서 얼마 동안 지원되나요?

A: Kubernetes 버전은 Amazon EKS에서 처음 제공된 후 14개월 동안 지원됩니다. 업스트림 Kubernetes가 Amazon EKS에서 제공되는 버전을 더 이상 지원하지 않는 경우에도 마찬가지입니다. Amazon EKS에서 지원되는 Kubernetes 버전에 적용할 수 있는 보안 패치를 백포트하고 있습니다.

Q: Amazon EKS에서 Kubernetes 버전에 대한 지원이 종료되면 알림을 받을 수 있나요?

A: 예. 계정의 클러스터에서 지원 종료 시점이 거의 도래한 버전을 실행 중인 경우 Amazon EKS는 Kubernetes 버전이 Amazon EKS에서 릴리스된 후 약 12개월되는 시점에 AWS Health Dashboard를 통해 알림을 보냅니다. 알림에는 지원 종료 날짜가 포함됩니다. 공지일로부터 최소 60일이 소요됩니다.

Q: 지원 종료 날짜에는 어떻게 됩니까?

A: 지원 종료 날짜에는 지원되지 않는 버전으로 새 Amazon EKS 클러스터를 더이상 생성할 수 없게 됩니다. 지원 종료 날짜 이후 점진적인 배포 프로세스를 통해 Amazon EKS에 의해 기존 컨트롤 플레인이 지원되는 최신 버전으로 자동 업데이트됩니다. 자동 컨트롤 플레인 업데이트 후에는 클러스터 추가 기능 및 Amazon EC2 노드를 수동으로 업데이트해야 합니다. 자세한 정보는 Amazon EKS 클러스터의 Kubernetes 버전 업데이트 을 참조하십시오.

Q: 지원 종료 날짜 이후에 컨트롤 플레인이 정확히 언제 자동으로 업데이트되나요?

A: Amazon EKS는 특정 기간을 제공할 수 없습니다. 자동 업데이트는 지원 종료 날짜 이후 언제든지 발생할 수 있습니다. 업데이트 전에 알림이 제공되지 않습니다. Amazon EKS 자동 업데이트 프로세스에 의존하지 않고 선제적으로 컨트롤 플레인을 업데이트하는 것이 좋습니다. 자세한 정보는 Amazon EKS 클러스터 Kubernetes 버전 업데이트을 참조하십시오.

Q: 컨트롤 플레인을 Kubernetes 버전에 무한정 그대로 둘 수 있나요?

A: 아니요. AWS에서 클라우드 보안을 가장 중요하게 생각합니다. 특정 시점(보통 1년)이 지난 후 Kubernetes 커뮤니티는 일반 취약성 및 노출(CVE) 패치 릴리스를 중단하고 지원되지 않는 버전의 CVE 제출을 금지합니다. 즉, Kubernetes의 이전 버전과 관련된 취약성은 보고되지 않을 수도 있습니다. 이렇게 하면 취약성의 경우 통지 및 수정 옵션 없이 클러스터를 노출합니다. 이를 고려하여 Amazon EKS는 컨트롤 플레인이 지원 종료에 도달한 버전을 유지하도록 허용하지 않습니다.

Q: Amazon EKS에서 지원하는 Kubernetes 기능은 무엇인가요?

A: Amazon EKS는 일반적으로 사용 가능한 Kubernetes API의 모든 기능을 지원합니다. 또한 기본적으로 사용 설정되어 있는 모든 베타 기능도 지원합니다. 알파 기능은 지원되지 않습니다.

Q: Amazon EKS 관리형 노드 그룹은 클러스터 컨트롤 플레인 버전과 함께 자동으로 업데이트됩니까?

A: 아니요. 관리형 노드 그룹은 사용자 계정에 Amazon EC2 인스턴스를 생성합니다. 이러한 인스턴스는 사용자 또는 Amazon EKS가 컨트롤 플레인을 업데이트할 때 자동으로 업그레이드되지 않습니다. Amazon EKS가 컨트롤 플레인을 자동으로 업데이트한다고 가정합니다. 관리되는 노드 그룹에 있는 Kubernetes 버전은 해당 컨트롤 플레인보다 두 버전 이상 이전 버전일 수 있습니다. 그런 다음 관리형 노드 그룹에 컨트롤 플레인보다 두 버전 이상 이전 버전의 Kubernetes를 실행 중인 인스턴스가 포함되어 있다고 가정합니다. 노드 그룹의 상태 문제는 콘솔의 클러스터에서 컴퓨팅(Compute) 탭의 노드 그룹(Node Groups) 섹션에 있습니다. 마지막으로 노드 그룹에 사용 가능한 버전 업데이트가 있는 경우 지금 업데이트(Update now)가 콘솔의 노드 그룹 옆에 표시됩니다. 자세한 정보는 관리형 노드 그룹 업데이트을 참조하십시오. 컨트롤 플레인과 노드에 동일한 Kubernetes 버전을 유지하는 것이 좋습니다.

Q: 자체 관리형 노드 그룹은 클러스터 컨트롤 플레인 버전과 함께 자동으로 업데이트됩니까?

A: 아니요. 자체 관리형 노드 그룹은 사용자 계정에 Amazon EC2 인스턴스를 포함합니다. 이러한 인스턴스는 사용자 또는 Amazon EKS가 컨트롤 플레인 버전을 업데이트할 때 자동으로 업그레이드되지 않습니다. 자체 관리형 노드 그룹에는 콘솔에 업데이트가 필요하다는 표시가 없습니다. 클러스터의 개요(Overview) 탭에 있는 노드(Nodes) 목록에서 노드를 선택하여 노드에 설치된 kubelet 버전을 확인하면 업데이트가 필요한 노드를 확인할 수 있습니다. 노드를 수동으로 업데이트해야 합니다. 자세한 정보는 자체 관리형 노드 업데이트을 참조하십시오.

Kubernetes 프로젝트는 최대 두 개의 마이너 버전에 대한 컨트롤 플레인과 노드 간의 호환성을 테스트합니다. 예를 들어 1.21 노드는 1.23 컨트롤 플레인에 의해 오케스트레이션될 경우 계속 작동합니다. 그러나 컨트롤 플레인보다 지속적으로 2개 버전 낮은 마이너 버전이 있는 노드가 있는 클러스터를 실행하는 것은 권장되지 않습니다. 자세한 내용을 알아보려면 Kubernetes 설명서의 Kubernetes 버전 및 버전 차이 지원 정책을 참조하세요. 컨트롤 플레인과 노드에 동일한 Kubernetes 버전을 유지하는 것이 좋습니다.

Q: Fargate에서 실행되는 pods는 자동 클러스터 컨트롤 플레인 버전 업그레이드로 자동 업그레이드되나요?

예. Fargate pods는 공동 책임 모델의 Amazon EKS 측 AWS 소유 계정 내 인프라에서 실행됩니다. Amazon EKS는 Kubernetes 제거 API를 사용하여 Fargate에서 실행되는 pods를 정상적으로 비웁니다. 자세한 내용을 알아보려면 Kubernetes 설명서의 제거 API를 참조하세요. pod를 제거할 수 없는 경우 Amazon EKS는 Kubernetes delete pod 명령을 실행합니다. Kubernetes 배포와 같은 복제 컨트롤러의 일부로 Fargate pods를 실행하는 것이 좋습니다. 이렇게 하면 pod는 삭제 후 자동으로 다시 예약됩니다. 자세한 내용을 알아보려면 Kubernetes 문서의 배포를 참조하세요. Fargate pod의 새 버전은 업데이트된 클러스터 컨트롤 플레인 버전과 동일한 kubelet 버전을 사용하여 배포됩니다.

중요

컨트롤 플레인을 업데이트하는 경우 Fargate 노드를 직접 업데이트해야 합니다. Fargate 노드를 업데이트하려면 노드가 나타내는 Fargate pod를 삭제하고 pod를 다시 배포합니다. 새 pod는 클러스터와 동일한 kubelet 버전을 사용하여 배포됩니다.