Amazon EKS 버전 - Amazon EKS

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

Amazon EKS 버전

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

사용 가능한 아마존 EKS 쿠버네테스 버전

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

  • 1.20.4

  • 1.19.8

  • 1.18.16

  • 1.17.17

  • 1.16.15

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

Kubernetes 1.20

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

Important

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

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

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

  • 프로세스 ID 제한는 이제 일반 공급으로 졸업했습니다.

  • 쿠바 디버그베타 상태에 도달했습니다.kubectl debug에서 직접 일반적인 디버깅 워크플로에 대한 지원을 제공합니다.kubectl.

  • Docker 컨테이너 런타임은 이제 사용되지 않습니다. 쿠버네테스 커뮤니티는블로그 게시물전용과 함께 자세히 이것에 대해FAQ 페이지. 도커에서 제작 한 이미지는 계속 사용할 수 있으며 항상 사용할 수 있습니다. kubelet 시작 로그에 인쇄 된 dockershim 사용 중단 경고 메시지를 안전하게 무시할 수 있습니다. EKS에 최적화된 Amazon Linux 2 AMI 의 런타임으로 EKS에 컨테이너로 이동합니다. 컨테이너 로드맵을 따를 수 있습니다.issue자세한 내용은..

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

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

완전한 Kubernetes 1.20 변경 로그는https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md

Kubernetes 1.19

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

Important

  • 1.19부터 아마존 EKS는 더 이상kubernetes.io/cluster/<cluster-name>태그를 클러스터 생성 중에 전달된 서브넷에 추가할 수 있습니다. 이 서브넷 태그는 Kubernetes 서비스 컨트롤러 또는AWSLoad Balancer 컨트롤러는 탄력적 로드 밸런서를 배치합니다. 클러스터 생성 중 Amazon EKS에 전달된 서브넷의 요구 사항에 대한 자세한 내용은클러스터 VPC 고려 사항.

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

    • 이AWSLoad Balancer 컨트롤러 버전v2.1.1및 이전 버전에는<cluster-name>서브넷 태그입니다. 버전v2.1.2나중에 태그를 지정하여 서브넷 검색을 세분화할 수 있지만 필수는 아닙니다. 에 대한 자세한 내용은 단원을 참조하십시오.AWSLoad Balancer 컨트롤러에 대한 자세한 내용은AWSLoad Balancer. 로드 밸런서 사용 시 서브넷 태그 지정에 대한 자세한 내용은 단원을 참조하십시오.Amazon EKSAmazon EKS.

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

  • 포드 ID 웹훅이 업데이트되어시작 프로브 누락GitHub 문제. 웹 훅은 이제 토큰 만료를 제어하는 주석을 지원합니다. 자세한 내용은 단원을 참조하십시오.GitHub 풀 요청.

  • CoreDNS 버전 1.8.0은 아마존 EKS 1.19 클러스터에 권장되는 버전입니다. 이 버전은 기본적으로 새로운 Amazon EKS 1.19 클러스터에 설치됩니다. 자세한 내용은 CoreDNS 추가 기능 관리 단원을 참조하세요.

  • 아마존 EKS 최적화 아마존 리눅스 2 AMI에는 Kubernetes 버전 1.19용 리눅스 커널 버전 5.4가 포함되어 있습니다. 자세한 내용은 Amazon EKS에 최적화된 단원을 참조하세요.

  • CertificateSigningRequest API안정 승진 된certificates.k8s.io/v1다음과 같은 변경이 이루어졌습니다.

    • spec.signerName를 입력해야 합니다. 에 대한 요청을 생성할 수 없습니다.kubernetes.io/legacy-unknown와 함께certificates.k8s.io/v1API

    • CSR을 계속 만들 수 있는kubernetes.io/legacy-unknown서명자 이름을certificates.k8s.io/v1beta1API

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

    • 인증서를 승인하려면 권한이 있는 사용자가kubectl1.18.8 또는 이후 버전입니다.

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

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

권한 Kind Namespace 이유
eks:certificate-controller Rolebinding kube-system 제어부의 서명자 및 승인자 기능에 영향을 줍니다.
eks:certificate-controller Role kube-system 제어부의 서명자 및 승인자 기능에 영향을 줍니다.
eks:certificate-controller ClusterRolebinding 모두 같은 특정 클러스터 기능에 영향을 미치는 서버 인증서를 요청하는 kubelet의 기능에 영향을 미칩니다kubectl execkubectl logs.

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

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

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

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

  • 수신 API가 일반 가용성에 도달했습니다. 자세한 내용은 단원을 참조하십시오.IngressKubernetes 설명서의 내용을 참조하십시오.

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

  • 이제 암호 및 ConfigMap 볼륨을 변경할 수 없도록 표시할 수 있으므로 클러스터에 많은 비밀 및 ConfigMap 볼륨이 있는 경우 API 서버의 로드가 크게 줄어듭니다. 자세한 내용은 단원을 참조하십시오.ConfigMapSecretKubernetes 설명서의 내용을 참조하십시오.

완전한 Kubernetes 1.19 변경 로그는https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.19.md.

Kubernetes 1.18

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

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

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

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

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

  • 구성 가능한 가로 포드 자동 크기 조정 동작 자세한 내용은 단원을 참조하십시오.구성 가능한 확장 동작 SupportKubernetes 설명서의 내용을 참조하십시오.

  • 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

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

중요
  • EKS는CSIMigrationAWS기능 플래그를 지정합니다. 자세한 마이그레이션 지침과 함께 향후 릴리스에서 사용할 수 있습니다. CSI 마이그레이션에 대한 자세한 내용은Kubernetes 블로그.

  • 클러스터를 1.16에서 1.17로 업데이트하면AWSFargate 포드는이kubelet부 버전은 1.16 이전 버전입니다. 클러스터를 1.16에서 1.17로 업데이트하기 전에 Fargate 포드를 재활용하여kubelet는 1.16으로 클러스터를 업데이트하기 전에 1.17로 업데이트해야 합니다. 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

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

중요
  • Kubernetes 1.16은 중단된 많은 API를 제거합니다. 클러스터를 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 주소를 네트워크 로드 밸런서에 할당하는 데 사용할 수 있습니다. 자세한 내용은 단원을 참조하십시오.다음을 사용하여 EIP 할당 SupportAWSNLBGitHub 문제.

  • 서비스 로드 밸런서용 Finalizer Protection은 현재 베타 버전이며 기본적으로 활성화되어 있습니다. 서비스 로드 밸런서 Finalizer Protection은 Kubernetes 서비스 개체 (예:네트워크 로드 밸런서서비스가 삭제될 때 파괴되거나 해제됩니다. 자세한 내용은 Kubernetes 설명서의 가비지 수집 로드 밸런서를 참조하십시오.

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

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

  • CustomResourceDefaulting 기능은 베타로 승격되고 기본적으로 활성화됩니다. 기본값은 apiextensions.k8s.io/v1 API를 통해 구조 스키마에서 지정할 수 있습니다. 자세한 내용은 Kubernetes 설명서의 구조 스키마 지정을 참조하십시오.

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

아마존 EKS 쿠버네테스 발매 일정

참고

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

Kubernetes 버전 업스트림 릴리스 Amazon EKS 출시 Amazon EKS 지원 종료
1.16 2020년 9월 8일 2020년 4월 30일 2021년 7월 25일
1.17 2019년 12월 9일 20202020년 7월 10일 2021년 10월 4일
1.18 2020년 3월 23일 2020년 10월 13일 2021년 11월
1.19 2020년 8월 26일 2021년 2월 16일 4월, 15일
1.20 2020년 12월 8일 2021년 5월 18일 2022년 6월
1.21 2021년 4월 8일 2021년 7월 9월, 2022일

아마존 EKS 버전 지원 및 FAQ

Kubernetes 커뮤니티가 지원하는 Kubernetes 버전에 따라 Amazon EKS는 언제라도 최소 4개의 프로덕션 수준 Kubernetes 버전을 지원할 수 있도록 최선을 다하고 있습니다. 지원 종료 전 최소 60일 이전에 지정된 Kubernetes 마이너 버전에 대한 지원 종료 날짜를 공시합니다. 새로운 Kubernetes 버전에 대한 Amazon EKS 자격 및 릴리스 프로세스로 인해 Amazon EKS에서 Kubernetes 버전 지원 종료일은 Kubernetes 프로젝트가 해당 버전 업스트림에 대한 지원을 중단하는 날짜 또는 그 이후가 됩니다.

FAQ

Q: 쿠버네티스 버전은 Amazon EKS에서 얼마 동안 지원됩니까?

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

Q: Amazon EKS의 Kubernetes 버전에 대한 지원이 종료되면 알림이 표시됩니까?

A: 예. 계정의 클러스터가 지원 종료에 가까운 버전을 실행 중인 경우 Amazon EKS는AWS Personal Health Dashboard약 12 Kubernetes 버전이 아마존 EKS에 출시 된 후 개월. 이 알림에는 지원 종료일이 포함되며, 이 날짜는 통지 날짜로부터 최소 60일이 소요됩니다.

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

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

Q: 지원 종료 날짜 이후에 제어판이 정확히 언제 자동으로 업데이트됩니까?

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

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

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

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

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

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

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

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

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

Kubernetes 프로젝트는 최대 두 개의 부 버전에 대한 제어 평면과 노드 간의 호환성을 테스트합니다. 예를 들어 1.20 제어 플레인에 의해 오케스트레이션될 경우 1.18 노드가 계속 작동합니다. 그러나 제어부 뒤에 지속적으로 두 개의 부 버전이 있는 노드가 있는 클러스터를 실행하는 것은 권장되지 않습니다. 자세한 내용은 Kubernetes 설명서의 Kubernetes Version and Version Skew Support Policy를 참조하십시오. 제어판과 노드에서 동일한 Kubernetes 버전을 유지하는 것이 좋습니다.

Q: Fargate 에서 실행되는 포드는 자동 클러스터 제어부 버전 업그레이드로 자동 업그레이드됩니까?

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

중요

제어 평면을 업데이트하는 경우 Fargate 노드를 직접 업데이트해야 합니다. Fargate 노드를 업데이트하려면 노드가 나타내는 Fargate 창을 삭제하고 포드를 다시 배포합니다. 새 포드는kubelet클러스터와 동일한 버전입니다.