기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
클러스터 업데이트
기존 클러스터를 새 Kubernetes 버전으로 업데이트하거나 클러스터에 대한 관리형 추가 기능을 구성할 수 있습니다.
Amazon EKS 클러스터 Kubernetes 버전 업데이트
Amazon EKS에서 새 Kubernetes 버전을 사용할 수 있는 경우 클러스터를 최신 버전으로 업데이트할 수 있습니다.
새 Kubernetes 버전으로 업데이트하기 전에 이 주제의 Amazon EKS Kubernetes 버전 및 업데이트 단계의 정보를 검토하는 것이 좋습니다.
새로운 Kubernetes 버전에는 중요한 변경 사항이 도입되었습니다. 따라서 프로덕션 클러스터를 업데이트하기 전에 새 Kubernetes 버전에 대해 애플리케이션의 동작을 테스트하는 것이 좋습니다. 새 Kubernetes 버전으로 이동하기 전에 애플리케이션 동작을 테스트하는 지속적 통합 워크플로를 구축하여 이를 달성할 수 있습니다.
업데이트 프로세스는 업데이트된 Kubernetes 버전으로 새 API 서버 노드를 Amazon EKS 시작하여 기존 노드를 대체합니다. 는 이러한 새 노드에서 네트워크 트래픽에 대한 Amazon EKS 표준 인프라 및 준비 상태 확인을 수행하여 예상대로 작동하는지 확인합니다. 이러한 검사 중 하나라도 실패하면 Amazon EKS는 인프라 배포를 되돌리고, 클러스터는 이전 Kubernetes 버전으로 남아 있게 됩니다. 실행 중인 애플리케이션은 영향을 받지 않으며 클러스터는 비결정적 또는 복구 불가능 상태로 남아 있지 않습니다. 는 모든 관리형 클러스터를 Amazon EKS 정기적으로 백업하며 필요한 경우 클러스터를 복구하는 메커니즘이 있습니다. AWS는 Kubernetes 인프라 관리 프로세스를 지속적으로 평가하고 개선하고 있습니다.
클러스터를 업데이트하려면 에서 클러스터를 생성할 때 제공된 서브넷의 무료 IP 주소가 2~3개 Amazon EKS 필요합니다. 이러한 서브넷에 사용 가능한 IP 주소가 없으면 업데이트가 실패할 수 있습니다. 또한 클러스터 생성 중에 제공된 서브넷 또는 보안 그룹이 삭제된 경우 클러스터 업데이트 프로세스가 실패할 수 있습니다.
가 고가용성 제어 플레인을 Amazon EKS 실행하더라도 업데이트 중에 사소한 서비스 중단이 발생할 수 있습니다. 예를 들어, API 서버를 종료하고 새 Kubernetes 버전을 실행하는 새로운 API 서버로 교체하기 직전 또는 직후에 API 서버에 연결하려고 하면 API 호출 오류 또는 연결 문제가 발생할 수 있습니다. 이 문제가 발생하는 경우 성공할 때까지 API 작업을 재시도하십시오.
Amazon EKS 는 클러스터를 업데이트할 때 Kubernetes 추가 기능을 수정하지 않습니다. 클러스터를 업데이트한 후 업데이트한 새 Kubernetes 버전에 대해 다음 표에 나열된 버전으로 추가 기능을 업데이트하는 것이 좋습니다. 이 작업을 수행하는 단계는 업데이트 절차에 포함되어 있습니다.
Kubernetes 버전 | 1.19 | 1.18 | 1.17 | 1.16 | 1.15 |
---|---|---|---|---|---|
Amazon VPC CNI 플러그인 | 1.7.5 | 1.7.5 | 1.7.5 | 1.7.5 | 1.7.5 |
DNS(CoreDNS) | 1.8.0 | 1.7.0 | 1.6.6 | 1.6.6 | 1.6.6 |
KubeProxy | 1.19.6 | 1.18.8 | 1.17.9 | 1.16.13 | 1.15.11 |
이전 표에 나열되지 않은 클러스터의 추가 기능을 사용하는 경우 클러스터를 업데이트한 후 해당하는 추가 기능을 최신 호환 버전으로 업데이트하십시오.
기존 클러스터 업데이트
클러스터 및 Kubernetes 추가 기능을 업데이트합니다.
기존 클러스터를 업데이트하려면
-
클러스터 제어 플레인의 Kubernetes 버전을 노드의 Kubernetes 버전과 비교합니다.
-
다음 명령으로 클러스터 컨트롤 플레인의 Kubernetes 버전을 가져옵니다.
kubectl version --short
-
다음 명령을 사용하여 노드의 Kubernetes 버전을 가져옵니다. 이 명령은 모든 자체 관리형 및 관리형 Amazon EC2 및 Fargate 노드를 반환합니다. 각 Fargate 포드는 자체 노드로 나열됩니다.
kubectl get nodes
새 Kubernetes 버전으로 제어 플레인을 업데이트하려면 클러스터의 관리형 및 Fargate 노드의 Kubernetes 마이너 버전이 제어 플레인의 현재 버전과 동일해야 합니다. 예를 들어, 제어 플레인이 버전을 실행 중1.18이고 노드 중 하나가 버전을 실행 중인 경우 제어 플레인의 Kubernetes 버전을 로 업데이트1.17하기 전에 1.18노드를 버전으로 업데이트합니다1.19. 또한 제어 플레인을 업데이트하기 전에 자체 관리형 노드를 제어 플레인과 동일한 버전으로 업데이트하는 것이 좋습니다. 자세한 내용은 관리형 노드 그룹 업데이트 및 단원을 참조하십시오자체 관리형 노드 업데이트. Fargate 노드의 버전을 업데이트하려면 노드가 나타내는 포드를 삭제하고 제어 플레인을 업데이트한 후 포드를 다시 배포합니다.
-
-
Amazon EKS 클러스터에서 포드 보안 정책 승인 컨트롤러가 기본적으로 활성화됩니다. 클러스터를 업데이트하기 전에 문제가 발생하지 않도록 업데이트하기 전에 적절한 포드 보안 정책이 있는지 확인하십시오. 다음 명령을 사용하여 기본 정책을 확인할 수 있습니다.
kubectl get psp eks.privileged
다음 오류가 표시되는 경우 계속하기 전에 기본 포드 보안 정책을 참조하십시오.
Error from server (NotFound): podsecuritypolicies.extensions "eks.privileged" not found
-
원래 Kubernetes
1.17
이하에 클러스터를 배포한 경우 CoreDNS 매니페스트에서 중단된 조건을 제거해야 할 수 있습니다.-
CoreDNS 매니페스트에 단어 만 있는 행이 있는지 확인합니다
upstream
.kubectl get configmap coredns -n kube-system -o jsonpath='{$.data.Corefile}' | grep upstream
출력이 반환되지 않으면 매니페스트에 행이 없으며 다음 단계로 건너뛰어 클러스터를 업데이트할 수 있습니다. 단어가
upstream
반환되면 줄을 제거해야 합니다. -
configmap을 편집하여 라는 단어만 있는 파일 맨 위 가까이에 있는 줄을 제거합니다
upstream
. 파일의 다른 값은 변경하지 마십시오. 줄이 제거되면 변경 사항을 저장합니다.kubectl edit configmap coredns -n kube-system -o yaml
-
-
eksctl
, AWS Management 콘솔또는 를 사용하여 클러스터를 업데이트합니다AWS CLI.중요 -
Amazon EKS는 가용성 높은 제어 플레인을 실행하므로 한 번에 한 마이너 버전만 업데이트할 수 있습니다. 이 요구 사항의 근거는 Kubernetes 버전 및 버전 스큐 지원 정책을
참조하십시오. 따라서 현재 버전이 이1.17고 를 로 업데이트하려는 경우 먼저 클러스터를 로 업데이트1.19한 후 에서 1.18 로 업데이트해야 1.18합니다1.19. -
업데이트하기 전에 관리형 및
kubelet
노드Fargate의 가 제어 플레인과 동일한 Kubernetes 버전에 있는지 확인합니다. 또한 자체 관리형 노드는 제어 플레인의 현재 버전보다 최대 한 버전 뒤에 있을 수 있지만 제어 플레인과 동일한 버전에 있는 것이 좋습니다. -
AWS Fargate 마이너 버전이 1.16 이전인
kubelet
포드가 있는 경우 클러스터를 1.16에서 1.17로 업데이트하지 못합니다. 클러스터를 1.16에서 1.17로 업데이트하기 전에 포드를 재활용하여 클러스터를 Fargate 1.16이kubelet
되도록 해야 합니다. -
1.16으로 업데이트하려면 먼저 배포된 리소스 중 일부를 업데이트해야 할 수 있습니다. 자세한 내용은 단원을 참조하세요.Kubernetes 1.16 업데이트 사전 조건.
-
-
kube-proxy
데몬 세트를 패치하여 클러스터의 리전 및 현재 Kubernetes 버전(이 예에서는1.19.6
).)에 해당하는 이미지를 사용합니다.Kubernetes 버전 1.19 1.18 1.17 1.16 1.15 KubeProxy 1.19.6 1.18.8 1.17.9 1.16.13 1.15.11 -
먼저 최신
kube-proxy
이미지를 검색합니다.kubectl get daemonset kube-proxy --namespace kube-system -o=jsonpath='{$.spec.template.spec.containers[:1].image}'
출력 예
602401143452
.dkr.ecr.us-west-2
.amazonaws.com/eks/kube-proxy:v1.18.8
-eksbuild.1 -
을 교체
kube-proxy
하여 권장 버전으로 업데이트
그리고602401143452
출력의 값을 사용하여us-west-2
클러스터의 권장1.19.6
kube-proxy
버전으로 바꿉니다. 이전 버전을 배포하는 경우1.19.6
를 바꿉니다.
을 사용한eksbuild.2
eksbuild.1
kubectl set image daemonset.apps/kube-proxy \ -n kube-system \ kube-proxy=
602401143452
.dkr.ecr.us-west-2
.amazonaws.com/eks/kube-proxy:v1.19.6
-eksbuild.2
-
(선택 사항) 동일한 클러스터에서 x86 및 Arm 노드를 사용 중이며 2020년 8월 17일 이전에 클러스터가 배포된 경우. 그런 다음 다음 명령을 사용하여 여러 하드웨어 아키텍처에 대한 노드 선택기를 포함하도록
kube-proxy
매니페스트를 편집합니다. 이는 일회성 작업입니다. 매니페스트에 선택기를 추가한 후에는 업데이트할 때마다 선택기를 추가할 필요가 없습니다. 클러스터가 2020년 8월 17일 이후에 배포된 경우kube-proxy
는 이미 다중 아키텍처가 가능합니다.kubectl edit -n kube-system daemonset/kube-proxy
다음 노드 선택기를 편집기의 파일에 추가한 다음 파일을 저장합니다. 편집기에서 이 텍스트를 포함할 위치에 대한 예제는 의 CNI 매니페스트
파일을 참조하십시오GitHub. 이렇게 하면 Kubernetes가 노드의 하드웨어 아키텍처를 기반으로 올바른 하드웨어 이미지를 가져올 수 있습니다. - key: "beta.kubernetes.io/arch" operator: In values: - amd64 - arm64
-
-
클러스터의 DNS 공급자를 확인합니다. Kubernetes 버전 1.10으로 생성된 클러스터는
kube-dns
를 기본 DNS 및 서비스 검색 공급자로 사용하여 출고되었습니다. 1.10 클러스터를 최신 버전으로 업데이트한 경우 DNS 및 서비스 검색CoreDNS에 를 사용하려면 를 설치하고 CoreDNS 제거해야 합니다kube-dns
.클러스터가 이미 를 실행 중인지 확인하려면 다음 명령을 CoreDNS사용합니다.
kubectl get pod -n kube-system -l k8s-app=kube-dns
출력의 포드 이름
coredns
에 가 표시되면 클러스터CoreDNS에서 이미 실행 중인 것입니다. 그렇지 않은 경우 설치 또는 업그레이드CoreDNS 를 참조하여 클러스터CoreDNS에 를 설치하고 권장 버전으로 업데이트한 다음 여기로 돌아가서 7-8단계를 건너뜁니다. -
클러스터
coredns
배포의 현재 버전을 확인합니다.kubectl describe deployment coredns --namespace kube-system | grep Image | cut -d "/" -f 3
결과:
coredns:v
<1.6.6>
해당하는 Kubernetes 버전에 대한 권장
coredns
버전은 다음과 같습니다.Kubernetes 버전 1.19 1.18 1.17 1.16 1.15 CoreDNS 1.8.0 1.7.0 1.6.6 1.6.6 1.6.6 -
현재
coredns
버전이 1.5.0 이상이지만 권장 버전보다 낮다면, 이 단계를 건너뜁니다. 현재 버전이 1.5.0 버전보다 낮은 경우,proxy
플러그인 대신forward
플러그인을 사용하도록coredns
의 Configmap을 수정해야 합니다.-
다음 명령을 통해 Configmap을 엽니다.
kubectl edit configmap coredns -n kube-system
-
다음 줄
proxy
의 를 로 바꿉니다forward
. 파일을 저장하고 편집기를 종료합니다.proxy . /etc/resolv.conf
-
-
최신
coredns
이미지를 검색합니다.kubectl get deployment coredns --namespace kube-system -o=jsonpath='{$.spec.template.spec.containers[:1].image}'
-
를 교체
coredns
하여 권장 버전으로 업데이트
,602401143452
, 및us-west-2
다음 명령에서 이전 명령의 출력을 포함한 . Replaceamazonaws.com을 위한 CNAME 별칭으로 구성해야 합니다
클러스터의 Kubernetes 버전에 권장되는 버전과 함께 을 실행한 다음 수정된 명령을 실행합니다.1.8.0
kubectl set image --namespace kube-system deployment.apps/coredns \ coredns=
602401143452
.dkr.ecr.us-west-2
.amazonaws.com
/eks/coredns:v1.8.0
-eksbuild.1 -
(선택 사항) 동일한 클러스터에서 x86 및 Arm 노드를 사용 중이고 2020년 8월 17일 이전에 클러스터가 배포된 경우 다음 명령을 사용하여 여러 하드웨어 아키텍처에 대한 노드 선택기를 포함하도록
coredns
매니페스트를 편집합니다. 이는 일회성 작업입니다. 매니페스트에 선택기를 추가한 후에는 업데이트할 때마다 선택기를 추가할 필요가 없습니다. 2020년 8월 17일 이후에 클러스터가 배포된 경우coredns
는 이미 다중 아키텍처가 가능합니다.kubectl edit -n kube-system deployment/coredns
다음 노드 선택기를 편집기의 파일에 추가한 다음 파일을 저장합니다. 편집기에서 이 텍스트를 포함할 위치에 대한 예제는 의 CNI 매니페스트
파일을 참조하십시오GitHub. - key: "beta.kubernetes.io/arch" operator: In values: - amd64 - arm64
-
Kubernetes에 대한 클러스터 Amazon VPC CNI 플러그인의 버전을 확인합니다. 다음 명령을 사용하여 클러스터의 CNI 버전을 출력합니다.
kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2
출력값은 다음과 같습니다.
amazon-k8s-cni:
<1.6.3>
CNI 버전이 1.7.5보다 이전인 경우 아래 명령을 사용하여 CNI 버전을 최신 권장 버전으로 업그레이드합니다.
-
미국 서부(오레곤) (
us-west-2
)kubectl apply -f https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/v1.7.5/config/v1.7/aws-k8s-cni.yaml
-
AWS GovCloud(US-East) (
us-gov-east-1
)kubectl apply -f https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/v1.7.5/config/v1.7/aws-k8s-cni-us-gov-east-1.yaml
-
AWS GovCloud (US-West) (
us-gov-west-1
)kubectl apply -f https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/v1.7.5/config/v1.7/aws-k8s-cni-us-gov-west-1.yaml
-
기타 리전의 경우
-
매니페스트 파일을 다운로드합니다.
curl -o aws-k8s-cni.yaml https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/v1.7.5/config/v1.7/aws-k8s-cni.yaml
-
Replace
다음 명령에서 클러스터가 있는 리전을 선택합니다. 그런 다음 수정된 명령을 실행하여 파일의 리전 코드(현재 )를 바꿉니다<region-code>
us-west-2
.sed -i -e 's/us-west-2/
<region-code>
/' aws-k8s-cni.yaml -
수정된 매니페스트 파일을 클러스터에 적용합니다.
kubectl apply -f aws-k8s-cni.yaml
-
-
-
(선택 사항) 클러스터를 업데이트하기 전에 Kubernetes Cluster Autoscaler를 클러스터에 배포한 경우 Cluster Autoscaler를 업데이트한 Kubernetes 메이저 및 마이너 버전과 일치하는 최신 버전으로 업데이트합니다.
중요 Arm에는 Kubernetes Cluster Autoscaler를 사용할 수 없습니다.
-
웹 브라우저에서 Cluster Autoscaler 릴리스
페이지를 열고 클러스터의 Kubernetes 메이저 및 마이너 버전과 일치하는 최신 Cluster Autoscaler 버전을 찾습니다. 예를 들어 클러스터의 Kubernetes 버전이 1.19이라면 1.19.으로 시작하는 Cluster Autoscaler 릴리스를 검색합니다. 다음 단계에서 사용할 수 있도록 해당 릴리스의 의미 체계 버전 번호 <1.19.n>
()를 기록합니다. -
다음 명령을 사용하여 Cluster Autoscaler 이미지 태그를 이전 단계에서 적어 둔 버전으로 설정합니다. 필요한 경우 교체
1.19
.n
고유 값을 가진 .kubectl -n kube-system set image deployment.apps/cluster-autoscaler cluster-autoscaler=k8s.gcr.io/autoscaling/cluster-autoscaler:v
1.19
.n
-
-
(GPU 노드가 있는 클러스터만 해당) 클러스터에 GPU가 지원되는 노드 그룹(예:
p3.2xlarge
)이 있는 경우 다음 명령을 사용하여 클러스터의Kubernetes용 DaemonSetNVIDIA 디바이스 플러그인을 업데이트해야 합니다. kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.8.0/nvidia-device-plugin.yml
-
클러스터 업데이트가 완료되면 노드를 업데이트된 클러스터와 동일한 Kubernetes 버전으로 업데이트합니다. 자세한 내용은 자체 관리형 노드 업데이트 또는 관리형 노드 그룹 업데이트. 섹션을 참조하세요. Fargate에서 시작된 새 포드에는 클러스터 버전과 일치하는
kubelet
버전이 있습니다. 기존 Fargate 포드는 변경되지 않습니다.
Kubernetes 1.16 업데이트 사전 조건
Kubernetes 1.15 changelog
1.16으로 업데이트APIs하기 전에 이를 변경하지 않으면 업데이트가 완료된 후 워크로드가 실패합니다.
-
NetworkPolicy v1에서는 리소스가
extensions/v1beta1
에서 더 이상 제공되지 않습니다. v1.8부터 사용 가능한networking.k8s.io/v1
API로 마이그레이션하십시오. 기존 유지 데이터는networking.k8s.io/v1
API를 통해 검색할 수 있습니다. -
PodSecurityPolicy v1에서는 리소스가
extensions/v1beta1
에서 더 이상 제공되지 않습니다. v1.10부터 사용 가능한policy/v1beta1
API로 마이그레이션하십시오. 기존 유지 데이터는policy/v1beta1
API를 통해 검색할 수 있습니다. -
DaemonSetv1에서는 , 배포, StatefulSet및 ReplicaSet 리소스가
extensions/v1beta1
,apps/v1beta1
또는apps/v1beta2
에서 더 이상 제공되지 않습니다. v1.9부터 사용 가능한apps/v1
API로 마이그레이션하십시오. 기존 유지 데이터는apps/v1
API를 통해 검색할 수 있습니다. 예를 들어, 현재apps/v1beta1
을 사용하는 배포를 변환하려면 다음 명령을 입력합니다.kubectl convert -f ./<my-deployment.yaml> --output-version apps/v1
참고 이전 명령은 현재 매니페스트 파일에 설정된 것과 다른 기본값을 사용할 수 있습니다. 특정 리소스에 대한 자세한 내용은 Kubernetes API 참조
.를 참조하십시오.
원래 Kubernetes 버전 1.11 이하로 Amazon EKS 클러스터를 생성했고 --resource-container
에서 kube-proxy
플래그를 제거하지 않은 경우 Kubernetes 1.16으로 업데이트DaemonSet하면 kube-proxy
오류가 발생합니다. 이 플래그는 더 이상 Kubernetes 1.16에서 지원되지 않습니다. 자세한 내용은 kube-proxy
Kubernetes 1.16 사용 중단 및 제거의 단원을
1.16으로 업데이트하기 전에 수행해야 할 작업
-
새 를 참조하도록 YAML 파일을 변경합니다APIs.
-
새 를 호출하도록 사용자 지정 통합 및 컨트롤러를 업데이트합니다APIs.
-
수신 컨트롤러, 지속적 전달 시스템 및 새 를 호출하는 기타 도구와 같은 타사 도구의 업데이트된 버전을 사용해야 합니다APIs.
클러스터에서 중단된 API 사용량을 쉽게 확인하려면
audit
제어 플레인 로그가 활성화되어 있는지 확인하고 를 이벤트의 필터v1beta
로 지정합니다. 모든 대체APIs는 1.10 이후의 Kubernetes 버전에 있습니다. 의 지원되는 모든 버전에 있는 애플리케이션은 Amazon EKS 이제 업데이트된 를 사용할 APIs 수 있습니다. -
클러스터가 원래 Kubernetes 1.11 이하 버전과 함께 배포된 경우 또는 kube-proxy 구성 파일(권장)을 사용하는
--resource-container=""
경우kube-proxy
에서 DaemonSet 플래그를 제거합니다. 의 현재 버전에 플래그kube-proxy
가 있는지 확인하려면 다음 명령을 입력합니다.kubectl get daemonset kube-proxy --namespace kube-system -o yaml | grep 'resource-container='
출력이 수신되지 않으면 아무것도 제거할 필요가 없습니다. 와 비슷한 출력이 수신
--resource-container=""
되면 플래그를 제거해야 합니다. 다음 명령을 입력하여 현재kube-proxy
구성을 편집합니다.kubectl edit daemonset kube-proxy --namespace kube-system
편집기를 열어
--resource-container=""
줄을 제거하고 파일을 저장합니다. 대신 kube-proxy 구성 파일을 사용하는 것이 좋습니다. 이렇게 하려면 다음 매니페스트를 다운로드합니다.curl -o kube-proxy-daemonset.yaml https://amazon-eks.s3-us-west-2.amazonaws.com/cloudformation/2020-06-10/kube-proxy-daemonset.yaml
다음 명령을 사용하여 클러스터의 엔드포인트를 확인합니다.
aws eks describe-cluster \ --name
<cluster-name>
\ --region<region-code>
\ --query 'cluster.endpoint' \ --output text출력값은 다음과 같습니다.
https://
<A89DBB2140C8AC0C2F920A36CCC6E18C>
.sk1.<region-code>
.eks.amazonaws.com다운로드한 파일을 편집합니다
kube-proxy-daemonset.yaml
. 에디터에서<MASTER_ENDPOINT>
( 포함<>
)를 이전 명령의 출력으로 바꿉니다. 을 클러스터의 리전<REGION>
으로 바꿉니다. 동일한 줄에서 필요한 경우 버전을 클러스터 버전으로 바꿉니다. 다음 명령을 사용하여 파일을 적용합니다.kubectl apply -f kube-proxy-daemonset.yaml
Amazon EKS 추가 기능 구성
추가 기능은 AWS 클러스터에 대한 관찰, 조정, 네트워킹 및 Amazon EKS 클라우드 리소스 통합과 같은 기능을 제공하는 Kubernetes
운영 소프트웨어입니다. 추가 기능을 직접 관리하거나, 플랫폼 버전 Amazon EKS 이상이 설치된 Kubernetes 버전 1.18을 실행하는 클러스터에
대해 Amazon EKS API를 통해 시작 및 버전을 eks.3
제어할 수 있습니다. Amazon EKS 추가 기능은 Kubernetes 버전 1.18 이상에서만 사용할 수 있는 Kubernetes 서버 측 적용 기능을 사용합니다. 자세한 내용은 Kubernetes 설명서의 서버 측 적용을
eksctl 또는 를 eksctl
사용하여 를 구성할 수 AWS Management 콘솔있습니다.
기존 클러스터에서 봉투 암호화 활성화
보안 암호 암호화를 활성화하면 Kubernetes 보안 암호는 선택한 AWS Key Management Service (KMS) 고객 마스터 키(CMK)를
사용하여 암호화됩니다. CMK는 대칭이어야 하고 클러스터와 동일한 리전에서 생성되어야 하며 CMK가 다른 계정에서 생성된 경우 사용자는 CMK에 액세스할
수 있어야 합니다. 자세한 내용은 https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html 개발자 안내서의 다른 계정의 사용자가AWS Key Management Service CMK를 사용하도록 허용을 참조하십시오. 기존 클러스터에서 봉투 암호화 활성화는 Kubernetes 버전 1.13
이상에서 지원됩니다.
봉투 암호화를 활성화한 후에는 비활성화할 수 없습니다. 이 작업은 되돌릴 수 없습니다.
클러스터에서 암호화를 활성화한 후 새 키로 모든 기존 보안 암호를 암호화해야 합니다.
eksctl
사용자가 보안 암호 재암호화를 자동으로 옵트아웃하도록 선택하지 않은 경우 다음 명령을 실행할 필요가 없습니다.
kubectl get secrets --all-namespaces -o json | kubectl annotate --overwrite -f - kms-encryption-timestamp="<time value>"
기존 클러스터에 대해 봉투 암호화를 활성화하고 사용하는 키가 삭제된 경우 클러스터에 대한 복구 경로가 없습니다. CMK를 삭제하면 클러스터가 영구적으로 성능 저하 상태가 됩니다.
기본적으로 create-key
명령은 계정의 루트 사용자에게 작업 및 리소스에 대한 액세스 권한을 부여하는 키 정책이 있는 대칭 키를AWS KMS 생성합니다. 권한을 축소하려면 kms:DescribeKey
API를 호출할 보안 주체의 키 정책에서 kms:CreateGrant
및 create-cluster
작업이 허용되는지 확인합니다.
Amazon EKS 는 키 정책 조건 를 지원하지 않습니다kms:GrantIsForAWSResource
. 이 작업이 키 정책 문에 있으면 클러스터 생성이 작동하지 않습니다.