Amazon EKS Kubernetes 버전 - Amazon EKS

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

Amazon EKS Kubernetes 버전

Kubernetes 프로젝트는 새로운 기능, 디자인 업데이트, 버그 수정으로 빠르게 진화하고 있습니다. 커뮤니티는 일반적으로 약 3개월마다 사용할 수 있는 새 Kubernetes 마이너 버전(예: 191.)을 릴리스하며, 각 마이너 버전은 최초 릴리스 후 약 12개월 동안 지원됩니다.

사용 가능한 Amazon EKS Kubernetes 버전

현재 다음 Kubernetes 버전을 의 새로운 클러스터에 사용할 수 있습니다.Amazon EKS:

  • 1.19.6

  • 1.18.9

  • 1.17.12

  • 1.16.15

  • 1.15.12

애플리케이션에서 특정 Kubernetes 버전이 필요하지 않은 한, Amazon EKS가 클러스터에 대해 지원하는 최신 버전의 Kubernetes를 선택하는 것이 좋습니다. Amazon EKS에서 새로운 Kubernetes 버전이 사용 가능해지면 미리 최신 버전을 사용하여 클러스터를 업데이트할 것을 권장합니다. 자세한 내용은 단원을 참조하세요.클러스터 업데이트. 자세한 내용은 Amazon EKS Kubernetes 릴리스 일정Amazon EKS 버전 지원 및 FAQ. 단원을 참조하십시오.

Kubernetes 1.19

이제 에서 Kubernetes 1.19을 사용할 수 있습니다.Amazon EKS. Kubernetes 1.19에 대한 자세한 내용은 공식 릴리스 발표.를 참조하십시오.

Important

  • 1.19부터는 가 클러스터 생성 중에 전달된 서브넷에 더 이상 Amazon EKS 태그를 추가kubernetes.io/cluster/<cluster-name>하지 않습니다. 이 서브넷 태그는 Kubernetes 서비스 컨트롤러 또는 AWS Load Balancer 컨트롤러가 Elastic Load Balancer를 배치하는 위치에 영향을 주려는 경우에만 필요합니다. 클러스터 생성 Amazon EKS 중에 에 전달되는 서브넷의 요구 사항에 대한 자세한 내용은 에 대한 업데이트를 참조하십시오클러스터 VPC 고려 사항.

    • 1.19로 업데이트된 기존 클러스터에서는 서브넷 태그가 수정되지 않습니다.

    • AWS Load Balancer 컨트롤러 버전 v2.1.1 및 이전 버전에는 가 필요했습니다.<cluster-name> 서브넷 태그. 버전 v2.1.2 이상에서는 태그를 지정하여 서브넷 검색을 구체화할 수 있지만 필수는 아닙니다. AWS Load Balancer 컨트롤러에 대한 자세한 내용은 단원을 참조하십시오AWS Load Balancer 서 컨트롤러. 로드 밸런서 사용 시 서브넷 태그 지정에 대한 자세한 내용은 의 애플리케이션 로드 밸런싱 Amazon EKS 및 단원을 참조하십시오의 네트워크 로드 밸런싱 Amazon EKS.

  • 서비스 계정의 IAM 역할에 사용하기 위해 웹 자격 증명 토큰 파일에 액세스해야 하는 비 루트 컨테이너에 대한 보안 컨텍스트를 더 이상 제공할 필요가 없습니다. 자세한 내용은 IAM서비스 계정에 대한 역할의 프로젝션된 서비스 계정 볼륨에서 파일 권한 처리 제안을 참조하십시오GitHub.

  • 포드 자격 증명 Webhook가 누락된 시작 프로브 GitHub 문제를 해결하도록 업데이트되었습니다. Webhook는 이제 토큰 만료를 제어하는 주석도 지원합니다. 자세한 내용은 GitHub pull 요청을 참조하십시오.

  • CoreDNS 버전 1.8.0은 Amazon EKS 1.19 클러스터에 권장되는 버전입니다. 이 버전은 새 Amazon EKS 1.19 클러스터에 기본적으로 설치됩니다. 자세한 내용은 단원을 참조하세요. 설치 또는 업그레이드CoreDNS.

  • Amazon EKS 최적화에는 Kubernetes 버전 1.19용 Linux 커널 버전 5.4가 Amazon Linux 2 AMIs 포함됩니다. 자세한 내용은 단원을 참조하세요.Amazon EKS 최적화된 Amazon Linux AMI.

  • CertificateSigningRequest API 는 다음과 같은 변경 사항certificates.k8s.io/v1으로 안정적인 로 승격되었습니다.

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

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

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

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

    인증서 v1 API에 대한 자세한 내용은 Kubernetes 설명서의 인증서 서명 요청을 참조하십시오.

다음 Amazon EKS Kubernetes 리소스는 Kubernetes 제어 플레인이 작동하는 데 중요합니다. 삭제하거나 편집하지 않는 것이 좋습니다.

권한 Kind 네임스페이스 Reason
eks:certificate-controller Rolebinding kube-system 제어 플레인의 서명자 및 승인자 기능에 영향을 줍니다.
eks:certificate-controller Role kube-system 제어 플레인의 서명자 및 승인자 기능에 영향을 줍니다.
eks:certificate-controller ClusterRolebinding 모두 Kubelet의 서버 인증서 요청 기능에 영향을 미치며, kubectl exec 이는 및 와 같은 특정 클러스터 기능에 영향을 미칩니다kubectl logs.

이제 Kubernetes 1.19 Amazon EKS 클러스터에서 지원되는 Kubernetes 기능은 다음과 같습니다.

  • ExtendedResourceToleration 승인 컨트롤러가 활성화되어 있습니다. 이 승인 컨트롤러는 와 같은 확장 리소스를 요청하는 포드에 테인트에 대한 내결함성을 자동으로 추가GPUs하므로, 내결함성을 수동으로 추가할 필요가 없습니다. 자세한 내용은 Kubernetes 설명서의 단원ExtendedResourceToleration을 참조하십시오.

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

  • Pod Topology Spread가 안정적인 상태에 도달했습니다. 토폴로지 분산 제약 조건을 사용하여 리전, 영역, 노드 및 기타 사용자 정의 토폴로지 도메인과 같은 실패 도메인 간에 포드가 클러스터에 분산되는 방식을 제어할 수 있습니다. 이를 통해 고가용성과 효율적인 리소스 활용을 달성할 수 있습니다. 자세한 내용은 Kubernetes 설명서의 Pod Topology Spread Constraints를 참조하십시오.

  • 수신 API가 정식 출시에 도달했습니다. 자세한 내용은 Kubernetes 설명서의 수신을 참조하십시오.

  • EndpointSlices 는 기본적으로 활성화되어 있습니다. EndpointSlices 는 서비스를 지원하는 Pod에 대한 IP 주소, 포트, 준비성 및 토폴로지 정보를 추적하기 위해 엔드포인트 API에 대해 보다 확장 가능하고 확장 가능한 대안을 제공하는 새로운 API입니다. 자세한 내용은 Kubernetes 블로그EndpointSlices의 Scaling Kubernetes Networking With 단원을 참조하십시오.

  • 이제 보안 암호와 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을 사용할 수 있습니다.Amazon EKS. Kubernetes 1.18에 대한 자세한 내용은 공식 릴리스 발표.를 참조하십시오.

이제 Kubernetes 1.18 Amazon EKS 클러스터에서 지원되는 Kubernetes 기능은 다음과 같습니다.

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

  • 서버 측 적용이 새 베타 버전으로 업데이트됩니다. 이 기능은 모든 새 Kubernetes 객체의 필드에 대한 변경 사항을 추적 및 관리하므로 리소스의 변경 사항과 변경 시기를 알 수 있습니다. 자세한 내용은 Kubernetes 설명서의 서버 측 적용이란 무엇입니까?를 참조하십시오.

  • pathType 필드와 새 IngressClass 리소스가 수신 사양에 추가되었습니다. 이러한 기능을 사용하면 수신 구성을 사용자 지정할 필요가 없으며 AWS 로드 Load Balancer 서 컨트롤러(이전에는 ALB 수신 컨트롤러라고 함)에서 지원됩니다. 자세한 내용은 Kubernetes 설명서의 Kubernetes 1.18에서 수신 API에 대한 개선 사항을 참조하십시오.

  • 구성 가능한 수평 포드 Autoscaling 동작. 자세한 내용은 Kubernetes 설명서의 구성 가능한 조정 동작 https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-configurable-scaling-behavior 지원을 참조하십시오.

  • 1.18 클러스터에서는 변형 웹 후크를 사용하든 AWS_DEFAULT_REGION=<region-code> 환경 변수를 수동으로 구성하든 중국 리전의 서비스 계정에 IAM 대한 역할을 사용할 때 더 이상 포드에 환경 변수를 포함할 필요가 없습니다. 이전 버전의 모든 포드에 대한 변수를 여전히 포함해야 합니다.

완전한 Kubernetes 1.18 변경 로그는 https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.18.md.를 참조하십시오.

Kubernetes 1.17

이제 에서 Kubernetes 1.17을 사용할 수 있습니다.Amazon EKS. Kubernetes 1.17에 대한 자세한 내용은 공식 릴리스 발표.를 참조하십시오.

중요
  • EKS가 CSIMigrationAWS 기능 플래그를 활성화하지 않았습니다. 이 기능은 향후 릴리스에서 활성화되며 자세한 마이그레이션 지침도 제공됩니다. CSI 마이그레이션에 대한 자세한 내용은 Kubernetes 블로그를 참조하십시오.

  • AWS Fargate 포드 중 하나에 1.16 이전 kubelet 마이너 버전이 있는 경우 클러스터를 1.16에서 1.17로 업데이트하지 못합니다. 클러스터를 1.16에서 1.17로 업데이트하기 전에 포드를 재활용하여 클러스터를 Fargate 1.16이 kubelet 되도록 해야 합니다. 1.15 이상 클러스터에서 Kubernetes 배포를 재활용하려면 다음 명령을 사용합니다.

    kubectl rollout restart deployment <deployment-name>

이제 Kubernetes 1.17 Amazon EKS 클러스터에서 지원되는 Kubernetes 기능은 다음과 같습니다.

완전한 Kubernetes 1.17 변경 로그는 https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.17.md.를 참조하십시오.

Kubernetes 1.16

이제 에서 Kubernetes 1.16을 사용할 수 있습니다.Amazon EKS. Kubernetes 1.16에 대한 자세한 내용은 공식 릴리스 발표.를 참조하십시오.

중요
  • Kubernetes 1.16은 중단된 를 다수 제거합니다APIs. 클러스터를 1.16으로 업데이트하기 전에 애플리케이션을 변경해야 할 수 있습니다. 업데이트하기 전에 1.16 업데이트 사전 조건을 주의 깊게 따르십시오.

  • 1.16부터 Amazon EKS 인증 기관은 SAN X.509 확장이 포함된 인증서 서명 요청을 준수합니다. 그러면 의 EKS CA는 SAN x509 확장 기능 요청을 준수해야 합니다GitHub.

이제 Kubernetes 1.16 Amazon EKS 클러스터에서 지원되는 Kubernetes 기능은 다음과 같습니다.

  • CSI 사양의 볼륨 확장이 베타로 전환되어 모든 CSI 사양 볼륨 플러그인의 크기를 조정할 수 있습니다. 자세한 내용은 Kubernetes CSI 설명서의 볼륨 확장을 참조하십시오. 최신 버전의 EBS CSI 드라이버는 Amazon EKS 1.16 클러스터에서 실행될 때 볼륨 확장을 지원합니다.

  • Windows GMSA 지원은 알파에서 베타로 전환되었으며, 이제 에서 지원됩니다.Amazon EKS. 자세한 내용은 Kubernetes 설명서의 Windows 포드 및 컨테이너에 대해 GMSA 구성을 참조하십시오.

  • 새로운 주석: service.beta.kubernetes.io/aws-load-balancer-eip-allocations는 서비스 유형 LoadBalancer에서 탄력적 IP 주소를 네트워크 로드 밸런서에 할당하는 데 사용할 수 있습니다. 자세한 내용은 AWS NLB를 사용한 EIP 할당 지원 GitHub 문제를 참조하십시오.

  • 서비스 로드 밸런서용 Finalizer Protection은 현재 베타 버전이며 기본적으로 활성화되어 있습니다. Service Load Balancer Finalizer Protection을 사용하면 서비스가 삭제될 때 AWS Network Load Balancer와 같은 Kubernetes Service 객체에 할당된 모든 로드 밸런서 리소스가 삭제되거나 릴리스됩니다. 자세한 내용은 Kubernetes 설명서의 가비지 수집 로드 밸런서를 참조하십시오.

  • Kubernetes 사용자 지정 리소스 정의 및 승인 Webhook 확장성 메커니즘은 모두 정식 출시에 도달했습니다. 자세한 내용은 Kubernetes 설명서의 사용자 지정 리소스동적 승인 제어를 참조하십시오.

  • 서버 측 적용 기능이 베타 상태에 도달했으며 기본적으로 활성화되어 있습니다. 자세한 내용은 Kubernetes 설명서의 서버 측 적용을 참조하십시오.

  • CustomResourceDefaulting 기능은 베타로 승격되고 기본적으로 활성화됩니다. 기본값은 apiextensions.k8s.io/v1 API를 통해 구조 스키마에서 지정할 수 있습니다. 자세한 내용은 Kubernetes 설명서의 구조 스키마 https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#specifying-a-structural-schema 지정을 참조하십시오.

완전한 Kubernetes 1.16 변경 로그는 https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.16.md.를 참조하십시오.

Kubernetes 1.15

이제 에서 Kubernetes 1.15를 사용할 수 있습니다.Amazon EKS. Kubernetes 1.15에 대한 자세한 내용은 공식 릴리스 발표.를 참조하십시오.

중요

1.15부터는 Amazon EKS가 더 이상 클러스터가 포함된 VPC에 태그를 지정하지 않습니다.

  • 클러스터의 VPC 내의 서브넷에는 여전히 태그가 지정되어 있습니다.

  • 기존 클러스터를 1.15로 업데이트할 때는 VPC 태그가 수정되지 않습니다.

중요

Amazon EKS 는 포드 자격 증명 Webhook에 대한 재호출 정책을 로 설정IfNeeded했습니다. 이렇게 하면 App Mesh 사이드카 인젝터와 같은 다른 변형 승인 Webhook에 의해 객체가 변경되는 경우 Webhook를 다시 호출할 수 있습니다. App Mesh 사이드카 인젝터에 대한 자세한 내용은 사이드카 인젝터 설치.를 참조하십시오.

이제 Kubernetes 1.15 Amazon EKS 클러스터에서 지원되는 기능은 다음과 같습니다.

  • EKS는 이제 네트워크 로드 밸런서에 대한 전송 계층 보안(TLS) 종료, 액세스 로그 및 소스 범위의 구성을 지원합니다. 자세한 내용은 의 AWS에서 Network Load Balancer 지원을 참조하십시오GitHub.

  • 버전 간에 즉시 변환할 수 있는 기능을 포함하여 CRD(사용자 지정 리소스 정의)의 유연성이 향상되었습니다. 자세한 내용은 CustomResourceDefinitions 에서 로 Kubernetes API 확장을 참조하십시오GitHub.

  • NodeLocal DNSCache 는 Kubernetes 버전 1.15 클러스터용 베타 버전입니다. 이 기능은 클러스터 노드에서 DNS 캐싱 에이전트를 로 실행하여 클러스터 DNS 성능을 개선하는 데 도움이 될 수 DaemonSet있습니다. 자세한 내용은 NodeLocal 의 Kubernetes 클러스터DNSCache에서 사용을 참조하십시오GitHub.

    참고

    CoreDNS 에서 실행할 때는 Amazon EC2 구성에서 를 사용하지 말고 force_tcp에서 가 설정options use-vc되지 않았는지 확인하는 것이 좋습니다/etc/resolv.conf.

완전한 Kubernetes 1.15 변경 로그는 https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.15.md.를 참조하십시오.

Amazon EKS Kubernetes 릴리스 일정

참고

월과 연도만 있는 날짜는 근사값이며 알고 있는 정확한 날짜로 업데이트됩니다.

Kubernetes 버전 업스트림 릴리스 Amazon EKS 릴리스 Amazon EKS 지원 종료
1.15 2019년 6월 19일 2020년 3월 10일 2021년 5월 3일
1.16 2019년 9월 8일 2020년 4월 30일 2021년 7월
1.17 2019년 12월 9일 2020년 7월 10일 2021년 9월
1.18 2020년 3월 23일 2020년 10월 13일 2021년 11월
1.19 - 2020년 8월 26일 2021년 2월 16일 2022년 4월
1.20 2020년 12월 8일 2021년 4월 2022년 6월

Amazon EKS 버전 지원 및 FAQ

Kubernetes 커뮤니티의 Kubernetes 버전 지원에 따라 Amazon EKS 는 지정된 시간에 최소 4개의 프로덕션 지원 Kubernetes 버전을 지원하는 데 커밋됩니다. AWS는 지정된 Kubernetes 마이너 버전의 지원 종료일을 지원 종료일로부터 최소 60일 전에 발표합니다. 새 Kubernetes 버전에 대한 Amazon EKS 검증 및 릴리스 프로세스 때문에 의 Kubernetes 버전 지원 종료일은 Kubernetes 프로젝트가 버전 업스트림 지원을 중지하는 날짜 당일 또는 그 이후Amazon EKS가 됩니다.

FAQ

Q: Kubernetes 버전이 에서 지원되는 기간은 얼마나 Amazon EKS됩니까?

A: 에서 처음 사용 가능해진 후 14개월 동안 Kubernetes 버전이 완전히 지원됩니다Amazon EKS. 업스트림 Kubernetes가 에서 제공되는 버전을 더 이상 지원하지 않는 경우에도 마찬가지입니다.Amazon EKS. 에서 지원되는 Kubernetes 버전에 해당하는 보안 패치를 백포트Amazon EKS합니다.

Q: 에서 Kubernetes 버전에 대한 지원이 종료될 때 알림을 받Amazon EKS나요?

A: 예. 계정의 클러스터에서 지원 종료에 가까운 버전을 실행 중인 경우 는 에서 Kubernetes 버전이 릴리스된 후 Amazon EKS 약 12개월이 지나면 를 통해 알림을 AWS Personal Health Dashboard 보냅니다Amazon EKS. 이 알림에는 지원 종료일이 포함되며, 이 날짜는 알림 날짜로부터 60일 이상 경과한 날짜입니다.

Q: 지원 종료일이 어떻게 됩니까?

A: 지원 종료일이 되면 더 이상 지원되지 않는 버전으로 새 Amazon EKS 클러스터를 생성할 수 없습니다. 기존 제어 플레인은 지원 날짜가 종료된 후 점진적Amazon EKS인 배포 프로세스를 통해 에서 가장 오래된 지원 버전으로 자동 업데이트됩니다. 자동 제어 플레인 업데이트 후 클러스터 추가 기능 및 Amazon EC2 노드를 수동으로 업데이트해야 합니다. 자세한 내용은 단원을 참조하세요.기존 클러스터 업데이트.

Q: 지원 날짜가 끝난 후 제어 플레인이 정확하게 언제 자동으로 업데이트됩니까?

A: Amazon EKS 는 특정 기간을 제공할 수 없습니다. 자동 업데이트는 지원 날짜가 종료된 후 언제든지 발생할 수 있습니다. Amazon EKS 자동 업데이트 프로세스에 의존하지 않고 사전 예방적 작업을 수행하고 제어 플레인을 업데이트하는 것이 좋습니다. 자세한 내용은 단원을 참조하세요.클러스터 업데이트.

Q: Kubernetes 버전에 컨트롤 플레인을 무기한으로 둘 수 있습니까?

A: 아니요. 의 클라우드 보안AWS이 가장 높은 우선 순위입니다. Amazon EKS 는 제어 플레인이 지원 종료에 도달한 버전에 유지되도록 허용하지 않습니다.

Q: 에서 지원되는 Kubernetes 기능은 Amazon EKS무엇입니까?

A: 는 Kubernetes API의 모든 일반 가용성 기능과 기본적으로 활성화된 베타 기능을 Amazon EKS 지원합니다. 알파 기능은 지원되지 않습니다.

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

A: 아니요. 관리형 노드 그룹은 계정에 Amazon EC2 인스턴스를 생성합니다. 제어 플레인을 업데이트하거나 Amazon EKS 업데이트할 때 이러한 인스턴스는 자동으로 업그레이드되지 않습니다. 에서 제어 플레인을 Amazon EKS 자동으로 업데이트하는 경우 관리형 노드 그룹의 Kubernetes 버전이 제어 플레인보다 두 개 이상 이전 버전일 수 있습니다. 관리형 노드 그룹에 제어 플레인보다 두 개 이상 이전 버전의 Kubernetes 버전을 실행하는 인스턴스가 포함된 경우, 노드 그룹은 콘솔에 있는 클러스터의 구성 탭에 있는 컴퓨팅 탭의 노드 그룹 섹션에 상태 문제가 있습니다. 노드 그룹에 사용 가능한 버전 업데이트가 있는 경우 콘솔에서 노드 그룹 옆에 Update now(지금 업데이트)가 나타납니다. 자세한 내용은 단원을 참조하세요.관리형 노드 그룹 업데이트. 제어 플레인 및 노드에서 동일한 Kubernetes 버전을 유지하는 것이 좋습니다.

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

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

Kubernetes 프로젝트는 최대 2개의 마이너 버전에 대한 제어 플레인과 노드 간의 호환성을 테스트합니다. 예를 들어 제어 1.17 플레인에 의해 오케스트레이션되는 1.19 노드는 계속 작동합니다. 그러나 제어 플레인 뒤에 두 개의 마이너 버전이 지속적으로 있는 노드가 있는 클러스터를 실행하는 것은 권장되지 않습니다. 자세한 내용은 Kubernetes 설명서의 Kubernetes 버전 및 버전 스큐 지원 정책을 참조하십시오. 제어 플레인 및 노드에서 동일한 Kubernetes 버전을 유지하는 것이 좋습니다.

Q: 자동 클러스터 제어 플레인 버전 업그레이드를 통해 에서 포드가 Fargate 자동으로 업그레이드됩니까?

예. Fargate 포드는 AWS Amazon EKS공동 책임 모델의 소유 계정에 있는 인프라에서 실행됩니다. Amazon EKS 는 Kubernetes 제거 API를 사용하여 에서 실행되는 포드를 적절하게 드레이닝하려고 시도합니다Fargate. 자세한 내용은 Kubernetes 설명서의 Eviction API를 참조하십시오. 포드를 제거할 수 없는 경우 는 Kubernetes Amazon EKS 명령을 delete pod 실행합니다. 삭제 후 Fargate 포드가 자동으로 다시 예약되도록 Kubernetes 배포와 같은 복제 컨트롤러의 일부로 포드를 실행하는 것이 좋습니다. 자세한 내용은 Kubernetes 설명서의 배포를 참조하십시오. Fargate 포드의 새 버전은 업데이트된 클러스터 제어 플레인 kubelet 버전과 동일한 버전으로 배포됩니다.

중요

제어 플레인을 업데이트하는 경우 Fargate 노드를 직접 업데이트해야 합니다. Fargate 노드를 업데이트하려면 노드로 표시되는 Fargate 포드를 삭제하고 포드를 다시 배포합니다. 새 포드는 클러스터와 kubelet 동일한 버전으로 배포됩니다.